2009/1/7 Vincent Untz
Le mercredi 07 janvier 2009, à 16:50 +0000, Rob OpenSuSE a écrit :
2009/1/7 Vincent Untz
: Le mercredi 07 janvier 2009, à 10:07 +0000, Rob OpenSuSE a écrit :
2009/1/7 Rajko M.
: Creating entry on the wiki is not a holly script, so anyone missing it can create wiki page, add reference it in the "Most Annoying Bugs".
How would I know it was a commonly reported bug, without being in the Bug Triage team?
Because you're experiencing the bug and saw there were many duplicates in bugzilla, for example.
Who's deciding they're duplicates? It's very often unclear, when you join a bug report, that it is actually the same bug. I've often for instance seen claims of "crashes", but unsupported by kernel dump or oops, when what I see is very poor performance and many errors written to log files.
Let's take a concrete example:
a) you file a bug (bug A). b) someone (doesn't matter who) closes your bug as duplicate of another bug (bug B)
You then have two possibilities:
That's not what we're supposed to do. Filing the bug report involves searching for similar reports, hence my experience of "joining" other bug reports, if the problem looks similar. Often this involves providing information, for a bug report filed on a previous release, that has stalled. Where Novell bug reports have been marked as duplicates, it's often due to poor titling of the initial report, or a partial intersection with another report rather than a full duplication. So if you're a concientious bug reporter, you generally do not get into the situation you hypothetically put forward.
Now, the person who closed your bug as duplicate could have added the bug in the list of most annoying bugs, but maybe this person just forgot or was doing something else at the same time. So you can do it. Sure, you might be afraid to do it because you're not 100% sure it's right, but it's a wiki and the good thing is that someone disagreeing with you will be able to fix the stuff.
I'm sorry but when I've been testing stuff, frequently I have to be not only selective of the bugs I report, as there is no shortage of obvious flaws to find in a release like 11.1-rc1, but then there's often test reports to gather in a timely turn around. The reality is, messing around in the Wiki is yet another task, one that is public and that decision "most annoying bugs" is one that I'd not be well placed to make a considered judgement. The developer's marking bugs as duplicates, who do not want another 10 bug reports, are however perfectly placed. The value of "Most Annoying Bugs" has actually been close to 0 to me, I really don't see any value in a whole load of "hand waving" community testers, feeling obliged to maintain such a list. Just following the Factory Mail list seems far more effective way to get a better feel for the issues, and solutions. For example, where was "Intel Graphics" in the "Most Annoying Bugs"? OTOH there were suspicions that CPUFREQ, was locking AMD Cool N' Quiet CPUs to the slowest frequency, marked a priority 1 bug, was reported monthes before release, the reporter failed to provide feedback; there communication from the Bug Assignee appealing for test on that before release would have been useful.
I have the feeling that you think the barrier to contribute is high. It doesn't have to be. An average bug reporter can make a good job too for this. You just don't have to be afraid of making mistakes.
I am actually saying, that contributing by testing, filing bugs, and providing info on "known" problems is fairly time consuming as is, without adding extra expectations of also creating Wiki pages which can only be of a speculative nature. Those who believe in doing the Wiki can "simply" scan the publically available bug reports and probably do a better job than I would. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org