Skip to content

Defining GNOME inclusion of projects

⚠️ This initiative is a work in progress: vision, technical approach, design and agreement of the community is on the works

Description

GNOME has always been loosely defined, being more a collection of different products that were added just because they were created by people with git access. This has caused an explosion of more than 1000 projects that most of them end up unmaintained or of low quality over the years. Some of the projects doesn't follow usual GNOME best practices or are not part of the vision and experience of what we would like to consider the GNOME product represents.

This creates other side effects, for instance, we don't have a path to be inclusive with projects that started outside of GNOME but that follow best practices of GNOME even more than some of the projects already inside our community.

Since GNOME is a both a product and a platform to build upon, it's harder to define. However, we can still define what projects can be part of the GNOME project independently of this difference.

With GitLab allowing personal projects and different groups we are no longer tied to have unfinished or toy projects within the GNOME product, while allowing the community to use par of our infrastructure.

Goals

  • Define what a GNOME application/library is.
  • Define a process for the acceptance of a project as a GNOME project.
  • Define a process for keeping the status of a GNOME project, while not putting in and out regularly.
  • Define what each kind of project gets.
  • Be inclusive, both for people and for projects.
  • Take into account important historical projects (e.g. GIMP :) )

Proposal

The proposal is to split in different categories the kind of project at GNOME. This will define what we consider the GNOME product, the GNOME platform, the GNOME infrastructure as an umbrella for other projects, etc. Splitting into categories will help on having clearer processes for inclusion and for explaining the benefits a GNOME project gets by default (fast CI, hackfests, etc.).

Note that exceptions to theses rules are fine.

Categories

Core GNOME app

  • Subset of Minimum GNOME apps
  • Still released by release team, same as now
  • Nothing changes for this group

Minimum GNOME app

What do they need to do?

  • Follow HIG / Design Vision
  • Good development practices
  • Fits in with technical vision
  • Hosted on GNOME Gitlab
  • No generic names which conflict with existing apps
  • Compatible license / legally unproblematic. FOSS.

What do they get?

  • Counts as contributions for foundation membership
  • Hackfests & sponsorship
  • GSoC / Internships
  • Translators
  • Can use org.gnome.App ID
  • Generic GNOME $APP name (optional, only if there's no conflict)
  • Fast Gitlab CI
  • GNOME/ Gitlab group

How to become one?

  1. Follows requirements
  2. Email the Inclusion Committee
  3. Committee iterates with the application authors and decides
  4. Once approved the maintainer gets GNOME Git access automatically.

Note that only the maintainer gets git access, this is to fix the missing bonding the application's team would have had if they would have contributed within GNOME before.

Maintainance & Exclusion Apps may lose their status if they don't

  • Release regularly
  • Keep up with the HIG as it evolves
  • Keep up with the platform's technical direction

Note that being resilient with this is part of the expectation, since projects are also developed by free time contributors.

Minimum GNOME library

Mostly the same as for apps, with one additional point:

What do they need to do?

  • Some GNOME project depends on it

Widely used by GNOME

What do they need to do?

  • We widely use it for regular development (GIMP, Inkscape, etc.)

What do they get?

  • Counts as contributions for foundation membership
  • Hackfests & sponsorship
  • GSoC / Internships
  • Translators
  • Fast Gitlab CI
  • GNOME/ Gitlab group

How to become one?

  1. Follows requirements
  2. Email the Inclusion Committee
  3. Committee iterates with the application authors and decides
  4. Once approved the maintainer gets GNOME Git access automatically.

Not widely used by GNOME

What do they need to do?

  • Uses GTK and/or some GNOME tech

What do they get?

  • Git hosting
  • Average Gitlab CI

How to become one?

  1. Ask Gitlab admin

Inclusion Committee

The committee is tasked with deciding whether new apps (or libraries) fit the "Minium GNOME app/lib" definition, and can become part of the GNOME project. They decide if newly submitted projects follow our design and technical vision.

Committee members

The board needs to have members with these skills/backgrounds (multiple points can be covered by one person):

  • Board Liaison
  • Designer
  • Someone with a technical background
  • Someone with some basic informal legal knowledge is a plus (licenses, trademarks and copyright).

Committee Charter Principles

  • Be inclusive
  • Give advice rather than strict requirements
  • Yearly check whether current projects fulfill the requirements

What is fixed by this proposal

  • Fractal, Podscasts, etc. and their respective developers to be part of GNOME
  • Tons of toy/unfinished projects in the GNOME product.
Edited by Carlos Soriano
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information