zecke at openmoko.org
Tue Aug 12 00:58:21 CEST 2008
On Monday 11 August 2008 22:44:05 Andy Green wrote:
> Somebody in the thread at some point said:
> |> If things continue that way I'm _forced_ to ask our engineers to not
> |> waste
> |> their time with the bugtracker.
> | If you do that, please at least hire somebody (or recruit a community
> | volunteer) to go through the bugtracker on a regular basis and add
> | some special tag to the items that should be looked at by the engineers.
> FWIW I seem to get a copy of all bug traffic in my inbox and at least
> glance at everything. Sometimes you get tantalizing clue from what is
> reported that is very hard to come at yourself, like SD Card affecting
> GPS). It's hard to say we "waste our time" looking at what prompted
> people to complain from the field, it all means something.
> If you think about it, our current bug traffic is pretty much nothing
> compared to what we would have to service if and when we start shipping
> "real numbers" of phones. The best answer in that case isn't going to
> be "ignore it harder", it would need more infrastructure along Mike's
> ideas, sort for first level support staff person who asks the questions
> that should have been answered in the first place, etc.
Sure, but with real numbers you will never ever reach the engineer responsible
for the issue. So no matter what kind of stuff you write, the engineer will
not see that but something that has been prepared, filtered, triaged.
A small example. Imagine you would be tick and responsible for assassin. For
some reason (probably people are unsure which component to use) people
select "Assassin" as component and tick gets the bug mail. So in his case
19/20 bug mails he gets are actually not for him so it is quite easy that
this one real bug mail that needs attention is lost.
So yes as mike said we might need to educate people to not use certain fields
(severity, milestone, component) and to stop the too many me too's. Actually
I think in most cases the confirmation is not really needed as the engineers
needs to be able to reproduce the issue anyway. We can add voting or just
count the number of CC's if we are unsure about severity. If educating fails,
what should we do? Allow only certain people (inside and outside of openmoko)
to change these fields? What if hijacking of issues do not stop? Should one
discuss bugs on the mailinglist and then move that information into the
E.g. with the SIM PIN Dialog it is pretty obvious that the severity is high, a
software problem and that it impacts many people and the first output of
logread was already really helpful.
More information about the devel