The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
WordPress 5.4 Release Candidate 3 was released on Tuesday March 17th! 🎉Thank you to everyone that has contributed! @johannlinnarsson asked when we might expect the final 5.4 release and @marybaum confirmed that March 31 is the target release date.
Upcoming releases WordPress 5.4
WordPress 5.4 About Page: @karmatosed shared that many many folks contributed to the design and creation of the About page. Thank you to everyone that contributed. Testing is very much appreciated at this point as we prepare for release candidate 4 on March 24.
@jorgefilipecosta mentioned that there are two pull requests that are in need of review for 5.4 and those can be found at this link.
@clorith asked if there was any additional information regarding the recent changes to editor default views and there is currently no new information outside of the discussions in the blog post.
Components Check-In
@azaozz had some exciting Media updates showing off the now merged 1.1 changes for the Lazy Loading Feature Plugin and said that he will be working on a patch to introduce in trunk (5.5.) More to come soon on this much anticipated feature! If you’d like to contribute here is a link to the GitHub repo.
@audrasjb introduced some new changes to WP Auto Updates saying, “WP Auto-updates Feature Plugin version 0.3.0 was released with email notifications for plugins automatic updates. Next version will be focused on porting all the current features to themes screen.” A summary of this chat can be found at this link. If you would like to get involved in contributing to this feature, please feel free to jump into the Feature Plugin GitHub repo.
@pbiron mentioned another plugin that could benefit from some testing; Core Sitemaps plugin is aiming for an early inclusion into 5.5. Please feel encouraged to test it ahead of time! If you’d like to contribute to this feature, explore the GitHub repo!
@aduth provided a #core-js update around their processes. He said, “In the #core-js chat this week, it was suggested to share that our weekly meeting summaries are now including a “News Roundup” of JavaScript and Gutenberg-related items, for those who might be interested or think it helpful to keep in the loop. “ A link to that can be found at the end of this summary post.
Props to @garrett-eclipse for the peer review of this summary. 🙏🏼
@johnbillion got to the heart of the matter: should beta be for fixing bugs that predate the ones introduced during alpha?
@jeffpaul shared his experience since version 4.7: beta is for any bugs, but the release candidate is for regressions only, even though the handbook doesn’t specifically point one way or the other.
@johnbillion liked the idea that beta is for every bug, as long as it’s in the milestone. But he noted that could make things tough in shorter release cycles.
@jeffpaul pointed out that avoiding committing non-regression bugs during beta means Beta and RC wouldn’t be as clearly different from each other as they are now. Potentially, they could merge into a single term.
@johnbillion averred that bugs could still get fixed in beta, but RC should be the point where the Core team is happy to release.
@joemcgill confirmed the current release cadence is set to assume that bug fixes of all types happen during the beta period (with digression from committers about what is safe to commit).
@joemcgill@johnbillion@azaozz all liked the idea of branching earlier in the cycle — for instance, at beta 1 — so people can keep working in trunk, and @sergey confirmed things typically go pretty smoothly on that end. He also favors branching as soon as the current milestone is empty.
per @johnbillion, @matt has, in the past, preferred to keep focus on the current release.
@joemcgill and @francina — with other voices chiming in from the group — confirmed that 5.4 will continue as planned, with no changes. Any changes the working group comes up with will be effective no sooner than with the 5.5 cycle.
@francina proposed a change to the Components Check-in.
Up to now it’s typically fallen towards the end of the chat, so it feels rushed and rarely leaves enough time to dig into topics the group might bring up. She offers two options:
Schedule a weekly post in Make, where maintainers can leave a status update, like the one for Community deputies;
Adopt a Slackbot that, once a week, asks maintainers for a status update.
@francina also proposed that those updates — and other communications — live in a new #component-maintainers Slack channel. Core is getting very busy with automated updates like Trac and Travis bots, plus RSS.
@valentinbora observed he hasn’t seen many check-ins in past meetings. @francina surmised that maintainers might not have time [to meet], or that time zones and other commitments [could be sources of conflict].
@francina and @valentinbora agreed that going async [communicating asynchronously] could help.
@noisysocks is taking the lead on examining the process of compiling dev notes. @audrasjb volunteered to help, and folks mentioned that the dev notes for 5.4 are being put together right now. @desrosj brought up that @jorbin, @jeffpaul, and @desrosj have facilitated the field guide for recent releases and can assist with this item, too.
5.4 Beta 3 is scheduled to be released on February 25, 2020. (Note to committers and maintainers, the cut off time to get bugs fixed and into WP 5.4 is February 25th, 20 UTC)
5.4 is intended to be released March 31st, 2020.
Agenda
Status report on the About page – content and design
Dev Notes status and how to proceed to get them all published in time for RC1 and the Field Guide.
@audrasjb suggested it would be great to schedule one or two bug scrubs before the next beta so we can punt/help the 134 remaining tickets in the milestone. @francina “seconded” with a call out for anyone who has spare time to help organize a bug scrub (See this post for how to run one). Open tickets for 5.4 can be found here (in order of priority). The Bug Scrub schedule for 5.4 lists scheduled scrubs for anyone to join in.
Status Report on the About Page – Content and Design
@karmatosed stated everything is lining up to start the About page earlier this release. There will also be a push to document this. @melchoyce and @elmastudio are leading the design charge on this with @marktimemedia riding along to observe. @marybaum added they’ve got chunks of the copy written and she promised to share it with major-release-squad.
Dev Notes Status
..and how to proceed to get them all published in time for RC1 and the Field Guide.
@audrasjb reports since the last dev chat, four new dev notes were published:
@audrasjb also reports to date, they have a dev note published for about 50% of closed tickets with the `needs-dev-note` keyword in the milestone and 4 drafted dev notes ready to publish. He is very confident they’ll have all dev notes published by the end of the month (during last week before RC1)
@jorgefilipecosta reports he is tracking the progress of the block editor related dev notes and requests that any feedback before the dev notes are published would be great as the content there was not yet reviewed and is just what the original people involved in a PR think the dev note should contain.
@johnbillion asks that if anyone sees changes going into core that they think need a dev note, to leave a comment on the ticket. @audrasjb adds “if you think there are some important tickets that don’t have the `needs-dev-note` keyword, please get in touch with me”. @azaozz asks that you ensure the dev notes are really for developers and are concise and to the point and preferably with a code example of changed usage. @jorbin reminds us to remember the guidelines for posts and the need to have a peer review.
@francina thinks having a separate page with guidelines on submitting dev notes would be helpful. @earnjam mentioned @desrosj would have a draft written up on the subject.
@francina announced the highlighted post. There were no comments.
Component Check-ins
News from Components
Components up for adoption (i.e. looking for maintainers): Filesystem API and Rewrite Rules
Components that need help
Cross component collaboration
News From Components
Administration
@valentinbora reports 1 week after he took up Administration, 40+ tickets have been triaged with 2-3 moved to other components. Per the previous meeting’s discussion regarding the very existence of the Administration component, @valentinbora thinks it’s here to stay.
Gutenberg
@jeffpaulraised the issue of Gutenberg development overlapping existing Core components and how to best communicate with their respective maintainers/teams. @francina proposed a continued discussion about the cooperation between Components and Gutenberg out of the meeting.
Widgets & Menus
@audrasjb noted 3 bug fixes with `commit` keyword and concerns about managing the transition and backward compatibility with tickets referring to current widgets/menus and new tickets referring to full site editing (FSE).
@noisysocks recommends that maintainers of the widgets, customizer and editor components get involved and look at the relevant labels in the Gutenberg repository.
Open Floor – Announcement
@pbiron announced that a new version of the WordPress Beta Tester plugin was released earlier today with a new feature. On the settings screen (`Tools > Beta Testing`), once you’ve already updated to either `Point release nightlies` or `Bleeding edge nightlies`, you’ll see a new option for `Beta/RC`. Once you’ve set that as your current stream, you’ll only be updated when the next beta or RC (or official) is released rather than the nightlies.
One advantage of this new feature is that you’ll be able to update to beta or RC packages right in the Dashboard (Dashboard > Update) as soon as the packages are built during the release parties if you’re not comfortable using wp-cli. Hopefully, this will increase the pool of testers during the release parties.
As the meeting was over time, the remaining two topics from today’s agenda were not started.
Action Items
These items were discovered within the content as stated action items.
@francina to add the bug scrubs to the meetings page (like she did for 5.3)
@francina to add “creating a separate page with dev note guidelines, adding comments to a ticket” to her desiderata. Check with @desrosj who might have a draft of a page with details about how to write a good dev note.
@audrasjb and @welcher should look at Widgets/Menus issues/PR on Gutenberg
@noisysocks to add a ‘call for volunteers’ to the next core editor chat to implement proactive communications from Gutenberg to those component maintainers to help find ways to work together.
@jeffpaul suggests we call out notice to the new WordPress Beta Tester plugin in the Beta 3 blog post (and future posts as well) so folks looking to help test have a starting place.
@clorith wants to chat about how to move more things into a React world and how to do it outside of Gutenberg.
@noisysocks to “put something up” on Make/Core to continue the conversation about cooperation between Components and Gutenberg (i.e. Cross Teams Collaboration).
Here is the Summary of the second Release Model Working Group Chat in #core on Slack at 20:00 UTC!
Thank you to @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.
A GitHub repo has been created for the project, and there are a few open issues for the group to get started with. Here are some areas the group will focus on:
Existing documentation on the 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 and Issue 4 for reviewing documentation can be broken down into different sections.
The internal release process. Issue 3 was created to get that started.
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!
The whole team should be assembled by the end of the week. There is a fewer roles than in 5.3, because it’s a shorter release. The first Beta release is in 3 weeks from now.
@davidbaumwald expects to release the bug scrubs schedule by the end of the week.
@karmatosed added that Core design triages (on Mondays) for a few weeks can also focus on 5.4 to boost things.
@audrasjb noted that depending on the number of accessibility related tickets, the Accessibility Team can organize some extra accessibility focused bug scrubs. He will check the milestone to see if there is a need for more accessibility bug scrubs.
As @azaozz stated, hopefully component maintainers will take bigger and bigger part in “driving” 5.4, and releases in general.
@pbiron asked if there is a specific focus for 5.4. @francina answered that in general, 2020 is going to focus on one big goal: full site editing with Gutenberg. @dingo_d noted that it would need some coordination with the Theme Review Team.
@paragoninitiativeenterprises noted that #49200 needs feedback from anyone interested in WordPress security, or who develops plugins/themes.
@audrasjb is working on two tickets related to Themes and Plugins auto-updates: #49199 and #48850. This is one of the 9 projects for 2019-2020. The design team already provided some helpful feedback. These tickets are now waiting for technical review so they could hopefully land in the next couple of releases.
@marybaum noted her availability for copy review on 5.4 features.
@francina mentioned that development on 5.4 should have started the day 5.4 was branched, back in October. In fact, many people wait for the kickoff to start working. With Beta release scheduled in 3 weeks, it’s not really the time to add not fully ready features to the scope. However, WordPress 5.5 agenda is already known, so there is no need to rush things.
@azaozz and @francina pointed out that as soon as a release’s code is moved to a branch, trunk is back in business for the next release.
@xkon noticed that the “Current Release” widget on Make/Core might be confusing for newcomers as it’s still indicating 5.3 as the current release in progress.
Calls from component maintainers
Media:@azaozz is looking at couple of small enhancements for the uploader changes from 5.3, specifically adding a link in the UI to the original image (if it was scaled), and looking at some of the edge cases when creating image sub-sizes, file size for large PNGs, etc.
Widgets & Menus:@audrasjb will coordinate with @welcher to identify priorities for an eventual specific bug scrub.
Build tools:@johnbillion is going to look at getting several of the Composer related tickets into 5.4 (like using Composer for external libraries and phpunit). @desrosj and @johnbillion to synchronize their work at some point as @desrosj is working on backporting the local Docker environment.
Comments:@imath committed to look at each ticket involving comments in 5.4.
Open Floor
Some new contributors asked about how to start with core contribution. Worth noting the next New Contributor Meeting is scheduled for next Wednesday at 20:00 UTC in #core Slack channel. This is a great opportunity to ask for help or to learn how to contribute to WordPress Core.
