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
