workflow

The basic idea of the workflow:

1. We define one or more use-cases, i.e., tickets, that should be done for the next release.
2. Each ticket is taken over by a pair of developers. They meet in some chat or whatever, and discuss what to do in detail..
3. Either separately or during the chats, the developers implement the required code for the ticket. Usually, there will be cycles of discussion - implementation - review.
4. When a certain number of tickets has been implemented, the next release is published. Usually every quarter to half of a year.

This is actually modelled after the Freelords workflow and subject to revision. The linked page also discusses development roles, which we might also use, if we ever need to be that formal.

Finally, a few conventions to try to follow:

• After a chat, a brief summary should be attached to the ticket and sent to the mailing list with the main topics, just so others can roughly follow what is going on.
• When you discuss something about a task or find something out that should be noted down, or otherwise have the feeling that there is a decision to be memorized somewhere, make liberal use of the comment function in the ticket system. Ideally the ticket should give a coherent overview of what was going on.