                     GNU Go Task List


You can help make GNU Go the best Go program.

This is a task-list for anyone who is interested in helping with GNU
Go. If you want to work on such a project you should correspond with
us until we reach a common vision of how the feature will work!

A note about copyright. Before any code can be accepted as a part of
the official release of GNU Go, the Free Software Foundation will want
you to sign a copyright disclaimer. Please contact the GNU Go
maintainer, Daniel Bump (email: bump@math.stanford.edu), to get more
information and the papers to sign.

Below is a list of things YOU could work on. We are already working on
some of these tasks, but don't let that stop you. Please contact us or
the person assigned to task for further discussion.

//--------------------------------------------------------------
// long term issues
//--------------------------------------------------------------

These issues are strategic in nature. They will help us to improve the
playing strength of the program and/or enhance certain aspects of it.

1. If you can, send us bug FIXES as well as bug reports. If you see
   some bad behavior, figure out what causes it, and what to do about
   fixing it. And send us a patch! If you find an interesting bug and
   cannot tell us how to fix it, we would be happy to have you tell us
   about it anyway. Send us the sgf file (if possible) and attach
   other relevant information, such as the GNU Go version number. In
   cases of assertion failures and segmentation faults we probably
   want to know what operating system and compiler you were using, in
   order to determine if the problem is platform dependent.

2. Extend the regression test suites. 
   See the texinfo manual in the doc directory for a description of
   how to do this.

3. Tuning the pattern databases. This is a sort of art. It is not
   necessary to do any programming to do this since most of the
   patterns do not require helpers. We would like it if a few more Dan
   level players would learn this skill.

4. Extend and tune the Joseki database.

5. The semeai module is vastly in need of improvement. In fact, semeai
   can probably only be analyzed by reading to discover what
   backfilling is needed before we can make atari. Also, the semeai
   module should be able to change the status of dragons.

6. The connection analysis is today completely static and has a hard
   time identifying mutually dependent connections or moves that
   simultaneously threatens two or more connections. This could be
   improved by writing a connection reader, which like the owl code
   uses pattern matching to find a small amount of key moves to try.

7. The eye space evaluation knows about ``chimeras'', positions where
   one player can make two eyes in one move but the opponent also can
   destroy both in one move. This information is, however, currently
   not used in the higher levels of life and death reasoning. There
   are also other interesting positions, such as moves making an eye
   in sente (i.e. by threatening to make another eye), that would need
   some consideration. For inspiration you may wish to read the paper
   ``Eyespace Values in Go'' by Howard Landman. The paper is linked
   from the GNU Go development web page.

8. The eye space evaluation would also need to learn about local games
   ending in various kinds of kos.

9. Learn GNU Go to actually fight ko. Currently the reading can
   identify attacks or defenses as being contingent on ko, but it does
   not know anything about making ko threats.

10. In some positions GNU Go may report a group as alive or connected
    with a living group. But after the opponent has placed one stone
    GNU Go may change the status to dead, without going through a
    critical status. It would be nice if these positions could be
    identified and logged for later analysis of the GNU Go
    team. [Nicklas is thinking about this.]

11. Automatic search for missing patterns by analysing games from
    NNGS. [Nicklas has started to work on this.]

