Re: [Bug-gnubg] A wekly reminder?!

[Jim Segrave]

Slightly expanded for people's perusal

1. Subscription

  You may always change your subscribtion options at
  http://mail.gnu.org/mailman/listinfo/bug-gnubg. This is also the
  place for unsubscribing.

2. Subject

  Please use a meaningful subject. It is not helpful to use " bug
  found" or "gnubg" as a subject. If you really want to be smart put
  something like:

bug: 
feature request:
position:
documentation:
compiling error:

  or a similar meaningful categoray at the front of your subject.

  For example:
  
Subject: bug: gnubg crashes when loading Snowie .mat file

3. Bug reports

  Much as the devopers would like to see nothing but praise and
  astonishment from the users, bugs do occur and they form one of the
  main purposes of this list. A good bug report makes it much easier
  for a developer to find and (one hopes) fix a problem. What's
  needed:

  A. Which software you are running:

  You need to report what version of gnubg you are running and the
  date on which it was built - gnubg changes rapidly and your bug may
  already have been reported and fixed. So please give some
  information like:

  gnubg 0.14-devel built on 2003/07/25 running on Windows XP
 
  Click on the Help button on the board to get a pop-up with the
  'gnubg 0.14-devel' or whatever. Your system should be able to tell
  you the date of the main file - gnubg.exe (Windows) or just plain
  gnubg (Unix/Linux). It helps to know if you are running a Windows
  machine, a Mac, a Linux or another Unix system. While the source
  code for gnubg is the "same" for each system, there are differences
  and some bugs only show up on one or another platform.

  Usually there's little point in giving a hardware description unless
  it's likely to be directly relevant to your problem. So if you are
  having display corruption problems or sound problems you might want
  to give a brief overview of your hardware.

  B. A short description of the problem. Try to keep it brief, but not
  at the expense of improtant information. If gnubg crashes when you
  do something, then if there's an error message, the developer's want
  to know what the message said. If there is no error message, that's
  relevant as well. What is not helpful is being told "When I do this
  and that, the program prints some kind of error message and then exits".

  Be sure to include why you think it's a problem. Sometimes it's
  obviously wrong - gnubg crashes or locks up and won't do anything
  further. But some bug reports are questions about gnubg's evaluation
  of a position and it may be that you simply didn't realise why it's
  probably the correct evaluation (forgetting about the Jacoby rule,
  failing to notice your opponent already has a man off, so you won't
  get a gammon/backgammon, not realising how likely you are to be
  doubled out on the next move, etc. Don't worry about making a
  mistake in public, various developers have made all of the previous
  mistakes before. 

  Along with all this it helps to know if the problem 1) happens every
  time you do some particular thing or 2) happens every once in a
  while but always when you've performed some particular action or 3)
  seems to happen with no apparent pattern.

  C. If at all possible, give a simple way of seeing the problem you
  are reporting. For example, giving a matchid and position ID (they
  are displayed on the board), then telling us what move you made
  which caused the problem makes it easy for someone to repeat the
  problem and find the cause. Sometimes this isn't possible, but when
  it is it makes getting a bug fixed *many* times easier.

  D. There are some cases where the only way to really illustrate the
  problem is to examine a full match file or a large output file such
  as an entire game in HTML. In those cases, please don't post the
  match or HTML file to the list, describe the problem and expect that
  one or more developers will ask you to mail them a copy privately. 

4. Formatting

  Please don't send HTML e-mails. Many readers of this list use
  mail-clients which don't support HTML mail. Some may use anti-spam
  filters which reject all mail which is in HTML, so they'll never
  even have a chance to see what you have to say.

  A few e-mail programs like Outlook Express send HTML by default (or
  send a copy in plain text and a second copy in HTML)It's easy to
  change this in the option menu. 

  Use the enter key to wrap lines at no more then 75 characters. This
  helps other readers whose mail client may not wrap lines and also
  makes it easier to quote your text when replying.

5. Signature

  Your signature should begin with a line on its own containing only
  two hyphens (minus signs) followed by a space. Good mail clients
  will recognise this as the start of the signature and will
  automatically remove the signature when composing a reply
  After that line, your signature should not be more than four more
  lines of text.

  For example:

-- 
    The world is so full of a number of things
    I'm sure we could all be as happy as kings
    And you know how happy kings are' James Thurber
Al Fansome (address@hidden)                  www.gnubg.org

 
  If you quote another posting, it's _not_ necessary to quote the
  signature also.

  Do *not* include graphics, logos, pictures or other strange images
  as part of your signature.


6. Quoting

  The object of quoting is to make it possible for a reader to see an
  exchange of e-mails as though they were listening to a
  conversation. The reader should normally not need to go back and
  read a previous e-mail to see what point you are replying to, nor
  should they need to scroll backwards and forwards in your e-mail to
  find the different parties to a conversation. 

  Ideally when responding to someone else's e-mail, you should quote
  only enough of that person's e-mail to let the reader know *what* the
  other person wrote that you are responding to. Remove any other text
  that isn't relevant to your reply. Some topics can develop into threads
  of 10 or more e-mails and no-one wants to read the same irrelevant
  portions 10 times while following the thread.

  If you are responding to more than one topic in someone else's
  e-mail, then quote each of those topics separately and put your
  responses immediately below the associated topic. 

  Please avoid top quouting and full qouting. What do we mean? A few
  MS Windows e-mail programs (like Outlook Express) always quote the
  original e-mail in full at the bottom of the reply and put your
  cursor at the top when you begin composing a reply. The result is
  referred to as top quoting - all the responses come at the top and
  the reader has to scroll down to see what it is you are replying
  to. Failure to remove those portions of the original e-mail to which
  you are not replying is referred to as full quoting. In the worst
  case, a lengthy exchange of e-mails could end up with 10 or 15
  copies of the original e-mail. Top quoting and full quoting from some
  of the most annoying behaviours in mailing lists. 

  With "good" quoting you will greatly enhance the readibility of your
  e-mail. Here is an example of qouting as it should be done:

| Adam  wrote:
| 
| Here is a bunch of text by someone. This was originally a 25 line
| paragraph, but [snip irrelevant portion]
|
| Now you, as the author, respond to those points, right here.
| If you have more to quote, do so:
|
| Someone still had a couple more points to which you wanted to
| reply, so you quote them [but still snip unneded stuff]
|
| and respond to it.
|
| Your sig then typically follows (but DON'T quote Someone's sig,
| unless that is what you are responding to... and if so, you'd better
| make sure that it is relevant to this mailing list, or that it
| is a miniscule fraction of your otherwise completely on-topic post.)

  When you answer to a posting, please use _always_ the "reply" or
  "reply to list" button. This will keep a thread readable like

| ---- original posting A
| -------| direct answer to A (B)
| ---------------direct answer to B (C)
| --------------------| direct answer to C
| -------| direct answer to A (D)
| ----------------direct answer to D


7. Attachments

  No. Don't send attached files to this mailing list. Exception: You may
  be asked to do so (mostly in a direct e-mail, very seldom to this mailing
  list.

-- 
Jim Segrave           address@hidden