Team Practices Group/Team Norms

Email Conventions
Team Practices Group team members label emails to tpg@wikimedia.org to help recipients prioritize follow-through times. If more than one tag is applicable, emails are generally tagged with the most relevant tag.


 * 1) No tag.  The sender hopes this email will be read, but it's okay if you do not read it.
 * 2) [ACT].  The sender requires actions from all recipients.  The required action should be indicated, preferably in bold face, near the top of the email.
 * 3) [ALL].  The sender expects that all recipients will read the email.
 * 4) [ANYONE].  The sender needs at least one recipient to read it; that team member should respond Reply-all so that others can see that the need is met.
 * 5) [DECISION].  This email contains documentation of a decision made by the team (see Meeting Conventions below).
 * 6) [FYI].  Can be ignored.  This email might be interesting, but it is fine if you do not get to it.
 * 7) [URGENT].  The email needs to be read as soon as possible by all recipients.

Optional Tags

 * 1) [SF] communications for SF-based TPG members (example: announcing Meetups)
 * 2) [LOLZ] Humor, typically agile or project management themed

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

Participation Gestures

 * Raising one handPEO-happy person raising one hand.svg
 * "I have something to say. Please add me to the speaking queue."
 * Emoji u1f64c.svgng two hands
 * "I have a direct response. When the current speaker finishes, please allow me to speak immediately. My response is time-sensitive and brief, and I promise you won't regret letting me bypass the queue."
 * Twinkle hands (spirit fingers, not jazz hands)
 * "I agree with or support what was just said or proposed."
 * We haven't found a suitable image on commons, but here is a non-free demonstration
 * Hand-shrug
 * Anna Torv (7595213038).jpg"I don't have a strong opinion on that."
 * Nadal vs Federer RG 2007.jpgng two fists as if holding up a picture of a kitten
 * "This conversation has gone offtrack. Whenever that happens, a kitten dies. Let's return to the main topic."

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: Ban on any further decisions in the last 5 minutes of the meeting
 * 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 sprint through 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]

Consensus and gradients of agreement
When first considering a new proposal, we often do a quick poll to figure out roughly 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 a similar poll to decide whether or not to move forward. The threshold might be "no vetoes", or "everyone supports the proposal".

For about a year, we used a 7-point "gradients of agreement scale". However, we found it unsatisfying, due to its linearity, and the ambiguity in the wording of some of the choices. To address our concerns, we have invented our own tool: Generally, if a decision is to be made based on the results, it would probably either be "Nobody on the left", meaning that everyone is neutral or higher, OR for big/important decisions, "Everyone on the right", meaning everyone supports or abstains.

Calendars
Keep your personal calendar updated:
 * 1) Indicate your preferred working hours
 * 2) Update your calendar to reflect when you are OOO​ or otherwise unavailable​ Remember that all-day events default to "available", not "busy", so must be changed explicitly.
 * 3) Mark yourself optional for meetings where possible
 * 4) RSVP yes/no/maybe to ​all ​invitations  NOTE: This means to indicate in the calendar whether or not you plan to attend. You might do this by hitting a button in the email invitation you receive (which generates an email to the organizer), or you might do this by clicking on the invitation in your calendar itself, which also allows adding a note to explain your RSVP.

Definition of Done
This section contains proposed norms that have NOT yet been agreed to

TODO

1) ? TPG manager says it's done. OR, submitter or worker has decided whether or not it needs TPG manager'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)

= See Also = TPG_Quarterly_Planning