[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-community
Subject: Re: Issues with the issue tracking system
From: Philippe Cloutier <chealer () gmail ! com>
Date: 2019-11-09 17:43:21
Message-ID: 49cf8e2b-39a5-7a62-deea-9f6bd2d80cee () gmail ! com
[Download RAW message or body]
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
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Martin,</p>
<div class="moz-cite-prefix">On 2019-11-04 03:05, Martin Flöser
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:88f05ab4cb7a848fde40ee79a750b780@kde.org">Am 2019-11-04
02:11, schrieb Philippe Cloutier: <br>
<blockquote type="cite">Dear community, <br>
I am facing 2 issues with the ITS which I cannot solve myself
currently. <br>
<br>
Over the last months, I requested the "severity" (importance) of
<br>
several tickets to be adjusted: <br>
<a class="moz-txt-link-freetext"
href="https://bugs.kde.org/show_bug.cgi?id=149902#c4">https://bugs.kde.org/show_bug.cgi?id=149902#c4</a>
<br>
<a class="moz-txt-link-freetext"
href="https://bugs.kde.org/show_bug.cgi?id=317656#c17">https://bugs.kde.org/show_bug.cgi?id=317656#c17</a>
<br>
<a class="moz-txt-link-freetext"
href="https://bugs.kde.org/show_bug.cgi?id=410284#c7">https://bugs.kde.org/show_bug.cgi?id=410284#c7</a>
<br>
<a class="moz-txt-link-freetext"
href="https://bugs.kde.org/show_bug.cgi?id=206170#c4">https://bugs.kde.org/show_bug.cgi?id=206170#c4</a>
<br>
<a class="moz-txt-link-freetext"
href="https://bugs.kde.org/show_bug.cgi?id=408981#c4">https://bugs.kde.org/show_bug.cgi?id=408981#c4</a>
<br>
<a class="moz-txt-link-freetext"
href="https://bugs.kde.org/show_bug.cgi?id=407059#c1">https://bugs.kde.org/show_bug.cgi?id=407059#c1</a>
<br>
<br>
No adjustment was done yet. Please either: <br>
1. Solve <a class="moz-txt-link-freetext"
href="https://bugs.kde.org/show_bug.cgi?id=272388">https://bugs.kde.org/show_bug.cgi?id=272388</a>
<br>
2. Allow more developers to modify the field <br>
3. Or perform the requested changes <br>
</blockquote>
<br>
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. <br>
<br>
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.
<br>
<br>
What I did not like at all when managing the bugs, was: <br>
* 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. <br>
* users changing severity. <br>
<br>
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. <br>
</blockquote>
<p>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.<br>
</p>
<p>In any case, had you looked at the requests under discussion, you
would notice that:</p>
<ol>
<li>none requests severity to be set to critical</li>
<li>in fact, a large part requests severity to be lowered<br>
</li>
</ol>
<br>
<blockquote type="cite"
cite="mid:88f05ab4cb7a848fde40ee79a750b780@kde.org">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. <br>
</blockquote>
<p>No... you're only supposed to set the field to actual severity,
not to the most common value disregarding evaluations from others.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:88f05ab4cb7a848fde40ee79a750b780@kde.org"> <br>
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. <br>
</blockquote>
<p>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.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:88f05ab4cb7a848fde40ee79a750b780@kde.org"> <br>
As bad as it sounds: the best way to get bugs fixed is to get
involved. Sorry. <br>
</blockquote>
<p>First, this is about issues in general, not just bugs.<br>
Secondly, I never asked to solve these. All I'm asking is to
assign them a proper (or better) severity.<br>
</p>
<p><br>
</p>
<p>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.<br>
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.<br>
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.<br>
</p>
<p>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.</p>
<pre class="moz-signature" cols="72">--
Philippe Cloutier
<a class="moz-txt-link-freetext" \
href="http://www.philippecloutier.com">http://www.philippecloutier.com</a></pre> \
</body> </html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic