DevelopersCharter

• The Speed Dreams developers charter
  • 1. Respect democracy
  • 2. Set up serious votes
  • 3. Respect the release method
  • 4. Communicate
  • 5. Think, then explain, listen and learn, and then only ... do

The Speed Dreams developers charter

Here we define and describe a set of rules :

• that every member of the development team
• commits him/herself to respect
• and to help the team to respect them.

Contributors are also warmly invited to learn about these rules and to respect them as far as they are concerned.

WIP (Jean-Philippe) but feel free to add draft items below :-) (kilo: 100% OK for me this way)

1. Respect democracy

1. the dev. team decides together on the game contents
2. when things are unclear, in order to decide, we set-up a serious vote taking into account the domain experts' know-how (see 2)
3. every member of the dev. team MUST participate in the voting (but explicit delegation is allowed)

2. Set up serious votes

1. the question must be crystal-clear
2. the possible answers have to be limited to a fixed set of clear and negotiated options, thus making a "complete" vote, with all the necessary options :
   • there's always the "I don't care = I abstain" option,
   • the whole active dev. team (see rule 4d) have to participate the negotiation : those who don't care must say it explicitly and those who can't participate after announcing it as expected by rule 4a have to be awaited ; the others are automatically excluded from the vote after 1 week of silence after the beginning of the vote,
3. every member of the team must participate, unless he/she explicitly delegated it,
4. on technical subjects where only a few devs care, all the experts of the domain must participate,
5. at the end, the result of the vote, as well as the question and options, have to be written somewhere (devel list, community, wiki, web site, ...)

3. Respect the release method

1. respect the plan (or start a discussion as soon as you have any issue with it on something specific)
2. respect the schedule (or start a discussion ... see 4)
3. help the team to respect it (trust is needed, but double-checking is even better)

4. Communicate

1. Notify the team of what happens to you
   • your progress on your tasks, especially when starting or completing one,
   • when you're unable to work on SD for more than a given duration (1 week after entering the Alpha release stage, 1 month before),
   • when you're unable to follow-up SD communication channels or answer to a question / participate to a discussion you're involved in for 1 week or more,
2. silence means nothing : always answer the questions targeting the whole team ("everyone", or "all" means "you" and no "the others" !); a simple answer like "don't know", "don't care", "let me some time", "+1", "yes", "No", ... is often enough and only takes a few seconds !
3. use the ticket system for any communication, when it's related to some task or bug (easier follow-up, better search tools that mailing lists, better auto-structuring, ...) ; if you are short in time for elaborating enough on a complicated thing, ask someone else in the team to do it for you if there's a hurry, or let the team know that you need time to answer,
4. Manage yourself your team activity state :
   • request for moving to the "inactive" state when you feel that you're about to fulfil the criteria for this,
   • request for getting back to the "active" state when it's over.

5. Think, then explain, listen and learn, and then only ... do

1. always take time to think and analyse things before starting,
2. when complicated, or interesting for the team, write a wiki page to explain and share, push other devs to discuss on it, especially domain experts (and push them again if they are asleep ;-),
3. take their opinion into account, go on analysing, trace it, and write down the final choice (as a reference for future discussions).