Hi all, I think, "last in first out" principle might be better for the issue processing in practice. The people, who issued recently are most active and as Clytie said can be "repeated". This principle helps for me at least to complete my email processing, because I receive too many emails per day.
Badral Am Dienstag, den 01.07.2008, 15:02 +0200 schrieb Kai: > Hello Clytie, > > thanks for your explation, it helps to understand. I see, that maybe > older issues are not an issue in actual builds. > > But for me it seems in general (not only by unconfirmed issues) that > older problems will stay from release to release while new features > (maybe with new bugs) will be implemented. Sure, it is more fun to > implement new cool features instead of searching bugs in code many > others wrote in the past! But IMHO the trustableness for the project > needs that older issues get fixed instead of new features. OK, this is > now a more political thing. > > To check newer issues first lets older issues stay unconfirmed and for > that unsolved for a long time. I think not working the issues "first in > first out" increases the occurrence of doubles, because people they are > interessted in getting a bug fixed quick make a new issue against the > newest build. > > That's just my opinion and I am new here in QA - so don't give it to > much weight. > > Ciao, > Kai > > > > Clytie Siddall schrieb: > > > > On 01/07/2008, at 5:12 PM, Kai wrote: > > > >> Hi Zhu, > >> > >> I don't understand you. > >> > >> I can't see a reason why such an issue should start later to get > >> confirmed? > >> > >> Ciao, > >> Kai > >> > >> > >> Zhu Lihua schrieb: > >>> Hi James & Kai, > >>> > >>> Maybe you've got a misunderstand with the "Priority". > >>> > >>> The priority Clytie and I talked about, is the priority of starting > >>> with the unconfirmed issues, > >>> not the priority of issues themselves. As my former letter mentioned, > >>> we, several workers in the Redflag company, > >>> are working with the unconfirmed spreadsheet issues. > > > > Thanks, Li Hua, for explaining what I meant. This priority is indeed > > about the time we spend checking the issues. Since we have limited time, > > we start with the newer issues. > > > > Kai, we do that because often the older issues have already been fixed > > in a newer build. Issues reported against the current builds are more > > likely to be valid problems. > > > > For example, I spent a day last week going through over 30 unconfirmed > > issues reported against the Mac porting project. Most of the ones > > reported against versions < 3 had already been fixed in later builds. So > > I spent most of my day confirming that those issues no longer existed. > > > > It's useful tidying up, and fortunately I had set out to check the older > > issues, but in general, in the pre-release stage, we want to focus on > > issues reported against the pre-release builds. > > > > When we're not quite so close to release, we can afford to spend more > > time on older issues. > > > > I hope that helps you understand. If not, please keep asking! :) > > > > from Clytie > > > > Vietnamese Free Software Translation Team > > http://vnoss.net/dokuwiki/doku.php?id=projects:l10n > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
