Amarok components in Bugzilla and how to improve this

[Bart Cerneels]

On Wed, Dec 9, 2009 at 23:47, Myriam Schweingruber
<schweingruber at pharma-traduction.ch> wrote:
> Hi all,
>
> currently, we have the following components in bugzilla:
>
> * AFT: Bugs and whishes related to Amarok File Tracking (0 open reports)
> * Collection: Bugs and wishes related to the database and scanning
> process (28 open reports)
> * CollectionBrowser: For bugs and whishes related to the Collection
> Browser (38 open reports)
> * ContextView: For bugs and wishes related to the Context View applet
> pane (22 open reports, default CC: Leo Franchi)
> * DAAP: Bugs and whishes related to daap. (2 open reports)
> * Documentation: All documentation related issues, like typos, missing
> elements, etc. (0 reports)
> * DynamicPlaylists: Bugs relating to the creation, population or
> management of Dynamic playlists.  (15 open reports)
> * Engines: Bugs pertaining to the engines. (6 open reports)
> * FileBrowser: For bugs and whishes related to the File Browser (7 open reports)
> * general: All reports that go in no specific category  (this is the
> default, 300+ open reports)
> * Mediabrowser: For bugs and wishes transferring music to your
> portable music device. (24 open reports)
> * Organizer: Bugs and wishes related to the "Organize Files Dialog" (0
> open reports)
> * OSD: For bugs and whishes related to the On Screen Display (7 open reports)
> * Playlist: Bugs and whishes related to the (main) playlist. (49 open reports)
> * Podcast: Podcast related bug reports (7 open reports, default CC:
> Bart Cerneels)
> * SavedPlaylists: Bugs pertaining to the playlistbrowser. (8 open
> reports, default CC: Bart Cerneels)
> * ScriptManager: Reports about the Amarok script manager and bundled
> Amarok scripts. Do not report bugs relating to third-party scripts,
> please contact the author. (12 open reports)
> * ServiceBrowser: Bugs and wishes related to the internet services
> components (10 open reports)
> * TagDialog: id3 tag editor (1 open report)
> * Usability: Container for all bugs/wishes that are usability issues
> (0 open reports)
>
> Where open reports means both bugs and wishes. Of course, as you can
> see from the amount of reports in general, this still needs a lot of
> filtering, especially in the wishlist.
> I added Documentation, Organizer and Usability recently, please tell
> me what you think, especially Usability might not necessarily the best
> solution, since it takes away the focus from the real element. I think
> it is necessary to be able to flag usability issues though, but the
> flags option seems too obscure to be really usable (and apparently no
> project uses them AFAICS).
>
> Some of these components are either underused if not used at all, some
> could be improved, either in their description or by adding new
> components to allow a more detailed filtering. Bart suggested new
> components in the past on several occasions, and I think it could
> really help filtering our bugs and wishes list.
> Currently, only very few of these components have default assignees,
> it could be helpful to add those who actually wish to get notified
> immediately.
>
> Please all, tell me what you think, what improvements would be
> appropriate, what is obsolte, etc.
>
> Also I would be grateful if you all could have a look at the wishlist,
> since I am sure there are a lot of already implemented features lying
> around that we forgot to close. I am going through the wishes with
> release numbers to put those up to date, but with almost 400 wishes
> there is a lot of work.
>
> As a reminder, we have the following queries available, which you can
> also add to your bugs list through that link:
> https://bugs.kde.org/userprefs.cgi?tab=saved-searches
>
> http://tinyurl.com/allamarokbugs, called AmarokBugs in the saved searches,
> http://tinyurl.com/amarok2assigned (including those waiting for info
> for backtraces), called AllAmarokBugs in the saved searches,
> http://tinyurl.com/wishlist2assigned, called AmarokWishlist in the
> saved searches.
>
> as well as the queries for the release-blocker and the 2.2.2 targets.
>
>
> Thanks in advance for your help and suggestions.
>
>
> Regards, Myriam.

Before going into these specific categories I would like to suggest a
bug sorting "philosophy" we could use to determine the categories.
I like to keep 2 classes of bugzilla users in mind: the bug-reporter
and the bug-solver. Solvers include triagers and developers.

They sit at opposite ends of the bug process with a different
viewpoint: the reporter sees the application misbehave through the UI,
the triager can see common causes (in stacktraces, similar behavior
but in another part of the UI) but the developer expects a plugin,
class, file, linenumber in the code where things go wrong. The
categories should be easy to work with for both, but that actually
conflicts. So why not create 2 different groups of categories and use
the changing of categories in our workflow.

So I suggest we create 2 groups of categories:
- corresponding to the common GUI elements with an easy to recognize
description for the reporters: the result should be most new bugs are
immediately reported in the correct category.
suggestions: ThePlaylist, MediaSources, Toolbar, ContextView,
LocalMusic, InternetServices, SavedPlaylists, etc.
This should be limited to common UI elements.

- a group for amarok subsystems and plugins (backends):
LocalCollection, DaapCollection, LastfmService, MagnatuneService,
IPodPlaylistProvider, UserPlaylistProvider, SqlPodcastProvider, ...
You'll notice these names are also names of classes in Amarok, most of
which are maintained by one or a small group of people, they would be
in the default CC for these categories.

The UI -> subsystem workflow is not very strict: some reporters might
report it to the correct subsystem immediately, other bugs might
really be UI specific and nothing to do with the backends. The concept
also breaks down a bit for context plasmoids and scripts where the UI
and backend are the same or where these is no UI.

I don't know if this is the case, but dr konqi should support
selecting a category, possible limited to a certain subset. With the
UI corresponding group of categories it should improve the quality of
those reports.

Sorry for the long text.

Bart