Release Process Checklists

The release process is complex and beyond one person. Releasing is an intricate dance that we haven’t been sufficiently capturing. Knowledge siloed in heads needs to be committed to public, institutional memory. The upcoming 4.5 release is an opportunity to capture every step of the dance so that we can iterate process, automate away lingering drudgery, and improve our cognitive net for the stressful task of releasing to 25%. I like using checklists in this cognitive net. They relieve anxiety, make process transparent, and help teams flow during stress. We already have a couple release checklists. We can build on those while adopting a little checklist culture in a manner empathetic to developers and flow. Pitch:

Checklist cool tricks


  • distribute power.
  • push power of decision making to the periphery.
  • provide a cognitive net.
  • make the minimum necessary steps explicit.
  • make sure simple steps are not missed.
  • make sure people talk.
  • capture and shape real flow.
  • inspire flow in emergencies and sustain it through the quotidian.
  • capture flow between teams.
  • encourage a shared culture around flow.
  • accessibly capture institutional memory in the context of flow.

Attributes of a good checklist

What makes a good checklist? Checklist shouldn’t be about just checking boxes. Instead of being a chore and an admonishing finger, checklists should fit and assist real flow. The Checklist Manifesto offers these suggestions. Ideally, checklists…

  • are not lengthy.
  • have clear, concise objectives.
  • define a clear pause point at which the checklist is supposed to be used.
  • have fewer than ten items per pause point.
  • fit the flow of the work.
  • continually update as living documents.

See this checklist for checklists and this example checklist for more.

Stuff to checklist

The major release checklist attempts to use pause points and follow the suggestions above. The major and minor release checklists are pretty rough and incomplete and overlap with each other. These and the things to keep in mind list need love and unification with help from developers who are in the release flow and handling controls on the release train.

about.php is…quite the process. It needs the oxygenating powers of a checklist.

Checklist Feature plugin merges.

Checklist bundled theme releases so stuff like this makes it into institutional memory.

Beta and RC releases.

Plenty of other stuff. 🙂

Start by capturing. As we walk 4.5 release flows, capture.

Selected quotes from The Checklist Manifesto

Checklists supply a set of checks to ensure the stupid but critical stuff is not overlooked, and they supply another set of checks to ensure people talk and coordinate and accept responsibility while nonetheless being left the power to manage the nuances and unpredictabilities the best they know how.

Continue reading

#checklists, #pitch, #process, #release-process

Dev Chat Notes for January 4, 2012

#3-4, #dev-chat, #process, #scope

The Purpose of the Dev Chat

Every now and then it seems like people forget the purpose of the dev chat, or new community members aren’t clear on it, so I thought this, the beginning of a new development cycle, would be a good time to reiterate the purpose of the dev chat. The dev chat is a weekly product team meeting (see About the Dev Chat), not a weekly social gathering/town hall/q&a. For anyone who’s ever worked at a software company, an agency, etc., this should be a familiar concept: The team working on a software project meets, everyone gives an update on their part of the project, any roadblocks/red flags are identified and solutions are discussed, and updated assignments are given/confirmed.

Each release cycle we remind people that this is the intended use of the dev chat, but somehow along the way we wind up losing track of that, and it turns into a combination of dev chat + ideas forum + wp-hackers live. Because the 3.1 cycle is so short (feature freeze is little more than a month away!), we need to stay focused this time around. We will be much stricter about staying on agenda, and while anyone is welcome to attend, we will ask people who have questions/suggestions that are not on the agenda to either wait until the dev chat is over or to bring it up in another venue, such as wp-hackers, on a Trac ticket, or in the forums.

It’s understandable that many people want a direct line to the lead developers, and knowing they will be in a specific place at a specific time makes it easy to corner them to pitch pet requests, but please respect that these busy individuals are continually prioritizing the pet requests of hundreds of people and millions of users. Hijacking their product team meeting doesn’t help anyone’s cause.

“Are you kicking me out?” some people may be thinking to themselves. No. The #wordpress-dev channel is open 24/7, and given the time zone distribution, there’s usually one or more lead developers in there, as well as numerous contributors. Discussion about core topics is welcome in the #wordpress-dev channel any time, and questions are usually answered gladly (and let’s face it, @nacin never sleeps). The weekly team meeting just needs to stay on target, on schedule, and focused on the actual contributing team. Though most people are volunteers working on WordPress core part-time, contributors are part of a product team, and their time should be treated with the same respect that any corporate product team would receive, if not more.

If you are not working on patches for this cycle, please let the core product team get through its agenda. Hang on to your other questions to ask during one of the 167 hours per week in the channel that don’t have a specific agenda/schedule, or ask in another venue (Trac tickets are best, since it’s asynchronous and acts as the permanent discussion record for each feature). A good guideline here would be to think of another piece of software that you use. Let’s say Firefox or Microsoft Word. If you wanted a new feature, or wished they would code something a certain way so you could do something you specifically want to do for your clients, would you interrupt their product team meetings to ask for it? If not, then please grant the same courtesy to the WordPress developers. If you would interrupt them because you found something so major that it really needed to be addressed asap (like a security problem), then please don’t wait for the weekly dev chat! Get in touch with the developers in the channel right away, so that someone can assess the issue.

If you’re following along in the dev chat and while the team is discussing a specific feature you think of something about the way they’re approaching it that you feel certain the lead devs/core contributors haven’t thought of yet, you are welcome to speak up (having read the Trac ticket first is a good idea, to make sure you’re not raising something that has already been discussed and dismissed). Maybe your idea is brilliant and everyone will thank you for the suggestion/fresh approach — go you! However, if you make your suggestion and the product team is not inclined to take it, please respect their decision. At that point, the best way to try and convince someone that your suggestion is a better approach is to code the patch yourself and upload it to Trac. Patches speak much louder than words in this case.

Remember, the WordPress motto is “Code is poetry,” and for this particular hour each week, the poets are the main event. Thanks!

#dev-chat, #etiquette, #process

Starting next week, we’ll be attempting…

Starting next week, we’ll be attempting to follow an agenda during the Wednesday dev chats. If you would like to propose a topic for the July 8, 2009 dev chat, please submit it in the replies/comments to this post. We’ll post an agenda the morning of the dev chat (i.e., about 8-10 hours in advance).