[mb-users] Fwd: Bug Triage

[Lauri Watts]

On 8/19/06, joan WHITTAKER <joan at whittaker1966.fsnet.co.uk> wrote:
> And by so doing Lauri, you are effectively excluding all the committed users
> and moderators on mb who have little or (in my case) absolutely no skills in
> programming or development.
>
> You, thereby, create an "elite" and sow the seeds for a "them and us"
> scenario and the potential for further flame wars in the future when a non
> programmer turns to the developers and says that they were not consulted.

Wow. You have clearly utterly misunderstood  the idea, if you think
any of those things.

This is about inclusion, not exclusion.  It's about mediating,
clarifying and streamlining the communication between the people who
do the work, and the people who use it, not about reducing it.

It's about including more people actively in the development process,
without them having to be developers, and about helping make the
process more effective.

Did I mention this is something that is fairly common in other
projects, and works, very efficiently and effectively?

 In fact, if you have an understanding of the workflow, and how things
work on MB, why do you think you would not be a good bug triager?
I've put in many hours sorting bugs in things I have absolutely no
hope of ever understanding the code of. I _can_ however,

* check if the problem is reproducible to me, clarify how, exactly, to
reproduce it (for an MB bug, that might be: what steps in what order
make it happen, what changes to those steps make it not happen, can I
make it happen any other way, does it only happen in IE, or Firefox,
or if I turn cookies off).
* I can figure out which of the available developers would be the best
to deal with this problem, either because it's their area, or I've
touched base with them on IRC and know who's actively working on a
particular thing.
* I can take a poorly worded bug, hostile bug report written by a
frustrated user, and follow it up with a clear and less
confrontational restatement of the problem, and work with the reporter
to make sure it's really the report they wanted to make.
* I can figure out which reports are probably duplicates, and merge them, and
* I can figure out if one bug report is really covering three things
(something users do often, without realising that's a pain in the butt
for developers and makes their lives difficult) and split them into
separate reports that can be managed independently.
* I can help rephrase a developers questions back to the users, if the
users are not giving the information the developer needs

All these things make finding the real problems, and dealing with
them, easier for developers,  Anything that makes life easier for the
developers, means their dealings with the user community is less
likely to become confrontational.  Less confrontational developers,
means happier, more satisfied users.

None of these things have anything to do with creating an elite, in
fact, it's a fair amount of work.  Work that the developers are
currently doing, by default, even though it's not necessarily a good
use of their time.

Imagine how much smoother that bug report about the release titles
would have been with a few well placed, non-combative  "So, you think
we should have the release titles back because...?" and "So, putting
the release titles back is a problem because..... and yet not putting
them back causes...."?  I expect you could have sorted out and
distilled the argument
 quite nicely, Joan, with far less hostility and frustration than
there ended up being.

Regards
-- 
Lauri Watts