Hi Eric, Yes. Changing assignee does confuse. Thanks for understanding.
So you will remove the rule from http://wiki.meego.com/Quality/Bug_Life_Cycle_and_Handling, right? Bests Jeff > -----Original Message----- > From: eric.le-r...@nokia.com [mailto:eric.le-r...@nokia.com] > Sent: Thursday, April 07, 2011 8:24 PM > To: ext-iekku.huttu...@nokia.com; Zheng, Jeff; aklap...@openismus.com > Cc: meego-qa@lists.meego.com > Subject: Re: [Meego-qa] Needinfo owner in bugzilla > > Hi Iekku, > > On 4/7/11 12:16 PM, "Huttunen Iekku (EXT-Ixonos/Tampere)" > <ext-iekku.huttu...@nokia.com> wrote: > > >Hi, > > > >My comments below. > > > >>-----Original Message----- > >>From: meego-qa-boun...@lists.meego.com [mailto:meego-qa- > >>boun...@lists.meego.com] On Behalf Of ext Zheng, Jeff > >>Sent: 07 April, 2011 12:07 > >>To: Le-Roux Eric (Nokia-SD/Helsinki); aklap...@openismus.com > >>Cc: meego-qa@lists.meego.com > >>Subject: Re: [Meego-qa] Needinfo owner in bugzilla > >> > >>I believe that it works fine in Nokia internal, but it's opensource. > >>Reporter might don't know the process, he just want to fix his issue. > >>But with this process, his might be assigned to himself! > > > >How the reporter should know that his/hers action is needed, if the bug > >isn't assigned to him/her? This is more visible if the process isn't > >familiar. > > Anyone with incentive on a bug fix actually follows up what is happening. > Bugzilla sends email notifications whenever a comment is made or status, > resolution, attachments etc. Are changed, so as long as the user has > configured his bugzilla email preferences, he gets to know almost > realtime, the bug activity. > In this regard, reassigning to the reporter doesn't actually bring value, > it's more like a nice to have and gives better visibility on who does > what, maybe. > > > >> > >>I assume that all yellow boxes will set "Assigned To" field to reporter > >>(as Timo said). This way in most bugs, I think that most bugs with > >>"Verified" will have same "Assigned To" and "Reporter" field, is it > >>correct? > >> > >>I tried for mcts bugs and arm bugs, looks like that most bugs have > >>different "Assignee" and "Reporter". Same even for ARM NEEDINFO bugs! > >> > >About the MCTS needinfo bugs, they are assigned to person who will retest > >and tell if the bug is still valid or not. As I said in the mcts bug > >triage, several times. > > As said above, this practice generates more email notifications and might > be perceived as bugzilla spam. (this is a remark we keep receiving in > Nokia internal bugzilla rather often, fyi.) > Now, if this actually helps organizing the work better and gain > significant velocity, why not. > From my view point, we need to focus rather on providing to the developers > who are fixing the bugs a good, fast and intuitive tool and process. So > altering bugzilla default behavior to automatically reset assignee based > on statuses doesn't really bring a real improvement to support this > approach, does it? > > As I earlier suggested, I'm not inclined in porting our internal > customization to change assignee automatically on specific events. > I'd rather see QA teams take care of the bugs seamlessly with the least > impact on actual development and bug fixing practices. > What actually matters most here, is that the default assignees and/or > people in the default CC. List watching a specific bugzilla component have > all they need to take prompt action. > > I'd like to find proper closure on this topic. > At least, I confirm we won't apply the customization we have internally at > Nokia. > For any manual activities of reassign to original reporter when setting to > needinfo, I just see unnecessary extra step and users may forget to > reassign back after answering (as a matter of fact, many answer the > questions yet the bug remains in needinfo status). > Proper follow-up by QA teams is the key to solve this issue and no need > for extra "burocracy" I believe... > > > > >>So my question is: Is this rule really practical? Any success example > >>for this rule? > >> > >>Bests > >>Jeff > > > >Br, > >Iekku > > Cheers, > Eric _______________________________________________ MeeGo-qa mailing list MeeGo-qa@lists.meego.com http://lists.meego.com/listinfo/meego-qa
