Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos

[Ilmari Lauhakangas]

On 23.8.2023 14.24, Paul Brown wrote:

A lot fo good ideas we can use to reach a compromise, but this ...


KDE members are of course free to participate in discussions anywhere
they want, but loading KDE resources (sysadmin team & machines) with all
possible proprietary network doesn't seem a priority for me.


... 

By that logic, would you have a problem if Promo stopped managing Facebook
(65,000+ followers), Xitter (120,000+ followers), LinkedIn (17,000+
followers), and Reddit (100,000+ followers)? These are all proprietary and all
load KDE's resources. But it is KDE's Promo resources.

If Promo didn't manage these platforms, KDE would gradually lose this
audience, and I can prove that with graphs.


It's not the same logic. Chat platforms with bridging infrastructure 
need moderators/user support + sysadmin time + hardware. 3rd party 
social network platforms need moderators/user support. If Facebook et 
al. would be bridged to the KDE chat infra (dark magic like this might 
awaken the Great Old Ones and should not be attempted), it would be the 
same logic.


Ilmari

Re: Winding down Phabricator

[Ilmari Lauhakangas]

Ben Cooksley kirjoitti 21.6.2020 klo 6.38:

Hi all,

With the completion of Phase 1 of our move to Gitlab, all code review
activity should now be taking place on Gitlab, with only residual
reviews being cleaned out of Phabricator (which hopefully we're
already well underway with - please start this if you haven't already)

This leaves just Tasks left on Phabricator.

As interacting with repositories isn't a core requirement for this
functionality, we've now taken the step of disabling all repository
functionality on Phabricator.

This means that going forward, repositories will no longer be
browsable on Phabricator, nor will commit information be visible on
Phabricator. Additionally, actions normally taken via hooks (such as
"Differential Revision" and "Fixes Txxx") will no longer work.

Should anyone have any questions regarding this, please let us know.


This bit in the Bugzilla attachment section could use some tweaking:
"KDE uses Phabricator for patch submissions. Please read our 
instructions on how to submit a patch through Phabricator. Bugzilla is 
not monitored for patches, so your patch is likely to be missed."


Ilmari

Re: The chat situation

[Ilmari Lauhakangas]

Christian Loosli kirjoitti 11.6.2020 klo 15.25:

And while IRC is improving  (and you are very welcome to participate e.g. in
#ircv3 or #freenode-dev on freenode) two of the main pain points people
mention   (lack of an endless scrollback / offline history, uploading media
directly) are unlikely to fully happen on freenode / IRC, due to both
technical and privacy / legal reasons. There is very likely to be (offline)
backlog, but it will be time-limited due to the above constraints. Not having
these constraints means someone else (neither freenode nor probably KDE) has
both the storage and the legal willingness to store that data, with all
implications this brings (DSVGO, security and privacy, ...)
These are usually profit oriented companies, and having to rely on these
brings up some new issues.


I'm not sure an endless scrollback is a dealbreaker. I've noticed folks 
in Telegram talking about cleanup bots that regularly delete the history 
due to whatever privacy concerns. But in general, sure, people want 
hosting & backups & everything for free and top notch customer support :)


Ilmari

Re: The chat situation

[Ilmari Lauhakangas]

Bernie Innocenti kirjoitti 11.6.2020 klo 14.02:

On 11/06/2020 19.28, Ilmari Lauhakangas wrote:

Bernie Innocenti kirjoitti 11.6.2020 klo 9.38:
Doesn't Riot.im support images well enough for your use-case? It's 
free software, and it's becoming fairly mature lately.


The root issue for both Telegram and Matrix seems to be that they're 
bridging through a legacy platform like IRC. Would it be fair to say 
that this problem will slowly resolve itself in time, as users leave 
IRC?


I don't mean to troll: I've been on IRC myself for 20+ years, but the 
protocol has been stagnating and clients requires too much setup for 
newcomers, particularly when you consider identity, presence and 
persistence. Other open source projects are migrating to Matrix or 
Gitter, and soon or later KDE will need to make a decision.


While progress with the IRC protocol has been slow, I would say 
freenode is suffering from stagnation the most at the moment. A 
service like KiwiBNC can act as a shim on top of freenode to bring 
modernity to everyone, but obviously limits to UX improvements will be 
hit. Freenode could solve this by moving to an actively-maintained 
IRCd (or invest a lot in their homegrown one).


Maybe a member of the KDE community could go on on #freenode and bring 
up the issue of stagnation in a civilized manner (like... without saying 
"give us $FEATURE or else we walk away" :-)


I'm sure they're already aware of it, and perhaps they're already 
working on a plan to address some of our issues, and looking for 
volunteers who want to help.


Well, there is even one KDE/freenode hybrid contributor in our known 
galaxy :)


An alternative would be setting up completely self-hosted IRC infra. 
This would really open up the possibilities as there are solutions 
like https://oragono.io/ which comes with an integrated bouncer.


A modern IRCd that doesn't look like it was written back in the 80's? 
WOW. It has all green boxes except for setname:


  https://ircv3.net/software/servers.html

Still... it feels like IRCv3 is still doing too little, too late. The 
design team needs to share images and short videos. Everyone wants 
threaded replies, profile pics...


So we need to wait for IRCv4, or switch to things like Matrix and 
Gitter, which are *already* IRCv4 ;-)


Yeah, it feels like a "boiling the ocean" type of scenario for sure with 
the ideal being clients advancing in lockstep with servers on the spec 
implementation. Threaded replies is a good example as the client-only 
reply tag has a single implementation: IRCCloud.


Image & file sharing I feel could be addressed by self-hosting, but of 
course it would need client support as well for the upload. For example, 
there is a file uploader plugin for the KiwiIRC webclient: 
https://github.com/kiwiirc/plugin-fileuploader


Profile pics / avatars as metadata have some implementations (at least 
IRCCloud). The metadata spec actually got a rewrite already (in draft 
status currently): https://github.com/ircv3/ircv3-specifications/pull/339


Ilmari

Re: The chat situation

[Ilmari Lauhakangas]

Bernie Innocenti kirjoitti 11.6.2020 klo 9.38:
Doesn't Riot.im support images well enough for your use-case? It's free 
software, and it's becoming fairly mature lately.


The root issue for both Telegram and Matrix seems to be that they're 
bridging through a legacy platform like IRC. Would it be fair to say 
that this problem will slowly resolve itself in time, as users leave IRC?


I don't mean to troll: I've been on IRC myself for 20+ years, but the 
protocol has been stagnating and clients requires too much setup for 
newcomers, particularly when you consider identity, presence and 
persistence. Other open source projects are migrating to Matrix or 
Gitter, and soon or later KDE will need to make a decision.


While progress with the IRC protocol has been slow, I would say freenode 
is suffering from stagnation the most at the moment. A service like 
KiwiBNC can act as a shim on top of freenode to bring modernity to 
everyone, but obviously limits to UX improvements will be hit. Freenode 
could solve this by moving to an actively-maintained IRCd (or invest a 
lot in their homegrown one).


An alternative would be setting up completely self-hosted IRC infra. 
This would really open up the possibilities as there are solutions like 
https://oragono.io/ which comes with an integrated bouncer.


Ilmari

Re: The chat situation

[Ilmari Lauhakangas]

Kenny Duffus kirjoitti 11.6.2020 klo 11.44:

On Thursday, 11 June 2020 08:19:21 BST Ilmari Lauhakangas wrote:

As an alternative, we can also "fix" IRC, meaning to improve its UX.

For offering a KDE-hosted always-online experience to everyone, there
are modern solutions such as

https://convos.chat/
https://thelounge.chat/
https://github.com/kiwiirc/kiwibnc

Of these, KiwiBNC is a general purpose bouncer, which means you can
attach any mobile or desktop client to it. Account creation could be
tied to KDE Identity.



Hi

KDE already offers a bouncer

https://community.kde.org/Sysadmin/BNC


Ok, that is nice, but KiwiBNC would remove the need for manual sysadmin 
work. Just thinking of a future that is up to modern expectations and 
without a setup UX requiring acrobatics. Even KiwiBNC still needs work 
to get rid of the need for command-line style setting up of SASL 
authentication.


Ilmari

Re: The chat situation

[Ilmari Lauhakangas]

Nate Graham kirjoitti 11.6.2020 klo 2.16:
Carson's email about bridging #kde-devel to Telegram got me thinking: we 
should have a discussion about the situation we're in regarding chat 
services in KDE.


The current Matrix solution does not seem not optimal to me. I have 
really tried my best to be a good citizen and use Matrix as much as 
possible over the last year but I find myself gravitating back towards 
Telegram because of how much better the overall UX is, especially for 
fast-moving discussions and those involving images.


I haven't found a Matrix client that offers both a half-decent UX and 
also a reasonable featureset. The service suffers from lag, sometimes 
severe. Periodically the federation breaks, or the bridge between IRC 
and Telegram breaks, leading to people's messages silently vanishing. 
The implementation of the bridge itself impedes discussions between 
Telegram users and IRC/Matrix users because when a Telegram user replies 
to a post made by someone on IRC or Matrix, that person person can't see 
the message being replied to. Overall it just does not feel like a great 
user experience.


This situation really needs to be fixed, somehow. I'm not knowledgeable 
enough regarding chat software to be able to propose solution, but I 
don't feel like the status quo is something we should live with. Can we 
fix Matrix? Or should we migrate to something that offers a better UX?


As an alternative, we can also "fix" IRC, meaning to improve its UX.

For offering a KDE-hosted always-online experience to everyone, there 
are modern solutions such as


https://convos.chat/
https://thelounge.chat/
https://github.com/kiwiirc/kiwibnc

Of these, KiwiBNC is a general purpose bouncer, which means you can 
attach any mobile or desktop client to it. Account creation could be 
tied to KDE Identity.


What is needed on the UX side is to make sure there is no requirement 
for command-line style interaction.


Ilmari

Re: New homepage for kde.org

[Ilmari Lauhakangas]

We can consult this site: http://shouldiuseacarousel.com/

Ilmari

Niccolò Venerandi kirjoitti 8.12.2019 klo 11.58:
Could that be an appropriate use case for a carousel? It takes less 
vertical space, and the user probably won't be annoyed by the automatic 
change of picture as he don't probably prefer one in particular, or stay 
much time looking at one.


On December 8, 2019 7:54:52 AM GMT+01:00, Kenny Duffus  
wrote:


On Saturday, 7 December 2019 22:52:55 GMT, Nate Graham wrote:

The Community section feels like it has too many pictures in
it. Maybe pare that down to just 3, like an Akademy group photo,
the GSoC photo, and the LaKademy 2018 photo.



I like that there are quite a few photos trying to show the variety, its
down at the bottom of the page so shouldn't be an issue for people not
scrolling past?


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Invent/gitlab, issues and bugzilla

[Ilmari Lauhakangas]

Elv1313 . kirjoitti 5.7.2019 klo 1.59:

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


The things other people mentioned (close issues when PRs are merged,
links with context on hover, etc) Plus, "in the future", maybe
improvements like being able to turn an issue in a pull request when a
patch is merged. Plus, as mentionned, an unified pipeline from
creating an issue to releasing a solution with proper metadata
tracking and APIs along the way.


We have had this sort of integration in LibreOffice (TDF) Bugzilla since 
the early 2010s as far as I know. BZ report numbers get linkified on our 
gerrit patch review and our various git web interfaces. Reports get 
automatic comments and whiteboard items upon commits. Changing the state 
to RESOLVED does not happen automatically, but that is because of very 
good reasons: some issues might take multiple commits/patches. Some easy 
hacks might stay alive for dozens of commits.


Bugzilla has had powerful APIs since forever and they are clearly 
wanting to keep improving them. Quoting from the BZ 7 UX roadmap:


Integrations

Bugzilla GraphQL API v1
GitHub integration
  Webhook support: Automatically attach pull request links and close 
bugs without a 3rd party bot


Regarding logins, if you visit https://bugzilla.mozilla.org/ you will 
notice it supports logging in with a GitHub account.


Single sign-on should be doable in any case, even if BZ would not offer 
support for a specific service out of the box.


The topic of managing low-quality or duplicate reports came up again. I 
think I mentioned this earlier in some other thread, but it bears 
repeating Mozilla is actively developing a tool to help with this and 
other bug management tasks: https://github.com/mozilla/bugbug


See "duplicate - The aim of this classifier is to detect duplicate bugs" 
etc.


Ilmari

Re: Invent/gitlab, issues and bugzilla

[Ilmari Lauhakangas]

Nate Graham kirjoitti 4.7.2019 klo 20.02:

On 7/4/19 10:39 AM, Boudewijn Rempt wrote:
Is it really true that gitlab makes reporting bugs easier for our 
users? I.e., does it offer easier login, an easier way to add screen 
shots and screen recordings or crash logs?


In my experience, yes. Being able to use a single account for everything 
is a big benefit. And being able to add multiple images and files inline 
via drag-and-drop is a huge improvement over Bugzilla IMO. Then again if 
Bugzilla 6 offers this, that will remove one advantage of GitLab issues.


Drag'n'drop & multi-upload is planned for BZ 7: 
https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-7-Roadmap


It would be cool, if entities like KDE e.V. and TDF could team up and 
sponsor BZ UX improvements so we'd get to BZ 7 & 8 goals faster. I'm not 
sure about the bureaucracy to make this happen, though.


BZ is also easier to extend under the hood now as it has started using 
Mojolicious framework. It will allow getting rid of the CGI dependency. 
Presentation about this: https://www.youtube.com/watch?v=0jIk3s7GsEo


Ilmari

Re: Invent/gitlab, issues and bugzilla

[Ilmari Lauhakangas]

On 04.07.2019 13:41, Boudewijn Rempt wrote:

So, what gitlab issues have over bugzilla is a rich text editor and a
confidentiality flag. What bugzilla has over gitlab issues is
reasonable solid set of features that help actually tracking and
managing the bug report. It's not that I'm a huge bugzilla fan, it
could be much better, but I need those features.


Bugzilla 6 supports Markdown in comments and automatic inline display of 
attachments such as images and text files (it will skip long text 
files). Note that what will be BZ 6 is live at 
https://bugzilla.mozilla.org/ - the big work during the past couple of 
years has been harmonising Mozilla's custom version and upstream BZ.


Re: confidentiality flag - BZ has supported private reports for a long 
time. Don't ask me how they work as I've never had to set those up.

Also, https://www.bugzilla.org/features/#private
"If you are in the "insider group," you can mark certain attachments and 
comments as private, and then they will be invisible to users who are 
not in the insider group."


Ilmari

Re: Invent/gitlab, issues and bugzilla

[Ilmari Lauhakangas]

Nate Graham kirjoitti 3.7.2019 klo 21.23:

On 7/3/19 11:53 AM, Albert Astals Cid wrote:

If the new is much better than the old, let's just remove the old.

As said, having two things that do the same is just confusing for 
everyone.


I would tend to agree, and having two is super confusing. In general, 
people who have reported bugs on both Bugzilla and GitHub or GitLab seem 
to agree that Bugzilla's UX is inferior. However I don't believe we've 
officially trialed GitLab Issues and investigated what missing features 
need to be added before we can migrate to it. Maybe the time to do that 
is now, as a part of the general GitLab evaluation and migration period.


Personally I find GitLab Issues to offer a vastly superior UX for bug 
reporting compared to Bugzilla. However the UX for bug management and 
triaging is not as granular. For example I still haven't figured out a 
way to create a saved search for "all Issues opened in the last 24 hours 
across all projects". And it would be nice to have some kind of overview 
similar to https://bugs.kde.org/weekly-bug-summary.cgi.


The upcoming Bugzilla version 6 will have a vastly superior UX to BZ 5: 
https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-6-Roadmap


With support from the BZ team, Kohei Yoshino has essentially solved BZ 
UX (this includes drafting plans for the future) and I am immensely 
grateful to him.


The underlying functionality will remain superior to GitLabs and hubs as 
it has been for years.


Ilmari

Re: Bugzilla order of sections when entering a new bug

[Ilmari Lauhakangas]

Nate Graham kirjoitti 22.6.2019 klo 12.44:

2) The description section should move above the duplicates check


I think this makes the duplicates check less useful, but the underlying 
issue here is that the duplicates check is itself not really as accurate 
as it could be so it's not helping users they way we envision it should.


Mozilla is working on an improvement:
https://github.com/mozilla/bugbug
https://hacks.mozilla.org/2019/04/teaching-machines-to-triage-firefox-bugs/

Ilmari

Re: Discourse

[Ilmari Lauhakangas]

Lays Rodrigues kirjoitti 27.11.2018 klo 18.25:

Let's not go in that way.
As a ~new person~ on KDE, 3 years only, we need to move to a modern web. 
At least in my point of view, I really think that using old stuff 
doesn't attract new people. In that I have a few ideas for some KDE 
websites go modern, but that is a project for the future.
Discourse is a way to do that. I don't have much idea on how is the cost 
to maintain such an application, but in the field to setup it, I don't

think that is hard since we just need docker and Postgres.

So Ben and other sysadmins,
Ben, you had some concerns that others answered on this thread.
What do you think?

Also, I found this ansible to deploy discourse with and without docker, 
that can be a starting point:

https://github.com/jamielinux/ansible-discourse

Let's think about how this can help all the KDE users, and push our 
community forward. If we have old stuff that is hard to maintain, and it 
is outdated, we should move forward.


The old stuff is not hard to maintain. Everything is hard to maintain, 
if you lack maintainers.


The Ansible setup you linked to is from 2015, but this is fresh: 
https://github.com/xpeppers/ansible-discourse


Ilmari

Re: Discourse

[Ilmari Lauhakangas]

Martin Flöser kirjoitti 26.11.2018 klo 19.03:

Am 2018-11-26 09:23, schrieb Ilmari Lauhakangas:

The main problem in any case will be getting enough engagement. I
don't think I have ever received a reply from a KDE developer in the
current forums.


And that's good! Do you want that developers spend time answering simple 
support questions any other user could answer or do you want developers 
to code? No company would put their expensive developers on the front 
line for support.


The thread started with: "I think KDE should consider moving away from 
mailman". Support questions were not what I had in mind.


Ilmari

Re: Closing NEEDSINFO bugs after 30 days

[Ilmari Lauhakangas]

Ilmari Lauhakangas kirjoitti 18.9.2018 klo 14.13:

Harald Sitter kirjoitti 18.9.2018 klo 13.40:

Anywayyy... I can throw together some automation so long as someone
tells me what exactly the process should be :P


Wait a bit as I have just been in contact with Andrew about re-using the 
automation LibreOffice already has for this. I need to ask our QA 
engineer about some details.


Ilmari


It turns out this task was not automated. It does have some Python 
scripting to figure out reports in need of closing: 
https://wiki.documentfoundation.org/QA/Bugzilla/Gardening#Cleaning-out_NEEDINFO:_30_days_later


Pinging reports untouched for a year is automated, though. See the 
bugzillaAutomation, bugzillaChecker and common scripts in 
https://gerrit.libreoffice.org/gitweb?p=dev-tools.git;a=tree;f=qa and 
look for "untouched". I hope it helps.


Ilmari

Re: Closing NEEDSINFO bugs after 30 days

[Ilmari Lauhakangas]

Harald Sitter kirjoitti 18.9.2018 klo 13.40:

Anywayyy... I can throw together some automation so long as someone
tells me what exactly the process should be :P


Wait a bit as I have just been in contact with Andrew about re-using the 
automation LibreOffice already has for this. I need to ask our QA 
engineer about some details.


Ilmari

Re: Improving Bugzilla Status Names

[Ilmari Lauhakangas]

Sorry, I don't have better suggestions. Naming things is a hard problem 
in bug science.


Ilmari

Andrew Crouthamel kirjoitti 5.9.2018 klo 11.17:
I like REPORTED as well. That leaves timeframe out of the status name. 
Bugs can stay REPORTED but never CONFIRMED, and that all makes sense.


Based on David's feedback, this would work for his needs I believe.

As for WONTFIX vs. ASDESIGNED, Ilmari, do you have any suggestions for 
alternatives? I know that isn't perfect, but was the best we could come 
up with so far.


Andrew Crouthamel



 Original Message 
On Sep 5, 2018, 12:03 AM, Nate Graham < n...@kde.org> wrote:


On 09/04/2018 10:01 PM, Christoph Feck wrote:
 > I still oppose to name a status NEW (again). It only attracts
"how is
 > this NEW? this is already [random timespan here] OLD!" comments.
 > There will always be products/components that have no active
maintainer
 > to look for bugs in a limited timeframe.
 >
 > My suggestions are OPEN, REPORTED, or UNRESOLVED.

I could get behind OPEN or REPORTED.

Nate

Re: Improving Bugzilla Status Names

[Ilmari Lauhakangas]

Andrew Crouthamel kirjoitti 5.9.2018 klo 5.28:
     d. If bug is not fixable due to technical limitations, or expected 
behavior, set to RESOLVED + ASDESIGNED.


WONTFIX is also typically used to refuse to implement features that are 
out of scope or not aligned with a product vision. Just wanted to point 
out that in these cases ASDESIGNED does soften the message, but does not 
clarify it :)


Ilmari

Re: KDE goals IRC office hour

[Ilmari Lauhakangas]

On 16.03.2018 17:35, Adriaan de Groot wrote:

On Friday, 16 March 2018 16:07:20 CET, Adriaan de Groot wrote:
I've now contacted the Janitor folks, so we'll see what can be updated 
and/or revised, and possibly start using it -- since it *does* sound 
like a very interesting service.


Please chime in on the GH issue I've created to discuss this:
 https://github.com/JanitorTechnology/janitor/issues/300
or if you want to use KDE infrastructure, please create a task on Phab 
and add that to this thread. The current environment is based on

 https://github.com/rcatolino/kdesrcbuild-docker
but we should have a few people -- part of the onboarding taskforce? -- 
look the janitor stuff over at least once.


Thanks for chasing this, Adrian, you rock! Thanks also to Raphael 
Catolino for the original Docker work and for still keeping at it. This 
is valuable not only for KDE, but for LibreOffice as well while we 
evaluate this thing.


Janitor is supposed to get Windows support mid-2018. This will be good 
for attracting more Windows hackers to KDE.


Ilmari

Re: KDE goals IRC office hour

[Ilmari Lauhakangas]

On 16.03.2018 12:29, Adriaan de Groot wrote:

On Friday, 16 March 2018 09:20:26 CET, Ilmari Lauhakangas wrote:

KDE

    Efforts:
    None
    WANTED: Maintaining KDE development environment image
    WANTED: Hosting Janitor containers for KDE
    Benefits:
    Development environments for KDE (hosted by IRILL)

It seems the ball was dropped regarding this. Why? Should be a perfect 
fit for the onboarding goal, no?



I think there was also:

Efforts:
    Missing: telling KDE that this thing exists

Maybe that's a bit snarky, but I can't find any previous mention of 
janitor on any KDE mailing lists. Is it possible that they set this up 
and then forgot to inform anyone? Maybe just the Mozilla tools list? I'm 
happy *you* know about it, and now think "this should be updated, and 
quick". There doesn't seem to be any way to quickly log in -- seems it's 
still in the alpha-invite-only phase.


[ade]



Ooo... k. That is highly weird. I've been wondering, how LibreOffice 
could get with the program "like the kool kids at KDE" and now it turns 
out KDE doesn't know it is in. You're too hip for your own good, it seems!


To Scott and anyone else: Janitor uses Docker so its not "either or". 
Here is the repo collecting all the environments: 
https://github.com/JanitorTechnology/dockerfiles


Ilmari

Re: Proposal for a poll to users about bug triaging

[Ilmari Lauhakangas]

On 28.02.2018 16:21, Jaroslaw Staniek wrote:
My story is, more rules, more scared users ignore the BKO. A single 
thing worth having is not too many rules but editing feature for *wrong* 
or outdated bug comments that make understanding the report so hard. 
Many years have passed since the first request and this feature still 
requires physical SQL access to the database or so, not regular user 
skills :)
Consequence is that I avoid BKO for own reports and go for fully 
editable Phabricator tasks.


Comment tags are a great way to keep the comment track clean: 
https://wiki.mozilla.org/BMO/comment_tagging
Bugzilla admins can define tags that make the comment automatically 
hidden. Here are the tags that we use in LibreOffice: 
https://wiki.documentfoundation.org/QA/BugTriage#Comment_tags


They can also act as useful pointers like "repro-steps" to highlight a 
useful comment.


The next release of BZ will have comment editing: 
https://bugzilla.mozilla.org/show_bug.cgi?id=540#c207


Note also the UX roadmaps:
https://github.com/mozilla-bteam/bugzilla-ux/wiki/Bugzilla-6-Roadmap
https://github.com/mozilla-bteam/bugzilla-ux/wiki/Bugzilla-7-Roadmap

Ilmari

Re: Proposal for a poll to users about bug triaging

[Ilmari Lauhakangas]

From experience, priority & severity are nice-to-haves most of the 
time. In LibreOffice, they are the most useful in the case of crashes or 
hangs, where we use high/highest & major/critical.


Ilmari

On 28.02.2018 16:25, Scott Harvey wrote:
As the former manager of an IT help desk (back in the olden days), my 
input on some of this. I'm only a junior developer who's offered up a 
few minor patches thus far and have done a bit of bug triaging.


We need to back up and remember the definition of the word triage:

(in medical use) the assignment of degrees of urgency to wounds or
illnesses to decide the order of treatment of a large number of
patients or casualties.


The former help desk manager in me says that's the key and that's what's 
not happening - severity sorting. An ordinary user will be able to help 
tell you if a bug can be reproduced, but it'll take someone more 
experienced to set the priority. Twenty years ago, I was sorting help 
desk tickets for Novell Groupwise and Windows 95. My staff of techs 
needed to be told what takes priority. As in, if the company preident's 
secretary can't access her email, head to the 6th floor immediately. 
That person with the sticky spacebar can tough it out a bit longer.


Those of you who are high-level developers or maintainers are still 
going to need to do this. An ordinary user who's "triaging" bugs can 
only tell you if they can reproduce a specific problem. It's going to be 
up to the gurus to shuffle things by priority. Someone like me, who's 
maybe more experienced than some - at age 48 - can help out a bit and 
retry a problem scenario, but I don't have the familiarity with the 
code, the frameworks, not even C++, to tell you what's top priority and 
what's not. Sure, if duplicating a bug brings down my whole system like 
the bug report says, I'm going to get someone's attention. But in 
between that and a minor annoyance... I can't decide that.


-Scott, graybeard wannabe junior developer

On Wed, Feb 28, 2018 at 7:54 AM, Ilmari Lauhakangas 
<ilmari.lauhakan...@libreoffice.org 
<mailto:ilmari.lauhakan...@libreoffice.org>> wrote:


I would argue this is not the most important thing, at least not
before recruiting a proper QA team for your application. It does
help with noticing duplicate reports, but it is quite
work-intensive. In LibreOffice we currently have 657 meta reports to
categorise everything. Yet, we also have 20-30 active QA persons
shuffling things around.

Assigning correct components can very well be done gradually by
increasingly educated and experienced non-developer QA contributors.

Having a lot of components makes it obvious that the Bugzilla
interface needs some tweaking, at least Advanced search. The
component selection field in there feels cramped and its width does
not even resize to show the longer component names.

Red Hat has customised their BZ and added sub-components (so you
have Product -> Component -> Sub-component). Their code is not yet
public.

I think when wanting to have a fine-grained categorisation, it would
be better to have only a handful of components and then a lot of
*optional* sub-components. Bug reporters not knowing what to pick
could skip the sub-component step.

I do not advise KDE to copy the LibreOffice model of meta reports.
Meta reports don't live in the bug creation/search interface and are
thus difficult to discover.

Ilmari

On 28.02.2018 13:49, Gilles Caulier wrote:

Hi,

Instead to start to talk with users about bugzilla, I recommend
to separate well the project with bugzilla sub-components.

In digiKam, i pass a lots of time to create sub-sections. This
is the most important task to do before triaging.

Remember that users are not developers. Some sections can be
relevant of some technical info from source code, so the
developers must prepare the sections before to delegate triaging
to users. If users process a wrong re-routage, this will be
complex later to maintain a project.

See the sections created in bugzilla about digiKam project for
example :

https://bugs.kde.org/editcomponents.cgi?product=digikam=1

<https://bugs.kde.org/editcomponents.cgi?product=digikam=1>

Best

Gilles Caulier

2018-02-28 12:35 GMT+01:00 Ilmari Lauhakangas
<ilmari.lauhakan...@libreoffice.org
<mailto:ilmari.lauhakan...@libreoffice.org>
<mailto:ilmari.lauhakan...@libreoffice.org
<mailto:ilmari.lauhakan...@libreoffice.org>>>:

     I am personally convinced that users do not know bug
triaging is a
     thing and certainly not how much they could help developers
by doing
     it. It would be very useful to test thi

Re: Proposal for a poll to users about bug triaging

[Ilmari Lauhakangas]

I would argue this is not the most important thing, at least not before 
recruiting a proper QA team for your application. It does help with 
noticing duplicate reports, but it is quite work-intensive. In 
LibreOffice we currently have 657 meta reports to categorise everything. 
Yet, we also have 20-30 active QA persons shuffling things around.


Assigning correct components can very well be done gradually by 
increasingly educated and experienced non-developer QA contributors.


Having a lot of components makes it obvious that the Bugzilla interface 
needs some tweaking, at least Advanced search. The component selection 
field in there feels cramped and its width does not even resize to show 
the longer component names.


Red Hat has customised their BZ and added sub-components (so you have 
Product -> Component -> Sub-component). Their code is not yet public.


I think when wanting to have a fine-grained categorisation, it would be 
better to have only a handful of components and then a lot of *optional* 
sub-components. Bug reporters not knowing what to pick could skip the 
sub-component step.


I do not advise KDE to copy the LibreOffice model of meta reports. Meta 
reports don't live in the bug creation/search interface and are thus 
difficult to discover.


Ilmari

On 28.02.2018 13:49, Gilles Caulier wrote:

Hi,

Instead to start to talk with users about bugzilla, I recommend to 
separate well the project with bugzilla sub-components.


In digiKam, i pass a lots of time to create sub-sections. This is the 
most important task to do before triaging.


Remember that users are not developers. Some sections can be relevant of 
some technical info from source code, so the developers must prepare the 
sections before to delegate triaging to users. If users process a wrong 
re-routage, this will be complex later to maintain a project.


See the sections created in bugzilla about digiKam project for example :

https://bugs.kde.org/editcomponents.cgi?product=digikam=1

Best

Gilles Caulier

2018-02-28 12:35 GMT+01:00 Ilmari Lauhakangas 
<ilmari.lauhakan...@libreoffice.org 
<mailto:ilmari.lauhakan...@libreoffice.org>>:


I am personally convinced that users do not know bug triaging is a
thing and certainly not how much they could help developers by doing
it. It would be very useful to test this by running a poll on
https://blogs.kde.org/ or somewhere.

Questions could be something along the lines of
"Did you know you can help KDE by analysing bug reports?"
"Did you know you can analyse most bug reports with regular user
skills?"

Ilmari

Proposal for a poll to users about bug triaging

[Ilmari Lauhakangas]

I am personally convinced that users do not know bug triaging is a thing 
and certainly not how much they could help developers by doing it. It 
would be very useful to test this by running a poll on 
https://blogs.kde.org/ or somewhere.


Questions could be something along the lines of
"Did you know you can help KDE by analysing bug reports?"
"Did you know you can analyse most bug reports with regular user skills?"

Ilmari

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Ilmari Lauhakangas]

On 28.02.2018 12:01, Luigi Toscano wrote:

On Wednesday, 28 February 2018 10:32:58 CET Boudewijn Rempt wrote:

On Wednesday, 28 February 2018 00:14:30 CET Luigi Toscano wrote:

On bugzilla.redhat.com some teams use the Triaged keyword. I think it
would
be a good solution.


I've been trying that, and it just doesn't work for me, like I said in my
first mail to this thread. It doesn't work because it's a tag separate from
the status of the report: tried-but-could-not-reproduce-yet is a state, part
of the flowchart, not a tag. The state should change once the bug could be
reproduced, or is resolved.


I disagree and I think it makes sense as keyword, as general attribute of the
bug (something happened according a triaging process). It is a modifier of the
"NEW"/initial state that is brought around later.


When we had our bikeshedding discussion about TRIAGED status over at 
LibreOffice, the rough consensus regarding the criteria was:


1. There was an attempt to find a duplicate
2. The bug was reproduced
3. Regression testing was performed
4. In case of regression, having completed bisecting was not mandatory
5. In case of crash, backtrace was obtained (or at least attempted)

Ilmari

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Ilmari Lauhakangas]

On 27.02.2018 22:06, Boudewijn Rempt wrote:

On Tuesday, 27 February 2018 20:39:31 CET Elvis Angelaccio wrote:


Exactly. Also, what Luca said: unconfirmed gives the impression that we
don't care about the bug.

My point is that confirmed/unconfirmed adds more problems than it solves.


Note _again_ that I am NOT asking for keeping unconfirmed/confirmed to stay
like it is with those terms. What I _need_ is another state. To repeat, I need
the following states:

* bug is reported, nobody has looked at it.
* bug is reported, somebody has looked at it, but the bug cannot be resolved
or confirmed at this point
* bug is confirmed, but not resolved yet
* bug is resolved in one way or another.

Call them whatever you want, I'll be fine with that. New, Triaged, Confirmed,
Resolved, whatever.


It is somewhat anxiety-inducing to follow this discussion from the 
perspective of someone who has worked in a solid QA team for several years.


What you need to focus on right now is not bikeshedding about statuses 
etc., but to recruit more and more QA/triagers. The QA team is Martin's 
"second level support". This is the primary solution.


Two years ago we had essentially the same "should we add a TRIAGED 
status" -discussion over at LibreOffice, initiated by myself. This was 
almost purely thinking about QA workers, not developers - yes, we are 
that independent. In the end we did not add the status. It is hard to 
predict the effects of increasing complexity so we did not bother.


Ilmari

Re: Let's get rid of UNCONFIRMED/CONFIRMED

[Ilmari Lauhakangas]

On 27.02.2018 15:45, Paul Brown wrote:

On Tuesday, 27 February 2018 13:43:17 CET Boudewijn Rempt wrote:

On Tuesday, 27 February 2018 13:30:12 CET Paul Brown wrote:

Is it true that users get confused by the bugtracking system? If so, this
is an issue, right?


Well, users can get confused by _everything_.


If a service is confusing for the target it is designed for, then should it
not be the job of the implementers to change it so it isn't?


Though I probably have more
absolutely non-technical users reporting bugs than most other KDE projects.
I haven't seen many signs of users being confused by UNCONFIRMED vs
CONFIRMED, though.

I'm all for making the initial reporting of bugs as smooth as possible for
users... Though really, I don't need any more bug reports.


Are you the only one dealing with bugs?


And after that,
giving me more information when I ask for it, that would be useful as well.


Then maybe think of ways of making that easy to do?


* It would be useful if users could embed images and videos instead of
creating attachments.
* It would be useful if users could use rich text in their reports.
* It would be useful if users could sign in with their cloud identities
(horrible though that idea is).
* It would be useful if bugzilla and the forum used the same login.
* It would even be useful if we could add badges or something like that to
tell the reporter "thank you for your report" with a nice graphic


This ties in well with the onboarding of new contributors project.


But messing with the statuses that basically define the workflow for the
developer because we think that users will feel happier seeing NEW than
UNCONFIRMED doesn't sound too useful to me.


Maybe, but whatever the solution, you'd be well-advised to start studying
carefully what users do now. Otherwise, whatever you try to implement will be
based on possibly false assumptions and prejudice and will have a higher
chance of failing.


I don't think it's relevant to ask Boud to start some huge Bugzilla user 
experience revamp on top of the things he is already dealing with. 
Naming of statuses are in any case the tiniest of problems. The 
fortunate fact is that Bugzilla UX is now being improved at a relatively 
fast pace: https://twitter.com/BugzillaUX


Bugzilla has been stuck in release limbo for quite some time due to 
Mozilla's instance diverging from upstream, but they have a plan to 
harmonise everything: https://wiki.mozilla.org/Bugzilla:Roadmap


In the upcoming version, rich text can be used in the form of Markdown. 
However, it does not support inline images and inline HTML. I am sure 
upstream BZ is open to discussion regarding the topic.


Ilmari

Re: Regarding KDE Chat Solution

[Ilmari Lauhakangas]

I see it rather as not moving away from IRC, but IRC moving towards 
modernity and thus remaining a viable protocol.


Regards,

Ilmari


On 21.02.2018 12:35, Ilya Bizyaev wrote:

Hello Severino! :)

I am glad you mentioned XMPP, and in fact I also see it and 
https://kdetalk.net/ as an alternative.


I am participating in a project that aims to develop a cross-platform 
XMPP client, Kaidan: https://github.com/kaidanim/kaidan

It uses Kirigami as a UI toolkit and libgloox for the backend.
It is still very basic, but we already have some users, so there 
clearly is interest.


Best regards,
Ilya.


 On Вс, 18 фев 2018 23:56:18 +0300 *Severino Ferrer de la Peñita 
* wrote 


Hello everyone.

When I was at FOSDEM this year, I was told about KDE moving away
from IRC and looking for something else.
I'm not involved in KDE as an active contributor or developer, but
I'm a happy KDE software user, so this felt really close to me.


After trying to follow the discussions on the mailing list, I was
hugely surprised that XMPP was not being mentioned.
That encouraged me to send this email.

I don't know if someone else already asked for the same thing. I
apologise if that's the case.


I have created this table:
https://github.com/SeveFP/KDE_IM_Requirements/wiki/XMPP-Table

based on the one at https://community.kde.org/IM_Survey_Results

I was not sure if I was allowed to modify the current table at
https://community.kde.org, that's why I started creating one by
myself first, to let you check it.

It has been a long time, trying to check all emails and blog
posts. If there's any requirement empty it's probably because I
didn't understand what it means.


Let me point out that XMPP is a safe bet for years to come, as
it's a widely deployed living standard.
Being this such an important move, I would like you to think about
XMPP as an option.

Personally, KDE has been doing awesome work with KTP and I would
love to see more work in this direction with XMPP.

Also, a mention to https://kdetalk.net/ is well deserved.

The XMPP community is really great, welcoming and active. Don't
hesitate to approach it, you won't be disappointed!


Thank you for your time,


Severino Ferrer de la Peñita.

Re: Telegram-IRC bridge not working

[Ilmari Lauhakangas]

On 14.02.2018 23:39, Nicolás Alvarez wrote:

Hi people,

The KDE Telegram-IRC bridge bot is not working anymore, and after some
troubleshooting and upgrades uhh I think I managed to break it more.
Maybe it's a problem with Telegram's servers though. I'll do some more
testing later, but for now it's down.

The same problem was reported for LibreOffice and it was said to be 
because of changes in Telegram itself.


Ilmari

Re: bugzilla, it's products, how they relate to projects. it's a mess...

[Ilmari Lauhakangas]

On 01.02.2018 12:50, Boudewijn Rempt wrote:

On Wednesday, 31 January 2018 20:44:13 CET Ilmari Lauhakangas wrote:

In LibreOffice, we only restrict priority and severity and even those
upwards from medium/normal. We monitor messy stuff with a script:
https://gerrit.libreoffice.org/gitweb?p=dev-tools.git;a=history;f=esc-report
ing/qa-tools.py


That looks pretty interesting!


If anyone wants to have a chat with Xisco about the script, he will be 
at FOSDEM: https://fosdem.org/2018/schedule/track/open_document_editors/
This has a mugshot: 
https://blog.documentfoundation.org/blog/2016/08/31/presenting-xisco-fauli-the-new-qa-engineer/


Ilmari

bugzilla, it's products, how they relate to projects. it's a mess...

[Ilmari Lauhakangas]

On Monday, 29 January 12:16:07 UTC Boudewijn Rempt wrote:

On Monday, 29 January 2018 12:25:24 CET Harald Sitter wrote:
I don't like going to our bugzilla.


Me neither... But that's more because I have to triage about a 1000 bug
reports a year, and many of them are not bug reports at all, but 
support

questions.


This sounds horrifying and should absolutely not be the case. Over at 
LibreOffice, an average full-time dev triages at most a 100 bugs per 
year from scratch (number pulled from my hat). Nearly all of the reports 
are first attacked by a ruthless gang of non-developers, numbering about 
20-30. Sure, there are some hybrid QA/dev beings, but they have usually 
"grown up" inside the tracker and started to lean more and more towards 
submitting patches.


As Nate has now attained demigod status with his usability blog posts, I 
think it would be good to take advantage of all the positive attention 
and tie it into one of the other goals "Streamlined onboarding of new 
contributors". The point has to be hammered home: "If you love some dev, 
set them free of the burden of bug triage".


Non-dev users often express themselves like they have an inferiority 
complex, "sadly I don't know C++ so I can't help" etc. They need to 
understand their amazing potential in something that is quite frankly a 
direct energy transfer to developers. Yet, compared to other non-dev 
tasks, QA does not require much to get started. You don't have to be 
able to express yourself in eloquent ways, it is enough to blurt out 
"Repro" or "No repro" in a hoarse voice every now and then.


Ilmari

Re: [kde-community] Conservative proposal: let's work with Kiwi IRC

[Ilmari Lauhakangas]

On 16.08.2017 14:56, Jonathan Riddell wrote:

On Wed, Aug 16, 2017 at 12:58:35PM +0300, Ilmari Lauhakangas wrote:

The work-in-progress Kiwi Next client can be tested like so:
https://kiwiirc.com/nextclient/#irc://irc.freenode.net/kde
You can add more channels separated with commas.


Looks like another IRC web client. It's just as full of scary stuff
like hostnames and nicks as any IRC. What makes you think users of
Telegram/Hangouts/Slack will be comfortable in it?


This is just the sort of stuff that can be solved by working closely 
with the developer. Independent UX designers are also looking into the 
interface. Your mention of nicks is in conflict with this item in the 
requirements list, though:
Anonymity: When using an account, all details (names, e-mail addresses 
...) are optional and hideable, no SIM requirement

Re: Conservative proposal: let's work with Kiwi IRC

[Ilmari Lauhakangas]

On 16.08.2017 14:08, Christian Loosli wrote:

I mostly agree, even though I am unsure of how certain things could be
implemented, e.g.


* Editing messages


which IRC simply does not support. So my best guess would be that this 
only
works for people using the Kiwi solution, or the IRC people will see 
both the

old and the edited message.


This is true, but at least it is being proposed to the spec: 
https://github.com/ircv3/ircv3-specifications/pull/304

Kiwi could thus act as a reference implementation.

Conservative proposal: let's work with Kiwi IRC

[Ilmari Lauhakangas]

Hello you radicals. I am a KDE user and contributor and a member of The 
Document Foundation. Jonathan already referred to my mail on the 
LibreOffice projects list, so I might as well branch out here.


I've been working with Kiwi IRC's lead developer Darren for some weeks 
now. Today I showed him the "KDE IM requirements" Etherpad contents. He 
said he is willing to work with KDE and LibreOffice to provide a modern 
messaging solution on top of IRC. Working together would mean we trial 
the releases to make sure we are happy with the features. This is 
something that I am already doing for Kiwi as a web designer and 
battle-hardened bug triager.


I want to note that I was intrigued by Eike's mail about a possible Qt 
Quick -based Konversation reboot. I suggested I could try and gather 
funding to get it to a releasable state, but he was hesitant because of 
the usual issues with FOSS funding (who does the money go to exactly, 
how to agree on goals etc.). It would be great to have a desktop client 
with a GUI that stands out from the crowd. I proposed funding because I 
have a lot of experience in promoting FOSS crowdfunding campaigns, 
including Blender and Krita.


The work-in-progress Kiwi Next client can be tested like so: 
https://kiwiirc.com/nextclient/#irc://irc.freenode.net/kde

You can add more channels separated with commas.

I am including here Darren's thoughts on the KDE IM requirements 
Etherpad:


Kiwi Next is the next generation of the Kiwi IRC client, specifically 
aiming to bring modern interfaces and ease of use from platforms such as 
Slack to IRC.


Many communities have established environments built up around IRC so 
any features or additions that Kiwi IRC brings will be 100% IRC 
compliant throughout and put to the IRCv3 working group so that other 
clients and servers may also make use of the functions.


The UI for Kiwi Next is getting tested on all major browsers including 
mobile, with translations being made available for 28 languages to make 
sure that anybody trying to be part of a community can do so.


Keeping people connected to IRC so that they may receive notifications 
on their desktop and/or mobile is a huge feature currently missing from 
IRC. This is currently being developed directly into Kiwi IRC so it is 
available out of the box with minimal fuss. Once connected and logged 
into your existing network services, a user can then simply resume their 
session with complete message history and searching. This is a feature 
that will be introduced on kiwiirc.com very soon but also entirely open 
source to be used anywhere. Works very similar to ZNC in that Kiwi acts 
as a normal IRC client which means any IRC client can make use of the 
same server.


A lot of the points mentioned are very much inline with the aims for 
Kiwi Next, most likely due to the same mindset: Slack + IRC merged 
together with some IRCv3 features thrown in.


Some quick overview points:
* 100% standards compliant
* Part of the IRCv3 working group to improve IRC itself
* Open source with an available hosted solution
* Use existing infrastructure and tools
* Multilingual and accessible
* Web based while still allowing desktop clients to be used
* Has already been tested with thousands of users in a single channel 
flood fest
* Built in media preview (images, videos, PDFs, anything that can be 
embedded)


Soon to be released:
* Team based channels that supports @everybody highlighting
* Switchable message views such as traditional IRC view and a more 
relaxed avatar + relaxed view
* Message reactions (Using IRCv3 standards so they work with other 
clients too)


In development at the moment:
* Built in BNC with desktop/mobile notifications
* Use Kiwi IRC and a desktop client on the same account at the same time 
(similar to ZNC)

* Message history + searching + exporting
* File sharing by uploading files through the UI, with optional file 
history


Not in development but can easily be added into Kiwi Next if required:
* Replying to a message with a reference/quote
* Editing messages
* Annotate images linked/shared through the client
* Stickers between Kiwi clients or between all IRC clients