2022-09-23 Nix team meeting minutes #1


  • Decide the rough scope of the team
  • Decide how we want to organize the team
  • Plan for an official announcement (draft here, but it’s clearly worth improving)

Attendees: @regnat @roberth @fricklerhandwerk

  • @fricklerhandwerk what do we do today if @edolstra does not show up?
    (note: it later turned out @edolstra was on vacation and we simply didn’t know)
    • @regnat we can still discuss a few things
      • he read the proposal and agreed on principle about having the team
      • foundation board also approved
    • does @roberth have commit access?
      • @roberth no, but interested. maybe I’m not the right person.
      • @regnat people who are morally entitled to commit are a different set to those who technically can
        • @fricklerhandwerk should be one of the first points on the agenda to align these sets
      • we need an actual mandate to eventually merge things autonomously, otherwise none of this makes sense
        • @regnat this is what the proposal is about, @edolstra would have to sign it off so we can get to work
          • would have been better for him to be here of course
  • @regnat the legitimacy of the team depends on it being official, otherwise it will have no authority to pull through with decisions
  • (@tomberek joins)
  • @regnat did you want to join the team @roberth?
    • @roberth cannot commit too much time to it though, but very interested in making it successful

Announcement review

  • Role of the team
    • @fricklerhandwerk: Just “be responsible” is too vague. The role of the team is to enable things to be done, not to do everything
    • @tom “responsible” means both the accountability and the empowerement
      • We should have both (see also What are the values that you see being expressed in the NixOS project? - #8 by tomberek)
      • don’t want to reinvent the wheel. is there an existing framework we could follow?
        • Linux kernel organization

        • Supported: Someone is actually paid to look after this.
          Maintained: Someone actually looks after it.
          Odd Fixes: It has a maintainer but they don’t have time to do much other than throw the odd patch in. See below…
          Orphan: No current maintainer [but maybe you could take the role as you write your new code].
          Obsolete: Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that.

        • 3. Debian Developer's Duties — developers-reference 12.7 documentation.

        • something else we want to model this on?

        • @regnat this is relevant. @ron and me were pushing the foundation board to organize the teams according to some established standards

          • this team could be a testbed for that
          • not sure Linux is the right thing, interviews with Linux foundation have shown they may be too different for our needs
          • Haskell, Rust, Plone were mentioned
          • for all of them there is a broad framework outlining what teams can and should do, otherwise they are self-organized
      • @regnat another thing that came up in the board discussions is ownership
        • owners have the power over something do things with it, and at the same time are accountable
      • @fricklerhandwerk possible homework: go through Debian developer duties page
        • @regnat this kind of document we should create once the team is established
1 Like