Comments on: QA -> Developers communication http://mesquilla.com/2010/01/22/qa-developers-communication/ Messaging with Mozilla by rkent Sun, 18 Jul 2010 18:30:57 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Bryan http://mesquilla.com/2010/01/22/qa-developers-communication/comment-page-1/#comment-98 Bryan Wed, 27 Jan 2010 01:24:04 +0000 http://mesquilla.com/?p=588#comment-98 It seems like we need a way to identify bugs which are clearly reproducible. Determining difficulty of fixing takes a developers time and seems hard to estimate; not that it isn't very useful. But it seems that at least if bugs have been well triaged with STRs then a developer can much more easily fix the problem. I don't know that we have a way which marks bugs as highly triaged w/ STRs such that a qualified developer could start on a fix. It would be really good to get some resolution to this issue. It seems like we need a way to identify bugs which are clearly reproducible. Determining difficulty of fixing takes a developers time and seems hard to estimate; not that it isn’t very useful. But it seems that at least if bugs have been well triaged with STRs then a developer can much more easily fix the problem. I don’t know that we have a way which marks bugs as highly triaged w/ STRs such that a qualified developer could start on a fix. It would be really good to get some resolution to this issue.

]]> By: rkent http://mesquilla.com/2010/01/22/qa-developers-communication/comment-page-1/#comment-97 rkent Sat, 23 Jan 2010 01:34:11 +0000 http://mesquilla.com/?p=588#comment-97 The two methods that you mention are redundant if the developer is watching the appropriate component. And cc can be used for lots of things, including "please comment on this issue". A search for all of the bugs that I am cc'd on will not give a meaningful list of bugs that I reasonably should consider fixing soon. So all of what you describe is in fact the current system, and IMHO is not very effective at helping me to decide "which bug should I try to solve next?" The two methods that you mention are redundant if the developer is watching the appropriate component. And cc can be used for lots of things, including “please comment on this issue”. A search for all of the bugs that I am cc’d on will not give a meaningful list of bugs that I reasonably should consider fixing soon.

So all of what you describe is in fact the current system, and IMHO is not very effective at helping me to decide “which bug should I try to solve next?”

]]> By: Tony Mechelynck http://mesquilla.com/2010/01/22/qa-developers-communication/comment-page-1/#comment-96 Tony Mechelynck Sat, 23 Jan 2010 01:22:53 +0000 http://mesquilla.com/?p=588#comment-96 I'm coming to this problem from the other side (as a triager, and not a very active one), and there's a lot here that baffles me too. I think there are two possible mechanisms to bring bugs to developers' attention, and that neither is perfect: - If the developer is particularly interested in bugs concerning some Product/Component pair, he should "watch" the default QA address for that Product/Component (the way I, as a triager, watch general@seamonkey.bugs which is where most new bugs get filed). He will then get bugmail wherever a new bug is filed in that P/C or reassigned to it. - If the triager knows (or thinks) that a bug is in some particular developer's (or developers') ballpark, he should add the corresponding entry or entries to the bug's Cc list in the hope of getting that dev's/s' attention. - One flaw of the above system is that it is easy to become flooded by a lot of bugmail, to the point of not paying attention to all of them. So what should we do? I don't know. Maybe timeless, who AFAICT gets at least one (and sometimes several) bugmail message(s) for *every* bug filed or changed at b.m.o., would have something better to contribute than I can. I’m coming to this problem from the other side (as a triager, and not a very active one), and there’s a lot here that baffles me too. I think there are two possible mechanisms to bring bugs to developers’ attention, and that neither is perfect:
- If the developer is particularly interested in bugs concerning some Product/Component pair, he should “watch” the default QA address for that Product/Component (the way I, as a triager, watch general@seamonkey.bugs which is where most new bugs get filed). He will then get bugmail wherever a new bug is filed in that P/C or reassigned to it.
- If the triager knows (or thinks) that a bug is in some particular developer’s (or developers’) ballpark, he should add the corresponding entry or entries to the bug’s Cc list in the hope of getting that dev’s/s’ attention.
- One flaw of the above system is that it is easy to become flooded by a lot of bugmail, to the point of not paying attention to all of them. So what should we do? I don’t know. Maybe timeless, who AFAICT gets at least one (and sometimes several) bugmail message(s) for *every* bug filed or changed at b.m.o., would have something better to contribute than I can.

]]>