The jobs file I created has been up on the web site for some time under the heading "Dev team responsibilities". http://www.xemacs.org/Develop/jobs.html But I get the feeling that many people listed in this file have not looked at the file. I am posting the file below. But please, if it's at all convenient, follow the link above instead! The tables don't turn out at all below. I ask that anyone who is contributing very much to XEmacs please scan the file for their name, and see if the assignments make sense. Please suggest any changes. The purpose of this file is not to rigidly force people to do something they don't want, but to make it easier to figure out who to contact in reference to a particular area, and to establish some people in backup positions to try to ensure that no major area of XEmacs gets wedged just because one person vanishes ben XEmacs JOBS Current version: 11/11/99 Maintainer: Ben Wing <ben(a)xemacs.org&gt; XEmacs Review Board Members The XEmacs Review Board has the authority to approve or veto any patch to XEmacs. Patches should be posted to xemacs-patches(a)xemacs.org. If someone vetoes your patch, you will receive e-mail from them, stating the veto but also describing exactly why the patch was vetoed, and how it should be changed in order to be acceptable. To qualify for membership to the Review Board, you should generally be someone who has put a lot of work into developing XEmacs for a long enough period of time that you are aware of the all of the basic ideas and issues in XEmacs and the XEmacs community. The current members of the XEmacs Review Board are: Andreas Jaeger <aj(a)xemacs.org&gt; Andy Piper <andy(a)xemacs.org&gt; Ben Wing <ben(a)xemacs.org&gt; Didier Verna <didier(a)xemacs.org&gt; Hrvoje Niksic <hrvoje(a)xemacs.org&gt; Jan Vroonhof <jan(a)xemacs.org&gt; Jareth Hein <jareth(a)xemacs.org&gt; Jonathan Harris <jonathan(a)xemacs.org&gt; Kyle Jones <kyle(a)xemacs.org&gt; Martin Buchholz <martin(a)xemacs.org&gt; Michael Sperber <mike(a)xemacs.org&gt; Olivier Galibert <galibert(a)xemacs.org&gt; Steve Baur <steve(a)xemacs.org&gt; Vin Shelton <acs(a)xemacs.org&gt; Primary Positions Primary positions are important enough that they should not allowed to remain unfilled for any length of time. Detailed descriptions of primary positions appear below. Position Primary Secondary Beta Release Maintainer Martin Buchholz <martin(a)xemacs.org&gt;, Steve Baur? <steve(a)xemacs.org&gt; Binary-Kit Coordinator Jason Mastaler <jason(a)xemacs.org&gt;, Stable Release Maintainer Vinnie Shelton <acs(a)xemacs.org&gt; Meta-Maintainer Ben Wing <ben(a)xemacs.org&gt; Core Patch Tender Jan Vroonhof <jan(a)xemacs.org&gt; Andy Piper <andy(a)xemacs.org&gt;, Martin Buchholz <martin(a)xemacs.org&gt; Package Patch Tender Andreas Jaeger <aj(a)xemacs.org&gt; Martin Buchholz <martin(a)xemacs.org&gt; CVS Manager Jareth Hein <jareth(a)xemacs.org&gt; Martin Buchholz <martin(a)xemacs.org&gt; Postmaster Jason Mastaler <jason(a)xemacs.org&gt; Martin Buchholz <martin(a)xemacs.org&gt; Webmaster John S Jacobs Anderson <jacobs(a)xemacs.org&gt; Marcus Thiessel <marcus(a)xemacs.org&gt; Bug Tracker Gunnar Evermann <gunnar(a)xemacs.org&gt; Japanese Liaison Stephen Turnbull <stephen(a)xemacs.org&gt; [NOTE: I put a question mark by Steve Baur's name because it is not clear what his status is currently. Hopefully this will be resolved soon.] Documentation Positions: All of the documentation is listed here. Some positions are listed without primaries. It would be really nice if there were people actively maintaining each of these documentation areas, but slippage here is not so catastrophic. Position Primary Secondary Lisp Reference Manual Martin Buchholz <martin(a)xemacs.org&gt; XEmacs User Manual Martin Buchholz <martin(a)xemacs.org&gt; Internals Manual Martin Buchholz <martin(a)xemacs.org&gt; Ben Wing <ben(a)xemacs.org&gt; PROBLEMS Martin Buchholz <martin(a)xemacs.org&gt; FAQ Martin Buchholz <martin(a)xemacs.org&gt; NEWS Hrvoje Niksic <hrvoje(a)xemacs.org&gt; Martin Buchholz <martin(a)xemacs.org&gt; README Ben Wing <ben(a)xemacs.org&gt; Martin Buchholz <martin(a)xemacs.org&gt; Coding Projects Position Primary Secondary General design issues Ben Wing <ben(a)xemacs.org&gt; Hrvoje Niksic <hrvoje(a)xemacs.org&gt;, Kyle Jones <kyle(a)xemacs.org&gt;, Olivier Galibert <galibert(a)xemacs.org&gt; Coding Standards Martin Buchholz <martin(a)xemacs.org&gt; Portable Dumper Olivier Galibert <galibert(a)xemacs.org&gt; Minimal tagbits implementation Kyle Jones <kyle(a)xemacs.org&gt; Windows support Andy Piper <andy(a)xemacs.org&gt;, Jonathan Harris <jonathan(a)xemacs.org&gt; Cygwin support Andy Piper <andy(a)xemacs.org&gt; Configure support Martin Buchholz <martin(a)xemacs.org&gt; Mule Ben Wing <ben(a)xemacs.org&gt;, Martin Buchholz <martin(a)xemacs.org&gt;, Olivier Galibert <galibert(a)xemacs.org&gt;, Stephen Turnbull <stephen(a)xemacs.org&gt; GUI support Andy Piper <andy(a)xemacs.org&gt; Redisplay Andy Piper <andy(a)xemacs.org&gt; Customize Jan Vroonhof <jan(a)xemacs.org&gt; GPM support William Perry <wmperry(a)xemacs.org&gt; The package system Steve Baur <steve(a)xemacs.org&gt; Michael Sperber <mike(a)xemacs.org&gt; Job Descriptions For Primary Positions Beta Release Maintainer The beta release maintainer is the primary maintainer for XEmacs, and serves as the de-facto spokesman. His responsibilities are (a) to put out new beta releases on a regular basis, i.e. at least every one to two weeks (depending on activity), (b) to go out of his way to be responsive to e-mail sent to him and communicative about and interested in important issues in all major aspects of XEmacs, and (c) to decide when it's time to do an external release. At this point, he is responsible for initiating a code freeze and assuming quasi-dictatorial power over the development process, doing whatever it takes to ensure that a relatively stable, bug-free release gets put out in a timely fashion. If some important job is not getting done during the critical pre-release period, it is ultimately the duty of the beta release maintainer (in conjunction with the meta-maintainer) to ensure that this gets done, for example, by finding somebody else who is willing to take over this position, or (last resort) doing the job himself. During periods when an external release is not happening, the beta release maintainer goes back to being a relatively low-key position, responsible primarily just for putting out regular beta releases. It is imperative, however, that the beta release maintainer continue to be as responsive as possible to e-mail sent to him, because he is the de-facto spokesman and is looked up to as the one providing overall guidance for the project. If he fails to respond to email, he will create the impression that the entire project is in disarray. Binary-Kit Coordinator The binary-kit coordinator is responsible for organizing the preparation, release, and distribution of pre-compiled XEmacs software based on the stable branch. Stable Release Maintainer The stable release maintainer is responsible for putting out `stable' releases of the code. These are generally small updates to previous external releases. Once a major external release happens, the development tree is forked, with one branch becoming the stable branch, the other the development branch. It is from this stable branch that stable updates happen and it is the stable release maintainer's responsibility to oversee this branch, decide which patches belong in this branch, and do whatever else is necessary to put out a stable update. Meta-Maintainer The meta-maintainer is responsible for defining and managing the separation of XEmacs duties into spheres of responsibility or "jobs". He maintains the list of jobs, which lists the jobs, their descriptions, and the current primary and secondary jobholder(s) for each of these jobs. (Generally, the primary actually does the work of the job, but if the primary becomes derelict in his duties, for example by simply disappearing and becoming unresponsive to email contact, the secondary steps in as the "acting jobholder", until the primary returns (along with assurances that he will not just disappear again) or another primary is found.) The meta-maintainer is also responsible, along with the beta release maintainer, for filling empty positions and for noticing when a job is not getting done. During pre-release cycles, the beta release maintainer may take the most active role in filling positions; during other periods, the meta-maintainer primarily assumes these duties. Core Patch Tender The core patch tender's responsibility is to make sure that no patch to the core of XEmacs falls through the cracks. Every core patch posted to XEmacs either needs to be approved and then applied, or vetoed with a suggestion for how to modify the patch so that it is acceptable. The core patch tender is responsible for making sure that this happens. If a patch is posted and is neither approved nor vetoed within a two-week period, the core patch tender needs to step up and make inquiries to determine what should be done with the patch. If a patch is posted and then vetoed with suggestions for improvements, but no improved patch is submitted within a week or so, the core patch tender needs to make inquiries to the patch submitter to see if he can finish up getting the patch up to snuff, and if not, the reviewers need to be contacted again. Package Patch Tender The package patch tender's job is analogous to the core patch tender's, except that it applies to the Lisp packages that are, in some sense, external to XEmacs itself. His job may be complicated by the fact that packages may have active maintainers who may not be directly involved in XEmacs development. In that case, he may need to track down the active maintainer and try to get him to accept the patch. The package patch tender also needs to create and maintain a list of all the packages that are part of the full XEmacs development tree. For each package, this list should specify the package's home page (if any), the maintainer and his contact address, any mailing lists devoted to the package, the number of the latest release and where to get it, the corresponding XEmacs package release number, and (if the information is available) a subjective judgment as to how well the package is currently being maintained, from 0 (package is obsolete, no one has maintained it in years) to 5 (package contains an active, well-organized development effort with regular releases, mailing lists, a web site, etc.). CVS Manager The CVS manager is responsible for all CVS issues related to XEmacs.This includes, for example, the CVS trees for the core and thepackages, and the CVS web interface. This includes the important but thankless task of doing backups. Postmaster The mailing list manager is responsible for maintaining the XEmacs mailing lists. Webmaster The webmaster is responsible for maintaining the www.xemacs.org web site. Bug Tracker The bug tracker is responsible for keeping track of all the bugs that have been posted anywhere, either to xemacs-beta, comp.emacs.xemacs, or similar sources. Properly speaking, they need to be kept in a database, assigned priorities, severities and owners, and managed in the standard way that bugs are managed. Unfortunately, we don't currently have such an infrastructure, so it's the current responsibility of the bug tracker to keep track of the bugs in any way possible (e.g. just a simple list), with the number one cardinal rule being: NO BUG MAY FALL THROUGH THE CRACKS. Every bug that gets reported through any standard means needs to end up on the list, along with as much information as possible from the bug report: The name of the person reporting the bug, the version number of XEmacs being run, the circumstances and behavior of the bug, etc. etc. etc. The secondary responsibility of the bug tracker is to investigate a workable bug-tracking system for XEmacs. I know that the Samba project has such a system in place, so we should just be able to use theirs, for example. Japanese liaison The Japanese liaison is responsible for assisting in communications between Japanese and non-Japanese XEmacs developers. Very few XEmacs developers are fluent in both English and Japanese. -- In order to save my hands, I am cutting back on my responses, especially to XEmacs-related mail. You _will_ get a response, but please be patient. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding.