Hi Andre, > -----Original Message----- > From: Andre Klapper [mailto:[email protected]] > Sent: Friday, June 17, 2011 5:56 PM > To: Wan, Shuang > Cc: [email protected] > Subject: RE: [Meego-qa] BugzillaRequestProcess [was: "HW Verification" field > usage] > > On Fri, 2011-06-17 at 13:46 +0800, Wan, Shuang wrote: > > > -----Original Message----- > > > From: [email protected] > > > [mailto:[email protected]] On Behalf Of Andre Klapper > > > > It's not mentioned anywhere that it is a draft. > > So I've added this to the top of the page. > > > > * "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. > > I moved them to the actual text where it is refered. > It's hypertext, no need to list links at the very end... :) > > > > * "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. > > So which cases in the past have been so urgent that they had to get > implemented faster than within one week? > What about 4 days?
Sorry, I don't think the requestor should wait error management team 4 days just get the feedbacks for all requests. Bugzilla is part of whole MeeGo distribution system, it's hard to imagine for me if all MeeGo infrastructures apply this rule as well. > > > > * "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 just answer them to use Bugzilla for such requests and to NOT send > requests to Bugzilla admins directly anymore. > No big deal to redirect folks to the proper channels... I will try to convince the requestor, so changed back to nice to have ... > > > > * "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/ > > So I've linked them. > And I've also linked "MeeGo Bugzilla git repository". > > And I've also removed the Priority and Severity explanations. That was > common stuff and nothing special, hence no need to list it (plus mixing > up instructions for users and for maintainers is already a bit > confusing). > > andre > -- > Andre Klapper (maemo.org bugmaster) > http://www.openismus.com _______________________________________________ MeeGo-qa mailing list [email protected] http://lists.meego.com/listinfo/meego-qa
