bugzilla, it's products, how they relate to projects. it's a mess...

[Boudewijn Rempt]

On Wednesday, 31 January 2018 14:33:07 CET Ilmari Lauhakangas wrote:
> On Monday, 29 January 12:16:07 UTC Boudewijn Rempt wrote:
> >> On Monday, 29 January 2018 12:25:24 CET Harald Sitter wrote:
> >> I don't like going to our bugzilla.
> > 
> > Me neither... But that's more because I have to triage about a 1000 bug
> > reports a year, and many of them are not bug reports at all, but
> > support
> > questions.
> 
> This sounds horrifying and should absolutely not be the case. Over at
> LibreOffice, an average full-time dev triages at most a 100 bugs per
> year from scratch (number pulled from my hat). Nearly all of the reports
> are first attacked by a ruthless gang of non-developers, numbering about
> 20-30. Sure, there are some hybrid QA/dev beings, but they have usually
> "grown up" inside the tracker and started to lean more and more towards
> submitting patches.

And then I'm also answering users on Reddit and Twitter and the Forum...

There are some people who help out -- but it's a very small group of three,
and only one of them is not a developers. This person is pretty good, 
especially considering the extremely low quality of most reports we get, 
but cannot manage this stream of bugs on their own, of course.

And so I'm kind of the buffer between bugzilla and Dmitry, who I'm paying
to work on Krita full-time, and who should be insulated from bugzilla even 
more than me.

> As Nate has now attained demigod status with his usability blog posts, I
> think it would be good to take advantage of all the positive attention
> and tie it into one of the other goals "Streamlined onboarding of new
> contributors". The point has to be hammered home: "If you love some dev,
> set them free of the burden of bug triage".

Yes, that would be very good!

> Non-dev users often express themselves like they have an inferiority
> complex, "sadly I don't know C++ so I can't help" etc. They need to
> understand their amazing potential in something that is quite frankly a
> direct energy transfer to developers. Yet, compared to other non-dev
> tasks, QA does not require much to get started. You don't have to be
> able to express yourself in eloquent ways, it is enough to blurt out
> "Repro" or "No repro" in a hoarse voice every now and then.

It's a bit more complicated, though -- there are three operating systems 
involved, the vagaries of all the different graphics tablets and drivers, 
multi-monitor issues. But I might be able to just put the usual suspects in a 
document, like "if a user complains about offsets, ask whether they have a 
multi-monitor setup", as well as instructions on which class of bugs can be 
reproduced.

But people will need to know enough about Krita so they know how to ask for 
clarification.

-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org