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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blog (versus network, site):
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 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/ 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 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)., currently scheduled for October 15.
Docs coordinator @justinahinon said 5.3 dev notes 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. 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 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. 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 (and super 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 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) 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 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. 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 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) 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 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).:
- 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 answered @samuelsidler and said that the design team has an experiment plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to use for that.
- @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 A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. 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 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. 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 Created for both bug reports and feature development on the bug tracker..
@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
