Team Practices Group/Team Norms

Meeting Hours
TODO ... keep personal calendars updated (where?)

should we have a TPG meeting hours period, when we can expect all TPG people to be available?

Definition of Done
TODO

1) ? Arthur says it's done. OR, submitter or worker has decided whether or not it needs Arthur's approval.  (If the second, maybe that's just part of review SOP, not definition of Done)

2) original submitter agrees it's done

3) if any process documentation is appropriate, that documentation is done and put in the right place (defaulting to mediawiki.org)

Email Conventions
Team Practices Group team members label emails to tpg@wikimedia.org to help recipients prioritize follow-through times:


 * 1) blank (= no tag) is default- sender expects email to be read but it's okay if individual team members do not get to it soon
 * 2) [ACT] the sender is using email as a method to get a result from each TPG members. So more important than blank. These emails often include "follow up" in subj line.
 * 3) [ANYONE] sender needs at least one set of team member eyes on but not every team member
 * 4) [URGENT]- email needs to be read as soon as possible by all team members
 * 5) [FYI] anything that sender is sharing because it might be interesting to the team but where it is also okay if individual team members do not get to it.
 * 6) [DECISION] used when communicating decisions that happened in meetings (see Meeting Conventions below).

Optional Tags

 * 1) [SF] communications for SF-based TPG members (example: announcing Meetups)
 * 2) [LOLZ] sharing project management themed humor

IRC Norms:
Team Practices Group/Team Norms/IRC Norms

Participation Gestures

 * Stacking and raising hands
 * Two hands for direct response
 * twinkle hands (spirit fingers, not jazz hands)
 * kittening (raising two hands as if holding up a picture of a kitten to indicate that conversation has gone offtrack)

Decisions in Meetings

 * 1) Meeting owner comes with
 * 2) Agenda
 * 3) Decisions to be made
 * 4) Decision rule (ie, twinkled by all team members or no vetoes)
 * 5) An understanding of who should be informed of these decisions
 * 6) For example, Joel and Grace may use RACI model to understand who should be involved at what level of participation.
 * 7) Always have time reserved at end of meeting for reviewing:
 * 8) Decisions made during meeting
 * 9) Next Steps
 * 10) Action Items
 * 11) Note: Decision making stops here apart from simple/quick decisions like flavor of seltzer or color of post-it note.
 * 12) Don’t try to escape the Groan Zone in a time crunch at the end.
 * 13) Meeting owner interrupts any such efforts to force a conclusion with a decision to resume discussion either in email or in another meeting of appropriate duration with the same attendees.
 * 14) Meeting owner decides who sends email to the team summarizing the decisions, tagging the email with [DECISION]

Gradients of Agreement
When first considering a new proposal, we often use "gradients of agreement" to figure out where each of us stand. This is similar to IETF "humming", but with more detail. Later, after we have discussed and refined a proposal, we often use gradients of agreement to decide whether or not to move forward. The threshold might be "no vetoes", or "everyone supports the proposal".

While using a 7-point gradient scale from a book for a year or so, we found it unsatisfying. To address our concerns, we have invented our own tool. Here is the current version that we all agreed to experiment with: This is a slight visual tweak that Kevin has proposed but which has not yet been agreed to: