On Aug 19, 2014 1:52 PM, "Elad Alfassa" <elad@fedoraproject.org> wrote:
>
> Hi all.
>
> Since apparently we can't remove anything from default without having a "policy", and we can't ask packagers to fix their software either, I have to write this message.
>
> Apparently, not including a package by default is seen as "punishment". So, instead of doing actual work on bugfixing or debugging Fedora 21, or working on our website so it'll be ready for release time, I have to write this email message. I assumed the whole idea of Fedora.Next was to reduce bureaucracy and making sure we ship a high quality product. Apparently, I was wrong, and the point of Fedora.next seems to be *increasing* bureaucracy and having to discuss and write a policy for every one line commit we do.
>
> If you are out of the loop of the recent events, look at this bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1131248
>
> ---------
> Now, enough bitter sarcasm, here is my draft:
>
> In the following policy, I differentiate between "app launcher" and "app".
> An "app launcher" is a desktop file+icon that is shown in the application view, clicking on it would launch the app.
> An "app" is an application as defined by the GNOME 3 HIG (link TBD when HIG is published)
>
> As always in policies, mandatory items are marked with the words "must" and "must not", the rest is nice-to-have.
>
> App launchers in Fedora workstation *must*:
>  * Have a unique 64x64 launcher icon (the same icon MUST NOT be used for one default launcher).
>  * Have a matching High Contrast icon.
>  * Have a name that is either short enough to not be elipsized by the shell or immediately recognizable even when elipsized.
>  * Have a comment field in the desktop file with a one line summary of what the app is.
>
> App launchers in Fedora workstation *should*:
>  * Launch software that is an actual app - see the GNOME 3 HIG on the exact definition (link TBD when the HIG is published)
>  * If the app is not an actual app, it should have the appropriate desktop file categories to be placed in the Sundry folder in GNOME Shell.
>
> Apps in Fedora Workstation *must*:
>  * Not depend on / pull in other apps OR app launchers.
>  * Have exactly *one* app launcher - ie. two launchers to two separate parts of the same app is not allowed.
>  * Be packaged separately (subpackages are okay) form other apps OR plugins.
>  * Installable and removable independently from within GNOME Software, unless part of the "core applications" set, in which case they must NOT be removable.
>
> Default apps in Fedora Workstation *should*:
>  * Have appdata metadata (soon to be turned into a must).
>  * Have a good reason for being included in the default set, especially if not considered part of the core desktop experience by the GNOME upstream.
>  * Start in under than 10 seconds (on modern hardware).
>
> An app or launcher that fails to complies with these guidelines MUST NOT be included in the default install.
>
> Furthermore, if an app that doesn't follow this policy is include by default, it should be considered a Final Release blocker until the app is fixed to conform the policy or removed from the default install.
>
> ----
>
> Each line in this policy has a very good reason behind it, and I hope I don't have to explain each one of them separately. Following this simple policy will ensure a polished and good user experience in viewing, launching and installing applications.
>
> Note that I'm being a bit lax on the requirements here. I'd place "launch an actual app" in the "must" column but we tried that before and it didn't work due to (silly) internal project politics, as people want things like release notes have a launcher by default.
>
>
>
> Feel free to reply with your opinion, and put it in the wiki somewhere when it's officially approved by the WG (which, to remind all involved parties, I'm not an official part of)
>
> -
> -Elad Alfassa.
>
> --

First, your approach here comes across as punitive.  Maybe that's just frustrated delivery tainting good intentions, but between this post and the bug that prompted it, the connotation is there.  There's an effort going to improve and create AppData files - a similar approach of offering guidance and contributions is sure to get more traction.

Back to the issue, you have:

1. A UI that shows all known (via .desktop file) graphical applications, without restrictions, to the user.

2.  Some packages provide graphical applications of a class that you don't want to show in the UI by default.

So you have at least two avenues to deal with the situation:

1. Filter or categorize into submenus the applications you don't want to show in the default UI based on the existing desktop file metadata.

2. Draft a complex and subjective exclusion policy that targets applications you don't want to present to users, requiring a lot of packaging effort that may adversely affect other environments.

Okay, maybe *I'm* sounding a little bitter now, but come on.  If something needs to change to meet your design goals, you can still be considerate and cooperative, and allow the possibility that the design might need to change to accommodate the software it presents.

--Pete