Dev Chat summary: October 2

The 5.3 Release Coordinator, @francina, led the chat (full transcript). For the record, here was the agenda for the meeting.

Announcements and highlighted posts

@francina made some announcements and pointed out highlighted posts from Make/Core blog:

Feel free to browse through these posts and add comments or thoughts.

@youknowriad mentioned Gutenberg 6.6 recap post. This version focused on stability for the editor and performance for WordPress.

Upcoming Releases

Gutenberg team lead @youknowriad said they welcome any testing to detect bugs and regressions before 5.3 release. You can see what’s happening with the editor on this GitHub board.

Site Health component maintainer @clorith reported that desired changes are on track and should be ready for the Release Candidate, currently scheduled for October 15.

Docs coordinator @justinahinon said 5.3 dev notes include some for major changes/enhancements, plus many others. Check out all the dev notes here.

@earnjam reminded the group that each published dev note on Make/Core sends an email to ~4000 newsletter subscribers. He suggested authors limit each dev note to a single topic so people can find things in the index.

@francina shared WordPress 5.3: Accessibility focus progress report.

WordPress project Executive Director @chanthaboune brought up changes that are coming to the admin interface. She stated that the focus leads have been discussing whether to keep the changes or allow extra exploration time for them, as suggested in this post.

Here are the key stances she noted from the various discussions so far:

  • There are some concerns about how quickly the changes were decided on and then implemented from design.
  • There are some concerns raised about the process overall, and whether there’s enough time for testing. Josepha and a few core committers share this concern.
  • There are concerns that further delays will result in loss of momentum from accessibility as well as confidence in an iterative process.

Josepha said she’s doing her best to balance progress with caution, and that she has gotten a lot of feedback from the release focus leads.

Here are the different opinions that have been shared by people regarding this:

  • @garrett-eclipse said that when the changes landed in trunk with several bugs popping up all over, he was leaning towards the pull, but now that the team seems to have addressed and crushed the majority of them, he’s more in favor in keeping the changes.
  • @clorith reminded that while they are worth doing, he agrees on the fact that the changes may have come a bit late in the cycle with limited time for testing and exposure.
  • @mapk asked if the a11y improvements at the cost of design worth immediate and rapid merging, or if we can take the time we need to fully test and address issues?
  • @samuelsidler asked about the items of concerns/tasks that can not or will not be fixed before 5.3 Release Candidate.
  • @melchoyce answered @samuelsidler about tasks that can’t/won’t be fixed before 5.3 RC:
    • Wider design changes to account for the shift in the hierarchy; because the new form fields are so much darker than the list tables, any page where both exist is thrown off a little.
  • @mapk answered @samuelsidler saying that he believes there are other design explorations to address and a committed testing cycle for a large release.
  • @karmatosed shared some worries she has about this:
    • Documentation: those that write tutorials and might find their screenshots out of date.
    • Testing: A longer testing phase for her would be better just like during mp6 project. She thinks that 5.4 should be a focused release, with testing, time and iteration feel safer.
  • @joemcgill said that since he has not been part of the discussions, he would be more concerned by process problems keeping a11y improvements from shipping rather than shipping changes that improve a11y and then iterating on the design.
  • @afercia clarified that most of the design changes come from design and were implemented on top of the a11y improvements. He also mentioned that from an a11y perspective all the matters are:
    • Removing the fixed heights from the input fields etc.
    • Improving contrast
  • He also said that all the other changes are unrelated to a11y and came from design feedback.
  • @samuelsidler asked @melchoyce if there is a plan in place to fix/iterate on those visual issues for the future? If yes, when in the future? He also asked if those improvements happen in 5.3.x or they would need to be in 5.4 or later?
  • @melchoyce replied to @samuelsidler and said that he thinks they would be wide-reaching enough that the design team would need to ship them in 5.4.
  • @earnjam expressed that he would personally lean toward a more cautious approach and allowing further iterating as a feature plugin with an earlier merge in a release cycle to allow more time to catch/fix the bugs. He also feels like we’re trading one set of bugs/issues for a different set and doing it during the beta period.

This discussion has continued with different arguments from design and a11y team members and with other contributors as well. You can read the discussion in its entirety here.

Calls for components maintainers have been skipped for this chat.

Open Floor

@azaozz noted that he’s started to get concerned by the 100+ tickets that are still open for 5.3. He invited maintainers and committers to review and comment on tickets that must be in the release and move the rest to the Future Release milestone.

@afercia said that while the a11y team is committing a lot of things, they will need urgent feedback on #47069 and #43037. @ryokuhi gave a brief explanation about the last ticket.

@davidbaumwald said he’s planning a last-minute scrub due to the high number of tickets that are remaining for 5.3. The schedule for 5.3 scrubs can be found here. Again, everyone is welcomed to attend scrubs and also to organize them.

@justinahinon shared a “Special interest” he has about developer documentation, dev-notes, and WordPress codebase. You can read about it on the chat agenda comments.

@davidbaumwald reminded that they will be doing a lot of punting at the end of the week, so two things:

  • If you have a ticket you absolutely want in 5.3, get moving.
  • If not, at least leave a comment on feasibility for 5.4, or he’ll be moving everything to Future Release if they haven’t seen any movement in a while.

@desrosj clarified that the tickets owned by committers and maintainers have largely been left in the 5.3 milestone to allow those owners to make the decisions they feel are appropriate. If those tickets are not gardened in the next few days they will be punted.

Finally, @azaozz added that the best would be the component maintainers to decide what is good to be in 5.3 and what is going to be in 5.4 of future releases.

That’s the end for this long, lively and important devchat.


#5-3, #dev-chat, #summary