2023-12-18 Nix team meeting minutes #113

Attendees: @thufschmitt @roberth @fricklerhandwerk @tomberek @edolstra (later @Ericson2314 @infinisil)


  • named profile index (5 min)
  • improving internal and external communication (10 min)
  • code ownership (10 min)
    • goal: brainstorming
  • fetchTree project-specific board (10 min)
  • call for reviewers (5 min)
  • triaging open issues (5 min)
  • workflow recordings (5 min)
  • how to reduce in-flight work (15 min)
    • collect constraints and possibilities
    • collect ideas to try out in the next months
  • make progress on store CLI stabilisation


  • @edolstra would like to rework the manifest format to have stable names
    • question is whether this change would make that harder
  • @edolstra will review this week

Improving internal and external communication

There are several new contributors to Nix, and there recently was some frustration due to ineffective communication. How can we improve that? How can we help people contribute more effectively (in a way that is also manageable for maintainers)?

Code ownership

  • How do we make sure that nothing falls through the cracks and gets left behind?
  • A proposal many months ago to funnel all PRs through the team was rejected as too inefficient
    • Today we do lean towards merging autonomously, but have implicit rules
  • Effective responsibilities do not map to concrete pieces of code
  • @fricklerhandwerk: let’s start with writing down how we currently do it
    • @thufschmitt does not own a clearly identifiable part of the code base
      • still takes on reviews on things related to work done previously
        • CA derivations, CLI and flake-layer things
    • @roberth
      • evaluator: particularly coroutines, bindings, wrote many issues
      • semi-knowledgable about build loop, having reviewed Dynamic Derivations
      • “rename nix shell” and related design issues (he spends a lot of time in the issue tracker)
      • Nix language interfaces (flake schema, package attrset definition)
    • @tomberek
      • Dynamic Derivations
      • CLI stabilisation
      • shebang/shell/develop.
      • shepherding external contributions
    • @ericson2314
      • Store interface
      • Build loop
    • @edolstra
      • fetchers
      • store-layer things
      • flakes and new CLI related things
      • bugs
    • @fricklerhandwerk: everything documentation
      • up to recently partially encoded in CODEOWNERS
  • Currently we have final say encoded as a formal assignment, but we need to reduce the group workload up-front
    • The implicit “merge quickly” process mostly works, but it’s ill-defined
  • Decision:
    • Next time: provide minimal coverage in the form of “X does not have to ask anyone to merge PRs on topic Y”

fetchTree project board

Call for reviewers

  • @roberth proposes to make a call for reviewers to reduce the waiting time
    • reviewers don’t have to be on the team
    • goal would be to increase confidence early on and make approving easier
    • could also be an onboarding path for joining the team eventually
  • @edolstra: who reviews the reviewers?
    • @roberth: maintainers have the last say
  • @fricklerhandwerk: in the past we asked people we already trust directly, it’s essentially asking for time donations
  • decision:
    • continue asking individuals for reviews as we see fit


Permission denied error when building symlink derivation · Issue #9579 · NixOS/nix · GitHub

StorePath: reject names starting with '.' by edef1c · Pull Request #9095 · NixOS/nix · GitHub

  • assigned to @robert, will discuss with @edef how to find a resolution

Rename `LocalStore` to `SQLiteStore` · Issue #9552 · NixOS/nix · GitHub

  • @roberth: we should not need different classes for different representations, those should rather be backends
    • composition over inheritance
  • decision: take this offline into a review

Workflow recordings

  • @fricklerhandwerk proposes recording small snippets to show day-to-day workflows
    • a major problem for contributors is that a lot of implicit contextual information is required to do seemingly simple things
    • that raises the barrier to effective contributions enormously
    • @thufschmitt: did a video on adding a primop which was received well, but it was long and one-off
  • @edolstra: videos are not maintainable and get out of date quickly
    • @fricklerhandwerk: right, and here the trade-off is ease of production and consumption for ephemeral but commonplace knowledge

How to reduce in-flight work

  • @thufschmitt: reducing our own amount of WIP will also reduce that of contributors
  • @infinisil: assign priorities
  • @thufschmitt: we’re not garbage-collecting items on the project board, and forget about things
    • triaging works because we have fixed time allocated to this
  • @tomberek: garbage collection is often more expensive than the initial work
    • have to figure out whether an issue is actually valid, or whether a fix is still applicable
    • @thufschmitt: historically the stalebot took the role of garbage collection, but that was not received well
  • @ericson2314: this all calls back into the team budget idea
    • @fricklerhandwerk: what can we do to be more diligent about the liabilities we take on?
  • @roberth: individuals can do regular sweeps and update state
  • @fricklerhandwerk: maybe encode more formal meeting protocol?
    • allocating fixed time to critical aspects seems to have helped in the past
  • @infinisil: how about using meetings for status updates?
    • @fricklerhandwerk: we already know quite well who’s doing what
      • the real benefit of meetings is quickly collecting feedback and ideas
  • @tomberek: could focus on highlighting successes, to compensate for discouragements
    • @thufschmitt: sounds good, maybe could coordinate with the marketing team
  • @ericson2314: focus on more on async decisions that are easy to revert, with obvious way how to escalate
    • @tomberek: have had the experience of being uncertain about making decisions alone
    • @fricklerhandwerk: there’s a risk of increasing FOMO though if things move too quickly
      • have to keep an eye on curse of availability
      • should optimise not just for speed but also predictability
      • @thufschmitt: should be covered by making clear that reverts are a part of the process
      • @ericson2314: yes, the more autonomous decisions the more we will deal with mistakes, so the revert policy gets more important
  • decision:
    • we want to increase autonomous async decision making
    • continue experimenting and looking out for ways to optimise the process
    • improve communication

Post-meeting updates

  • @fricklerhandwerk and @roberth reworked the project board:
    • There are now three main views, all sorted by Priority (which we should use more systematically)
      1. Maintainers
        • Implements the team process as a living agenda for “update meetings”
          • Triage (no status)
          • Blocked: needs action to make progress
          • To discuss: needs a decision
          • Implementation: team member(s) making something
          • Review: team member(s) guiding contributions
        • We should eventually dissolve the “Postponed” and “Team review” columns in the next meetings
          • Postponed should be either blocked, prioritised, or not on the board
          • Team review should be just review with multiple assignees
        • Have to update the team handbook and define a concrete amount of time allocated to go through each column with the goal to reduce the number of items in it
        • The process should also ensure that once triaged, an item has all fields set xor is off the board (and ideally closed in that case)
      2. Milestones
        • Tracks progress of items per “milestone” (such as stabilising fetchTree or the store CLI) for “work” meetings:
          • Idea approved: work pool
            • Unfortunately cannot displace the idea approved label, as the state cannot be used in search
          • Blocked: needs action to make progress
          • Work in progress: someone is working on it