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