Issues with the issue tracking system

Sat Nov 9 17:43:21 GMT 2019

Hi Martin,

On 2019-11-04 03:05, Martin Flöser wrote:
> 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.

Without claiming there is no hint of truth behind this, this is 
extremely exaggerated. If you look at the severity of new reports, you 
will find that only a minority is critical. As reporters set initial 
severity themselves, allowing them to adjust severity after would in 
fact help with that issue. But the real solution for the problem you 
expose is to create disincentives for severity inflation.

In any case, had you looked at the requests under discussion, you would 
notice that:

 1. none requests severity to be set to critical
 2. in fact, a large part requests severity to be lowered

> 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.

No... you're only supposed to set the field to actual severity, not to 
the most common value disregarding evaluations from others.

>
> 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.

I'm sorry but if you look at the issues described, you'll see that none 
of this is about nagging. Regarding the severity issue, in all 6 cases I 
made one single request to change severity. This topic represents the 
first time I somehow reiterate these requests, and that's after all of 
these 6 requests failed to generate a single adjustment. Plus, I'm not 
really recommending to go for option #3, but would really rather see a 
systemic solution through #1 or #2.

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

First, this is about issues in general, not just bugs.
Secondly, I never asked to solve these. All I'm asking is to assign them 
a proper (or better) severity.

Finally, to get this kind of comment on this situation is highly 
ironical. If this community wants to get badly needed new blood to fix 
its bugs, it should welcome new contributors.
Many years ago, someone saw me help with ticket triaging and recruited 
me. He allowed my account to commit to that project, and I started 
fixing tons of bugs, even though I initially had no intention at all to 
get involved in that project.
Nowadays, I'm even way more busy, so the chances I'll help with 
bug-fixing in a project to which I have no commit access are quite low. 
But it can be even way lower; if the issues one reports are considered 
resolved, then the chances one will further help fixing them are just null.

New contributors who help with issue tracking should be seen as 
recruitment opportunities. If this project has decided to go in the 
opposite direction and dismiss their issues instead, this project will 
not get fewer tickets to treat; it will get fewer people to deal with 
tickets, and much more importantly, longer term, way more issues to deal 
with.

-- 
Philippe Cloutier
http://www.philippecloutier.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20191109/e67b45a1/attachment.htm>