Google Summer of Code 2008

Loblaw is just getting started, but there are already some tasks that are possible and ready-made for student contributors this summer. Students who are interested in discussing these projects can join #conservancy on the FreeNode? IRC network, or email bkuhn@softwarefreedom.org.

Trac-Related Projects

Trac is an excellent system for project management. Loblaw seeks to adapt Trac for use to manage and organize non-profit work.

Project 0: Store Trac Wiki in SVN

Currently, the Trac wiki uses a MySQL database to store the Wiki. For an organization that is already using SVN to store its non-software-related documents, it would be useful for editing of regular SVN documents to work the same as it does with the Wiki.

The goal of this project would be to generalize the storage engine for Trac's Wiki so it can use both MySQL, SVN, and possibly other plug-in storage engines for the Wiki other than those two (that might later be written by others).

Those interested in this project should first read the thread discussing this issue on trac-dev.

Successful completion is defined as follows:

• The user can clearly and easily edit the Trac Wiki via normal SVN operations without using the Trac Web interface, and all data integrity remains consistent.
• Patches to Trac needed to support this feature are sent upstream by the Trac developers, and some work to convince upstream to take them should be done.

Project 1: Trac Plug-In for SVN Permission Management

Currently, Trac is not particularly focused on management of permissions of the SVN tree. The beginnings of a plug-in for editing the SVN Authz file exist, but something much more substantial is needed for an organization with highly tuned SVN permissions.

A full-fledged Trac plugin for SVN access control should also augment the permission levels Trac already supports and merge the Trac user set with the SVN user set as defined in the authz file. Perhaps, in fact, the right solution is to store the SVN permissions in the Trac database and write out the authz file when they change.

The permission structure needed should be anything that can be controlled with the SVN authz file (i.e., read and write permissions at each directory level per user and group), as well as controls of who is allowed to grant others such permissions at each level.

Successful completion is defined as follows:

• SVN authz file should be fully editable in the Trac Web Admin interface.
• Meta-permissions should be stored regarding who has or does not have permission to grant access to each directory in SVN.
• A clearly defined and well organized authentication model that merges the Trac permissions with the SVN authz permissions should be determined, documented, and implemented.

AntiMatter Projects

AntiMatter is the component of Loblaw for keeping track of hours worked on various categories (sometimes called matter time tracking).

Project 2: Database and REST API implementation

Currently, the existing AntiMatter component, the IRC-based time keeping system called tim is a proof-of-concept centered around a IRC bot that keeps track of categories and time. This proof-of-concept needs a complete rewrite based on an SQL database and REST API. Reimplementation can be done in Perl or Python.

Successful completion is defined as follows:

• Creation of a basic SQL database that replaces the MLDBM database currently used by tim (see DB.pm and related modules for details)
• Write all basic DB operations expected by the time tracking system (again, see what DB.pm already does)
• Make test cases for all these operations, ensuring full test coverage.
• Make a REST API (and tests) for all these operations.

Project 3: Reimplement tim with a newer Bot infrastructure

Currently, the IRC-based time keeping system called tim is written in Perl using Bot::BasicBot?. There are newer, better maintained bot infrastructure libraries available in Python currently, namely Gozerbot and Supybot (although if the student wanted to make use of Conservancy's member project, Twisted, that would be acceptable as well). The student should select one of these systems to reimplement tim.

Successful completion is defined as follows:

• Feature compatible with tim (perhaps using a mock-up database as tim does, or using the work in Project 2 as it develops)
• Full test coverage for the bot.

Stet Projects

These are projects that are actually for another project of the Conservancy/SFLC, called Stet, but are listed here since this is the official Google SoC URL.

Over the past two years the heat-map functionality and the ease of use of the entire system have led to many requests of others wanting to apply the system to their sites and documents.

However, Stet was written without recourse to any of the many rich libraries for Javascript development (it predates most of them), leading to cranky browser support and a limited scope for growth on the current code base. But many have expressed interest in using it for texts other than the GNU license drafts.

Project 4: Modernize stet javascript

The goal of this project is to rewrite the front-end javascript code for comment creation and intensity highlighting, probably based on JQuery and as a JQuery plugin, but possibly using other libraries if there is a compelling reason. Documents for commenting would ideally not require any special markup.

The basic features and requirements are:

• JavaScript? will be extensions to JQuery
• There will be several types of annotation available to the user:
  • Simple tagging/stamping of an entire document or page
  • Drop in commenting system (similar to digg.com buttons, but with a pop-up form)
  • Inline annotation at the page, paragraph, image, and character level.
  • Shared commenting system (details to be described later).
• A combination of ATOM and Microformats will be used for storing annotations, reviews, et al.
  • The server side should be flexible enough to be added to a system such as Trac or RequestTracker?.

Successful completion is defined as:

• the user can easily create comments on arbitrary text in a web page,
• overlapping comments have some manner of incrementing style attributes so that areas of greater activity are easily noted
• the features may be added by a simple inclusion of the javascript code
• Full test coverage (using a well-known Javascript testing library) for the entire rewrite codebase

Project 5: More abstract stet storage/syndication (Atom?)

An abstract storage backend for annotations made with the js library above. Will receive comments via XMLHTTPRequests or other arbitrary structured input; store them in the user's choice of *SQL, bug tracker, etc., and retrieve them in response to queries. Open-ended possibilities for bug-tracking features too.; also maybe a centralized server for annotation from anywhere.