
[[title
                      Instructions for Bug Czars
]]


* Introduction

  As a bug czar, your main job is to accept bug reports, boil them
  down to an essential content, and store that essential content
  in this tree.

  Bug reports can come from multiple sources.   You might be reading
  them from a `bug-arch' mailing list;  you might find them informally
  described on `gnu-arch-users' or `gnu-arch-dev';  you might even
  simply find some yourself or hear of some in casual conversation.

  Regardless of the source, your job is to put the but report here, in
  a simple but neatly organized format, so that programmer's working
  on arch can examine and respond to the report.



* The Basic Action

  To enter a new bug, you must chose a /"short name"/ for the bug.
  The short-name is both a short-hand when speaking about the bug
  and a filename stem for files related to the bug.

  For example, let's suppose the bug report is about the `munge'
  command:  it crashes if passed the `--tweak' option.   A plausible
  short-name for the bug is:

  [[tty
		munge-tweak-crash
  ]]

  To enter the bug, you must have an up-to-date copy of this tree.

  Copy the file `Template' from this directory to the sub-directory 
  `all-bugs', naming the copy after the short name with the suffix
  `.bug'.   At the same time, add a tag for the `.html' file that
  will be created for this bug:

  [[tty
  		% cp Template all-bugs/munge-tweak-crash.bug
  		% tla add all-bugs/munge-tweak-crash.html
  ]]

  You must then edit the new file to enter information about the bug,
  run an update script to rebuild the HTML pages which report on the
  status of all bugs, and commit your changes.  You can update the
  HTMl pages by running:

  [[tty
		% sh =meta-update
  ]]

  in this directory.   You must have `awiki' in your path.

  It is recommended (as always) that you run at least `tla tree-lint'
  and ideally also `tla changes' before committing.

  The file <"Template-instructions.txt" --
  Template-instructions.html>, in this directory, contains step by
  step instructions for filling out a bug report.

  At the end of a "shift" as Bug Czar, you should update the copy of
  of this tree on the web so that the newly updated HTML pages are
  visible.


* Go the Extra Mile When You Can but Don't Spend Much Time on It

** For the Users

  Whenever you can, give direct, accurate, and constructive feedback
  to the submitters of any bug you enter, at the time you enter it.
  If the bug looks high priority, let the user know you recognize
  that.  If you aren't sure it's really a bug, tell the user that and CC
  the developers.

** For the Programmers

  Formatting a bug report carefully and neatly is a great help to the
  next person who has to study it, usually a programmer.

  If you receive multiple reports that are closely related, combine
  them when you can in a single `.bug' file.


** But not Extravagantly

  Going the extra mile is great when you can but, don't lose site of
  the bigger picture and spend /too/ much time processing bugs.




[[null
  ; arch-tag: Tom Lord Sun Feb  6 14:51:03 2005 (bugs/INSTRUCTIONS)
]]

