Dev chat summary: March 17, 2021

@francina led the chat on this agenda.

Announcements

The big news: WordPress 5.7 “Esperanza” landed March 9, and the group took a well-deserved bow.

Moving on, Francesca highlighted these posts:

@jeffpaul noted Trial run: Consistent minor release squad leaders for each major branch. Francesca added that the post is both a highlight and a call for volunteers.

@annezazu put out a last call for FSE Program Testing Call #3: Create a fun & custom 404 page. If you’d like to catch up on the previous two FSE tests, Anne and Francesca said you can find previous calls under this tag. If you’d like to do your own testing, the FSE Handbook has a page with instructions. Capping off the FSE discussion was Marketing Team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. @webcommsat, who said you can also share this LinkedIn promotion.

@francina then turned to posts that need feedback. This Proposal: A WordPress Project Contributor Handbook drew spirited emoji support from the group. Francesca also reminded the group to sign up for the Updates blog to keep up with a variety of team updates, as well as posts from @chanthaboune about cross-team efforts and the latest news from leadership.

Components check-in and status updates

@sergeybiryukov started with jQuery news: the version in 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. has updated to 3.6.0, which is mostly bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes and improvements. Two callouts:

Aside from the change to no longer ensure XHTML-compliant tags for you, we do not expect other compatibility issues when upgrading from a jQuery 3.0+ version.

See ticketticket Created for both bug reports and feature development on the bug tracker. #52707 for more details.

 jQuery hoverIntent library has updated from version 1.8.3 to 1.10.1. The changes all appear to be minor.

See ticket #52686 for more details.

@adamsilverstein checked in with Media news: he’s working on landing support for WebP images in 5.8 and would like testing and feedback on ticket #35725.

Up next, @audrasjb said he has nothing new for Menus and WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user., but he’s quietly scrubbing bugs and watching tickets. On Upgrade/Install, he highlighted this feature plugin proposal post.

@sabernhardt wrapped up the Component updates with his announcement of a Toolbar triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors./bug scrub for the following day, March 18, at 16:00 UTC.

Open floor

IE11 support

@adamsilverstein asked: Given that the Project has decided to drop support for IE 11, have we discussed a specific release to make that change in?

The discussion that followed outlined a general process—notify, then act—but pointed out the group still needs to make a specific plan for IE11. Adam noted that IE11 is the only major browser that doesn’t support WebP images.

@desrosj said there might already be a notification in place. @adamsilverstein found a ticket, #48743, to that effect. Further discussion also made it clear that the team needs to do more to announce the change, including stronger language in relevant tickets (@desrosj and @audrasjb), a News blogblog (versus network, site) post (h/t: @jorbin) and relevant Handbook updates (h/t @jeffpaul)

“Try FSE?”

@sergeybiryukov observed:

It seems that most of WP users (outside of the contributing teams) are still largely unaware that full-site editing is coming later this year.

Perhaps that’s intentional, but once we have something stable to test, have we considered adding a dashboard widget to one of the upcoming minor releases, to invite more users to test FSE before final release, like we did with 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/ in #41316 for WP 4.9.8?

See the full discussion that followed, with a variety of people sharing a variety of views on the subject.

#5-7-1, #5-8, #core, #dev-chat, #meetings, #summaries, #summary

Devchat summary: February 26, 2020

@francina facilitated the chat on this agenda.

@valentinbora took care of publishing the meeting summary with special thanks to @amykamala, @audrasjb, @Cenay and @marybaum.

Full Meeting transcript on Slack

This devchat marked week 7 of the 5.4 release cycle.

Announcements

Upcoming Releases

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). 1, scheduled for March 3rd (read more about the WordPress 5.4 Development Cycle)

WordPress Release Cycle

For background, please read:

@johnbillion got to the heart of the matter: should 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. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., 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-regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. 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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 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., 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 stressed that the core team needs more clarity on what types of fixes are appropriate to commit to the 5.4 release, pointing out that the discussion in chat echoes this proposal to review historical practices to improve the project and potentially speed up release cycles.

@francina referred the group to the Release Model Working Group Chat Summary: February 19th, 2020 for the latest on that proposal.

@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.

Components Check-in

  • News from components
  • Components up for adoption (Filesystem API and Rewrite Rules)
  • Components that need help
  • Cross component collaboration

@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:

  1. Schedule a weekly post in Make, where maintainers can leave a status update, like the one for Community deputies;
  2. 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 SlackSlack 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. Core is getting very busy with automated updates like TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. 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 conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved.].

@francina and @valentinbora agreed that going async [communicating asynchronously] could help.

@cenay was in favor of the Slackbot option.

Action items

  • @francina to collect all the different info streams about the development cycle, offer a window to comment and update documentation;
  • @audrasjb to get all 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 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. by the end of the week and publish 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. 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. before RC1.

Next Meeting

Meetings for #devchat take place weekly in the #core channel. The next meeting is Wednesday, March 4, 2020, 21:00 UTC.

#5-4, #component-maintainers, #core, #dev-chat, #meetings