Good meetings

This attempts to describe some good habits for having good or even great meetings among members of the Wikimedia development community. This advice centers on consensus-oriented meetings between peers (possibly from different employers) rather than centrally-controlled meetings with a clear decision maker available to "pull rank" and make an unpopular decision over widespread objection.

Meetings are work
An old Fast Company article (The Seven Sins of Deadly Meetings, 1996) points out one sin of meeting organization being “People don't take meetings seriously”, and then elaborates on how people fail to treat them like work. Intel had (and probably still has) a culture of treating meetings as important work, with then CEO Andy Grove actually teaching a course on it:"[CEO Andy Grove] believed that good meetings were such an important part of Intel's culture that it was worth his time to train the troops. &quot;We talk a lot about meeting discipline,&quot; says Michael Fors, corporate training manager at Intel University. &quot;It isn't complicated. It's doing the basics well: structured agendas, clear goals, paths that you're going to follow. These things make a huge difference.&quot;"This isn’t to say “people need to be miserable, or we haven’t done our job”. Everyone should still enjoy their day-to-day work, and in fact may enjoy it more if they actually felt meetings were productive instead of squandering time that could be better spent on "real work".

Taxonomy
"See also: Consensus"Different meetings need different conversations: make this distinction clear to everyone before the heart of the agenda. Here’s a 1999 Fast Company article about running good meetings:"For example, some meetings are built around a &quot;conversation for possibility.&quot; The group acknowledges that it has come together to generate ideas, not to make decisions. The goal is to maximize creativity. Other meetings are built around a &quot;conversation for opportunity.&quot; The goal is not to reach a final decision but to narrow down a field of ideas or options. You gather lots of information; you do some analysis; people take positions. Finally, there are meetings that are built around a &quot;conversation for action.&quot; The goal is to decide, to commit: &quot;We want to leave this room with our three investment priorities for 2000.&quot;  [...]If you call a meeting, make it clear to people what kind of conversation they're going to have, and then impose a certain amount of discipline on them. Remember: Meetings don't go off topic. People do."This seems to be the taxonomy of good consensus-oriented Wikimedia engineering meetings.
 * Strawman - Talk in depth about an engineering idea that doesn’t have consensus, potentially evangelizing that idea
 * Successful outcome: more people know about the idea, and maybe more people agree that it’s a great idea.
 * Successful outcome: clear definition and agreement on the problem the strawman is intended to solve
 * Stretch goal: consensus on the priority about the importance of solving the problem the strawman presumably solves (or consensus that it isn’t a problem after all)
 * Non-goal: consensus about the priority of implementing the engineering idea
 * Problem definition (nee Problem-solving) - Figure out what problem we're really trying to solve, and if it's really a problem
 * Successful outcome: consensus on the priority about the importance of solving this problem (or consensus that it isn’t a problem after all)
 * Successful outcome: a list of clearer problem statements that can be prioritized (e.g. if the problem is "code review sucks", emerge with a list of actionable things that suck about code review)
 * Stretch goal: an idea or a reasonably complete list of ideas for how to solve the problem. "Conversation for possibility" as described by 1999 article
 * Non-goal: a decision for how to solve the problem


 * Field narrowing - Narrow down choices for solving a problem, a.k.a. a &quot;conversation for opportunity.&quot;
 * Successful outcome: tentative consensus about the limited set of options, with someone assigned to clearly document the tentative consensus in the consensus-building forum of record (see )
 * Non-goal: singular consensus about the solution to the problem.  This is a nice bonus outcome, but if people enter the meeting afraid that the train is leaving the station, they may position themselves on the tracks rather than being helpful participants in the field narrowing conversation.


 * Consensus - Arrive at rough consensus about the best solution to a problem
 * Successful outcome: tentative consensus on a singular most viable solution to a problem, with agreement to postpone or eliminate competing solutions from consideration.  Someone assigned to clearly document the tentative consensus in an email to wikitech-l. Further advice:  RFC 7282: On Consensus and Humming in the IETF
 * Non-goal: “Resourcing agreement”.  We want to walk away from this type of meeting with tentative engineering consensus about the proper solution for the problem, but not an insistence for a real-time promise to “dedicate resources” to the proposed solution.


 * Education - teaching people about an idea that already has consensus and/or has been implemented
 * Successful outcome: more widespread interest and knowledge about an existing engineering solution, and/or recruitment of people to support/maintain/use/implement the solution
 * Non-goal: retroactive blessing of a controversial portion of our system

Roles
Valerie Aurora gave a talk called "Meeting Skills for Inclusive Moderators" based on her experience running AdaCamp unconferences with Mary Gardiner. The gist of the talk is in this quote from an Ada Initiative blog post she and Mary Gardiner wrote, based on Intel's meeting skills:

Thus, we encourage the discussion groups at AdaCamp to watch out for unproductive derails, and to appoint four people in each group to different roles for the length of a session: 
 * 1) a Facilitator, who presents the topic and keeps the discussion moving forwards
 * 2) a Gatekeeper, who keeps the discussion productive and empowers people who haven’t spoken up to make themselves heard
 * 3) a Timekeeper, who keeps the session to time
 * 4) a Note-taker, who makes notes on the session

During the "Meeting Skills" talk, Valerie and the audience spoke about other potential roles in the Wikimedia engineering context:
 * Reporter, who communicates the conclusion. May be especially important in unconference-style discussions where ownership isn't clearly defined
 * Advocate, who ensures balance in conversation, making sure that quiet/introverted people still get heard (similar to the Gatekeeper role)
 * Online voice - in hybrid in-person+remote meetings, having someone available to interject on behalf of remote participants may be important

Discussion of record
In our consensus-oriented environment, it's important that people who have a stake in the outcome of a conversation understand what happened. Many governments have established a newspaper of record as a legally-acceptable means of making important announcements when that is required. Our work shouldn't rely on publishing announcements in our paper of record (whatever that is for us), but we should have a means of making important announcements in a way where stakeholders can be effectively informed, and intervene at the appropriate time.

This may mean engaging in the appropriate discussion forum of record for both the announcement of the meeting, as well as providing the minutes. For Wikimedia software, the wikitech-l mailing list seems to be the norm, but as of this writing (January 2016), it isn't official.

Misc
Much of this content was made in preparation for WikiDev16, so some of it may still be specific to that world.