[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:34
Message-ID: 2788181.DUWpZ16ZX3 () sebe
[Download RAW message or body]

On donderdag 4 juli 2019 22:18:32 CEST Elv1313 . wrote:
> Ok, lots of email in the last few hours, lets recap a bit.
> 
> 1. "Top" projects don't like GitLab issues because they are too
> simple. Can we try to make a comprehensive list of issues on a pad
> somewhere? So far, I see:

I did make a comparison between bugzilla as it is current and gitlab; I don't think \
anyone could conclude from that there is any chance of gitlab's issues feature being \
capable of being improved to the point where it can replace bugzilla. It is, simply \
enough, _not designed to do that_. It is not designed to be a bug database, it's a \
developer task tracker. Not a good one, but it is NOT a bug tracker. Everyone should \
stop thinking it is. We've had enough mails today to prove that beyond all doubt.

Nobody should advocate anymore for replacing bugzilla with gitlab's issues. That ship \
has sunk.

> 2. For point 1.3, maybe this is where the solution is. @Boud, you
> mention that Krita "ask" failed. Can you provide more insight here on
> why? 

It failed, as I have said, because the software was modeled on stackoverflow. That \
is, on users helping each other. Users cannot help other users with support \
questions; they do not have the knowledge for that.

> Is there anything to learn so we can try better? 

A good user support system is smart and offers a shortlist of most common answers to \
any question. It does not require logging in for the user. Zoho helpdesk might be a \
good user support system; none of the open source user support systems is usable. Me \
and the rest of the Krita team looked at all of them.

> How about
> redirecting users directly to a ticket system for top-10 projects?
> Ticket systems are overkill (and problematic) for 95% of the KDE
> projects, but seem a step forward for larger projects. Or maybe send
> people to "a forum" first? For my largest non-KDE project (AwesomeWM),
> when we switched to GitHub (from FlySpray), we updated the contact
> page of the website to point to StackOverflow.com, SuperUser.com and
> Reddit above the GitHub Issue link. This worked fine for a relatively
> medium-large user base (of geeks).

AwesomeWM's userbase is exceptionally technically capable. Our users are just about \
capable of shouting out on Reddit things like "Help! I have an issue! Help me! I have \
an assignment due tomorrow!" Without giving more detail.

> 3. The login (identity.kde.org) issue. Maybe I am not on enough
> mailing lists, but what is the situation regarding generic OAuth2
> login for a subset of non-developer services? Is it only an
> integration issue or a political one? Being able to login with
> Google/Facebook/GitHub/Yahoo/Microsoft/GitLab/Gnome(?!) accounts with
> a path to upgrade to "proper" account seems to currently be the
> popular and future proof way to handle this. This is better from a
> security standpoint because all of them support 2 factor
> authentication in a way *normal people* can understand (aka, a
> notification on Android phones). Of course it doesn't help with GPG
> and SSH public key wallets and other dev related concerns. That's not
> relevant for most users.

I don't know; I do know that even the least technically able of my users has managed \
to get a bugs.kde.org account. A KDE Identity account so they can post on the Forum \
is a far bigger challenge.

> 4. For point 1.5, this isn't really solving anything. Sure, a better
> BZ with all the powerful features would be nice. It would not solve
> the PR<->Issues integration problems at all, which still leaves half
> of the people here unsatisfied.

I have no idea what you mean with PR<-->Issues integration problem.

> It would not be welcoming to projects
> looking to move into the incubator because they are used to a more
> integrated pipeline.

Are they? Please provide hard proof.

> It would also leave the whole problem of slowly
> making the services more bot friendly, which is the future.

What do you mean with that?

> 4.1 This would leave the sequestration of BKO and IKO into 2
> ecosystems. This makes bots more complex and makes porting good open
> source bots such as mergify.io even harder since it would be more
> painful than just a GitHub<->GitLab API compat (or if they ever
> support GitLab). Bots are a solution to many of the problem outlined
> here, such as when is a pull request acceptable to merge or some magic
> rebase/squash/fixup bots.

To me, that sounds like a lot of very technical gibberish, and as far as I can \
understand it, totally irrelevant. What is "mergify.io" and how did that ever come \
into this discussion?


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


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