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.

No tag. The sender hopes this email will be read, but it's okay if you do not read it.
[ACT]. The sender requires actions from all recipients. The required action should be indicated, preferably in bold face, near the top of the email.
[ALL]. The sender expects that all recipients will read the email.
[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.
[DECISION]. This email contains documentation of a decision made by the team (see Meeting Conventions below).
[FYI]. Can be ignored. This email might be interesting, but it is fine if you do not get to it.
[URGENT]. The email needs to be read as soon as possible by all recipients.

Optional Tags

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

IRC Norms:

Team Practices Group/Team Norms/IRC Norms

Meeting Conventions

Participation Gestures

Raising one hand
Raising a hand to speak
- "I have something to say. Please add me to the speaking queue."
Raising two hands
Raising 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
- Hand shrug
  "I don't have a strong opinion on that."
Raising fists
Raising 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

Meeting owner comes with
1. Agenda
2. Decisions to be made
3. Decision rule (ie, twinkled by all team members or no vetoes)
4. An understanding of who should be informed of these decisions
  1. For example, Joel and Grace may use RACI model to understand who should be involved at what level of participation.
Always have time reserved at end of meeting for reviewing: Ban on any further decisions in the last 5 minutes of the meeting
1. Decisions made during meeting
2. Next Steps
3. Action Items
  1. Note: Decision making stops here apart from simple/quick decisions like flavor of seltzer or color of post-it note.
Don’t try to sprint through the Groan Zone in a time crunch at the end.
1. 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.
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:

		Yes
Need more information	Neutral	Abstain/ don't care
No

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.

Calendars

Keep your personal calendar updated:

Indicate your preferred working hours
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.
Mark yourself optional for meetings where possible
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

Create lunch breaks or other gaps to avoid multi-hour blocks of back-to-back-to-back meetings

Try not to set aside too much solo time, or inviting you to meetings will become difficult.

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.

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

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.