[RFC] Defining a policy for what's a GNOME project

Community
#1

The Board is interested in formalizing a policy for the release-team to have autonomy over evaluating whether a project is part of GNOME.

This is important because projects which are part of GNOME represent our brand, identity and community, and for that I believe we should have high standards.

Considering that we now have GNOME Circle, which enables third-party applications to (among other things) benefit from the GNOME infrastructure, we would like to propose a similar framework for the release-team to define what’s a GNOME component.

One example of this is the proposal at https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/363#note_1064866 where some projects want to join the GNOME namespace and use the GNOME branding.

A great start could be to review our existing Software Policy and then define a [somewhat] formal process for evaluating a proposal. This could potentially involve:

The desired outcome for this discussion is for us to put together a proposal formalizing this process, to be presented to the Board.

3 Likes
#2

To start… I think a good process could be:

  1. Have a dedicated gitlab project at https://gitlab.gnome.org/Teams/Releng where applicants can file issues requesting to add an application or library to GNOME (similarly to what’s done to GNOME Circle). An application needs to have a justification and fulfill all the technical requirements and expectations (such as https://gitlab.gnome.org/GNOME/gnome-build-meta/-/wikis/home#technical-conditions-to-enter-gnome-core)

  2. The approval could be similar to the release freeze break requests: two approvals from release-team members and no objections.

1 Like
#3

Following “Official proposal: how we define GNOME software” for apps this would imply that the app will either become part of core or is a developer tool. If I understand correctly, core apps are recommended to be part of the default installation.

If all this is correct, shouldn’t there be some kind of criterion that ensures that the app is relevant for a good proportion of users or has some other reason to be installed as a default (like Orca)?

#4

Indeed, a strong rationale should be provided.

Although I am not sure we should limit this policy to apps that end up being part of core or developer tools, but applications that want to use the GNOME branding in general. I don’t have an opinion about this tbh.

#5

If other apps should be included the Software Policy needs an addition moduleset. Maybe it’s worth considering what a future set of core apps could look like and based on this try to estimate if there would be enough resources to maintain the required app quality for more than the core apps.

I noticed that the linked wiki page lists https://wiki.gnome.org/ReleasePlanning/ModuleRequirements as requirement which in turn states “This page is totally obsolete and exists for historical interest only.” Maybe this is not a good requirement :laughing:

Some brainstorming for less-technical requirements if it helps

  • The app provides at least what is the minimum that average users would expect from the apps name (a bit more than minimum viable product)
  • There is some minimal user testing that ensures that there is no uniform obstacle in using the app for the first time.
  • Basic design review from design team
  • Basic code quality review from ???

(I guess I’m a bit on the conservative side concerning the quality of new GNOME apps.)

#6

I think though - we might have a lot of noise if we don’t have a overall “organizing vision” to which we can apply to software. I think it might be important to figure out what that is - for instance, if we say we are optimized for developers (for argument’s sake) then that infers what kind of software is going to be included in the release or we would consider.

Otherwise, we’ll have a lot of debates on what we are including (as we have in the past) - so basically I’m saying we need a vision statement which gives some hint on what we are looking when considering software as part of the release.

2 Likes