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.
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:
Have a dedicated gitlab project at Releng · GitLab 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 Home · Wiki · GNOME / gnome-build-meta · GitLab)
The approval could be similar to the release freeze break requests: two approvals from release-team members and no objections.
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)?
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.
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 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.
