Am 2018-02-27 12:22, schrieb Paul Brown:
On Tuesday, 27 February 2018 11:51:42 CET Boudewijn Rempt wrote:
On Tuesday, 27 February 2018 11:47:22 CET Paul Brown wrote:
> On Tuesday, 27 February 2018 11:41:04 CET Boudewijn Rempt wrote:
> > Given that bugzilla is a tool for developers, I don't care that users
> > might
> > get confused.
> >
> > > We don't have this problem with phabricator tasks because they can be
> > > either Open or closed (for whatever reason).
> >
> > I don't let users report issues in phabricator anyway, because
> > phabricator
> > is where we plan our work. Bugzilla is the big pile of shit that comes
> > from
> > the outer world. So, phabricator's lack of fine-grained task statuses is
> > irrelevant.
>
> So... where are users supposed to report bugs?
Users report bugs in bugs.kde.org. But that doesn't change that
bugs.kde.org
is a tool for the developer, not the user. Once the bug is in
bugzilla,
it's my property, as a developer, and I need to have a workflow that
allows
me to efficiently handle over a thousand bug reports a year.
Users do treat bugs.kde.org as a helpline, but that's invalid, and I
close
such help requests as invalid, though I also give the users the help
they
need, of course.
I'll ask the question again with a slight modification: So... where are
users
supposed to report bugs according to you?
As KWin has the same problem as Krita I can also answer. In the case of
KWin about 90 % of the incoming bug reports is not a bug, but either
duplicate, driver crash, useless crash reports from Arch users or user
support questions. I as the maintainer handle this. Just imagine in a
corporate world having the product owner or developer with largest
domain knowledge handle the first level user support. No company would
do that because it's a waste of time and money. We as a free software
community still practice this.
So where should users report bugs? Not anywhere where the developers
look for bugs. We need an efficient support portal which can handle the
90 % of requests which create the noise. If the users truly report a
bug, then it could be forwarded to the developers. With a corporate
style workflow going from first level support (taking the issue), to
second level support (figuring out whether it's a bug) and then to third
level support (developers).
Due to the high level of noise there is also a lot of conflict
potential. I operate on the assumption that any incoming bug report is
not valid. This is experience based. If > 90 % of the reports are not
valid you start to get a feeling that the next bug won't be valid
either. So bugs get closed, closed with short sentence. Feature requests
dismissed, etc. Sometimes answered on a tablet or smartphone with too
short answers. Things escalate, we need to bring in the CWG. That's all
quite common to the very frustrating and demotivating bug wrangling
process. I'm sure the situation would be better if the developers would
not interact directly with the users, but if a first or second level
support team acts as an intermediate for it.
Cheers
Martin
