More explicit policies for core apps
We have relatively detailed naming/branding guidelines for third party apps, but no clear policy for core apps, which has been a source of friction. More generally, we don't have a clear process for how to deal with core app maintainers disagreeing with the design or release teams, which I think would be good to have for more efficient collaboration going forward.
With regard to naming/branding core apps present a number of unique challenges in this regard that don't apply to third party ones:
- Core apps need to be incubated (sometimes for a long time) before a decision about inclusion in core can be made. Ideally they can be used as daily drivers for some time before becoming core, e.g. via the Nightly Flatpak repo or a COPR. This means that during the incubation period they need to have a name and app ID of some kind, and of course the app name also appears throughout the app's code.
- We need display names to be generic, but if the display name is different from the binary/project name that can lead to confusion and feels unpolished. Ideally binary, project, app ID, display name, internal code names, etc. should all be consistent.
- This means that you either need to incubate apps with generic core-style names (e.g. gnome-text-editor), which can be problematic when an app doesn't make it into core in the end, the name needs to be changed before core inclusion (e.g. kgx), or you end up with inconsistent new core apps.
- The current core app set has a number of GNOME 2 era apps with different internal names, some of which are quite weird (Eye of GNOME, Evince, Epiphany, Nautilus), as well as GNOME 3 era ones with generic
gnome-
prefix names (gnome-software, gnome-clocks, gnome-weather). There are also apps with generic project names but different generic display names (gnome-disk-utility, gnome-control-center). It's unlikely that we'll be able to change all existing app names, so we'll probably have to live with some amount of inconsistency for years to come. However, the question is what do we do for new apps? - Core apps may be dropped from core at some point in the future, at which point they would ideally have a non-generic third party app name.
Changing most aspects of an app's brand is difficult, which is why renames should be kept to a minimum:
- Changing binary names can be an API break
- Changing flatpak app IDs requires EOLing
- Changing internal names (files, classes, etc.) means you lose git history
- App icon and display name can be changed relatively easily, but changing only those means you get inconsistency
Tentative goals for a new policy around this:
- Process/best practices for incubating new apps that may or may not make it into core at some point
- Process for getting new apps added to core
- Process for removing/replacing core apps, ideally in a way that's transparent to users
- Process for how decisions around core apps are made in general, as well as roles and responsibilities for various groups
- A clear way to handle names/app IDs/etc throughout the lifecycle of a core app
I can try drafting something, but would be good to hear if there are any other concerns/goals missing from this.
cc @aday @mcatanzaro @alatiera @ZanderBrown @BrainBlasted @exalm @verdre