Empowering Nix Teams - Alpha Phase

Announcements
1

Empowering Nix Teams - Alpha Phase

TL;DR: We want to improve the functioning of teams in the Nix project by giving them clear ownership and responsibilities, with greater support from the NixOS Foundation. Since not all teams need the same level of formality, we will have different tiers of teams.

Since Nix was first introduced it has grown and improved tremendously. This has been further catapulted over the last three years. A critical majority of the reason this is happening is because of the tremendous amount of work done by the community through its amazing members.

Over time our community has self-organized into various teams, each supporting a different aspect of Nix. However, since many of these teams have emerged organically, they often lack a well-defined mandate and structure - for instance, it’s often not clear what the responsibilities and powers of a team are, who its members are, or what their plans are.

We believe it’s time that we take another leap forward, bring Nix and the community to the next level by focusing on empowering Nix teams.

Since not every team is equally critical and we don’t want to burden people with bureaucracy when it’s not needed, we plan to have three tiers of teams: Critical, Formal and Community. This will help us provide each team with what they need to reach their goals. We learned more about the core of this concept in our conversations with other open source foundations such as Rust and Plone who leverage it in their respective communities.

Implicitly we already have different tiers of teams, but making it explicit resolves various issues the community has called out in various channels (including the NixOS survey) and provides a needed boost. We believe this will empower the community in many ways, which include:

  • Clear mandates and responsibilities for teams.
  • Better communication and transparency of teams towards the community.
  • Reduction of overlap and redundancies between efforts.
  • Providing direct board support and funding.
  • Improve bus factors.

Nix Teams

Community Teams

The core of our community. Any group of people willing to collaborate on a common goal can form a community team. The foundation doesn’t get involved as long as there are no high-level conflicts or breach, and it does not receive any unique support or funding. However we want to provide some legitimacy and visibility to these teams. We can also empower these teams further by enabling the process to formalize, meaning that a Community team will be able to become a Formal team.

Anyone can create a community team with nothing involved: just open a pull request to the website to add your team to the community page (we plan to release more structured guidance on this soon but this isn’t blocked). For any team we plan to further encourage and support them by providing a “Nix Team Knowledge Base” and team lead handbook, that would provide the community with the support they need to create and maintain teams (i.e. a collection of templates for running meetings, making roadmaps, project management, best practices).

Proposed examples of community teams:

Formal Teams

Formal teams do work that has a broad impact on the Nix project, yet if the team were to “disappear” the project won’t be immediately hindered or broken. We therefore recognize that these teams need to receive more formal support (monetary and non-monetary) while becoming formally structured.

We have started to see this across a few teams in the last few months. IDoc Team / Nix Team)

Support Formal Teams Receive

  • Ability to apply to Nix Foundation funding and other direct funding related opportunities such as
    • Financial support for meetups and hackathons
    • Purchasing needed resources (hardware/cloud)
  • More prescriptive ability to request non-monetary support such as advisory and planning - for example, the board or other Nix teams can join to provide more help when desired by the teams.
  • Added visibility across all channels (Nix website, social media, discourse, etc.)
  • Team level @nixos.org email address

Structure and Responsibilities

  • Keep track of team membership, including a team lead who is the main point of contact
  • Publish meeting minutes
  • Have clear ownership, i.e. a statement about which areas/processes are the team’s responsibility.
  • Maintain a long term vision, a short statement that helps both the team and community understand what its goals are and how it plans to make Nix better.
  • Have a public issue tracker
  • Update Nix wide team calendar to share team related events (meetings/plannings/etc.)

Proposed examples of formal teams

  • Nix Team
  • Doc Team

Critical Teams

Teams that work on the most foundational aspects of Nix: if they disappear tomorrow will have an immediate and direct impact on Nix and the community.

In addition to the support given to Formal teams, Critical teams have a commitment from the board to get involved immediately to unblock and support resolving key issues should the team need it. This requires the board to be more involved in supporting the teams but will further strengthen these teams’ ability to continuously be optimized.

Critical teams and its members will also have more responsibilities and transparency in front of the Nix community. Beyond those of the Formal team, the Critical teams will have –

  • Quarterly Plan and Retrospective – Defining their short term scope of work and deliverables. Sharing a retrospective of the work done in the previous quarter, what went well, what didn’t and how the team can improve.
  • 1 Year Roadmap
  • 48 hour response time - An escalation path in case something goes wrong. The Nix board members will also commit time to be part of this path to ensure swift resolution.

Proposed examples of Critical teams

  • Infra
  • RFC
  • Marketing

Team checklist

For formal and critical teams:

For community teams:

  • Add a page for your team to nixos.org. It should list the following:
    • A short description of the team.
    • At least one member as a contact.
    • And anything else you want to list.

What’s Next?

We will move to an “alpha” phase for this new model by starting out with a handful of teams. With the goals of starting this process, see if it works, iterating on improving it, and beginning to create more resources for teams (knowledge base/templates/standardize formats). We believe that this will empower the community, the teams and Nix itself by providing that layer of structure and transparency to the entire community. We also plan to talk more about this at Nixcon!

These are the teams we are starting out with:

  • Infra team (critical)
  • RFC (critical)
  • Nix team (formal)
  • Doc team (formal)
  • Marketing (critical)

Getting involved

Whether you have feedback, want to formalize a team or have thoughts, you can directly reach out to us here, on Matrix or by creating an issue.

@armijn / @edolstra / @domenkozar / @ron / @thufschmitt / @grahamc / @garbas / @fricklerhandwerk / @lheckemann / @tomberek

6 Likes
2

I’m glad to hear more from the Foundation these days, and I think this kind of effort to recognize and structure the different groups that make this community work is especially important.

I’d like to know the motivation for choosing these specific teams and why they are deemed critical or formal. Looking at what constitutes a critical team, I find that it very much focuses on development (plans and roadmaps). One common critique is that this emphasis on the development of new features causes stability problems.

From my point of view, to find the most critical teams we should look at what is needed to maintain first and foremost the status quo. The core of Nix(OS) is the package manager along with the Nix expressions that are most commonly used. We want to test these hence we need to build them for which we need the infra and the funding. Thus to simply maintain the status quo I’d argue we have here four critical teams:

  1. Nix team
  2. Core packages (mass rebuilds, this includes security, as well as NixOS)
  3. Infra team
  4. Foundation for allocating/ensuring funding of the infra

I think we can all reason a bit differently here and end up with different results, hence why I am curious to the Boards reasoning.

8 Likes
3

I agree with @FRidh that critical teams should be about keeping the lights on, and Marketing or RFCs do not play a role there. Maybe maybe we can break down “Core packages” into Security and Release management, which we already have as teams.

A small proposal, but wording is sometimes important: What if we rename “Formal teams” to “Development teams” - all teams are “formal” already, in a sense. Critical teams are clearly much less about development, but all share the property of having to be responsive. Then community teams can cover other, more diverse, special, or less well-defined topics.

Concretely, what about this:

Critical teams

Foundation board
Infrastructure
Security
Release management
Moderation

Development teams

Nix
Nixpkgs (architecture)
Documentation
RFCs
Marketing
NixCon

Community teams

Nix installer
emacs
static builds
macOS
…

10 Likes
4

That looks great :slight_smile:

I feel Documentation, RFC, Marketing and NixCon don’t really fit under the term “development”. Sure, they are developing something but it’s not code which is what I’d typically expect from that term in the context of IT.
They are the “main engine” to advance the Nix ecosystem through various means (perhaps actually mostly not code). Perhaps a more generic term like “Core teams” would be more appropriate.