                          GNU Go Task List

You can help make GNU GO the best Go program.

This is a tasklist 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 you we reach a common vision of how the feature will work!

If your revisions are extensive, the Free Software Foundation may
want you to sign a copyright disclaimer before they can be part of
the official release. 

Here is a list of things YOU could work on. Two of these tasks
are marked TAKEN because someone has already started thinking
about them.

1. Convert documentation to texinfo. We can maintain the 
documentation but could use some help converting it.

2. 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 an sgf file.)

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

4. Write a ``compiler'' for helper functions so that writing them
is less tedious. (TAKEN)

5. Write a module for detecting moyos, and for generating moves that
expand or reduce moyos.

6. Joseki Library. A small Joseki library, possibly a collection
of sgf files with move values in comments, which could be compiled
into input for mkpat, then turned into a pattern database. There's
a programming problem here as well as the problem of accumulating
such a database.

7. Obtain a more realistic estimate of whether an eye space or open
eye space is likely to yield two or more eyes.

8. Amalgamation of dragons can definitely be improved. We need a
database of connections.

9. An algorithm which looks at the ``footprint'' of a group on
the side of the board and estimates whether it likely has
sufficient size to get two eyes or not.

10. Semeai module is vastly in need of improvement. In fact,
semeai can probably be only analyzed by reading to discover
what backfilling is needed before we can make atari.

11. Our current approach to life and death is very ad hoc. It
is good enough for the time being but eventually will have to
be scrapped in favor of something better.

12. Figure out what we should do about ko fights. This may
require a paradigm shift in the reading code---the routines
in reading.c recognize the outcome of a read as alive or
dead, but not ko. Maybe we'll get the type of reading that
results in ko in the context of the limited alpha/beta search
proposed under 15 below. At another level, GNU needs to
understand how to go out an look for ko threats.

13. Implement territory estimation taking into account GNU Go's
opinions of current life/death situations and heuristics (based
on strategic_distance and similar functions) for determining
which areas are probable territory.

14. One move lookahead (say for candidates valued > 80,
which would include most moves intended to attack and
defend strings) would prevent many errors. The worm,
dragon, half eye and strategic distance data would have
to be pushed and popped.

15. Item 14 is a first step towards alpha-beta pruning.
Implement a reading mode in which a static evaluation 
function based on the territory estimation in Item 12 is very
selectively evaluated at deeper nodes of the move tree. Since
this will mean recomputing the dragon data, this won't be
done for many variations. But even very selective deeper
reading and alpha/beta pruning will allow GNU Go to make more
informed decisions than is currently possible. At least, GNU Go
should be able to evaluate as many variations as a shodan
without too much time penalty.

16. Implement a debugging/tuning mode which reads a professional
or dan level game and identifies places where we did not
consider the move, or considers it with a disproportionately
small value. Taken to its logical conclusion, this might lead to
up a genetic mode for automatically adjusting the weights of
existing patterns.

17. Implement back stepping so that the user can take moves back.
(TAKEN)



