User:RobLa-WMF/WikiDev16

Tracked in Phabricator
Task T104346

We’re in the midst of planning out the Wikimedia Developer Summit 2016 in January.  This is being tracked in Phabricator task T104346: Goal: Define Wikimedia Developer Summit 2016.  Rachel Farrand is leading the planning effort, and I’m planning out what the architecture-related bits should be (which, if I get my way, is everything!….bwahahahaha)  :-)  I’ve been thinking a lot about how we use these opportunities to set our software development goals, and clarify our direction.

I think there is a lot of work we need to do before the Developer Summit to make sure that it’s successful. Modernizing our software is going to take a lot of work, so let’s not squander this opportunity.  Let’s figure out the most productive way to use this meeting to get 2016 off to a really positive start.

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. "We talk a lot about meeting discipline," says Michael Fors, corporate training manager at Intel University. "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."

This isn’t to say “people need to be miserable, or we haven’t done our job”.  I want this to be an enjoyable experience for everyone, in the same way that I want everyone to enjoy their day-to-day work.  Let’s strive for creating a sense of flow, and a sense of excitement about the future of the Wikimedia technology stack.

As I’ve said, we have a lot of work to do to modernizing our software stack.  Let’s use this time well; let’s use our meeting time to agree on the direction we need to take to modernize some of the cruftier bits.

Running good meetings by setting 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 "oops, I haven't been doing that".  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 "conversation for possibility." 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 "conversation for opportunity." 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 "conversation for action." The goal is to decide, to commit: "We want to leave this room with our three investment priorities for 2000."  [...]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.

I think we need to have a mix of clearly identified “opportunity” and “action” conversations, and try to encourage the conversations for “education” and “possibility” for before the Developer Summit.  Conversations for education and possibility are the easiest to do online rather than in-person, as they are more easily handled asynchronously.  That said, we should have some of all of it.  We just need to avoid the temptation to make it all-education-all-the-time, since it creates an environment where non-presenters feel like their obligation is to “show up”, and presenters spend all of their prep time on preparing their educational material.

Learning from the IETF

We should probably learn from the Internet Engineering Task Force (IETF), where many contentious issues of software design are discussed in a very open way.  Here’s how The Tao of the IETF describes their format:

The computer industry is rife with conferences, seminars, expositions, and all manner of other kinds of meetings. IETF face-to-face meetings are nothing like these. The meetings, held three times a year, are week-long "gatherings of the tribes" whose primary goal is to reinvigorate the [working groups] to get their tasks done, and whose secondary goal is to promote a fair amount of mixing between the [working groups] and the [working group areas].

IETF meetings are a cacophony of activity, covering pretty much every area of Internet interoperability.  Their scope is enormous, and their work is still relevant.  IETF meetings keep the “conversations for education” on the periphery of the scheduled time.  I’ve put in a request (T111306) to purposefully scout the next IETF meeting to give us more knowledge of their process.

Working Groups and “Areas”

If we adopt elements of the IETF model, we have bits and pieces we can map onto their process.  We have (with the Architecture Committee, aka ArchComm) something somewhat akin to the IETF’s Internet Engineering Steering Group (IESG).  Our process for picking the membership of the Architecture Committee isn’t nearly as formal as the IETF, which is probably a good thing.  That said, our current ArchComm process lacks explicit balance of specialization and interest, whereas the IETF has the concept of “areas”.