2024-03-07 Nix teams gathering meeting minutes

Meta
1

(also here for future-proofness)

Attendees

Team Name/handle
Foundation board @thufschmitt, @edolstra
Security @hexa
Infra @hexa
NixOS release
NixCon
RFC steering committee @infinisil
Marketing
Moderation
Nix team @thufschmitt, @edolstra, @tomberek
Documentation @fricklerhandwerk
Nixpkgs architecture @infinisil
Nixpkgs @raitobezarius
Geospatial

Agenda

  • @infinisil’s proposal for code ownership
  • Teams transparency: Making sure that all the relevant information for participating/staying up to date with a team’s activity are available
  • Graduating new projects to make them official (e.g. Home Manager)

@infinisil’s proposal for code ownership

  • started an RFC draft: https://github.com/nix-open-org/rfcs/blob/a3dbc94d9629592f1e992b2252dd841ea094e9ab/rfcs/0000-open-org.md
  • doesn’t actually have to be an RFC though
    • just collecting current structure and rules
    • reproducing the status quo doesn’t require community approval
  • idea: make the organisation “open” and enable anyone to propose changes via pull requests
  • @zimbatm is currently doing most of the implementation work
  • that should also answer the question “what is official?” as it could be tracked there, and there would be a place for discussing decisions

Teams transparency: Making sure that all the relevant information for participating/staying up to date with a team’s activity are available

  • @thufschmitt, after some discussions with @zimbatm
  • most teams have somewhat of an established process to stay up to date, get in touch, help out
  • but there is a lot of “somewhat”, and it’s on average hard to get going for beginners/outsiders, and figure out who to reach out to
  • most teams have some sort of information page, on nixos.org or in some repo
    • which information would we want on such pages?
    • do we need it standardized? if so, what should be there?
  • @raitobezarius: this topic comes up a lot
    • maybe what we want is an opt-in directory for code owners, domain experts, …
    • @qlyss brought up that it’s hard to contribute in a problem domain because you don’t know the domain
      • @tomberek: this could be said about anything, and having that raises the barrier to entry
      • @raitobezarius: agreed, and we should provide a ramp-up into the ecosystem. but it’s hard to ask everyone to write down this sort of instructions
  • @thufschmitt: the point is more about being able to get a big picture of what’s going on. it’s also a matter of granularity that we want
    • @infinisil: we could start with the teams, and e.g. require them to publish a decision log after checking which teams already does what
  • @thufschmitt: what should teams provide to empower new people to follow or participate? meeting notes?
    • @infinisil: more important would be a decision log and a way to know how to be involved in future decisions
  • @thufschmitt: should we require a particular format? some teams publish on Discouse, some in their repo, some have a Google document
    • @infinisil: the RFC steering committee recently switched to Discourse
    • @tomberek: at this stage it’s fine not to have “the one way”, as long as it’s transparent
    • @fricklerhandwerk: Important to be able to find stuff easily. Matrix is not great, not searchable. Discourse summaries are a good entry point, as they show up in notifications and are persistent
    • @tomberek: Should start with asking why we do this: It provides stability and predictability. Allows longer-term efforts to persist and succeed
      • general agreement
    • @thufschmitt: yes, it should be an enabler for teams, and valuable for teams themselves, otherwise it will just be additional work
    • @tomberek: and provide a positive reaason+benefit to do so? resources? attention? prioritization?
    • @fricklerhandwerk: With the Nix team we’re working with PR’s → just posting links to them. Could be automated
      • @raitobezarius: Relates to not having project management tooling. I know a group who’s working on a tool that would like it to test with a large community such as Nixpkgs
      • @fricklerhandwerk: Agreed. Just have to consider migration/onboarding costs. Teams could volunteer to try it out
    • @tomberek: Such tools should provide value to users and contributors, such as easier access to Foundation support, simpler processes for getting funding, etc.
    • @infinisil: this is also tied to giving teams authority, as then you also have to define what to do with that authority. but we seem to agree we generally want this.
      • maybe such process should only be required for teams which actually have authority. for example. the Nixpkgs Architecture Team doesn’t have any, as it abides to the RFC process (posting notes regardless)
  • @thufschmitt: should answer the basic questions, e.g. tomorrow a group appears that wants to be the next X. what are the guidelines for that to happen?
  • to do:

Archiving old projects

  • @thufschmitt: ran a script to bulk-archive old things. one false-positive was reported but turned out not to be one
  • updates for?
    • NixOps
      • @roberth asked to not archive
      • is now funded by Fediversity to write NixOps 4, but agreed to make it in a different org
        • once it’s “ready” it would be up to the “community” to decide to make it official
      • @raitobezarius has concerns; NixOps hasn’t been very community-oriented for years now and not reflecting reality accurately is problematic
      • @tomberek: solution is similar to what we already talked about
        • “official” is a privileged position. if it is to be provided, it cannot be run like a private project → Meeting notes, public decisions, etc. required
        • If that can’t be done, it’s not official
      • @fricklerhandwerk: Indeed, the ecosystem can’t reasonaly be run like private property, and we should absolutely stress figuring out what it would mean to run it as a commons
        • there is not just an issue of immense cognitive overhead for new users if it’s not clear who to believe or trust
        • we’re also risking our collective reputation, if people/projects not closely associated with “the collective” cannot be easily discerned as such
        • we should start asking the hard questions what all of this is about, where the boundaries are, what we want long-term, etc
        • @tomberek This team should establish goals, intentions, desires, plans, and communicate them.
      • @roberth appears
        • @roberth: NixOps 2 still maintained in terms of bug fixes, but not active development
          • given NixOps 4 is not viable for production yet, it’s perfectly reasonable to be outside of the org
          • NixOps 2 can be considered to belong to the community
            • @fricklerhandwerk: what would that even mean?
            • @roberth: just like Nix or Nixpkgs, a shared project with multiple maintainers
        • @raitobezarius: there are not many tools for that use case, and because NixOps existed, it seems to have stalled/discouraged development of alternatives
          • it seems like it had more of a development mode like for nix-community
        • @raitobezarius’s questions:
          • Is development open?
            • @roberth: Hacking locally, but planning to open in a couple weeks
            • @thufschmitt: As long as it’s not official this is no concern
          • Can anybody join?
            • Will be answered once public
      • @infinisil: coming back to the name - reusing the same name gives it an official feel; maybe using a new name could help distinguish that?

Meta

@fricklerhandwerk: the project needs someone/somegroup to declare that they will make specific decisions and to then make them. This has been a long-standing problem we’ve been collectively weaseling around so far - many of the discussions today relate to this.

Graduating new projects to make them official

For next time

4 Likes