Starting with this coming Monday's bug triage, I want to try and make sure the community's voice is heard. In order to do that, I've created the “triage” keyword in Bugzilla. Every week, I'll announce a theme and use this keyword to keep track of the bugs that will be handled in the meeting.
As we discuss the bug, it will be modified, probably assigned to a developer, and the “triage” keyword removed. Some people may see this as bug-spam, but I'd like to keep the email notifications on so that people who have expressed an interest will know that we're giving the bugs some love.
This week, I'm going to focus on Parser-related bugs. There are currently 10 bugs on the with the “triage” keyword applied. A bug triage meeting needs about 30 bugs, so I have room for about 20 more right now. I'll be adding to the list before Monday, but this is your chance to get WMF's developers talking about YOUR favorite parser bug by adding the “triage” keyword.
I will reserve the right to remove the “triage” keyword — especially if the list becomes unwieldy, or if the bug has nothing to do with parsing — but I wanted to start to open up the triage process a bit more and begin to provide a way for the community to participate in these meetings.
Mark.
I love this idea! Diederik
On Wed, Apr 6, 2011 at 5:21 PM, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Starting with this coming Monday's bug triage, I want to try and make sure the community's voice is heard. In order to do that, I've created the “triage” keyword in Bugzilla. Every week, I'll announce a theme and use this keyword to keep track of the bugs that will be handled in the meeting.
As we discuss the bug, it will be modified, probably assigned to a developer, and the “triage” keyword removed. Some people may see this as bug-spam, but I'd like to keep the email notifications on so that people who have expressed an interest will know that we're giving the bugs some love.
This week, I'm going to focus on Parser-related bugs. There are currently 10 bugs on the with the “triage” keyword applied. A bug triage meeting needs about 30 bugs, so I have room for about 20 more right now. I'll be adding to the list before Monday, but this is your chance to get WMF's developers talking about YOUR favorite parser bug by adding the “triage” keyword.
I will reserve the right to remove the “triage” keyword — especially if the list becomes unwieldy, or if the bug has nothing to do with parsing — but I wanted to start to open up the triage process a bit more and begin to provide a way for the community to participate in these meetings.
Mark.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 6 April 2011 23:21, Mark A. Hershberger mhershberger@wikimedia.org wrote:
This week, I'm going to focus on Parser-related bugs. There are currently 10 bugs on the with the “triage” keyword applied. A bug triage meeting needs about 30 bugs, so I have room for about 20 more right now. I'll be adding to the list before Monday, but this is your chance to get WMF's developers talking about YOUR favorite parser bug by adding the “triage” keyword.
This is generally a nice idea, of course, but in the specific case of parser bugs, we already have a keyword for that; I guess you could get your ~30 bugs just by https://bugzilla.wikimedia.org/buglist.cgi?keywords=parser&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&resolution=--- ;-)
-- [[cs:User:Mormegil | Petr Kadlec]]
On Thu, Apr 7, 2011 at 11:32 AM, Petr Kadlec petr.kadlec@gmail.com wrote:
On 6 April 2011 23:21, Mark A. Hershberger mhershberger@wikimedia.org wrote:
This week, I'm going to focus on Parser-related bugs. There are currently 10 bugs on the with the “triage” keyword applied. A bug triage meeting needs about 30 bugs, so I have room for about 20 more right now. I'll be adding to the list before Monday, but this is your chance to get WMF's developers talking about YOUR favorite parser bug by adding the “triage” keyword.
This is generally a nice idea, of course, but in the specific case of parser bugs, we already have a keyword for that; I guess you could get your ~30 bugs just by https://bugzilla.wikimedia.org/buglist.cgi?keywords=parser&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&resolution=--- ;-)
This is an area where the community can help. Of that query, only about half of them have seen any activity at all this calendar year. We spend *some* time in the triage meeting with old bugs that are still a problem, but bugs where no one is even commenting generally are de facto low priority bugs.
Now, if you see something that you think should be high priority on that list, you should provide your reasoning in comment on one of those bugs. Lots of "+1s" are noisy and useless, but if a bug hasn't seen any activity for a few months, it's useful to provide a reminder about why the bug is still important.
Rob
Rob Lanphier wrote:
This is an area where the community can help. Of that query, only about half of them have seen any activity at all this calendar year. We spend *some* time in the triage meeting with old bugs that are still a problem, but bugs where no one is even commenting generally are de facto low priority bugs.
Now, if you see something that you think should be high priority on that list, you should provide your reasoning in comment on one of those bugs. Lots of "+1s" are noisy and useless, but if a bug hasn't seen any activity for a few months, it's useful to provide a reminder about why the bug is still important.
Rob
Sometimes the problem is to determine if it is really a bug or a wontfix...
Petr Kadlec petr.kadlec@gmail.com writes:
This is generally a nice idea, of course, but in the specific case of parser bugs, we already have a keyword for that
This assumes that all parser-related bugs already have that keyword. By asking people to put parser bugs that they thought merited notice on the triage agenda, we've found these, previously un-tagged, parser bugs:
Preceding text and single apostrophes are not included in links https://bugzilla.wikimedia.org/468
[[#foo|]], [[/bar|]] should be equivalent to [[#foo|foo]], [[/bar|bar]] (new use of "pipe trick") https://bugzilla.wikimedia.org/845
Newline as list item terminator is troublesome https://bugzilla.wikimedia.org/1115
Need method for multiparagraph list items, continuing numbered lists, and assigning specific numbers to list items https://bugzilla.wikimedia.org/1584
External URL syntax cannot handle square brackets https://bugzilla.wikimedia.org/3695
Blank lines at the top of an article should be ignored https://bugzilla.wikimedia.org/4161
Block element written inline splits multiline paragraphs https://bugzilla.wikimedia.org/5718
Now, granted, these are older bugs that might pre-date the “parser” keyword but now we've got them.
I think this sort of community involvment in sifting through the huge pile of bugs is just what we need to help us find these sorts of hidden gems.
Mark.
wikitech-l@lists.wikimedia.org