Hello Andre, Thanks for your feedbacks.
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Andre Klapper > Sent: Thursday, June 16, 2011 5:44 PM > To: [email protected] > Subject: [Meego-qa] BugzillaRequestProcess [was: "HW Verification" field > usage] > > On Thu, 2011-06-16 at 15:18 +0800, Wan, Shuang wrote: > > In addition, I just drafted a wiki page > > It's not mentioned anywhere that it is a draft. > > > at meego.com wiki based on the discussions at F2F and ML, see bellow: > > http://wiki.meego.com/Quality/BugzillaRequestProcess > > Welcome to revise it if something lost or incorrect ;) > > After reading it twice I *guess* that it is about changes in MeeGo > Bugzilla itself, and not in the MeeGo codebase? > "Bugzilla Request Process" to me sounds like processing any kind of > MeeGo platform requests in Bugzilla. Not clear what it means. Just renamed the page to MeeGoBugzillaRequestProcess and feel free to rename it if that make it easy to be understood by other users. > > > * "This process is to ensure the features or changes are implemented & > deployed under the planned way and also ensure the feature is generic > enough for most of users." > > Does that refer to any MeeGo UX, or to the Bugzilla UI? This document is all for features & changes to MeeGo Bugzilla itself. Revised the text little bit. > > * "Have a bug entry or feature entry for all change requests both for > code level and new custom fields & new flags" > > Direct link welcome. Make it easy to create such entries... Good idea. Links to feature request and bug & change request are added. > > * "Error management team will provide feedbacks in one working day > normally once receive the request notification" > > One working day is not enough if you don't want to have a national > holiday and accidentially be excluded from decision process. I propose > one week. One week to provide feedbacks is too long from my opinion for most of cases and only applies for rare cases example here holiday session. If the feature is a big change to Bugzilla, I believe there should be some discussions in advance and guys in error management team are hard to lost chance to participate. > > * "but nice to have a bug entry for change request" > > Can we please make this a "should"? > I am tired of all this intransparency. > When I wanted to have admin rights for the MeeGo wiki I was also asked > to file a bug report first, for transparency. And it made sense. May be we could enhance this by show more visibility how we handling the new bugzilla request transparently. IMO, most users don't know we have a wiki page document the MeeGo bugzilla change requests process. If they have the Bugzilla change request, they might continue to send the requests to Bugzilla admins directly. So this is a communication issue. In addition, Bugzilla 4.1.1 have added change audit functionality. Changes at Bugzilla administration level like add component, change component owners will be audited in DB. That will help us great to track such information in efficient way. > > * "Feedbacks from testing on our staging instances" > > So how can I test the "staging instances" please? > Can you please link the URL on that wikipage? Good point, let's document how we use staging instances in wiki page. You may have used staging instances already example: https://01.bugs-dev.meego.com/ https://02.bugs-dev.meego.com/ @Steve, do you want to contribute to this ;) Thanks Shuang > > > andre > -- > Andre Klapper (maemo.org bugmaster) > http://www.openismus.com > > _______________________________________________ > MeeGo-qa mailing list > [email protected] > http://lists.meego.com/listinfo/meego-qa _______________________________________________ MeeGo-qa mailing list [email protected] http://lists.meego.com/listinfo/meego-qa
