My first priority as a member of the Automattic team is wading into WordPress bug reports. This is my new bug garden.
In bug gardening my goals are:
- Gain a better understanding of the product.
- Confirm bugs.
- Verify fixes.
- Add to the knowledge the reports contain.
- Consider and possibly adjust severity, priority, milestones, tags, etc.
- Weed out duplicate, stale and invalid reports.
- Close bug reports that are not high severity or priority, and don’t have developer interest.
The last goal is often controversial in QA communities. I know how annoying it can be to have your bug closed, particularly with the label WONTFIX.
But it does not mean won’t fix ever. It just means won’t fix now.
You are welcome to reopen it to clarify the case for it being a priority. Also, if a bug should have a higher severity, it will likely get reported again soon.
What happens if these bugs are not closed? They get in the way of (having fun) getting work done:
- Every time someone searches for a bug, they are more likely to have to read through bug reports that do not describe the severe problem they are encountering.
- The bugs get stale long before they are fixed, and so when finally considered for fixing, the work is often greater than the reward.
- Regularly (often when milestone are reached) these bugs have to be re-evaluated to find out why they are still open and when they should be fixed.
Matt and Ryan said to me that there were too many weeds in the WordPress bug garden. There were 717 bugs when I started on Monday. Even if all those bugs were up to date, valid bugs, it would be too many active bugs for a team that I would guess equals between 5 and 10 full time developers. Way too many!
How many detailed records can you keep sorted in your mind? How many will you get to in the next six months?
Consider a project that both amazes and scares me, Firefox. It has 9271 open bugs! Of those, 7377 are assigned to nobody. Do you think they have a problem?