Bug scrubs are conducted throughout the WordPress project as a way to quickly review Trac tickets and identify next steps. CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Performance bug scrubs can be held by any team member at any time. That said, the Core Performance Team holds a scheduled bug scrub every 2 weeks on Wednesdays and the current meeting time is always up-to-date on the Meetings calendar.
Bug scrubs are informal meetings and do not require posting an agenda before or summary after.
Responsibilities and access
Anybody can host a bug scrub. To host the regular scheduled bug scrub, please add your WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ user name in one of the vacant meeting slots in the bug scrub hosts spreadsheet. The Core Performance Team Reps are responsible for ensuring that upcoming meetings have a host assigned. If an upcoming meeting is missing a host, they should reach out in the #core-performance channel to kindly ask for a volunteer.
There are no technical requirements for hosting a bug scrub other than having a WordPress.org account and a WordPress 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/. account. Ideally you have access to use the /here command in the #core-performance channel on Slack, but this is not a requirement.
Please feel free to host a bug scrub at your own convenience. The scheduled bi-weekly bug scrubs are purely in place to ensure there is a regular cadence. But more bug scrubs are always welcome and appreciated.
Running the bug scrub
A Core Performance Team bug scrub is not a meeting in the traditional sense. The format involves the bug scrub host, a single person (rotating for each scheduled bug scrub), that works through a specific WordPress Core TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket or Performance Lab issue “report”. It is an informal meeting with flexible structure.
A report is a list of specific Trac tickets / GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issues that can be publicly shared with others via URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org. Some examples:
- Performance tickets milestoned for WordPress 6.9, sorted by least recently modified
- Performance tickets with a patch that are milestoned for a future release, sorted by most recently modified
- Performance tickets awaiting review, sorted by most recently created
- Performance tickets awaiting review, sorted by least recently modified
- Performance tickets labelled “good first bug”, sorted by most recently created
- Performance Lab issues milestones for one of the next releases, sorted by most recently created
- Performance Lab issues labelled “good first issue”
- Performance Lab issues sorted by least recently updated
The bug scrub host should choose a report to work through (either from the above list or any other performance relevant report) and share the corresponding URL on Slack. The host should then encourage anyone watching to review the relevant tickets asynchronously afterwards and, if needed, follow up with another comment if there are questions or concerns about a decision taken by the bug scrub host.
As the main part of the bug scrub, the bug scrub host should then work through the tickets / issues in the report on their own, providing an update on every ticket they work through. This could be changing the milestone, changing the priority, changing assignments, changing keywords, or asking for an update by the reporter or the PR author, just to name some examples.
The bug scrub host may share whatever they think is valuable in the Slack channel too. That said, as the bug scrub is no traditional meeting, there is no need to wait for other folks that are potentially around to weigh in.
Ideally each bug scrub should last at least about an hour, though the bug scrub host is of course free to continue if they like. Once they stop scrubbing tickets, they should share this update on Slack, formally concluding their bug scrub.
Example messages
Feel free to copy and paste these messages, or ignore them and write your own. These examples are here only for reference and are by no means a guideline or required to be used.
Bug scrub start
- /here Hey there! I’m about to start a performance focused <bug-scrub>.
- Today I will work through tickets in the following report: <report-url>
- I will leave updates or comments on each ticket as I go through the list.
- If you’re around, please feel free to review these tickets as well and share any thoughts you may have. You can do so either in a reply to my ticket update or, if it’s a ticket I haven’t gotten to yet, feel free to leave a ticket comment already or send a chat message right here in the channel.
Bug scrub end
- And that’s it for the bug scrub today. Please remember that anyone is welcome to run a bug scrub like this at any point. Feel free to reach out if you have any questions.
- Thank you to anyone around, and see you in 2 weeks!
- </bug-scrub>
