= VCS Issue Tracker =

Proposal: An issue tracker tied to the VCS state of e.g. code.  The
issue tracker is designed to be very light-weight and easy to use, as
opposed to robust and extensible. As a
test illustration case, the VCS issue tracker should boot-strap itself
for issues.


== Implementation ==

A post-commit hook lives on a repository.  A number of types of issues
are defined for the project type as given by a mapping of strings
found in e.g. comments in source code.  The example default mapping
is::

 issue_types = {'XXX': 'issue',
                'TODO': 'enhancement'}

Each issue has a specific URI, e.g. ::

 http://example.com/issues/1234

Where the number (``1234``) is the chronologic counter of the
issue. 

You can also look up the issues by path;
http://example.com/issues/myproject.py  will display all issues for
the ``myproject.py`` file.

Issues are opened and closed by writing and deleting an (e.g.) comment
of the appropriate form, respectively.  Likewise, updates are made by
modifying the comment.  When you create an issue, a subcommit will
(optionally) be made on the repository that adds the issue URI to the
end of the e.g. comment.

You can choose to follow any pattern of files to be notified to issue
opening/closing. These events are also pluggable.


== Analysis ==

By tying issue tracking to the source code, several distinct
advantages are achieved:

- the need for auth and user accounts is removed entirely.  Auth takes
  place at the VCS level. (This is either a feature or a misfeature
  depending on your project and POV.)

- there is no context shifting required in going from writing bugs and
  development. 

- sensible organization of project files is encouraged

There are also several disadvantages to this approach::

- there is minimal workflow.  Issues are open or closed and can be in
  no other state. Reopening could be done with e.g. a special commit,
  but even that is a bit much.  

- while you could associate arbitrary metadata with issues, there is
  no real point in doing so outside of tagging.  This isn't
  necessarily a huge disadvantage, as a robust issue tracker with
  typed workflow does not exist in the open source world