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. Of course you can work on a forked
version without signing such a disclaimer. If you want your changes to
the program to be incorporated into the version we distribute we need
such a disclaimer. Please contact the GNU Go maintainers, Daniel Bump
(bump@math.stanford.edu) and Gunnar Farneback (gf@isy.liu.se), 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. In particular it would be useful with test suites
   for common life and death problems. Currently second line groups, L
   groups and the tripod shape are reasonably well covered, but there
   is for example almost nothing on comb formations, carpenter's
   square, and so on. Other areas where test suites would be most
   welcome are fuseki, tesuji, and endgame.

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.

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. Speed up the tactical reading. GNU Go is reasonably accurate when
   it comes to tactical reading, but not always very fast. The main
   problem is that too many ineffective moves are tested, leading to
   strange variations that shouldn't need consideration. To improve
   this the move generation heuristics in the reading code needs to be
   refined. Some improvements should also be possible to obtain by
   tuning the move ordering.

8. 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.

9. Automatic search for missing patterns by analysing games from
   NNGS.