Development Philosophy
Initial Design
At the beginning of most projects, after we have been asked to do something, we try to sit around as developers and discuss the new project or how to integrate a newly requested feature into an existing project. The results of these meetings make it into a general summary in the bioinformatics mailing list. From that point, new projects are set up on beanstore and an initial batch of tickets are made from the summary.
Ticketing and Revision Control
In making tickets we use TRAC. Each project gets its own TRAC system on beanstore (and a corresponding svn repository for revision control of any artifacts). The tickets serve as guides to what tasks need to be completed or which bugs need to be fixed. A ticket should describe as atomic a unit of work as is possible, avoiding tickets that span more than a couple hour's work. Larger tickets can exist, but sub-tickets should be created at a finer level of granularity. Captured in the ticket should also be a categorization of the ticket (implementation/documentation/testing/etc.) and an indication of its priority. Estimations of difficulty and time to complete should be made at the offset of a ticket and potentially adjusted (with comments) throughout the ticket lifetime or if someone else can provide more concrete information. Upon closing a ticket, the actual time and difficulty should be provided.
Given that most of our work resides in svn, we adhere to the approach of linking all svn commits to related tickets and all closed/adjusted tickets to the appropriate svn revisions. TRAC interprets a simple notation that facilitates this as svn revisions can be viewed from within TRAC. This allows quick traceability between tickets and actual changes. A similar thing can be applied to changes to project-specific TRAC wiki pages. While we encourage only commits on completed tickets, sometimes that is not possible. However, each commit that is not trivial should contain a link to its corresponding ticket(s), and there should be a comment on that ticket corresponding to the revision (although often one comment on a ticket will link to many revisions, the traceability is still there).
Note that by "trivial commit" we mean any change that does not materially affect the outcome of what was changed. This is usually a matter of white space, organizing imports, removing unused local variables or adjusting private/seldom used field/method names. Changing of naming conventions across a project would likely entail a full ticket and would not be considered a trivial change. The reasoning is that tracking what we describe here as a trivial change does not benefit anyone. Often the change is even automatic due to an IDE touching unrelated files.
When working on any given ticket, if a new task or defect is discovered, it should be immediately ticketed, but not addressed until the current ticket is resolved (unless it blocks the current ticket). This increases focus and minimizes the complication of commits.
We take special care with our Documenation and Testing to achieve a high level of quality in our products.