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:
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.
Here’s a summary of the #core-media chat from January 9, 2020. Weekly media meetings happen on Thursdays at 14:00 UTC; see the full transcript here, in the Make WordPress Slack.
Happy 2020! Because of the holidays, the group postponed chats until Thursday, January 9.
This morning, the group also discussed moving the regular time, so more people can join the chat – particularly people working on critical tickets in the 5.4 release cycle.
Here are three options. Vote for your favorite in the comments:
Move the current Thursday 14:00 UTC time to 15:00 UTC
Move the date to Tuesday at 21:00 UTC (this option works well for the three who came to today’s meeting.)
Multiple meetings, to account for both sides of the world. This option would likely require a push of the currently scheduled meeting to 15:00 or 16:00 UTC as well as an agreed time and date for the second meeting. @joemcgill suggested that multiple meetings not be forced to cover the same agenda items. Some items will overlap where it makes sense, but, for example, if one meeting has cleared the ticket queue, it would be pointless for the next meeting to consist largely of a triage.
New Media ticket triage
#48194 – Unregistered image sizes used for IMG tag “srcset”
As @joemcgill pointed out: “The problem here seems to be that someone has deleted image files that are still referenced in the database in attachment metadata. Regenerating image sizes ( wp media regenerate ) would fix this problem, but should we only use registered sizes in `srcset` attributes if there are other sizes available?”
#48321 – Hotswapping featured image with gallery images
It seems the ask is for (after creating gallery) the option to click on one of the gallery items and set as featured image of the associated post. It was agreed by attendees that this may not be best fit in the gallery block UI and perhaps would be better fit as an option within the media modal when creating galleries, images, etc.
The group changed the ticket to ask for reporter feedback.
@karmatosed made another point. The “Uploaded to this post” filter, in the Set Featured Image modal, does give the reporter part of what they’re asking for.
#48325 – Additional filter in media-template.php. Let developers hide attachment page link.
@joemcgill pointed us to the code that creates the attachment link: https://github.com/WordPress/WordPress/blob/master/wp-includes/media-template.php#L511 and said, “At minimum, I think that template should check that data.link is actually a URL before displaying [it]. [Developers] could filter the data that is used by this template.”
WordPress 5.4 Media Focuses
While it didn’t come up in the meeting, notes are a great place for all of us to develop ideas for Media focuses in 5.4.
If you have any media-related focuses you’d like to work on in the 5.4 cycle, and that you’re ready to work on, please leave a comment.
That helps the Media maintainers gather and prioritize the work. Plus, it would be great if you’d come to next week’s chat so we can all discuss your idea!
There seems to be a strong will to increase the number of releases per year and some exploratory work has been already done by multiple sources. Now it’s time to put it all together and move forward with a plan of action.
What problem needs to be solved
WordPress releases involve quite a lot of manual labor and testing so the releases right now can’t be more than 3, 4 per year. Core contributors are eager to move to a more frequent cadence.
Scope of the Working Group
To evaluate what is needed to change the Core release model in terms of procedures, cadence, resources and produce a report that will:
Document the existing release process
Evaluate the technical changes needed to speed up the release process
Evaluate if those changes are doable with the existing resources and tools
What has been done so far
A few people have already done some research and told their experience during dev chats or in the above-mentioned posts, including in the comments.
In particular, some blockers have been identified and the working group aims to document all of them and find reasonable and feasible solutions. Here is a nonexhaustive list of things that have been mentioned:
scoping the release
putting together a release team
the process itself: automated, semi-automated, manual tasks
supporting fewer PHP versions
supporting fewer WP versions (for security and other things)
better E2E tests and vuln tests
Tide support
writing the announcements
writing the dev notes
writing the field guide
Prerequisites
The team needs people with different skills and levels of expertise
A project manager/coordinator to make sure work gets done
People with commit and mission control experience to document the process of the release itself
People able to write E2E and vuln tests
People that worked in previous released and are familiar with the coordination part: from scope to release.
Historians! People that have been contributing for a while and are able to provide some background and context.
Anyone who is willing to help 🙂
Time commitment and frame
Between 2 and 3 hours a week, more if you want to!
By the end of 5.4 release the group should produce:
A research of the various steps of the release
An evaluation of the technical changes needed
A draft of the feasible proposed changes
Communication and project management
I propose the group meets weekly in #Core and adopts a project management tool for the research phase – Trello would be my suggestion. Once it moves to build solutions (hopefully!) Trac or GitHub can be used.
Who is in?
Please drop your name, WordPress.org and Slack username in the comments if you are interested and how you think you can help.
Deadline: January 5. Hopefully, work will start on January 7th or 8th
The following is a summary of the weekly media component meeting that occurred on Thursday, December 19, 2019. Weekly media meetings are held every Thursday at 14:00 UTC. A full transcript can be found here in the #core-media room in the Make WordPress Slack.
Due to the holidays, we are postponing weekly meetings until Thursday, January 9.
Additionally, we are planning to adjust the meeting time in the new year to allow for better attendance from people working on priority tickets during the 5.4 cycle. @joemcgill will be reaching out to component maintainers to gather preferred times and will post an updated schedule before January 9.
WordPress 5.4 Media Focuses
As planning for WordPress version 5.4 is beginning, @francina has reached out to component maintainers to see if there are any major plans for this release. Here are the items currently being discussed:
#44427: Introduce lazy-loading API for media and other elements – @flixos90 is leading this effort and will be looking for feedback.
@azaozz plans on working on more meaningful error messages when uploads fail (possibly in cooperation with Site Health).
@azaozz also plans to look into deprecating some of the “notoriously misused” image related functions, like constrain_size_for_editor().
Several other regular contributors are still working out how much time they’ll have to contribute in the new year and what their focuses will be.
If anyone has any additional media-related focuses they plan to work on during the 5.4 cycle, please leave a comment below so we can gather and prioritize work in the new year.
