Am 16.09.22 um 13:00 schrieb Dawid Wrobel:
On Thu, Sep 15, 2022 at 11:59 PM Johannes Zarl-Zierl <johan...@zarl-zierl.at> wrote:Is the launcher category the same as on https://apps.kde.org/? If so, I would strongly prefer to use that as well. From a user perspective, apps.kde.org <http://apps.kde.org> should be the single source of truth. I know this was discussed to death dozens of times before, but given this context, wouldn't it make sense to devote bugs.kde.org <http://bugs.kde.org> to user-facing applications (as in http://apps.kde.org/) *only*, and move all the issues related to the underlying libraries, frameworks, tooling, etc. to GitLab, hopefully after migrating away from Phabricator as well? 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 bugs.kde.org <http://bugs.kde.org> less intimidating to end-users. Cause if I was coming from Windows/macOS and saw something like this: - KDE apps - KDE Plasma Desktop - KDE Plasma Mobile - KDE Frameworks - KDE Neon , 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. Just my 2c.
Hi, 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: - kwindowystem or kwayland instead of kwin - pulseaudio-qt instead of plasma-pa - bluez-qt instead of bluedevil - networkmanager-qt instead of plasma-nm - knotifications instead of plasmashell | notifications Separating these "internal" components a bit from the user-facing products could make sense to reduce the apparent confusion. 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. Cheers Nico
