On Thursday 06 March 2003 16:57, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > What do you think most of us are doing? The real problem seems to be > > > that there just aren't enough Mandrake developers to address most bugs. > > > Out of the 6 bug reports I have filed, none of them have moved from > > > UNCONFIRMED. > > > > That is not a developer responsibility. If you want the bug fixed, > > ensure it gets confirmed. > > Well, but how ? I have only one vote per component. Only people from the > editbugs group are able to confirm bugs. So, since not many people vote for > bugs, how can I ensure that the bug is confirmed ? By spamming cooker list > pleading for people to test the same thing and vote for my bug ? I think, > that this logic is flawed, since we are blaming problems on bug reporters > instead of saying, "OK, there is a problem, let's have a look at that" and > either mark the bug as invalid or assign it to somebody. > > Moreover, I didn't find anywhere in the FAQ or on the web, what has to be > done to get the bug to the 'confirmed' state. I know now, that you have to > vote for it and it has to get at least two votes. But if this is not > written anywhere for new bug reporters (as me), then people will not vote > for bugs and most of the issues will stay as 'unconfirmed'. > > > There is little point in a developer looking at a bug if it is not > > confirmed, if he has many other confirmed bugs. > > See above - the unconfirmed bugs are seen as 'non-important' or obscure, > but since it is not possible to easily 'confirm' the bug, we "mark" almost > everything as 'non-important' and it never gets fixed, to the frustration > of the bug reporters, testers and, in the end, users. > > Jan
What about different states of bug-reporter ? 1) normal user => current system 2) a group of bug hunter => trying to reproduce, track down and ask questions. They should have the right to immediatly confirm bugs and put them to not important or critical. 3) developer If needed group two could be even divided up in reproducer and solution-men ;) (roughly no strict seperation needed) Further I would suggest to split up cooker in task forces: server networking .... desktop maybe some special task forces. (like Linux Audio) And lets make a big discussion after release and do some changes. -- Regards Steffen ____________________ counter.li.org : #296567. machine: 181800 vdr-box : 87 ____________________ Please dont CC me, since if I have replied I'll watch the tread. Both mails will be filtered to the ML-folder. Thanks
