Attendees: @thufschmitt @roberth @fricklerhandwerk @tomberek @edolstra (later @Ericson2314 @infinisil)
Agenda
- named profile index (5 min)
- improving internal and external communication (10 min)
- code ownership (10 min)
- goal: brainstorming
-
fetchTreeproject-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
https://github.com/NixOS/nix/pull/8678
-
@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)?
-
@tomberek: lots of uncertainty about how and when something gets reviews
- have addressed this in part with labels and review state
- add a note to the process documentation what the different states mean so progress is more evident
- @roberth: could link that from the pull request template
-
@thufschmitt: to help us be stricter with the Review/Assigned column, do regular reviews
- @roberth: should finish reviews before starting new implementation work
-
@fricklerhandwerk: consequence should be dropping things from the board and announce they’re deprioritised
- even if it’s sad; we can’t create more time
- decisions:
- @tomberek will amend the PR template
- @thufschmitt: add process note to review the review column monthly
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
- still takes on reviews on things related to work done previously
-
@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
- up to recently partially encoded in
-
@thufschmitt does not own a clearly identifiable part of the code base
- 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
-
@roberth opened a board to track progress on
fetchTree: Nix team fetchTree board · GitHub- don’t have a tracking issue yet, so tried a project board instead
-
@fricklerhandwerk: could manage everything in one board using views
- should keep the number of “channels” we work on very low
- decision:
- @fricklerhandwerk and @roberth will work on it at the end of the meeting
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
Triage
Permission denied error when building symlink derivation · Issue #9579 · NixOS/nix · GitHub
- assigned to @thufschmitt
StorePath: reject names starting with '.' by edef1c · Pull Request #9095 · NixOS/nix · GitHub
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
-
@fricklerhandwerk: we already know quite well who’s doing what
-
@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)
- 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)
- Implements the team process as a living agenda for “update meetings”
- Milestones
- Tracks progress of items per “milestone” (such as stabilising
fetchTreeor the store CLI) for “work” meetings:- Idea approved: work pool
- Unfortunately cannot displace the
idea approvedlabel, as the state cannot be used in search
- Unfortunately cannot displace the
- Blocked: needs action to make progress
- Work in progress: someone is working on it
- Idea approved: work pool
- Tracks progress of items per “milestone” (such as stabilising
- Maintainers
- There are now three main views, all sorted by Priority (which we should use more systematically)