This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/how-many-people-are-paid-to-work-on-nix-nixpkgs/8307/49

@8573 Thanks for your feedback! I incorporated two out of your three remarks. Please unresolve if you feel I missed the point. Please also make suggestions for rephrasing if you feel I'm failing on being clear (I'm known for failing at times). I'm still pondering over your point about legitimacy, I'll make a draft PR on to my branch in my fork so we can discuss. I need some input about this aspect in order to not f*** it up.

@jtojnar Thanks for bringing up the manual. would you agree with my suggestion to put a note into the brainstorming section thereby clarifying the intended relationship?

It is still not clear to me – this whole proposal feels more like the postmodern prose Pinker mentions. What does “comprehend, consolidate and showcase” mean? Since discussions are not a goal, is the repository simply meant as a place where documentation about meta-stuff will be accumulated, after “ephemeral” discussion happens elsewhere? How does this differ from a “portal page” – I would think most portal pages just use set of markup files in a git repo as a backend these days, just like our manuals.

We should also ask if having a special place for meta stuff will not cause proliferation of meta stuff, thus defeating the goal of simplicity. 🤷‍♀️ meta stuff is hard.

@jtojnar I identify three points of your feedback:

1. Wording / Concepts (I don't succeed in make you see what I'm seeing)
2. Although, I think "meta-stuff" is an inappropriate abstraction, I think I understand what you want to say: "We should rather do things than talk about (how) doing things"
3. We might also call this NixOS/portal-page - while we could, it kind of takes a different stance. Don't you think?

Did I understand you?

Re 2:

• The current reality of discourse is, a lot of "talk only" is taking place consuming an incredible amount of resources.
• It lends meaning to individuals, but it doesn't systemically bias individuals towards action.
• This is where the motivation for this proposal comes into play and what it tries to solve.

@jtojnar Please let me know if you disagree with crediting you for this: 682b80a (I'd edit the commit message)

@jtojnar While processing your point about the risk of proliferation of "meta stuff": under which aspect on the below content this repo should cover do we anticipate this undesired proliferation?

Therefore it shall act as single source of truth for aspects of:

• Communication
  • Channels
  • Modes & Policies
• Governance
  • Processes
  • Structure
• Onboarding
  • Code Contributions
  • Community Engagement

I can see what you're after with this RFC and up to a degree it might help, however, I don't think we're there just yet and as pointed out by others, there's a lot of overlap with existing resources.

The Nix community cannot be compared with Kubernetes. Kubernetes has thousands of people working with it professionally full-time. The major corporations have huge interests in that project, making available some of their resources, which they want to be used well. The Nix community is significantly smaller. Yes, Nixpkgs has many contributors, however many are volunteers, that like to use Nix(OS), but maybe not do so professionally, and thus are themselves in charge how they spend their time. It's changing, for sure, more people are working with Nix on a professional level.

Now, I do think it is good if we record a bit more of our best practices, but again, that's really up to the contributors to do so. Currently it may cause frustration if certain maintainers don't allow useful changes (often for a reason), but its not clear to the contributor why not and the maintainer has no time to explain. Writing thinks out why they are the way they are and what direction it should take therefore can be helpful, but I am not sure whether this kind of process is needed for that at this point.

@FRidh Thanks for you comment. Since I agree with the your overall assessment: we can start very small and grow this idea organic, basically just linking all the way around the place to existing resources and formalizing 1-2 Working Groups or even Special Interest Groups (e.g. Marketing Team) and see if some of such groups could fly + record some meeting minutes from the steering committees and the marketing team and otherwise keep the profile as low as possible. Ah and put this cool quote somewhere at some footer page: 'Culture eats strategy for breakfast.' --Peter Drucker — I also still want to hear @samueldr 's opinion, since the wiki is kind of the closest artifact we have. We can also revamp this RFC for a motion to improve the wiki or a good mix of the ideas presented that everyone is comfortable with.

Like: Test it out and iterate quickly

addressed in 1d10fa4 - now also more inline with #74 (comment) which has had some support.

I'd like to point out that the Governance structure was already added to nixos.org some months ago. It is far from perfect and many things can be improved on those pages (as always PRs welcome 😉). How Nix community is organized/governed will be part of nixos.org.

I also share the sentiment with @FRidh that this is a bit too early. While you raise many good points I only wish Nix community would be at the state where such coordination would be needed. I think for now having teams and process described on nixos.org would be more then good enough first step by my opinion.

@garbas Is there a chance to put all content in markdown files? Such might already go half the way in implicitly achieving what this RFC is pointing at. (and stack all content into a content folder - so content and code are more clearly separated) - if there could be a highly volatile section in the spirit of this RFC within such content folder (even as submodule? -> nixos/community hihihi), then we are good to go. I can rewrite this RFC to it. But I postulate md's familiarity is a pre-requisite for the spirit of this RFC...

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/dockertools-imprecisions-docs/8770/17

@zimbatm 's NixFridays revived. 🥳 - They are an excellent "feedback loop conveyor belt". I'm going to plug into it and feed back things into this RFC that pop up over there. After listening to @ryantm and @jonringer, it is clear this RFC does merit some level of persistence and evolution.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/marketing-team-can-we-present-nix-nixos-better/6249/100

@burke would you be interested in becoming shepherd ? I imagine your company's current investment in nix (runix) makes you interested in promoting some spillover effects from other successful communities when it comes to resource coordination.

@garbas Is there a chance to put all content in markdown files? Such might already go half the way in implicitly achieving what this RFC is pointing at. (and stack all content into a content folder - so content and code are more clearly separated) - if there could be a highly volatile section in the spirit of this RFC within such content folder (even as submodule? -> nixos/community hihihi), then we are good to go. I can rewrite this RFC to it. But I postulate md's familiarity is a pre-requisite for the spirit of this RFC...

Currently we are not touching the format and keeping everything in HTML. Maybe once a tool for documentation is selected we might also switch to that, but we might need more structure in that page than what markdown can provide.

On the markdown note, I don't think using markdown file is the point of the RFC, but to have somewhere an information how Nix code is governed, organized and how to get involved.

After listening to @ryantm and @jonringer, it is clear this RFC does merit some level of persistence and evolution.

I don't think I conveyed my thoughts very well. I think it would be a great addition to have someone, who as their day job, would review PRs, issues, and do some community engagement. Work that is actual "work", and volunteers are likely not to put themselves through on a consistent basis. A lot of issues and PRs go unattended, and many more just get "forgotten" due to lack of time from volunteers.

@garbas

On the markdown note, I don't think using markdown file is the point of the RFC, but to have somewhere an information how Nix code is governed, organized and how to get involved.

Being convenient and accessible is — I'd expect daily updates on active groups. After markdown there is not much left, but let it just be a concise pars-pro-toto for a convenient format.

The more important questions actually was:

if there could be a highly volatile section in the spirit of this RFC within such content folder (even as submodule? -> nixos/community hihihi), then we are good to go

@jonringer I hadn't had the chance to incorporate feedback from NixFridays, yet. I'm still listening... 😉 Some of my quick notes include:

• nix-review vs r-ryantm
• "maintainer" means more practically "user with vested interest"
• how to get commit access
• the hardest part of contributing is to find the right folder — so true.
• discoverability of the manuals
• nix-update vs r-ryanthm

@blaggacao Could you suggest someone to shepherd this?

There is a trial implementation of this RFC conducted at https://discourse.nixos.org/c/sig/36.

This RFC is on hold and further data/experience needs to be gathered.

Once such data and experience is available, this RFC should document a fine tuned policy which bridges the gap in organization between low-commitment "ephemeral" discourse discussions and high-commitment RFC process.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/meeting-minutes-2020-10-27-empower-the-ecosystem/9677/1

Would you like to close the RFC while it's on hold? That way you can reopen it when you're ready to proceed.

@lheckemann Fully agree, if that's the process (which it seems to be).

The reasoning behind this is that the steering committee otherwise needs to discuss every two week this RFC and see where the process hangs.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/maximising-donation-input-from-community/12441/7