Thank you for your patience, it took longer than I predicted to kick off this working group, but here we are!
On Wednesday, January 29th let’s have the first meeting for the Release Model Working Group at 19:00 UTC. It’s the same time slot as the New Contributors Meeting and we can alternate meetings with them.
The problem we are trying to solve
Many fixes and enhancements are made continuously in WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., the Gutenberg 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. https://wordpress.org/gutenberg/ block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, and third-party libraries, but everyone has to wait up to four months to see these due to the cycle of three or four major releases per year. This has a negative impact on both end-users and developers.
What will the Release Model Working Group do?
This working group will spend some time during the 5.4 release cycle to:
- Evaluate the technical changes needed to speed up the release process
- Evaluate if those changes are doable with the existing resources and tools
The group will also document the existing release process in order to achieve the above.
The end result will be a few factual, non-opinionated documents which outline the above.
Why do we need a working group?
A working group is a bit of a fancy name for a group of people who come together to spend time focused on a particular problem – in this case, the issues caused by the current release cadence – and identify potential solutions and their feasibility.
We need this because increasing the rate at which new versions of WordPress are released has a big impact not only on end-users but on those involved in the release.
When
A meeting can be held in the #core Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel every two weeks, alternating with the New Contributors chat, and it will be mostly a status report so everyone is aware of what the findings are so far, and what everyone is doing.
How will the group work?
The group is self-organising based on experience, skills, and interest. Team members should commit to one of the above-mentioned areas.
Which approach to use for the research and which tool to use for collecting the results has to be determined: please leave your comments below, so by next Thursday we will have a few ideas to pick from.
I can take on the role of facilitator, with main tasks being:
- Pinging people to remind them of their commitment and deadlines 😉
- Remove blockers if necessary
- Check overall progress
Who is the team made of
Many people raised their hands in the call for volunteers post. Thank you for your enthusiasm and generosity!
I am spending the next few days reaching out to each one of you to see how your experience and expectations, together with the capability of being self-organised, aligns with the group.
The chats will be public, so everyone can see what is being discussed.
Initial research: The different aspects of a release
I took some time to explore all the aspects involved in releasing a new version of WordPress and divided them into macro areas. The list is not exhaustive but a starting point. At this point it’s not necessary to go too granular, that’s what the working group is for.
This list should give the working group a starting point of areas to focus on.
Stages of the release cycle
- Alpha
- Beta 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.
- Release Candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).
- General release
Issue tracking
- Bug reporting
- Bug gardening
- Code writing
- Testing
- Committing
Planning and coordinating
- Scoping the release
- Putting together a release team
- Scrubs scheduling
- Collecting feedback and status reports from everyone involved
Communication of the release
- Blog (versus network, site) posts in /news for each stage
- About page
- Dev notes Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.
- Field guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page.
- Bug scrubs (schedule and hosting them)
- Dev chats (agenda and hosting them)
The people involved in releasing
- Coordinator
- Mission control
- Core committers
- Security team
- Systems
Thank you for making WordPress!
#release-process
