Component Maintainers in 5.3

On the heels of APAC Triage and Bug Scrub Sessions and Bug Scrub Schedule for 5.3, thanks @pento and @davidbaumwald, I’d like to propose something a little bit different.

The WordPress 5.3 release is shaping up to be substantial. There are tons of fixes and improvements in Gutenberg, for both users and developers. Even if 5.3 only included the Gutenberg update, it would have been a very nice, very desirable upgrade.

There is more to this release! Currently there are 632 tickets on the 5.3 milestone on Trac, both open and closed. A few smaller new features and user facing enhancements are in the works, and a lot of bugfixes and under-the-hood improvements are coming up or already done.

I’d like to propose that component maintainers take more “charge” of the tickets in their components. There is a general expectation that if you moved a ticket to a milestone you are the “lead” for that ticket and will see it through to completion, or move it to a future milestone if not feasible. But that shouldn’t stop component maintainers from helping to keep those tickets moving.

With the scheduled bug scrubs, and the per-component bug scrubs that usually happen at the components’ meetings, the 329 open tickets aren’t that big of a mountain. 

The 5.3 Challenge

During the next few weeks (by beta-1 scheduled for 23 September) join me in making sure all 5.3 tickets in our components will either be resolved or moved to a future milestone. And if there are any hurdles leave a comment on the ticket briefly outlining the difficulties and include a resolution timeline.

It would also be helpful if during this time all component maintainers do a short, concise update about their component on the weekly core dev chats. These updates would typically include the number of open 5.3 tickets and whether there are any difficulties with any of them. This will help people know where help is most needed, especially any newer contributors who are having trouble deciding where to spend their time.

Also, we have a Docs Wrangler for our release! After 5.3.0-beta-1 is out, it would be great if component maintainers review all changes to their component (if not already reviewed), then, if possible, help @justinahinon with writing or editing dev. notes. There are currently 301 fixes and enhancements committed to the 5.3 milestone and they will need documentation.

The proposed change for component maintainers is to act early, before beta-1, and to regularly make updates and bring any difficulties to the core dev chat.

#5-3, #bug-scrub, #components, #core

Dev Chat Summary: August 28th 2019

This post summarizes the weekly dev chat meeting from August 28th 2019 (agenda / Slack Archive).

Announcements

@chanthaboune mentioned a Make/Core post about using SSL for auto-updates.

@francina mentioned the recently created WP-Notify working group. They had their first meeting and they have two weekly meeting so people from different timezones can attend. If you are interested, join #feature-notifications dedicated slack channel.

WP-Notify was also added to the features list page on Make/Core.

@francina also mentioned there is a new time slot for Core tickets/Gutenberg issues triage and bug-scrubs. If you are in the APAC timezone feel free to take part into the bug scrubs, they are great to get started in understanding how WordPress is made.

Upcoming Releases

5.2.3

5.2.3 RC 1 is available for testing.

Release lead @whyisjake mentioned they are skipping RC2 for 5.2.3 as there are no new commits since RC1 and no regression was reported against RC1. The final release is scheduled for this coming Wednesday.

Please continue testing, and provide feedback. If you are new to testing Core releases, there is a guide to get started. Getting involved in testing WordPress means you will be directly involved in raising the quality of the WordPress user experience.

5.3

@francina announced that @audrasjb is joining the Release Team as focus lead for the accessibility part.

@davidbaumwald ran the first bug scrub of the release cycle, focused on tickets that are milestoned for 5.3, but haven’t see any movement in some time.

@johnbillion: “We need more people attending bug scrubs and scrubbing bugs. Tell all your friends.”. @davidbaumwald added that’s being added for the 5.3 cycle to give props for those running scrubs.

If you want lead a scrub, please get in touch with @davidbaumwald and it will be added to the official schedule to spread the word.

@azaozz mentioned it would also be great if component maintainers could help triage their components.

@audrasjb mentioned the accessibility team will run two additional bug scrubs dedicated to 5.3.

@karmatosed mentioned the design team also runs weekly bug scrubs.

@davidbaumwald is maintaining the list of 5.3 bug scrubs. There was a discussion about having it as a sticky post to see if it helps to increase the number of people attending bug scrubs.

@karmatosed published a post concerning the design of WP core About Page. The post is to start a discussion about what could be easier about this screen. It has a few of the current problems around it and then leads into some potential ideas. Any input on this is welcome.

Call for component maintainers

As per today, there is 6 components without maintainer. Any interested contributors is welcome to help maintain components.

@justinahinon mentioned his interest for the Site Health component.

@francina asked if all the components who seem to have a maintainer really maintained.

@jeffpaul did one component maintainers audit this year and one last year, so the current listing is nearly almost folks who committed to maintaining as best they can.

#5-3, #5-2-3, #bug-scrub, #components, #feature-plugins

Call for Component Maintainers

WordPress is organized into 60 components. Each component can have more than one maintainer. A maintainer triages new tickets, looks after existing ones, spearheads or mentors tasks, pitches new ideas, curates roadmaps, and provides feedback to other contributors.

Pings/Trackbacks, Date/Time, Autosave, Quick/Bulk Edit, Export, Import, Mail, Permalinks, Rewrite Rules, Post Thumbnails, Menus, and Role/Capability are currently without a maintainer. Are you familiar with one of the components and want to help to maintain this component? Please comment below or ping @jorbin or @ocean90 on Slack if you’re interested.

 

The list of component maintainers is a living document. If you are no longer actively maintaining a component, please remove yourself or let us know so that the list can be as accurate as possible

#4-6, #components

Component Page Updates for 4.4

Now that 4.4 is underway, let’s update the component pages to reflect 4.4 activity. The Customize, Editor, and Press This pages serve as good templates, though they all need 4.4 updates. The component pages are targeted at beta testers. They should describe the component, list milestones (roadmap), and explain what needs testing and how to test it. Good component pages assist triage. For details, see the previous round of component page updates.

Also, if your component has a corresponding Slack chat, link to the component page from the chat’s channel topic. This assists using Slack in beta testing flows.

Component maintainers, here are your component pages…

Continue reading

#components, #maintainership

Proposed Trac component reorganization

Warning, this long. tl;dr: I propose a reorganization of our Trac components. 34 top-level components with two dozen subcomponents. New tree at the bottom. First, an overview of some of our problems.
Continue reading

#components, #trac

Continuing the Trac component re-organization with "focuses"

Based on triaging a few hundred tickets in the General and Multisite components, we’ve added five components:

  • Bootstrap/Load — applies to wp-settings.php, ms-load.php, load.php, ms-settings.php, etc.
  • Login and Registration — useful for multisite, but applies to single-site too
  • Options and Meta — option.php, meta.php, etc.
  • Script Loader — WP_Scripts, WP_Styles, and script-loader.php
  • Networks and Sites — multisite only

We also removed two components that (poorly) described the problem rather than the affected area of core. “Validation” ranged from from validation tickets to XHTML issues. HTML validation issues now belong in the affected component, like “Template” or “Administration.” “Warnings/Notices” contained tickets ranging from PHP warnings to providing feedback to users. The open tickets were moved to more appropriate components. Additionally, the remaining tickets in “AtomPub” were wontfixed and the component was removed.

A new concept: Focuses

We’ve also added seven new “focuses”ui, accessibility, javascript, docs, multisite, performance, and rtl. Focuses are about broad concepts and help break tickets down by specialties and skills, rather than functional areas of core. Multisite and RTL are widely general “modes” for WordPress, and each have contributors who focus strongly on those areas, but they are not well-contained “components” of core. Accessibility isn’t an area of core — it permates the entire user experience. A ticket about inline documentation should still receive the attention of developers for that area of core (say, comment.php), while those who focus on inline documentation should still be able to do so.

“Focuses” is a new field in Trac. They’re like tags, and more than one can be assigned to a ticket. It can be queried using custom queries. And they have their own reports which we hope to properly expose and make better really soon — https://core.trac.wordpress.org/focus/accessibility.

Guidelines to help with the transition

The corresponding components for the new focuses have been removed. The “ui-focus” keyword has also been converted over. Overall, we gained five components but lost eight.

This has the potential to be confusing at first and we’ll surely need to make some adjustments. Also, the component cleanup is not done yet — this is just the beginning. Here are some guidelines for how to use the new focuses.

  • The old RTL component — use the rtl focus and assign a relevant component. If it’s RTL issues with the media library, use the “Media” component. If it’s about the RTL build tools, then use the “Build Tools” component. If it’s more general, then use the “I18n” component.

  • The old Accessibility component — use the accessibility focus and assign a relevant component. For issues with the media library, use “Media.” For issues with activating a theme, use “Themes.”

  • The old Inline Docs component — use the docs focus and assign a relevant component. Hook documentation for user.php belongs in the “Users” component.

  • The old Multisite component — use the multisite focus and assign a relevant component. If it’s related to users, use “Users.” If it’s related to the loading process of multisite (choosing a site based on domain and path, etc.), use “Bootstrap/Load.” If it’s related to the installation process, use “Upgrade/Install.” network_admin_url() goes into the “Permalinks” component. get_site_option() is “Options and Meta.” The Network Admin still has its own component. (Choosing that component or “Networks and Sites” automatically assign the “multisite” focus for you.) @jeremyfelt recategorized about 110 tickets into about 15 different components.

  • The old Performance component — use the performance focus and assign a relevant component. Improving the performance of WP_Query belongs in “Query,” improving the performance of get_option() belongs in “Options and Meta,” etc.

  • The old Graphic Design component — use the ui focus and assign a relevant component. (This is probably going to be “Administration”, at least for now.)

  • The old ui-focus keyword — This has been removed. Simply use the ui focus.

  • The old JavaScript and UI components — these have not existed for some time. Use the corresponding focus and assign a relevant component.

We may add more focuses over time. For example, the “Text Changes” component would probably make a better focus, for our wordsmiths.

Any questions, suggestions, or comments?

This is a summary and addendum of one section of this Wednesday’s weekly developer meeting. Logs.

#components, #trac

It might be useful to create a …

It might be useful to create a “Text” component that people could use for reporting typos, suggesting text changes, etc. This would also automatically be a good starter component for people who need something super easy to learn how to submit a patch.

#components