Making WordPress Releases Easier

Update: Let’s move forward with the March release, a July release (to give folks time to adjust their company plans), and a final release in December. I will create a plan to help us lessen the burden of releases, and in December I will see what we’ve accomplished and get some 2022/23 target release months published.

The past few weeks have been very busy in terms of WordPress’ release cadence. There has been the WP 5.6.1 release, WP 5.7 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1, and discussions to start organizing the next major and minor releases are already underway. The roadmap for the year promised four major releases, as well as any follow-up minor releases, and flags have been raised about how we can accomplish that.

tl;dr I’ve been exploring the problem of making the release process easier with WordPress contributors for 3+ years; high level notes are shared below. From my research, the work to automate what we can (and potentially get the project ready for more releases per year) would take 3-4 dedicated developers who are proficient in our backend tools/infrastructure, at least a project manager, 1-2 internal communications people, and probably a year or more of work (if we had all the resources, and they were working at full capacity). This means that 4 major releases is not a viable plan in 2021.

What are the challenges?

  • Balancing developer needs with user needs. A rapid release cycle (CI/CD) definitely appeals to some developers. In my observation, our users see no difference between our nuanced guidelines around minors vs majors, and currently experience each type of release (~9ish on average) as “yet another thing I have to update.”
  • Balancing the OSS philosophy of releasing early and often with the reality that we ship a CMS to ~39% of the web. In my observation, our commitment to backward compatibility and relative consistency is key to our users’ continued use of WordPress, and makes “ship, then iterate” more challenging.
  • WordPress takes a responsive approach to open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. product and project management, despite our scale. Contributors expect WordPress maintainers to seek out and respond to feedback on both product and process, which is time-consuming.
  • Related, every release team — major or minor — makes hard calls and unpopular decisions. This results in fatigue and increased risk of burnout in contributor roles that have a limited pool of trained and experienced candidates. The more releases, the more fatigue and burnout risk we run.
  • Currently, only a small number of active contributors can do the administrative work required during a release, and they split that responsibility across releases for the year. The onboarding process for contributors with that skill set is lengthy, and the main mechanism we use to recruit and start training them (our in-person events) is not available.
  • Automating the basic tasks involved in a major or minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. requires time from skilled developers as well as product ownership and project management. In my observation, we do not have people with those skills and extra time available to help here, given our ongoing need for increased project coordination.

What changes are needed?

  • Better testing: That would include automated testing, security testing, smoke testing, E2E tests, beta testing, etc.
  • Seasoned CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developers: Many more of them, and also more of their time focused on Core.
  • Better handoff in design/dev iterations: The WordPress project has more developer contributors than design contributors, and few people who have the time, experience, and skill required to coordinate the work at scale.
  • Shifts in our collective philosophies: A shift to a culture of review, to an ideology of continuous development (as it relates to CMSs and software that is open to a vast networknetwork (versus site, blog) of extenders), and finally a shift in the nuanced application of OSS methodologies (aimless contributions vs agenda-free contributions, non-reciprocal vs no value, coordination vs dictation, etc).

What could we change right now?

  • Mentorship: The mentorship programs that are in place across teams in the project, could stand a fresh eye to account for active and passive learning that happens during in-person events. If we gave it a little more definition, and some better tools, then we could potentially remove that barrier to entry for all future contributors.
  • Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.: There was a call for this at the end of 2018, and it suffered from a bit of a false start. Triage is not only a key part of maintaining WordPress, it’s also the common denominator in the paths of success for many of the long-term contributors I’ve spoken to.
  • Feature Proposals: The feature proposal process was suspended during the first phase of GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc., but I think it’s time to revive it. The benefits of this process are that discussions can happen on the Make network, which opens up feedback to a broader audience, so that when a proposal gets to any final decision makers, the questions have all been answered (or at least asked).
  • Product/Project Processes: This is hard in open source. We know that trying to design by committee is prone to failure, but making that work have a clear owner feels like we’re walling off the future of the project. I have no solutions, but I will start a few conversations in the near future so we can collectively come to a potential way forward.

Time for your feedback!

I believe that it is essential to reduce the effort required to have a successful WordPress release, but that we should start with some planning. I’d like to hear from folks in the comments if you’re interested and available to lead efforts around any of the things listed above, or if you have anything that needs clarification in what I shared!