We use a special life cycle for service and orchestrations development inside jSeduite. It is definitively inspired by state-of-the-art project management life cycle with some personal enrichments which fit with jSeduite ideology.

The previous figure represent the expected life cycle. This life cycle is handled through the Status label of the Google Issue Tracking system. This lifecycle can help us to capitalize knowledge about jSeduite development (average development time, architectural discussions, …).

• New: An enhancement request is proposed using the tracking engine.
  • Event: A developer starts to think about the problem.
    • He becomes the owner of this issue (eventually using the CC field if multiple developers).
    • He set the status to Modeling.
• Modeling: A development team is trying to find a solution
  • Event: A document issue_XX.pdf describing the solution is produced
    • He send this document to the jSeduite mailing list: jseduite@googlegroups.com
    • Discussions about the design and the proposed solution take palce on the mailing list
    • When a consensus is obtained, he sets the status to Accepted.
    • He sets the Milestone- label to the expected delivery date (Milestone-YYYY-MM-DD).
• Accepted: Work is in progress … :)
  • Event: A solution (e.g. code) is defined
    • He commits his code inside the repository
    • He adds a comment indicating the revision which perform the fix.
    • He sets the status to Fixed.
    • He asks for a Code review on the mailing list.
• Fixed: The enhancement should be ok
  • Event: The review is negative
    • He sets the status to Accepted and iterate over the identified troubles
  • Event: The review is positive
    • He sets the status to Ended
• Ended: Final state, exiting the life cycle with success.

• New → Rejected: This request doesn't make any senses inside jSeduite context.
  • ⇒ the proposition is rejected, ans vanish from the to do list
• Modeling → Rejected: Even with the Modelling brainstorming steps, this enhancement seems unrealistic.
  • ⇒ the proposition is rejected, ans vanish from the to do list
• New → Duplicate: This request is included inside another one.
  • ⇒ The issue is declared as Duplicate and the duplicated issue ID is reported.

A Buried status means that this enhancement is full of senses, but definitively unrealistic for now considering the team load. So, this status means: Good idea, put it on a corner, we're going to re use it when our work load will be lower than now.