[issue] Tracker procedures [keywords=+has doc]

I really appreciate the efforts of several people in picking out issues and updating the tracker. There are some procedural issues I'd like to clarify. Don't worry too much about "conforming" exactly to procedure, but I would like to make some suggestions to make the tracker as useful as possible. (1) An issue should not be closed until you've confirmed that the issue is documented in the appropriate places. The mailing list archives do *not* count as documentation! (2) Missing, incorrect, or hard-to-find documentation *is* a bug in itself, even if the related behavior is acceptable. Do not close an issue as "not a bug" simply because somebody explained why it works that way on the mailing list. (3) If you find a patch labelled "committed" in the tracker, it's OK to assign the issue to the committer as committing a patch is a definite assumption of responsibility. However, by default you should bump status only as far as "assigned". (4) Be conservative about updating status. You should only push status to "committed", "documented", or "closed" if you understand the issue and any related patches or documentation well enough to have written them yourself. (That doesn't mean you need to be able to write it in English!) If you find yourself doing this more than once or twice, consider nominating yourself for XEmacs Reviewer. (No joke, we always need more reviewers!) (5) Keywords are important! Some keywords are workflow-related, the "has X" and "needs X" keywords in particular. The "has X" keyword means that such an item has been contributed, typically by the issue's creator, and needs to be confirmed before committing the change. The "needs X" keyword means that such an item must be developed and committed to resolve the issue. The "has X" and "needs X" keywords are *not* opposites. When a contributed X is verified and committed, the "has X" keyword should be removed. Similarly, when an X is developed and committed, the "needs X" keyword should be removed. Other keywords refer to XEmacs behavior, and are helpful to users in filtering out issues unrelated to their problem. At present, I've created the following keywords for general areas of XEmacs behavior: display, i18n, input/output, motion, performance, search, and security. Feel free to add more if appropriate, but as mentioned I'd like to keep the number small for now. Try to keep new keywords at a pretty high level of generality. Currently a majority of the keywords are tracker-related; I'm thinking about how to get them out of your face, but for now please bear with that. Thanks again for helping! _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta