Dev Chat summary: January 8, 2020

The chat was facilitated by @francina on this agenda.

Full meeting transcript on Slack

Upcoming Release – WordPress 5.4

@francina reminded the main feature of 2020 will be full site editing. All component maintainers received a ping before Christmas to put together a scope for WordPress 5.4. An open call for tickets was also published on Make/Core. While @francina noted there were mostly bugfixes and not so many new features, @audrasjb raised ticket #48850 from the comments of this post. This ticket is related to automatic updates for plugins (with manual opt-in), which is one of the 9 projects for 2019-2020.

@azaozz noted that the media component team plan to continue with image post-processing. It looks like it will need couple of small UI changes/enhancements.

@audrasjb added the accessibility team will probably focus on bugfixes on both Gutenberg and Core for 5.4, and target the next major (5.5) for bigger new features.

Highlighted posts

@francina noted that a lot of volunteers signed up to the release model working group. @francina will write a recap post on Make/Core.

Worth noting @azaozz published a 5.3 release cycle post-mortem.

Components check-in

Comments: @imath is working on #35214. Feedback welcome.

Core privacy: @xkon said the privacy team won’t have any specific focuses for 5.4, only bugfixing & enhancements on existing parts. Some of them need backward compatibility review, especially #44038 and #44176. Both tickets have a patch and are ready for further iterations if needed.

Media: @azaozz is experimenting with #44427. Seems a very worthwhile enhancement for 5.4.

Open floor

In the agenda comments, @justinahinon pointed out some editing needed in the roadmap, and highlighted reactions of the community concerning handling of big media on WP 5.3. @azaozz noted most comments are about “missing” the original image in some way. The initial plan was to have a link to it in the user interface. It should be added in 5.4. Another enhancement for the UI would/may be to show when an image is missing some of the sub-sizes and have a way to create them. There are plugins that handle this, but may be time to have it in core. There are couple of pre-existing edge-cases that need fixing too. Most notably increase of the file size for indexed PNGs when resized to smaller dimensions.

@timothyblynjacobs shared #47192 as a possible 5.4 feature. It’d bring a pretty often requested feature to Recovery Mode. It would need design and copy input as well as a security review from people familiar with the intricacies of the Users/Capabilities API.

#5-4, #devchat, #release-process, #summaries

Continuing inline docs improvements adjacent to 4.8

As we’re now into the full throes of the 4.8 cycle, the uncertainty that comes with not releasing “until it’s ready” inevitably creates a lull in areas other than the three focuses. Areas like maintaining our inline documentation, which populates the official Code Reference.

In the past, the freshness of core’s inline documentation relied almost entirely on a regular, major release schedule. And due to a preference for keeping the number of changed files low, inclusion of docs fixes in minor releases has previously been a rare occurrence.

Until now.

I’ve spoken with @matt, and the decision has been made to go ahead and prioritize some inline docs fixes for inclusion in minor releases going forward.

As with any decision, there are certainly pros and cons. Here are some of them:

Pros:

  • Ability to continue our ongoing inline docs maintenance adjacent to the 4.8 major release
  • Ability to address some glaring docs errors that we’ve been fixing manually in the Code Reference
  • Continue forward progress in documenting core JavaScript
  • Prioritize docs improvements for existing functionality in the three focus areas ahead of the 4.8 release, freeing up resources for documenting new functionality

Cons:

  • Number of changes and changed files in minor releases will increase (within reason)
  • All changes pushed to trunk will also need to be backported to the 4.7 (or current stable) branch

It’s worth noting that the reason the number of changed files has traditionally been kept low is to reduce the number of automatic update failures. The hope is that since we’ve been pushing automatic updates for 10 major versions now, reliability is less of a factor now than it has been previously.

It’s also worth noting that we shouldn’t expect a downtick in activity for core team resources focused on the three areas following this decision. As always, inline docs contributors will be focused on major release priorities before minor release ones.

This decision simply maintains the inline docs team’s ability to ensure the usefulness of core’s source documentation for the thousands of users and developers who rely on it every day.

#inline-docs, #minor-releases, #release-process

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

Checklists…

  • 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