From kde-community  Mon Nov 04 08:05:30 2019
From: =?UTF-8?Q?Martin_Fl=C3=B6ser?= <mgraesslin () kde ! org>
Date: Mon, 04 Nov 2019 08:05:30 +0000
To: kde-community
Subject: Re: Issues with the issue tracking system
Message-Id: <88f05ab4cb7a848fde40ee79a750b780 () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-community&m=157293614511199

Am 2019-11-04 02:11, schrieb Philippe Cloutier:
> Dear community,
> I am facing 2 issues with the ITS which I cannot solve myself 
> currently.
> 
> Over the last months, I requested the "severity" (importance) of
> several tickets to be adjusted:
> https://bugs.kde.org/show_bug.cgi?id=149902#c4
> https://bugs.kde.org/show_bug.cgi?id=317656#c17
> https://bugs.kde.org/show_bug.cgi?id=410284#c7
> https://bugs.kde.org/show_bug.cgi?id=206170#c4
> https://bugs.kde.org/show_bug.cgi?id=408981#c4
> https://bugs.kde.org/show_bug.cgi?id=407059#c1
> 
> No adjustment was done yet. Please either:
> 1. Solve https://bugs.kde.org/show_bug.cgi?id=272388
> 2. Allow more developers to modify the field
> 3. Or perform the requested changes

I just looked through some of the bug reports and I think there is a 
general misunderstanding about bugs. Let me first introduce myself: I 
used to be KWin maintainer and managed all incoming bug reports for 
KWin. KWin is one of the products in bugs.kde.org getting most new 
reports - about 600 reports just last year.

While it would be awesome to fix all issues, that is just impossible. We 
are a community of mostly volunteer developers and don't have the time 
to fix all issues, especially not in a timely manner. Some bug reports 
while seeming a minor issue on first glance are a big issue and require 
years of planning and work. In my development it happened quite 
regularly that after years the code base had moved in a way to resolve 
10+ year open bug reports.

What I did not like at all when managing the bugs, was:
  * adding comments "still not fixed in 5.12.3" as that adds useless 
noise. If it's fixed we mark it as fixed, otherwise it's not fixed. 
That's the state of the bug.
  * users changing severity.

The severity is a field important to developers. We decide how important 
an issue is. Of course the issue is important to the affected users, 
otherwise they would not have reported the issue. We are quite aware 
that an issue is important, is affecting users and is problematic to 
workflows. Changing the severity doesn't indicate this. Every user 
thinks his issue is critical. If users are allowed to change the 
severity it would end in every bug report being critical. It becomes a 
nagging feature which is working against the community.

In KWin I used the severity field to decide what gets fixed. E.g. 
critical in KWin has the meaning "system freeze". A critical bug has 
highest importance. It's the issue which has to be resolved before any 
other work. It's the issue which once fixed results in an emergency 
release. I hope you understand that if a user reported a bug as critical 
I immediately changed back the severity to "normal" - which is what it 
is in most cases.

Overall my suggestion is to not nag in bug reports. At least in my 
involvement nagging and demanding in bug reports always had the opposite 
effect. If I have n bugs to fix and time to fix m bugs and n is 
significantly larger than m, I chose the subset m which gives me in 
volunteer working most pleasure.

As bad as it sounds: the best way to get bugs fixed is to get involved. 
Sorry.

Best Regards
Martin Flöser