NixOS / SC-election-2024

2024 Election for the Steering Committee
31 stars 75 forks source link

How do you plan on making community projects official? #99

Open minijackson opened 1 month ago

minijackson commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

TL;DR: I have a similar stance on this as I did in the question mentioned above and https://github.com/NixOS/SC-election-2024/issues/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

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 commented 1 month ago

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 commented 1 month ago

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:

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 commented 1 month ago

Since you related your question to https://github.com/NixOS/SC-election-2024/issues/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 commented 1 month ago

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 commented 1 month ago

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:

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.