On donderdag 4 juli 2019 20:42:31 CEST Martin Fl=F6ser wrote:
>=20
> Boud pretty much describes the problem large projects (krita, kwin,=20
> plasma) have with bugzilla. We don't use bugzilla to handle bug reports,=
=20
> but to somehow manage all the reports we get, to survive. I blogged=20
> about these issues years ago, I did statistics for KWin showing that >=20
> 90 % of the incoming bug reports are not bug reports, but rather=20
> duplicates, user support, etc. The situation hasn't changed much over=20
> the years. Reading Boud's comments it looks like the situation became=20
> much worse for krita lately and I do not want to swap with him.

=46or the past six months or so, Krita is the KDE product which gets the mo=
st bug reports. We're also seeing a continuation of the real rise in downlo=
ads, social media traffic and user base. That results in lots more interact=
ion with end-users, which I normally like. I like my users. The big differe=
nce between working on Krita and all other jobs I've ever had is that when =
I work on Krita, my work ends up being used.

> Obviously for any large project the idea of swapping to an inferior=20
> system (which gitlab seems to be, haven't used it yet) is a horrible=20
> idea. But that's not the problem. The problem is that users interact=20
> with developers directly. The user goes to bugzilla or gitlab issues and=
=20
> reports a support request. Instead of friendly user support he gets a=20
> grumpy third level support answer that this is not an issue. No help,=20
> frustrated user and frustrated dev who just wasted another minute on=20
> bugzilla to handle user support.

I try not to be grumpy... But we've closed ask.krita.org and I've retired f=
rom reddit and we don't do support on Twitter -- because it's no longer man=
ageable.

> No company would allow to have Boud handle user support. That's insane.=20
> He's product owner, chief technologies, call him whatever you want, but=20
> he is not first level user supporter.

In fact, I hired one of the volunteers who spent all her time helping peopl=
e to help me fix bugs. It's working out great, and I've hired a second bug-=
fixing minion, and now the first minion (they choose their titles) is tryin=
g to help to figure out how to plug the user support gap.

> That's the problem we have to face. Whether we use bugzilla or gitlab=20
> issues for internal issues is irrelevant.=20

Not totally irrelevant. Gitlab just does not cut the mustard for tracking b=
ugs. It was not designed for that, it cannot handle that. The whole discuss=
ion about ditching bugzilla and moving to gitlab issues is, as far as I am =
concerned, a has-been. It's over. You don't point people at something like =
invent.kde.org and ask them to figure out how to report a bug.

> What is important is that we a
> get users to use an adequate user support forum and not bugzilla or=20
> gitlab issues. Once we get the shit reports out of our bug tracker,=20
> everything looks different.

I'm not very hopeful about that happening, though.

> Right now from KWin perspective I would say "hell no!" to the idea of=20
> using gitlab issues. But a better tool for development which gitlab=20
> issue seems to be is something I would like to have. Because for=20
> development planing I never really liked bugzilla. Although it might be=20
> that it was just too useless due to all the invalid bug reports.

Yes, development planning is not what bugzilla is for. We need a four-stage=
 system:

1. User support system. User reports an issue, gets a canned answer in 90% =
of the cases. In 10% of the cases, they have found a bug.
2. Bug tracker. Those user bugs, and the bugs the developers find are regis=
tered. With the right component, version, all the data we can get. Once the=
 bug gets assigned, we move to system 3.
3. Task system. Information about one or more bugs gets consolidated into o=
ne task, and a plan is formulated. The task gets updated with commits, comm=
ents and so on during the implementation phase. It ends in  review request =
or merge request...
4. There's a merge request or review request, and once it gets accepted or =
merged, 3 is informed, 2 is informed and 1 is informed.

> My suggestion is to address the user support and then look into whether=20
> we want to keep bugzilla or switch to gitlab issues.

=46or me it's clear: gitlab issues can, barely, replace Phabricator's tasks=
=2E They cannot replace a bug tracker.=20

=2D-=20
https://www.valdyas.org | https://www.krita.org