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