Hello Andre, > On Fri, 2011-06-17 at 21:29 +0800, Wan, Shuang wrote: > > > > > * "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. > > I don't care about rules of other infrastructure teams. > They have different needs, environments and interactions. > > Question still stands: > Examples for urgent cases that needed less than four days?
Here is a sample: https://bugs.meego.com/show_bug.cgi?id=18860 Most bugzilla requests are align with the MeeGo release decisions & roadmaps. I don't understand why requestor should wait 4 days and actual bugzilla administration works could be done in few minutes. For requests that need source code works, it makes sense we need time on implementation and testing etc before deployment. But for changes could be done from Bugzilla administration page and decisions shouldn't be made at error management perspective, I really don't understand why we should hold it so long. > > > > > > * "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 ... > > Erm, sorry? > There is nothing to "convince" here. Either the requestor files a ticket > in bugs.meego.com or s/he will not get what is wanted. > Now what is complicated about that? > Transparency, please. If we could deploy bugzilla 4.x in near future, there will be an audit log there, and I believe it will record the key information there. We need to focus on the key changes to Bugzilla have the ticket filed and open discussed, for other trivial things, I don't think these could be followed as you enforced. For how requests send to Bugzilla admins, the channels could be in f2f discussion, phone call, IM, email... These will add more extra efforts to Bugzilla admins if everything discussed must have a bug entry in record. > > andre > -- > Andre Klapper (maemo.org bugmaster) > http://www.openismus.com _______________________________________________ MeeGo-qa mailing list [email protected] http://lists.meego.com/listinfo/meego-qa
