Talk:Bug triage
Requesting input from other developers
Sometimes it's hard to know when somebody has been added as watcher in order to require input from him/her. That's because own watches aren't different at all from "request watches" from other developers.
IMO it could be really interesting to have one new field, possibly only for developers and testers, in order to request input from other moodlers. That way, we could have one simple filter, call it, "Bugs I've been requested to input about". By taking a quick look to that list daily I think we could improve the decision process in a nice way.
Commented with Martin and agreed about to suggest it here. Thanks! --Eloy Lafuente (stronk7) 10:51, 31 March 2008 (CDT)
- Eloy, I like your idea, however I don't know a way of creating a field for developers and testers only. (I wish fields like QA assignee and difficulty could be removed from the create issue form to make the form shorter.) Perhaps we could implement your idea by reassigning the issue to someone when you want their input and adding a comment like 'Reassigning to Helen for her input on whether more documentation is needed. Please reassign back to me afterwards.' --Helen Foster 13:02, 3 September 2009 (UTC)
- Yes, temporal reassigning could be a solution, but main problem is that the original assignee can lost the track of the issue easily (if forgets to add him/her-self as watcher or so). Also, that won't solve the problem of searching for those bugs (based in one "free-content" string, any typo or change in the entered text will cause the issue to not appear in the list of "Requesting my opinion". Those are the reason about to have one specialised field for easier searching. About the fields... I haven't tested that... but... aren't the QA and difficulty fields only available (for input) to some groups within Jira? Do a simple Jira user have those fields available when creating new issues? I hope no. --Eloy Lafuente (stronk7) 13:58, 3 September 2009 (UTC)
- Edited: Crap! I just created a new user in Jira and, when creating new issues, the QA and difficulty fields are available :-( --Eloy Lafuente (stronk7) 13:58, 3 September 2009 (UTC)
- Edited 2: Seems to be an old JIRA limit: http://jira.atlassian.com/browse/JRA-4616 (hackable, see last comment, but I wouldn't recommend it). --Eloy Lafuente (stronk7) 14:13, 3 September 2009 (UTC)
- Yes, the only field which is not available to an ordinary Jira user is the assignee field. --Helen Foster 14:09, 3 September 2009 (UTC)
- I'm not sure we need this. I think there is a risk of over-engineering the bug database when all you need are comment. If you want input from a particular person, add them as a watcher, then add a comment with the question you want them to answer. Sometimes we need extra fields like QA assignee, but this is not one of them, I think.--Tim Hunt 19:41, 13 September 2009 (UTC)
Sharing the responsibility of bug triaging
I've been rewording Bug triage to hopefully make the two-step process a bit clearer. I was thinking that I could help with step 1, as could any developers new to Moodle. Senior developers could then help with step 2.
Commenting promptly on new issues will act as an encouragement to bug reporters. Not having to check whether a bug can be reproduced should help senior developers triage bugs more efficiently.
Any comments on this way of sharing the responsibility of bug triaging? --Helen Foster 14:23, 3 September 2009 (UTC)
Life after triage
Bugs are removed from the triage list by giving them a fix version or closing them. What happens to all unresolved bugs then? How can we keep the list of triaged bugs as low as possible? Here are some suggestions from Eloy:
- Encourage all Moodle HQ developers to identify and fix a minimum of 3 stable bugs per week. Perhaps send an email reminder.
- 'Perhaps also we could introduce, one day per week, to have a quick review in the developer chat about some bugs needing decision. So, while we are triaging... we comment with some "keyword" and then can look for those or so.'
--Helen Foster 14:42, 3 September 2009 (UTC)
BUG: Bugs are not removed from the triage list
"Bugs are removed from the triage list by giving them a fix version..." - does not seem to workBug_triage
For example, MDL-20270 still appears at http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10231 even I set a fix version to it
--David Mudrak 08:21, 14 September 2009 (UTC)
- David, thanks for your observation. I've just edited the Recent unresolved bugs that need triage filter so that issues with fix versions are now omitted. I also checked that the fix version field doesn't appear in the create issue form for non-developers. Developers (i.e. users in the jira developers group) can of course create new issues with fix versions and so bypass the triage process. --Helen Foster 13:05, 14 September 2009 (UTC)
