Title: release-process – Page 3 – Make WordPress Core

---

#  Tag Archives: release-process

 [  ](https://profiles.wordpress.org/amykamala/) [Amy Kamala](https://profiles.wordpress.org/amykamala/)
6:27 am _on_ February 26, 2020     
Tags: [core ( 756 )](https://make.wordpress.org/core/tag/core/),
[meeting notes ( 227 )](https://make.wordpress.org/core/tag/meeting-notes/), release-
process   

# 󠀁[Release Model Working Group Chat Summary: February 19th, 2020](https://make.wordpress.org/core/2020/02/26/release-model-working-group-chat-summary-february-19th-2020/)󠁿

This is the Summary of the Release Model Working Group Chat in [#core](https://make.wordpress.org/core/tag/core/)
on [Slack](https://make.wordpress.org/chat/) at 20:00 UTC!

Folks are welcome to [check out the agenda](https://make.wordpress.org/core/2020/02/19/agenda-release-model-working-group-february-19-2020/)
and [Slack archive](https://wordpress.slack.com/archives/C02RQBWTW/p1582142431019600)
for this week’s meeting. Here is a [recap of the last meeting](https://make.wordpress.org/core/2020/02/06/release-model-working-group-chat-summary-february-5th-2020/),
as well.

Thank you to [@mikeschroder](https://profiles.wordpress.org/mikeschroder/) for doing
the peer review on this summary!

This week a [kan ban project board](https://github.com/francescamarano/release-model-wg/projects/1)
was introduced with new GitHubGitHub GitHub is a website that offers online implementation
of git repositories that can easily be shared, copied and modified by other developers.
Public repositories are free to host, private repositories require a paid subscription.
GitHub introduced the concept of the ‘pull request’ where code changes done in branches
by contributors can be reviewed and discussed before being merged by the repository
owner. [https://github.com/](https://github.com/) issues created!

[@noisysocks](https://profiles.wordpress.org/noisysocks/) broke down some of the‘
development’ phase of the pre-release cycle into individual issues for each critical
step. 

A few of the issues have been assigned to contributors and more volunteers are welcome!
Workflow is being broken down amongst team members as follows:

 * [@marybaum](https://profiles.wordpress.org/marybaum/) is covering the [kick off release video](https://github.com/francescamarano/release-model-wg/issues/12)
   and [alpha phase announcement](https://github.com/francescamarano/release-model-wg/issues/6)
   steps, and mentioned that the alpha kick off announcement would happen weeks 
   to months earlier than the video. [@desrosj](https://profiles.wordpress.org/desrosj/)
   pointed out that the [last release video was for 5.0 Bebo](https://www.youtube.com/watch?v=72xdCU__XCk).
 * [@marybaum](https://profiles.wordpress.org/marybaum/) may also put together an
   [alpha-beta launch brief](https://github.com/francescamarano/release-model-wg/issues/19).
 * [@noisysocks](https://profiles.wordpress.org/noisysocks/) is taking the lead 
   on examining the [process of compiling dev notes](https://github.com/francescamarano/release-model-wg/issues/13).
   [@audrasjb](https://profiles.wordpress.org/audrasjb/) volunteered to help, and
   folks mentioned that the dev notesdev note 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. for 5.4 are being put together right now. [@desrosj](https://profiles.wordpress.org/desrosj/)
   brought up that [@jorbin](https://profiles.wordpress.org/jorbin/), [@jeffpaul](https://profiles.wordpress.org/jeffpaul/),
   and [@desrosj](https://profiles.wordpress.org/desrosj/) have facilitated the 
   field guideField guide The field guide is a type of blogpost published on Make/
   Core during the release candidate phase of the [WordPress release cycle](https://make.wordpress.org/core/handbook/about/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. for recent releases and 
   can assist with this item, too.
 * [@francina](https://profiles.wordpress.org/francina/) is working on [collecting information from component maintainers](https://github.com/francescamarano/release-model-wg/issues/1).
 * [@clorith](https://profiles.wordpress.org/clorith/) is researching [each team’s role in a release](https://github.com/francescamarano/release-model-wg/issues/9).
 * [@hristo-sg](https://profiles.wordpress.org/hristo-sg/) and [@amykamala](https://profiles.wordpress.org/amykamala/)
   are evaluating the process of [testing involved in a release](https://github.com/francescamarano/release-model-wg/issues/5)
   with the goal of identifying areas that could be further automated or streamlined.

[@noisysocks](https://profiles.wordpress.org/noisysocks/) mentioned that some conversations
have already lead to ideas for recommendations!

## Next Meeting

Meetings for the Working Group will take place on the first and third Wednesday 
of the month at [ Wednesday March 4, 2020 at 08:00 UTC ](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200304T0800)
and [ Wednesday March 4, 2020 at 20:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200304T2000).
Hope to see you there!

[#meeting-notes](https://make.wordpress.org/core/tag/meeting-notes/), [#release-process](https://make.wordpress.org/core/tag/release-process/)

 [  ](https://profiles.wordpress.org/amykamala/) [Amy Kamala](https://profiles.wordpress.org/amykamala/)
7:16 pm _on_ February 19, 2020     
Tags: release-process   

# 󠀁[Agenda: Release Model Working Group – February 19, 2020](https://make.wordpress.org/core/2020/02/19/agenda-release-model-working-group-february-19-2020/)󠁿

Here is the agenda of the chat happening today, [Wednesday, February 19, 2020, at 08:00 PM UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200219T20&p1=1440).

Some progress has been made following [last week’s meeting](https://make.wordpress.org/core/2020/02/06/release-model-working-group-chat-summary-february-5th-2020/)!
This week, we’ll discuss:

 * Kan Ban Board and Project for the Release Model Working Group
 * New issues/tickets added to the [Github Repo](https://github.com/francescamarano/release-model-wg)
 * Issues/tickets that need volunteers

Looking forward to our chat!

[#release-process](https://make.wordpress.org/core/tag/release-process/)

 [  ](https://profiles.wordpress.org/amykamala/) [Amy Kamala](https://profiles.wordpress.org/amykamala/)
11:55 pm _on_ February 6, 2020     
Tags: [core ( 756 )](https://make.wordpress.org/core/tag/core/),
release-process   

# 󠀁[Release Model Working Group Chat Summary: February 5th, 2020](https://make.wordpress.org/core/2020/02/06/release-model-working-group-chat-summary-february-5th-2020/)󠁿

Here is the Summary of the second Release Model Working Group Chat in [#core](https://make.wordpress.org/core/tag/core/)
on [Slack](https://make.wordpress.org/chat/) at 20:00 UTC!

Thank you to [@sergeybiryukov](https://profiles.wordpress.org/sergeybiryukov/) for
the peer review on these meeting notes!

The Release Model Working Group was kicked off last week, with these goals in mind:

 * Evaluate the technical changes needed to speed up the release process.
 * Evaluate if those changes are doable with the existing resources and tools.
 * Produce factual, objective documentation outlining the group’s findings.

Folks are welcome to self-assign areas of interest, which are outlined [in this spreadsheet.](https://docs.google.com/spreadsheets/d/1KZ4dZyhco3sbYQ3LGpNbsu7HC4WcTM6SLQHt6Ggjz-Q/edit#gid=0)

A [GitHub repo](https://github.com/francescamarano/release-model-wg) has been created
for the project, and there are a few [open issues](https://github.com/francescamarano/release-model-wg/issues)
for the group to get started with. Here are some areas the group will focus on:

 * Existing [documentation on the release cycle](https://make.wordpress.org/core/handbook/about/release-cycle/),
   with an emphasis on out of date items, items contingent on other steps, items
   that should be tied to specific timeframes and items that can be automated. As
   next steps, [Issue 2](https://github.com/francescamarano/release-model-wg/issues/2)
   and [Issue 4](https://github.com/francescamarano/release-model-wg/issues/4) for
   reviewing documentation can be broken down into different sections.
 * The internal release process. [Issue 3](https://github.com/francescamarano/release-model-wg/issues/3)
   was created to get that started.
 * During the chat [@marybaum](https://profiles.wordpress.org/marybaum/) opened 
   an [issue proposing a formal announcement](https://github.com/francescamarano/release-model-wg/issues/6)
   of the alpha process at branchbranch A directory in Subversion. WordPress uses
   branches to store the latest development code for each major release (3.9, 4.0,
   etc.). Branches are then updated with code for any minor releases of that branch.
   Sometimes, a major version of WordPress and its minor versions are collectively
   referred to as a "branch", such as "the 4.0 branch"..
 * [Testing ](https://github.com/francescamarano/release-model-wg/issues/5)as it
   relates to the release cycle.
 * [Security ](https://github.com/francescamarano/release-model-wg/issues/8)as it
   relates to the release cycle.
 * [How each team is involved](https://github.com/francescamarano/release-model-wg/issues/9)
   in the release cycle, with [@clorith](https://profiles.wordpress.org/clorith/)
   leading the charge on that one.
 * [New Contributor Onboarding](https://github.com/francescamarano/release-model-wg/issues/7).
 * [@francina](https://profiles.wordpress.org/francina/), [@audrasjb](https://profiles.wordpress.org/audrasjb/),
   [@marybaum](https://profiles.wordpress.org/marybaum/) are handling the pre-kick-
   off phase.

## Next Meeting

Meetings for the working group will take place on the first and third Wednesday 
of the month at 08:00 UTC and 20:00 UTC. The next meeting is on Wednesday, February
19th, 2020. Hope to see you there!

 [#release-process](https://make.wordpress.org/core/tag/release-process/) [#meeting-notes](https://make.wordpress.org/core/tag/meeting-notes/)

[#release-process](https://make.wordpress.org/core/tag/release-process/)

 [  ](https://profiles.wordpress.org/amykamala/) [Amy Kamala](https://profiles.wordpress.org/amykamala/)
7:42 pm _on_ February 5, 2020     
Tags: release-process   

# 󠀁[Agenda: Release Model Working Group – February 5, 2020](https://make.wordpress.org/core/2020/02/05/agenda-release-model-working-group-february-5-2020/)󠁿

Following last week’s kickoff meeting, here is the agenda of the chat happening 
later today: [Wednesday, ](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20191113T2100)
[February 5, 2020, at 08:00 PM UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200205T2000).

The group works on a self-organized basis, but there are some things to agree upon
all together as per [last week chat’s recap](https://make.wordpress.org/core/2020/01/31/chat-recap-release-model-working-group-january-29-2020/):

 * Schedule planning regarding adoption of tasks
 * Next Steps towards research and documentation in GitHubGitHub GitHub is a website
   that offers online implementation of git repositories that can easily be shared,
   copied and modified by other developers. Public repositories are free to host,
   private repositories require a paid subscription. GitHub introduced the concept
   of the ‘pull request’ where code changes done in branches by contributors can
   be reviewed and discussed before being merged by the repository owner. [https://github.com/](https://github.com/)

Thanks!

 [#release-process](https://make.wordpress.org/core/tag/release-process/)

 [  ](https://profiles.wordpress.org/francina/) [Francesca Marano](https://profiles.wordpress.org/francina/)
2:08 pm _on_ January 31, 2020     
Tags: release-process   

# 󠀁[Chat recap: Release Model Working Group – January 29, 2020](https://make.wordpress.org/core/2020/01/31/chat-recap-release-model-working-group-january-29-2020/)󠁿

Today the kickoff meeting for the group happened at in the CoreCore Core is the 
set of software required to run WordPress. The Core Development Team builds WordPress.
channel, based on this agenda. [You can read the whole chat in Slack](https://wordpress.slack.com/archives/C02RQBWTW/p1580324472084800).

This recap is not in the order things were said, but in the order that (IMHO of 
course 🙂 ) makes more sense to see the project as a whole.

## The Situation Now

As provided by [@chanthaboune](https://profiles.wordpress.org/chanthaboune/) (thanks!)

 * We have some handbook documentation that has most of the steps plus some out 
   of date things
 * We are lacking full documentation of the interior processes (knowing that some
   are irresponsible to publish in their entirety).
 * We are also lacking which steps are
    1. out of date
    2. contingent on other steps
    3. should be tied to particular timeframes
    4. automatable

## Short introduction of the scope of the group

The increase of the cadence is not a foregone conclusion. The working group is here
to **research and document**.

By documenting the existing release process, the group can:

 * Evaluate the technical changes needed to speed up the release process
 * Evaluate if those changes are doable with the existing resources and tools

The end result will be a few factual, non-opinionated documents which outline the
above.

## So! What is the group actually working on?

This point sparked a lively conversation! After a bit of back and forth, the group
decided to adopt an [existing document](https://docs.google.com/spreadsheets/d/1KZ4dZyhco3sbYQ3LGpNbsu7HC4WcTM6SLQHt6Ggjz-Q/edit#gid=0),
put together by [@chanthaboune](https://profiles.wordpress.org/chanthaboune/) over
two years (thanks, again!): it divides the release into phases that group types 
of work needed.

Some of the attendees have already expresses interest in some specific areas:

 * [@aaroncampbell](https://profiles.wordpress.org/aaroncampbell/) is interested
   in helping document out the jobs of, and needs/struggles of, the security team.
 * [@francina](https://profiles.wordpress.org/francina/) and [@audrasjb](https://profiles.wordpress.org/audrasjb/)
   are interested in the pre-kickoff phase:
    - Talk to leads, committers, and component maintainers.
    - Set a scope
    - Set a schedule
    - Etc…
 * [@pandjarov](https://profiles.wordpress.org/pandjarov/) (who wasn’t present, 
   so [@francina](https://profiles.wordpress.org/francina/) represented his commitment)
   is ready to work on E2E tests. These have been identified as a must-have even
   if the release model doesn’t change.
 * [@amykamala](https://profiles.wordpress.org/amykamala/) is available for general
   project management and help with facilitating/coordinating E2E testing improvements
   with the hosting team + document.
 * [@clorith](https://profiles.wordpress.org/clorith/) can track down all the various
   teams touched by a release.
 * [@marybaum](https://profiles.wordpress.org/marybaum/) is interested in the human
   side: making sure we have enough people at any stage and make sure there are 
   backups.

Action item: go over the [Google Spreadsheet](https://docs.google.com/spreadsheets/d/1KZ4dZyhco3sbYQ3LGpNbsu7HC4WcTM6SLQHt6Ggjz-Q/edit#gid=0),
see if there is a topic that you are familiar with and it sparks joy. If yes, please
see below and start working on it based on the workflow suggested.

## Tools

We will be using GitHubGitHub GitHub is a website that offers online implementation
of git repositories that can easily be shared, copied and modified by other developers.
Public repositories are free to host, private repositories require a paid subscription.
GitHub introduced the concept of the ‘pull request’ where code changes done in branches
by contributors can be reviewed and discussed before being merged by the repository
owner. [https://github.com/](https://github.com/).

A [repo](https://github.com/francescamarano/release-model-wg) has been created and
we can use the Project feature to keep track of the process.

The workflow will be (at least for now, so we can test it):

 1. Create an issue for the topic researched.
 2. All comments, research, findings will be added as comments. This will help keep
    the discussion focused.
 3. Once the research is ready, recap and move it to a document

## Proposed meeting times

 * 1st and 3rd Wednesday, at 20:00 UTC (alternating with the New Contributors chat
   and back to back with Dev Chat)
 * 1st and 3rd Wednesday, at 8:00 UTC for APAC

Action item: times to be confirmed by group members.

## All right, that’s a lot of info: what is next?

 1. Please confirm in the comments that the proposed meeting times are ok and if you
    are available to facilitate the chats.
 2. [@francina](https://profiles.wordpress.org/francina/) – I will create the first
    issue on GitHub as an example. [Done](https://github.com/francescamarano/release-model-wg/issues/1).
 3. Everyone interested: adopt a topic and get working 🙂 PingPing The act of sending
    a very small amount of data to an end point. Ping is used in computer science to
    illicit a response from a target server to test it’s connection. Ping is also a
    term used by Slack users to @ someone or send them a direct message (DM). Users
    might say something along the lines of “Ping me when the meeting starts.” me if
    you need to be added to the repo. Use the first issue as an example if you wish.

Thank you for making WordPress, now let’s get working!

[#release-process](https://make.wordpress.org/core/tag/release-process/)

 [  ](https://profiles.wordpress.org/francina/) [Francesca Marano](https://profiles.wordpress.org/francina/)
5:12 pm _on_ January 29, 2020     
Tags: release-process   

# 󠀁[Agenda: Release Model Working Group – January 29, 2020](https://make.wordpress.org/core/2020/01/29/agenda-release-model-working-group-january-29-2020/)󠁿

Here is the agenda for the the kickoff meeting happening later today: [Wednesday, ](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20191113T2100)
[January 29, 2020, at 07:00 PM UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200129T1900).

More information about the working group in the [previous post](https://make.wordpress.org/core/2020/01/22/release-model-working-group-kickoff-january-29-2020/).

 1. Short introduction of the scope of the group
 2. Self-assign areas of interest
 3. Decide on tools to track process
 4. Decide on times of meetings

[#release-process](https://make.wordpress.org/core/tag/release-process/)

 [  ](https://profiles.wordpress.org/francina/) [Francesca Marano](https://profiles.wordpress.org/francina/)
8:11 pm _on_ January 22, 2020     
Tags: release-process   

# 󠀁[Release Model Working Group – Kickoff, January 29, 2020](https://make.wordpress.org/core/2020/01/22/release-model-working-group-kickoff-january-29-2020/)󠁿

Thank you for your patience, it took longer than I predicted to kick off this [working group](https://make.wordpress.org/core/2019/12/20/call-for-volunteers-release-model-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 coreCore Core is 
the set of software required to run WordPress. The Core Development Team builds 
WordPress., the 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. [https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)
blockBlock 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](https://make.wordpress.org/core/tag/core/) 
SlackSlack Slack is a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/).
The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](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 capabilitycapability A **capability**
is permission to perform one or more types of task. Checking if a user has a capability
is performed by the `current_user_can` function. Each user of a WordPress site might
have some permissions but not others, depending on their role. For example, users
who have the Author role usually have permission to edit their own posts (the “edit_posts”
capability), but not permission to edit other users’ posts (the “edit_others_posts”
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
 * 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.
 * Release Candidaterelease 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)](https://make.wordpress.org/core/tag/release-process/page/3/?output_format=md#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

 * Blogblog (versus network, site) posts in /news for each stage
 * About page
 * Dev notesdev note 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 guideField guide The field guide is a type of blogpost published on Make/
   Core during the release candidate phase of the [WordPress release cycle](https://make.wordpress.org/core/handbook/about/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](https://make.wordpress.org/core/tag/release-process/)

 [  ](https://profiles.wordpress.org/audrasjb/) [Jb Audras](https://profiles.wordpress.org/audrasjb/)
1:45 pm _on_ January 11, 2020     
Tags: [5.4 ( 53 )](https://make.wordpress.org/core/tag/5-4/),
[dev chat ( 932 )](https://make.wordpress.org/core/tag/dev-chat/), release-process,
[summary ( 980 )](https://make.wordpress.org/core/tag/summary/)   

# 󠀁[Dev Chat summary: January 8, 2020](https://make.wordpress.org/core/2020/01/11/dev-chat-summary-january-8-2020/)󠁿

The chat was facilitated by [@francina](https://profiles.wordpress.org/francina/)
on [this agenda](https://make.wordpress.org/core/2020/01/08/dev-chat-agenda-for-january-8-2020/).

[Full meeting transcript on Slack](https://wordpress.slack.com/archives/C02RQBWTW/p1578517243289200)

## Upcoming Release – WordPress 5.4

[@francina](https://profiles.wordpress.org/francina/) reminded the main feature 
of 2020 will be _full site editing_. All component maintainers received a pingPing
The act of sending a very small amount of data to an end point. Ping is used in 
computer science to illicit a response from a target server to test it’s connection.
Ping is also a term used by Slack users to @ someone or send them a direct message(
DM). Users might say something along the lines of “Ping me when the meeting starts.”
before Christmas to put together a scope for WordPress 5.4. [An open call for tickets](https://make.wordpress.org/core/2019/12/04/wordpress-5-4-open-call-for-tickets/)
was also published on Make/CoreCore Core is the set of software required to run 
WordPress. The Core Development Team builds WordPress.. While [@francina](https://profiles.wordpress.org/francina/)
noted there were mostly bugfixes and not so many new features, [@audrasjb](https://profiles.wordpress.org/audrasjb/)
raised ticketticket Created for both bug reports and feature development on the 
bug tracker. [#48850](https://core.trac.wordpress.org/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](https://make.wordpress.org/core/2019/12/06/update-9-projects-for-2019)
for 2019-2020.

[@azaozz](https://profiles.wordpress.org/azaozz/) noted that the media component
team plan to continue with image post-processing. It looks like it will need couple
of small UIUI User interface changes/enhancements.

[@audrasjb](https://profiles.wordpress.org/audrasjb/) added the accessibilityAccessibility
Accessibility (commonly shortened to a11y) refers to the design of products, devices,
services, or environments for people with disabilities. The concept of accessible
design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning
compatibility with a person’s assistive technology (for example, computer screen
readers). (https://en.wikipedia.org/wiki/Accessibility) team will probably focus
on bugfixes on both 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. [https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)
and Core for 5.4, and target the next major (5.5) for bigger new features.

## Highlighted posts

[@francina](https://profiles.wordpress.org/francina/) noted that a lot of volunteers
signed up to the [release model working group](https://make.wordpress.org/core/2019/12/20/call-for-volunteers-release-model-working-group/).
[@francina](https://profiles.wordpress.org/francina/) will write a recap post on
Make/Core.

Worth noting [@azaozz](https://profiles.wordpress.org/azaozz/) published a [5.3 release cycle post-mortem](https://make.wordpress.org/core/2020/01/08/5-3-release-cycle-post-mortem/).

## Components check-in

Comments: [@imath](https://profiles.wordpress.org/imath/) is working on [#35214](https://core.trac.wordpress.org/ticket/35214).
Feedback welcome.

Core privacy: [@xkon](https://profiles.wordpress.org/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](https://core.trac.wordpress.org/ticket/44038)
and [#44176](https://core.trac.wordpress.org/ticket/44176). Both tickets have a 
patchpatch A special text file that describes changes to code, by identifying the
files and lines which are added, removed, and altered. It may also be referred to
as a **diff**. A patch can be _applied_ to a codebase for testing. and are ready
for further iterations if needed.

Media: [@azaozz](https://profiles.wordpress.org/azaozz/) is experimenting with [#44427](https://core.trac.wordpress.org/ticket/44427).
Seems a very worthwhile enhancementenhancement Enhancements are simple improvements
to WordPress, such as the addition of a hook, a new feature, or an improvement to
an existing feature. for 5.4.

## Open floor

In the agenda comments, [@justinahinon](https://profiles.wordpress.org/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](https://profiles.wordpress.org/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](https://profiles.wordpress.org/timothyblynjacobs/) shared [#47192](https://core.trac.wordpress.org/ticket/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/Capabilitiescapability A **capability**
is permission to perform one or more types of task. Checking if a user has a capability
is performed by the `current_user_can` function. Each user of a WordPress site might
have some permissions but not others, depending on their role. For example, users
who have the Author role usually have permission to edit their own posts (the “edit_posts”
capability), but not permission to edit other users’ posts (the “edit_others_posts”
capability). APIAPI An API or Application Programming Interface is a software intermediary
that allows programs to interact with each other and share data in limited, clearly
defined ways..

[#5-4](https://make.wordpress.org/core/tag/5-4/), [#dev-chat](https://make.wordpress.org/core/tag/dev-chat/),
[#release-process](https://make.wordpress.org/core/tag/release-process/), [#summary](https://make.wordpress.org/core/tag/summary/)

 [  ](https://profiles.wordpress.org/drewapicture/) [Drew Jaynes](https://profiles.wordpress.org/drewapicture/)
12:54 am _on_ March 11, 2017     
Tags: [inline-docs ( 13 )](https://make.wordpress.org/core/tag/inline-docs/),
[minor releases ( 42 )](https://make.wordpress.org/core/tag/minor-releases/), release-
process   

# 󠀁[Continuing inline docs improvements adjacent to 4.8](https://make.wordpress.org/core/2017/03/11/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 coreCore Core is the set of software required to run
WordPress. The Core Development Team builds WordPress.’s inline documentation relied
almost entirely on a regular, major releasemajor release A release, identified by
the first two numbers (3.6), which is the focus of a full release cycle and feature
development. WordPress uses decimaling count for major release versions, so 2.8,
2.9, 3.0, and 3.1 are sequential and comparable in scope. 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](https://profiles.wordpress.org/matt/), and the decision
has been made to go ahead and prioritize some inline docsinline docs (phpdoc, docblock,
xref) 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 JavaScriptJavaScript JavaScript
   or JS is an object-oriented computer programming language commonly used to create
   interactive effects within web browsers. WordPress makes extensive use of JS 
   for a better user experience. While PHP is executed on the server, JS executes
   within a user’s browser. [https://www.javascript.com](https://www.javascript.com/)
 * 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 trunktrunk A directory in Subversion containing the latest
   development code in preparation for the next major release cycle. If you are 
   running "trunk", then you are on the latest revision. will also need to be backported
   to the 4.7 (or current stable) branchbranch A directory in Subversion. WordPress
   uses branches to store the latest development code for each major release (3.9,
   4.0, etc.). Branches are then updated with code for any minor releases of that
   branch. Sometimes, a major version of WordPress and its minor versions are collectively
   referred to as a "branch", such as "the 4.0 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 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.
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](https://make.wordpress.org/core/tag/inline-docs/), [#minor-releases](https://make.wordpress.org/core/tag/minor-releases/),
[#release-process](https://make.wordpress.org/core/tag/release-process/)

 [  ](https://profiles.wordpress.org/ryan/) [Ryan Boren](https://profiles.wordpress.org/ryan/)
5:22 pm _on_ March 4, 2016     
Tags: checklists, pitch, [process ( 4 )](https://make.wordpress.org/core/tag/process/),
release-process   

# 󠀁[Release Process Checklists](https://make.wordpress.org/core/2016/03/04/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](http://atulgawande.com/book/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](http://www.projectcheck.org/checklist-for-checklists.html))
and [this example checklist](http://www.who.int/patientsafety/safesurgery/ss_checklist/en/)
for more.

### Stuff to checklist

The [major release checklist](https://make.wordpress.org/core/handbook/about/release-cycle/releasing-major-versions/)
attempts to use pause points and follow the suggestions above. The major and [minor release](https://make.wordpress.org/core/handbook/about/release-cycle/releasing-minor-versions/)
checklists are pretty rough and incomplete and overlap with each other. These and
the [things to keep in mind list](https://hackpad.com/Things-to-keep-in-mind-during-various-stages-of-a-WordPress-Release-UBcvCVqeXGP)
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](https://make.wordpress.org/core/handbook/about/release-cycle/features-as-plugins/#feature-plugin-merge-checklist).

Checklist bundled theme releases so [stuff like this](https://core.trac.wordpress.org/ticket/35270#comment:3)
makes it into institutional memory.

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. and RCrelease 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)](https://make.wordpress.org/core/tag/release-process/page/3/?output_format=md#alpha-beta).
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 →](https://make.wordpress.org/core/2016/03/04/release-process-checklists/#more-16766)

[#checklists](https://make.wordpress.org/core/tag/checklists/), [#pitch](https://make.wordpress.org/core/tag/pitch/),
[#process](https://make.wordpress.org/core/tag/process/), [#release-process](https://make.wordpress.org/core/tag/release-process/)

# Post navigation

[Newer posts →](https://make.wordpress.org/core/tag/release-process/page/2/?output_format=md)