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 ;-)

In reply to Re^3: Open sourcing perlmonks by Tanktalus
in thread Open sourcing perlmonks by BUU

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.