From kde-community  Sat Nov 09 17:43:21 2019
From: Philippe Cloutier <chealer () gmail ! com>
Date: Sat, 09 Nov 2019 17:43:21 +0000
To: kde-community
Subject: Re: Issues with the issue tracking system
Message-Id: <49cf8e2b-39a5-7a62-deea-9f6bd2d80cee () gmail ! com>
X-MARC-Message: https://marc.info/?l=kde-community&m=157332142208934
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--------------B56091223A503681A8AC0F82"

This is a multi-part message in MIME format.
--------------B56091223A503681A8AC0F82
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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


--------------B56091223A503681A8AC0F82
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

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

--------------B56091223A503681A8AC0F82--