Stolen from http://subversion.apache.org/docs/community-guide/roles.html#patch-manager
Patch Manager $project usually has a Patch Manager, whose job is to watch the dev@ mailing list and make sure that no patches "slip through the cracks". This means watching every thread containing "[PATCH]" mails, and taking appropriate action based on the progress of the thread. If the thread resolves on its own (because the patch gets committed, or because there is consensus that the patch doesn't need to be applied, or whatever) then no further action need be taken. But if the thread fades out without any clear decision, then the patch needs to be saved in the issue tracker. This means that a summary of any discussion threads around that patch, and links to relevant mailing list archives, will be added to some issue in the tracker. For a patch which addresses an existing issue tracker item, the patch is saved to that item. Otherwise, a new issue of the correct type — '$DEFECT', '$FEATURE', or '$ENHANCEMENT' (not '$PATCH') — is filed, the patch is saved to that new issue, and the "patch" keyword is recorded on the issue. The Patch Manager needs a basic technical understanding of $project, and the ability to skim a thread and get a rough understanding of whether consensus has been reached, and if so, of what kind. It does not require actual $project development experience or commit access. Expertise in using one's mail reading software is optional, but recommended :-). The current Patch Manager is: $person <$contact> I really like the basic outline, but what I feel is missing, is the notion of watching $issuetracker. Often we have patches getting lost in there. So our patch manager should also look out for $PATCH issues and make sure they are followed up, or assigned, or whatever. Thoughts? Comments? Ideas? I happily welcome all of these. So long, i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE