Openmoko Bugtracker

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Somebody in the thread at some point said:
| 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.
I can already imagine it about the ambiguously but inticingly named
"System Software..." category.
| 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
| bugtracker?
I wouldn't call it hijacking if we give them the field to edit in the
first place they're blameless if the meddle with it. It would be better
if the bug owner alone marked it with his opinion of where it fitted in
his other priorities, because typically every bug will be "blocker" for
a customer.
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkihPM4ACgkQOjLpvpq7dMpekgCfSBlA1/9R9xrF7IyiPcRl/xGW
1vcAnjqXG9v7YStZl+QyumLvD8kTV41Z
=5N7Z
-----END PGP SIGNATURE-----