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

[Stephen J. Turnbull]

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!