Invent/gitlab, issues and bugzilla

[Martin Flöser]

Hi all,

I just read through the complete thread and thought I want to add a 
little bit, because I think we miss the big picture.

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.

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.

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.

That's the problem we have to face. Whether we use bugzilla or gitlab 
issues for internal issues is irrelevant. What is important is that we 
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.

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.

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

Cheers
Martin

Am 2019-07-04 19:26, schrieb Boudewijn Rempt:
> On donderdag 4 juli 2019 19:19:17 CEST Nate Graham wrote:
>> On 7/4/19 11:06 AM, Christoph Cullmann wrote:
>> > Actually, do we really want that every user bug reporter opens an
>> > account on invent.kde.org?
>> >
>> > I actually think the split of accounts between phabricator/gitlab vs.
>> > bugzilla is no bad but a good feature.
>> 
>> It would definitely solve that problem, but there are a few practical
>> problems with this:
>> 
>> - People would continue to need two accounts (BKO and 
>> identity/invent),
> 
> Like I said in my other mail, it's not hugely important for the kind
> of reporter who is not already a developer, and who knows, maybe that
> can be fixed as well. It's not like Identity is universally beloved.
> 
>> and the systems wouldn't be integrated as well as thy could be, which
>> negates some of the purported advantages of moving to GitLab in the
>> first place
> 
> But that's the _point_. There needs to be a kind of division between
> user issue reporting and developer/development activity.
> 
>> - GitLab Issues are lacking some of the features of Phabricator Tasks
>> such as parent & sub-task tracking
>> 
> 
> Yes, gitlab issues is an all-round aenemic feature, but I could live
> with it for a tasks replacement, but not for a issue reporter
> replacement.
> 
>> - Using GitLab Issues exclusively to replace Phab Tasks will confuse
>> users who are accustomed to using Issues for bug reporting in other
>> projects (though I suppose this could be remedied by renaming "Issues"
>> to "Tasks" in the UI, and implementing a template that explicitly says
>> "Don't use this to report bugs")
> 
> And users get would sent to bugs.kde.org anyway; no normal user is
> going to something called "invent.kde.org" to report a bug, unless
> there's very specific guidancce to send them there.