Recent changes to workflow

workflow modified by Ulf Lorenz

Ulf Lorenz — Thu, 23 Mar 2017 12:04:16 -0000

--- v6
+++ v7
@@ -1,8 +1,8 @@
 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.
-* Each ticket is taken over by a pair of developers. They meet in some chat or whatever, and discuss the design of the code.
-* Either separately or during the chats, the developers implement the required code for the task.
+* Each ticket is taken over by a pair of developers. They meet in some chat or whatever, and discuss what to do in detail..
+* Either separately or during the chats, the developers implement the required code for the ticket. Usually, there will be cycles of discussion - implementation - review.
 * 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](https://sourceforge.net/p/freelords/wiki/Project management) and subject to revision. The linked page also discusses development roles, which we might also use, if we ever need to be that formal.

workflow modified by Ulf Lorenz

Ulf Lorenz — Thu, 23 Mar 2017 12:03:24 -0000

--- v5
+++ v6
@@ -1,14 +1,13 @@
 The basic idea of the workflow:

-1. We set a goal for the next release (one or more use-cases that should be tackled)
-* The work to do is split up into separate tasks to work on.
-* Each task is taken over by a pair of developers. They meet in some chat or whatever, and discuss the design of the code.
+1. We define one or more use-cases, i.e., tickets, that should be done for the next release.
+* Each ticket is taken over by a pair of developers. They meet in some chat or whatever, and discuss the design of the code.
 * Either separately or during the chats, the developers implement the required code for the task.
-* When all tasks are implemented, the next release is published.
+* 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](https://sourceforge.net/p/freelords/wiki/Project management) 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 sent to the list with the main topics, just so others can roughly follow what is going on.
+* 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.

workflow modified by Ulf Lorenz

Ulf Lorenz — Sat, 11 Jun 2016 21:24:52 -0000

--- v4
+++ v5
@@ -6,7 +6,7 @@
 * Either separately or during the chats, the developers implement the required code for the task.
 * When all tasks are implemented, the next release is published.

-This is actually modelled after the [Freelords workflow](https://sourceforge.net/p/freelords/wiki/Project management) and subject to revision. The linked page also discusses development roles, which we might also use; we will see.
+This is actually modelled after the [Freelords workflow](https://sourceforge.net/p/freelords/wiki/Project management) 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:

workflow modified by

Tue, 29 Oct 2013 19:53:54 -0000

--- v3
+++ v4
@@ -1,10 +1,10 @@
 The basic idea of the workflow:

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

 This is actually modelled after the [Freelords workflow](https://sourceforge.net/p/freelords/wiki/Project management) and subject to revision. The linked page also discusses development roles, which we might also use; we will see.

WikiPage workflow modified by

Thu, 31 Jan 2013 19:29:27 -0000

--- v2
+++ v3
@@ -7,3 +7,8 @@
 * When all projects are implemented, the next release is published.

 This is actually modelled after the [Freelords workflow](https://sourceforge.net/p/freelords/wiki/Project management) 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.

WikiPage workflow modified by

Mon, 24 Dec 2012 13:55:12 -0000

--- v1
+++ v2
@@ -6,4 +6,4 @@
 * Either separately or during the chats, the developers implement the required code for the project.
 * When all projects are implemented, the next release is published.

-This is actually modelled after the [Freelords workflow](http://sourceforge.net/apps/mediawiki/freelords/index.php?title=Workflow) and subject to revision. The linked page also discusses development roles, which we might also use; we will see.
+This is actually modelled after the [Freelords workflow](https://sourceforge.net/p/freelords/wiki/Project management) and subject to revision. The linked page also discusses development roles, which we might also use; we will see.

WikiPage workflow modified by

Sun, 16 Dec 2012 23:03:39 -0000

The basic idea of the workflow:

We set a goal for the next release (one or more use-cases that should be tackled)
The work to do is split up into separate projects to work on.
Each project is taken over by a pair of developers. They meet in some chat or whatever, and discuss the design of the code.
Either separately or during the chats, the developers implement the required code for the project.
When all projects 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.