in reply to Open sourcing perlmonks

Hmmm... I think this is a reasonable example - which shows many aspects of where this thread could go, and I get an advantage as the pmdevil who was involved ;-)

First off, it's incredibly trivial to become a pmdev member. Really. You make it sound difficult - it isn't. It does take some willpower to justify to oneself that you'll do something with it, but it doesn't seem, from looking at the list, that actually producing a patch is a requirement. I'm betting the promise to produce a patch isn't strictly required either.

What this means is that the source code to PM is already nearly open source - you pretty much just have to ask to gain access. What is unfortunate is that you can't just grab a tarball of the whole thing and play with that, but even the GPL doesn't really say how an interested party may receive the source code, only that interested parties must be able to do so. Signing up for pmdev merely says you're interested. (I'm not saying that PM is GPL'd, either, so they are allowed to say no.)

The real issues are, based on my limited experience, and a number of /msg's I've received:

  1. A desire to do something. Generally speaking, people fix their own itches. In the commercial world, this means that eating and a roof over one's head is an itch, for which one sells their programming expertise to solve someone else's itch. In the volunteer world, this means that they solve the problems that affect themselves first. Thus, if it itches you, you're the most likely person to scratch it.
  2. An ability to do something. Even once you write the patch(es), you need to convince someone that it's a good, useful patch. There is generally one person who will point out holes, whether that's coding, style, or usability, and block significant numbers of patches from people he doesn't know/trust. (If this is not the case, he's masking it very well, in my experience. As well as a number of others whose names/aliases I won't reveal.)
The bottom line to me, having overcome the first hurdle, is that certain gods have a very tight hand in keeping changes from going in. At least, that's the perception others will get from dealing with him. I'm actually 100% positive that he believes he's keeping the chaos from grabbing hold of PM, leaving us with an ever-changing (the definition of instability) web site that will drive people away. At least on his usability comments. On his technical comments (code, style), I firmly believe that he knows more of the code than most other pmdevils, thus he probably is right about those anyway. (Although I'll continue to disagree about "unless is confusing".)

So, on one hand, there are too few pmdevils submitting patches, yet on the other, there is a subconscious effort to stymy patches by anyone other than a select few (who generally can apply their own patches). It's the latter which demoralises the former, and it ends up in a violent circle which I cannot offer advice on how to fix.

Replies are listed 'Best First'.
Re^2: Open sourcing perlmonks
by demerphq (Chancellor) on May 28, 2005 at 11:06 UTC

    Tanktalus I feel that I owe you an explanation. As you know your vote patch has been applied for some time in a test configuration. As I am one of the people who experiences its effect I should say why I havent promoted it to a full patch: I am not sure if the patch is healthy for the site. For mature users seeing the downvotes is nice. But i find myself grumbling about certain things I see which makes me think that others will go far beyond grumbling. Its for this reason that I have been reluctant to promote the patch.

    Also you need to understand that this glacial pace (which I know to be frustrating) also effects stuff the gods themselves have written. I have written things that will never see the light of day here, I have written things that are in production but remain totally undocumented and thus for all intents and purposes non-existant. There are various reasons for this but who posted the patch is NOT one of them, being a god here only slightly raises your chance that a non-trivial patch will be accepted by the community as appropriate and needed.

    Basically I see it like this, you can break patches down into three classes:

    1. Controversial -- Patches that touch on controversial subjects like voting and experience. These will always be difficult patches to get into production just because of their potential to stir up trouble.
    2. Infrastructure -- Anything that is heavily used or involves multiple patches and table updates is going to take a while to get into production. Its difficult and time consuming to apply and test patches like this, and to do things like this properly takes considerable care and understanding of the sites behaviour and design to do right. Infrastructure changes also require heavy testing, and for one reason or another we still have problems in this area.
    3. Minor Feature or Enhancement -- These usually go in almost instantly. Assuming it doesnt fall into one of the other categories generally all this takes is to make a patch and ask somebody to apply it. Its quite possible that the code will be totally rewritten prior to being applied however the presence of an initial patch almost always results in something equivelent being applied. Cabal Matrix is an example of this. Arunbear had the idea, and put together an initial implementation, ysth rewrote part of it, and i added some more changes as well. But it got applied quite quickly.

    Lastly there is one thing that a patch producer needs to do: champion the patch and idea the patch represents. The gods are human, with various interests and responsibilities meaning we are just as forgetful as the next guy. If we havent applied your patch it may not be because of any particular reason it may simply be because we have forgetten that there is a patch that needs to be applied. Reminding us through /msg's or through PMD's about the proposed change can really help. With controversial nodes, PMD's discussing the state of the patch and the issues it raises can help the community come to a collective decision about the proposal.

    Anyway, the fact is that most patches that I see remain unapplied are in the first two categories. For some reason many peoples first patch tends to fall into one of the two (most often the reason being they are "controversial" patches). Also a potential patcher needs to understand that rejecting patches is part of our job as gods. However i personally beleive that the person posting the patch is owed an explanation as to why, and if one isnt forthcoming I beleieve the poster should just ask.

    ---
    $world=~s/war/peace/g

[reply]

      Darn. Seems like I should have been more explicit. ;-)

      For starters, I am not looking for an explanation - I'm looking for a pmdev-guide (tye assures me there is one, but I've gone back in the wiki a fair bit without finding one or a link to one). One that explains what is expected from those in the pmdev, one that explains the rules of the gods on applying patches, one that shows this relationship. One that is also dynamic - as the rules are changed (whether evolution or revolution), somewhere for the appropriate god to update. One that can explain to the non-pmdevil what to expect should s/he put his/her name in the hat. Because I know at least one pmdevil who is yet to know what it's like to submit a patch; because I know I didn't really know what to expect when I offered to write that patch.

      This would also help the gods who are less than becoming in their manner or style of rejection. It's much less personal to point at a prewritten, yet living and dynamic, document than to gruffly say (paraphrasing here) "I don't like it, I'm not approving it." It will help promote writing patches because it gives a guideline to all. You get better behaviour out of people when they can predict, with 100% accuracy, the consequences of their actions. In this case, if the pmdevil can predict, with 100% accuracy, whether their patch will be accepted or not, they can then start producing acceptable patches. Or they can know whether to expect some sort of reticence, and provide reasonable explanation along with their patch.

      This should be a document that is referred to often - to the point where it's a common-knowledge document, like How (Not) To Ask A Question seems to be. Rather than pointing petitioners such as bofh_of_oz or artist (or even myself) to become pmdevils themselves to write and submit patches, they should be referred to this document, just as we point people who post bad questions to jeffa's How (Not) To Ask A Question. Because, as should be evident by the small number of people who are actually becoming pmdevils vs merely complaining about feature requests, we can't read the gods' minds no matter how much you may want us to.

      Now, as for actually initiating this document, yeah, yeah, become a member of the SDC and write it myself. I know. :-)

      On to a slight change in topic - below you wrote:

      Once this has been done reviewing the code is fairly easy and IMO mostly intuitive.
      I find this very entertaining. :-) To be honest, intuitive is only because you've been doing it a long time. I find the 15,000-line behemoth I designed/wrote at work to be fairly intuitive, too. The poor guy who is taking it over from me isn't so sure ;-)

[reply]

        To be honest, intuitive is only because you've been doing it a long time.

        Well, im not sure that I agree with you. I found the PmDev Nodelet to be quite intuitive. It shows you the basic data on the type of node you are viewing, what display page associated to that nodetype was used for rendering the page, it give you ways to view the code of the node being rendered if its relevent, abilities to show the container structure, view the type heirarchy, view lists of nodes by type and to view the master list of site patches. All of this on top of being able to search the full codebase of the site, (with grep capabilities) and links to offsite documentation which although not specific to PM is still very useful.

        Im not sure what of the above isnt intuitive. Maybe if I did I could document it better. :-)

        ---
        $world=~s/war/peace/g

[reply]
[reply]

In Section Perl Monks Discussion