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. Some of the information here may be specific to our community (e.g. use of the wikitech-l mailing list, which is where we have "discussions of record")

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".

Expectations
Here’s a later 1999 Fast Company article about running good meetings. Some of the advice I reread resonates more with me now than it did when I first read it in 1999, and makes me say &quot;oops, I haven't been doing that&quot;. One thing they talk about is “different meetings need different conversations”, and encourage making the distinction clear to everyone. From the article:"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."The type of meeting they don’t address is “conversation for education”, which is less of a conversation and more of a tutorial.

Taxonomy
This attempts to provide a taxonomy for good consensus-oriented Wikimedia engineering meetings.
 * Problem-solving - Discuss a problem that we don’t know how to solve. "Conversation for possibility" as described by 1999 article
 * Successful outcome: an idea or a reasonably complete list of ideas for how to solve the problem
 * Successful outcome: consensus on the priority about the importance of solving this problem (or consensus that it isn’t a problem after all)
 * Non-goal: a decision for how to solve the problem


 * 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.
 * Non-goal: consensus about the priority of implementing the engineering idea


 * 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 an email to wikitech-l
 * 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 tentative 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
 * 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

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