[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: Invent/gitlab, issues and bugzilla
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2019-07-04 20:49:30
Message-ID: 1971034.XQCPXHXggD () sebe
[Download RAW message or body]

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

For the past six months or so, Krita is the KDE product which gets the most bug \
reports. We're also seeing a continuation of the real rise in downloads, social media \
traffic and user base. That results in lots more interaction with end-users, which I \
normally like. I like my users. The big difference 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 
> system (which gitlab seems to be, haven't used it yet) is a horrible 
> idea. But that's not the problem. The problem is that users interact 
> with developers directly. The user goes to bugzilla or gitlab issues and 
> reports a support request. Instead of friendly user support he gets a 
> grumpy third level support answer that this is not an issue. No help, 
> frustrated user and frustrated dev who just wasted another minute on 
> bugzilla to handle user support.

I try not to be grumpy... But we've closed ask.krita.org and I've retired from reddit \
and we don't do support on Twitter -- because it's no longer manageable.

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

In fact, I hired one of the volunteers who spent all her time helping people 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 trying 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 
> issues for internal issues is irrelevant. 

Not totally irrelevant. Gitlab just does not cut the mustard for tracking bugs. It \
was not designed for that, it cannot handle that. The whole discussion 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 
> gitlab issues. Once we get the shit reports out of our bug tracker, 
> 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 
> using gitlab issues. But a better tool for development which gitlab 
> issue seems to be is something I would like to have. Because for 
> development planing I never really liked bugzilla. Although it might be 
> 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 registered. 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 one task, and a \
plan is formulated. The task gets updated with commits, comments 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 
> we want to keep bugzilla or switch to gitlab issues.

For me it's clear: gitlab issues can, barely, replace Phabricator's tasks. They \
cannot replace a bug tracker. 

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


[prev in list] [next in list] [prev in thread] [next in thread]