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.

A lighter option we use for smaller decisions is to ask for a show of thumbs: Options are "thumb up" (yes), "thumb down" (no), or "thumb sideways" (neither yes nor no). If anyone feels like they need more information before choosing a gesture, they should speak up immediately.

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.

Honor holidays:
Holidays should reduce stress, not increase it. When recurring meetings fall on a holiday, consider canceling them instead of rescheduling them into other workdays. "Don't try to pack 5 days of work into a 4-day week". Obviously, this only makes sense for certain meetings and contexts, so use your judgment.

Maintain calendar sanity for yourself and others:
TPGers are encouraged to find habits and practices that avoid stress due to over-full calendars.

When scheduling meetings, consider the sanity of the people you are inviting. And consider adding events to your own calendar to reserve time to work or recharge.

For your own calendar, some of these optional techniques might help (or not):
 * Reserve specific blocks of time to complete specific tasks
 * Set aside recurring blocks of time, and use them to work on whatever is most important then

Try not to set aside too much solo time, or inviting you to meetings will become difficult.
 * Create lunch breaks or other gaps to avoid multi-hour blocks of back-to-back-to-back meetings

For your own calendar and others, be mindful when scheduling meetings. Everyone has different habits and preferences, so not all of these ideas will benefit everyone. When in doubt, ask someone if they have a preference.
 * If someone has indicated normal working hours, respect those
 * Some people don't like starting the day with a meeting; others prefer to get them out of the way before an uninterrupted block of work.

When scheduling meetings with people who benefit greatly from uninterrupted blocks of time, consider scheduling meetings near natural breaks when they will already be interrupted. This is sometimes known as a "maker's schedule". Examples would be before/after lunch, or before/after another related meeting.
 * Some people don't like back-to-back-to-back meetings; others prefer to clump their meetings together.
 * Some people don't like meeting late on a Friday

= See Also = TPG_Quarterly_Planning