Is there a process for reviewing a bugzilla staffer?
awaite2 at uiuc.edu
Thu Aug 2 12:04:50 CDT 2007
Chris Morgan wrote:
> On 8/2/07, Kuba Ober <kuba at mareimbrium.org> wrote:
>> On Wednesday 01 August 2007, Vitaliy Margolen wrote:
>>> Whit Blauvelt wrote:
>>>> Is there a formal process for reviewing an arguably incompetent bugzilla
>>>> staffer? Obviously it wouldn't be to submit their name as a bug. But is
>>>> there any defined administrative layer that concerns itself with people
>>>> on that level who are dragging on the project?
>>>> I looked around a bit for information on this. Sorry if it's posted
>>>> somewhere and I missed it.
>>> To spare everyone time and to skip directly to an entertainment see bug
>>> 9147: http://bugs.winehq.org/show_bug.cgi?id=9147
>> I agree with Whit. Most of your writing in that bug report would be in line
>> with lack of sleep or prolonged fatigue, or some other factor that causes you
>> to be compartmentalized in your own verions of things and completely ignore
>> the real issue at hand.
>> Similar behavioral pattern that happened on China Airlines Flight 006. The
>> resemblance is striking: the pilots completely unaware of what the real
>> problem is, and were dealing with non-issues (rather than fluing the plane).
>> Similar thing here: the user tells you one thing (the real issue), your
>> situational awareness is as if something entirely different has been taking
>> place (dupes, etc). Interesting.
>> [...] the captain had become so preoccupied with the dwindling
>> airspeed that he failed to note that the autopilot, which relied on ailerons
>> only, not the rudder, to maintain heading, was using the maximum left control-
>> wheel deflection available to it to overcome the thrust asymmetry due to the
>> hung outboard engine. When the right wing nevertheless began to drop, ...
>> the captain didn't notice the bank on the attitude indicator ... . When he
>> did notice it, he refused to believe what he saw. At this point, ... the
>> upset had begun and the captain and first officer were both spatially
>> You can almost substitute terms from the bugreport for the flying terms
>> Common thing to happen when you're tired, distracted, etc. So this is nothing
>> personal, just noticing a pretty common problem. BTDT, one has to learn to
>> recognize the first signs and take a break (helps me). At least here it won't
>> kill anyone. Now, if you *are* sleeping well (and long enough), and are not
>> tired, then IANAD and wouldn't know what to do either...
>> Cheers, Kuba
> I've spent a fair amount of time helping users on irc in #winehq and
> this bug report sounds like one of the most common issues, user error
> precipitated by a distribution that requires a high level of user
> knowledge. The back and forth on the bug is mostly a waste of time
> trying to figure out user compile time options, which version of wine
> is actually running when multiple versions are installed etc. I can
> understand Vitaliy's frustration with this stuff as its easily
> avoidable on almost all binary package based distributions.
> Maybe we should point gentoo users at the gentoo wiki page we have and
> enhance that page with things we've learned from gentoo debugging.
As a Gentoo user, I would have to agree. If a fairly good document is
put together a lot of headaches can be avoided. When they are done
following the guide then bugzilla staff and others can help them. The
advantages of this are twofold. One is that there are fewer headaches
from chasing down weird compile time options, etc. The second is that
Gentoo is a more advance/complicated distro and some of the users really
know their stuff and can be quite useful. By providing good
documentation we might encourage those users to participate more. Weed
out the bad, keep the good.
More information about the wine-devel