workflow

The basic idea of the workflow:

  1. We set a goal for the next release (one or more use-cases that should be tackled)
  2. The work to do is split up into separate tasks to work on.
  3. Each task is taken over by a pair of developers. They meet in some chat or whatever, and discuss the design of the code.
  4. Either separately or during the chats, the developers implement the required code for the task.
  5. When all tasks are implemented, the next release is published.

This is actually modelled after the Freelords workflow and subject to revision. The linked page also discusses development roles, which we might also use; we will see.

Finally, a few conventions to try to follow:

  • After a chat, a brief summary should be sent to the 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.

Related

Wiki: Home