<div dir="ltr"><div dir="ltr">On Sat, Sep 17, 2022 at 12:05 AM Nicolas Fella <<a href="mailto:nicolas.fella@gmx.de">nicolas.fella@gmx.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>Am 16.09.22 um 13:00 schrieb Dawid
      Wrobel:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr">On Thu, Sep 15, 2022 at 11:59 PM Johannes
          Zarl-Zierl <<a href="mailto:johannes@zarl-zierl.at" target="_blank">johannes@zarl-zierl.at</a>>
          wrote:</div>
        <div dir="ltr"><br>
        </div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is
            the launcher category the same as on <a href="https://apps.kde.org/" rel="noreferrer" target="_blank">https://apps.kde.org/</a>?
            If so, I would <br>
            strongly prefer to use that as well. From a user
            perspective, <a href="http://apps.kde.org" rel="noreferrer" target="_blank">apps.kde.org</a> <br>
            should be the single source of truth.<br>
          </blockquote>
          <div><br>
          </div>
          <div>
            <div dir="ltr">I know this was discussed to death dozens of
              times before, but given this context, wouldn't it make
              sense to devote <a href="http://bugs.kde.org" target="_blank">bugs.kde.org</a> to user-facing
              applications (as in <a href="http://apps.kde.org/" target="_blank">http://apps.kde.org/</a>)
              *only*, and move all the issues related to the underlying
              libraries, frameworks, tooling, etc. to GitLab, hopefully
              after migrating away from Phabricator as well?
              <div><br>
              </div>
              <div>It is not uncommon for organizations to maintain two
                kinds of bug trackers: one for end-users, and one
                internal, hiding the technical discussion away. I am
                sure this would improve developers' workflow while
                making <a href="http://bugs.kde.org" target="_blank">bugs.kde.org</a> less
                intimidating to end-users. Cause if I was coming from
                Windows/macOS and saw something like this:</div>
              <div><br>
              </div>
              <div>- KDE apps<br>
                - KDE Plasma Desktop<br>
                - KDE Plasma Mobile<br>
                - KDE Frameworks<br>
                - KDE Neon<br>
              </div>
              <div><br>
              </div>
              <div>, I still would be confused as hell. I mean how many
                KDE users are familiar with what Plasma
                (Desktop/Mobile), Frameworks or Neon are? Let's bear in
                mind that many of them use KDE apps individually on
                non-Linux platforms.</div>
              <div><br>
              </div>
              <div>Just my 2c.</div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Hi,</p></div></blockquote><div><br></div><div>HI Nicolas,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>you are on to something that I wanted to raise anyway: Quite
      often people report bugs for a frameworks they think is related to
      the problem instead of the product we expect them to use. Some
      examples:</p>
    <p>- kwindowystem or kwayland instead of kwin</p>
    <p>- pulseaudio-qt instead of plasma-pa</p>
    <p>- bluez-qt instead of bluedevil</p>
    <p>- networkmanager-qt instead of plasma-nm</p>
    <p>- knotifications instead of plasmashell | notifications</p>
    <p>Separating these "internal" components a bit from the user-facing
      products could make sense to reduce the apparent confusion.</p>
    <p>However, I don't think using an entirely separate (and
      different!) system for app bugs (bugzilla) and library bugs
      (Gitlab Issues) is a good idea. Those two are somewhat different
      in their workflows and capabilities (each having pros and cons)
      and I doubt having to deal with *both* would be challenging. For
      example think about moving bugs between the two systems.</p></div></blockquote><div><br></div><div>From my experience people will find their way to other systems anyway, and will merrily and happily ignore any signposts you put in their way saying "don't come here for this".</div><div>Therefore while we probably should utilise classifications to put the places we want users to file bugs front and center, another system certainly isn't the fix.</div><div><br></div><div>(Even with the great big red notice at the top of the new issues page on <a href="http://invent.kde.org">invent.kde.org</a> people still use the feature...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>Cheers</p>
    <p>Nico<br></p></div></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>