APAC Triage and Bug Scrub Sessions

Living in APAC timezones can be difficult. From waking up at 3am for meetings, to flying 20+ for WCUS or WCEU (WCAsia is coming to fix that!), to hearing “what’s it like living in the future?” jokes for the millionth time. One thing that shouldn’t be hard is contributing to WordPress, and it’s time to make that even easier, with APAC-friendly triage and bug scrub sessions.

You may have already seen Gutenberg meetings happening every second week for the last few months, but starting Thursday at UTC 0600, we’ll alternate each week between working on WordPress Core, and Gutenberg! This week, join in the fun in the #core Slack channel for a WordPress Core bug scrub. Next week, the party will be in the #core-editor Slack channel, for a Gutenberg bug scrub. 🎉

The meeting lead will pick a report to work through, but if there are particular issues you’d like to get more eyes on, or you have a patch/PR that you’d like reviewed, this is the place to bring it up!

#apac, #bug-scrub, #core, #core-editor, #gutenberg, #triage

Reverting the Bulk Ticket Closing

Recently, a bulk modification was performed on Trac affecting 2,300+ tickets that had not seen any activity in 2 years or more. These tickets were closed and marked as wontfix. To read a more detailed breakdown, check out the previous post on the subject.

After discussing, it has been determined that the bulk action should be reverted, but only for tickets that have not had their status changed or otherwise confirmed via comments that closing is acceptable since the bulk closure. It can be safely assumed that closed tickets updated after the bulk edit have been appropriately groomed and should remain in their current state. A full list of tickets slated to be reopened can be found using this Trac query.

Tickets should only be closed if they have been individually evaluated and it is determined that they are either no longer relevant, have been fully and properly addressed, and any changes have been adequately communicated to the community.

These tickets will be reopened during the week following the 5.1 release (February 24-March 2) by @jeffpaul and myself (@desrosj). All reopened tickets will be placed in the Awaiting Review milestone so that they can be properly triaged by component maintainers and the Triage Team in the coming months.

#trac, #triage

On WordPress + Git

Can you believe it – we’ve made it through a State of the Word without anybody asking “when is WordPress moving to Git/GitHub?” You may, however, have caught a brief mention of issue trackers in relation to the Triage Team focus for 2019. While it’s very important to make the distinction between Git the version control system (VCS) and GitHub the service, as the answer usually goes, it’s understandably a continued area of interest. Many parts of WordPress have been developed using GitHub as the central tool, along with countless plugins and themes and even the WordPress book.

Here’s the tl;dr (but you should definitely keep reading after this): Changing things up doesn’t just mean “let’s make the GitHub mirror at WordPress/wordpress-develop the canonical and migrate Trac tickets over” – it means imagining what kind of change would be a net benefit to the core development process and eventually the entire .org ecosystem, and then finding the right tools to do it.

To that end, there is a group of people including myself (@helen), @desrosj, and @omarreiss who have been and will continue to be doing more coordinated research and planning around tooling. There is no current planned timeline nor is this a priority on top of the projects already enumerated for 2019, but any potential tooling change is being evaluated as it potentially relates to those projects, especially if it can better support phase 2 of Gutenberg development and the Triage Team.

This is not about chasing the latest and greatest or evangelizing a preference – it’s important to identify the goals we have for the project and what pain points we are experiencing. More specifically than “democratizing publishing”, in the core development process we should be aiming for diverse participation, a faster-but-steady pace of development, predictable and timely feedback cycles, and continuing to build user trust among users of all types. Recent pain points have been merges between branches (especially 5.0 back to trunk), JavaScript package updating, and continued participation when projects move from plugins and GitHub into core and Trac.

Roughly, here are some early thoughts on various moving pieces and potential future improvements.

Repositories and Workflows

  • SVN repositories would need to remain, essentially flipping the mirroring process to go from Git -> SVN, making SVN (and Git) repos on .org read-only
  • Should the core build process continue to be handled as-is or should we move to something like Travis?
  • Integration of more automated testing – visual regression, end-to-end, accessibility, performance
  • Identification of the ideal lifecycle of an issue and process for a pull/merge request – design, docs, review, testing, etc.
  • Identification of contribution workflows (contributor documentation, Git branching methodology, etc.)
  • Security tracking and releasing

Issue Tracker

  • Critical for a Triage Team to review existing issues and to remain active going forward
  • Potential for the bulk triage process to include migration from Trac to another tracker
  • Any issue migration should be determine on a case by case basis by the Triage Team in collaboration with component maintainers; the most automation that should happen is a tool that takes a list of Trac tickets and imports them elsewhere
  • Issue import process needs to take commenter attribution into account
  • Trac would remain in a read-only state
  • How are reports generated and used (i.e. is the built-in filtering capability enough in a given tool or will we need something more robust to support workflows)
  • Is the issue tracker still the best place for feature requests?
  • Implementation of issue templates
  • Identifying existing custom integrations and whether those problems still exist and still need to be solved after a move

Broader Ecosystem (later / bigger question mark)

  • Connectors from GitHub to .org plugin and theme repos (GitHub Actions-powered build+deploy)
  • Automated testing – sniffers, Tide, unit tests, WP and PHP compat testing, Theme Check
  • Aligning plugin and theme review teams

#git, #trac, #triage

If anyone has time this week there are…

If anyone has time this week, there are about 100 tickets that need to be reviewed for potential 3.2 issues we missed. The first page of Report 40 lists “Defects Awaiting Review, reported against trunk” and “Defects Awaiting Review, reported against no version.”

Basically, we’re just looking for bugs to 3.2 features, and regressions. Many of these either need the version numbers dropped (or added) or converted to enhancements. If someone wants to do full triage, ping me or someone in IRC and we’ll arrange milestone adjustments.

Update: Specifics on how to help.

  • The Version field is for the earliest known version that the ticket affects. For bugs, this would be the version to which it applies or was introduced. All the ones that say “3.2,” if they aren’t new bugs in 3.2, then they should be changed to 3.1 or, for extra credit, earlier.

  • If the ticket is pushing for an enhancement, rather than reporting a bug, then simply change the Type field to “enhancement.” (Rarely “feature request,” never “task.”)

(Contributors who have participated on Trac before will of course know to adjust keywords, perhaps even adjust milestones and what not. But these are two simple ways to help clean up this report.)

#trac, #triage