Leading Bug Scrubs

Ensuring tickets move towards a resolution is one of the most important aspects of maintaining the WordPress project. Bug Scrubs serve as one of the ways to make this happen.

Bug Scrubs can have a general focus, focus on a specific component, or focus on a specific report (such as ancient tickets).

Want to learn more? Here is a list of “Potentially Asked Questions”.

Who can run a Bug Scrub?

You! Leading a Bug Scrub is something any interested community member can do.

Top ↑

What is a Bug Scrub?

Bug Scrubs are set and announced meetings where the goal is to go through a list of tickets and move them towards a resolution. They are also something where anyone is welcome to run them!

Top ↑

Where do I get a list of tickets for my Bug Scrub?

There are many pre-generated reports that you can use, such as:

You can also create a custom query. For example, here’s one for defects discussed during the last cycle that don’t have a resolution yet.

Top ↑

What does it mean to move tickets towards a resolution?

There are a number of possible resolutions to a ticketticket Created for both bug reports and feature development on the bug tracker.. Moving a ticket towards a resolution might involve:

  • Pinging a specific person for feedback/information
  • Reviewing a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. and providing feedback on it
  • Adding a new keyword to a ticket

Almost always, it should include a summary of the discussion.

Top ↑

How many tickets should be reviewed in a Bug Scrub?

There is no magic number for Bug Scrubs. It is entirely up to the organizers.

Bug Scrubs work best when they have a specific end goal. This may be a number of tickets or this may be a time period. Generally, 1 hour is a good amount of time and no more than 5 minutes is enough for each ticket.

Top ↑

How do I run a Bug Scrub?

Let’s walk through the steps:

  1. At the start of the scrub, you should:
    • Announce it by opening the Bug Scrub <bug-scrub> tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) and welcoming people
    • Then link to the list of tickets you will be going through. This list should either be a pre-existing report on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. or a query that you generate.
  2. Then post the first ticket for discussion. Make sure to mention it via number or a link so that 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/. auto posts a link so someone can see this ticket was discussed.
  3. Then take a moment to review the ticket and discuss what it needs to move forward. You may call for volunteers for specific tasks.
    • Tip: Sometimes cutting off discussion and moving it back to the ticket with some summary of thoughts makes the most sense. That’s a decision you need to make, though anyone should feel free to suggest it.
  4. Finally, make sure one person is responsible for updating the ticket with whatever decision is made.
  5. Repeat steps 2-4 for the next ticket on the list.
  6. When done, make sure to close </bug-scrub> and thank everyone who helped.

Top ↑

What do I need to organize a Bug Scrub?

You’ll need:

  • An internet connection
  • An account on both 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/ and wordpress.slack.com ( which you can get through https://make.wordpress.org/chat/ with your WordPress.org account)
  • A willingness to devote some time to help WordPress 

You don’t need to be:

  • A coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. or someone that would be called a “core dev” (whatever that means) to lead a Bug Scrub.
  • A developer at all. Designers, project managers, QA engineers, and product managers can be great Bug Scrub leaders.

People that are successful at running Bug Scrubs are people that can communicate well and are familiar with the trac workflow and how WordPress uses keywords on trac.

Running a Bug Scrub involves Bug Gardening, so a tester mindset and understanding users helps as well.

Top ↑

I want to lead one, what do I need to do?

Awesome! Thank you!

You are welcome to schedule a scrub at any time. You will get the most attendees by ensuring it is announced and publicized in advance. Three ways to ensure that happen are: pinging the Core Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. lead for the current release, announcing it during the Core Dev chat open floor time, or by commenting on the Core Dev chat agenda/summary posts with your interest.

Have the report or list of tickets that you want to go through in mind, and someone will make sure your scrub is scheduled in the most appropriate Slack room.

Most scrubs will happen in the #core room, though some components have their own rooms where it makes sense to hold the scrub.

If you are new to leading bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs, you can be paired up with an experience scrubber to help guide you through the process!

Top ↑

What should I do if a ticket won’t realistically get completed in its “milestoned” release?

If a ticket will not likely be completed in a timely manner for a given release, you will want to “puntpunt Contributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.)” it from the milestone. The best approach is to change the milestone to Future Release and not the next major or minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. as this typically ends up with a large amount of open tickets rolling over from release to release. “Punting” them to Future Release allows component maintainers and people particularly passionate about the issue to purposefully, intentionally milestone it for a release.

Top ↑

What if no one else shows up?

This sometimes happens and is fine. It just means you end up publicly sharing your thoughts on how to move a ticket forward. Sometimes people will start to chime in once they see someone being active.

An active bug tracker is one sign of a healthy project. Help ensure the health of WordPress by running a Bug Scrub.

This page is a modified version of the Bug Scrubs for 4.7 post on Making WordPress Core. Props to @jorbin for writing that post.

Last updated: