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?
