How do you plan on making community projects official?

[minijackson]

Question

What procedure would you implement to make community projects official? What benefits would those projects get once they are?

Related to #89

Candidates I'd like to get an answer from

No response

Reminder of the Q&A rules

Please adhere to the Q&A guidelines and rules

[numinit]

We value experimenting with designs and concepts, and folding successful experiments back into continuous improvement for stable components.

I feel like we should observe how projects are being used and look for people making de facto standards out of them. That's an indication that an experiment is working. Then, we discuss with the project owners and the community about the pros and cons of promoting it. Being bundled with a core Nix project in some fashion would be a benefit.

[getchoo]

TL;DR: I have a similar stance on this as I did in the question mentioned above and #34. See my previous responses in both for some context

How do you plan on making community projects official?

I don't think there should be set plans for making these projects official. Having projects fully owned by the community is very valuable, and I believe has resulted in great work being done in an environment with a lot less pressure put on contributors. It allows more risks to be taken, new ideas to be explored, and isn't limited by opinions held by the primary governance of the official organization. We should only be leaving the door open for projects that would like to graduate to an "official" status

What procedure would you implement to make community projects official?

I believe community projects must

• Align with our stated values
  • Specifically in not introducing too high of a maintenance burden and having a commitment to stability
• Explicitly follow our consitution
• Bring a clear benefit to the wider community
• Have approval from most stakeholders in the implementation (be it the SC itself, teams we delegate responsibilities to, and/or regular users)

What benefits would those projects get once they are?

The biggest would probably be the attention that results from being considered "official". This (usually) results in more PRs, reviewers, bug reports from users, and improved moderation. They may also be able to leverage other resources in the Foundation such as Hydra and our Security Team, which can be extremely important for mission critical projects

[tomberek]

I think most of the answers to this question will be quite similar and are non-controversial (eg: @numinit
and @getchoo covered it well). The only thing I'd like to add is that this is a [primary responsibility of the SC](Management of Official Resources); acting upon the consensus and executing the decisions will take the most work. This involves a lot of coordinating across many communities and interested parties. My plan to address this is to establish clear responsibility to execute these decisions, because otherwise they become "decisions without action".

[proofconstruction]

As I discussed in my answer to #11, community projects that want to become official should first move to the nix-community GitHub organization where they can be further developed with upstream integration in mind. Officially adopting projects into the NixOS organization should probably happen via the RFC process, where we could answer questions like the following:

• does this project fit the broader strategy and goals of the official organization?
• do we have enough maintainer support to make this project official?
• what other impacts, both positive and negative, will result from this project's officialization?

Projects that do ultimately become official should receive the same treatment as any others: dedicated development and maintenance effort as part of the broader roadmap of the organization.

[mschwaig]

Since you related your question to #89 I am going to answer it from the 'ecosystem fragmentation' point of view.

For a lot of practical things people want to accomplish with Nix, and cutting-edge efforts like https://github.com/nix-community/lanzaboote and https://github.com/nix-community/trustix, users have to go out of their way to use them.
This increases friction for users, because it makes it more difficult for them to get to where they want to go.

Making projects official, to avoid fragmentation, then generally looks like taking steps towards including them in official repos and making them part of the default user experience. Those steps are roughly:

1. implementing them in a way that can actually be up-streamed
2. ironing out issues
3. merging them into official repos, so they can be enabled with a flag or experimental feature
4. enabling them by default

This is only a very rough outline, and the specifics will very much depend on the project and require a lot of communication. For some of these changes utilizing the RFC process might useful and necessary, but we have to make both the practical and formal process work well for each individual project.

[jtojnar]

I agree with @proofconstruction above that this should happen by RFC.

I do not think making the project official necessarily provides any benefits other than signalling the level of maintenance. But that can be done in other ways so I do not actually consider officiality very important.

We might also want to come up with specific criteria and demote projects that no longer satisfy them.

[asymmetric]

As I mentioned in my candidate form think it's super important to define, basically, a finite-state machine, with clear states and clear transitions, around a "Platform", defined by the OCaml project as

a coherent set of tools, documentation, libraries, and testing resources

This would help in a few ways:

• Help us determine where to allocate our finite resources: declaring that a project is in a given state comes with support requirements, in the form of stability, documentation, polish, backwards-compatibility, etc
• Set expectations for users
• Indicates to interested parties where we need help, and what kind of help (e.g. funding, or greenfield experimentation, or stabilization)
• Clarify how a project transitions to a next state, e.g. towards stabilization or deprecation.

Now this is all well and good, but how do we go about this? A first step in this direction has already been started. The SC should put its energies behind this effort, and clarify questions like "what does it mean for a project to be official".

I don't think this is going to be a quick and easy job, especially for the first round of SC nominees, so part of this cohort's job will be to discover, establish and document processes for slowly converging towards this goal.