in reply to Re: Open sourcing perlmonks
in thread Open sourcing perlmonks

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

Replies are listed 'Best First'.
Re^3: Open sourcing perlmonks
by Tanktalus (Canon) on May 28, 2005 at 16:04 UTC

    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]

        First off, intuitive is all in the eye of the beholder. Which is what I was saying about my perl project at work.

        Second, when I first wanted to do the vote patch, it did take me a few days to figure my way around things. If there was a document like this to explain even just the PmDev Nodelet, it would have been nice to have:

        #xxxxxx
        Node number being used to display the current document.
        = <node type>
        Type of document the above node is see this to see an explanation of all the node types.
        via <blah>
        I'm not sure what this is... here is a document that explains the different types
        Dump Fields
        Dumps the fields - you can only dump all the data about the current node if you have certain authorities which are ...
        ...
        ...
        Everything Bible
        Mandatory reading - too bad it's too new for the level of Everything we're using here.
        ...
        ...
        And, of course, there'd be an extra entry - "PmDev Help" - that would point to this doc. But, really, what I was referring to that I thought was not intuitive is just following around all the code. On one hand, it's great - it's hugely modular. On the other hand, a web browser is not the most conducive method for reading/writing code that is spread out all over the place ;-)

[reply]
Re^3: Open sourcing perlmonks
by Chady (Priest) on May 29, 2005 at 19:23 UTC
[reply]

In Section Perl Monks Discussion