History

Valentin Gagarin a4af966d5d add maintainers' handbook write down the process we have been developing and following so far. Co-Authored-By: Théophane Hufschmitt <theophane.hufschmitt@tweag.io> Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems>		2022-11-21 14:35:01 +01:00
..
README.md	add maintainers' handbook	2022-11-21 14:35:01 +01:00
upload-release.pl	Integrate push-docker.sh into the release script	2022-02-18 13:58:01 +01:00

README.md

Nix maintainers team

Motivation

The goal of the team to help other people to contribute to Nix.

Members

Eelco Dolstra (@edolstra) – Team lead
Théophane Hufschmitt (@thufschmitt)
Valentin Gagarin (@fricklerhandwerk)
Thomas Bereknyei (@tomberek)
Robert Hensing (@roberth)

Meeting protocol

The team meets twice a week:

Discussion meeting: Fridays 12:00-13:00 UTC
1. Triage issues and pull requests from the No Status column (30 min)
2. Discuss issues and pull requests from the To discuss column (30 min)
Work meeting: Mondays 12:00-14:00 UTC
1. Code review on pull requests from In review.
2. Other chores and tasks.

Meeting notes are collected on a collaborative scratchpad, and published on Discourse under the Nix category.

Project board protocol

The team uses a GitHub project board for tracking its work.

Issues on the board progress through the following states:

No Status

Team members can add pull requests or issues to discuss or review together.

During the discussion meeting, the team triages new items. If there is disagreement on the general idea behind the issue or pull request, items are moved to To discuss, otherwise to In review.
To discuss

Pull requests and issues that are important and controverisal enough to warrant a discussion by the whole team.

This may be where the merit of the change itself or the implementation strategy is contested by a team member.
In review

Pull requests in this column are reviewed together during work meetings. This is both for spreading implementation knowledge and for establishing common values in code reviews.

When the overall direction is agreed upon, even when further changes are required, the pull request is assigned to one team member.
Assigned for merging

One team member is assigned to each of these pull requests. They will communicate with the authors, and make the final approval once all remaining issues are addressed.

If more substantive issues arise, the assignee can move the pull request back to To discuss to involve the team again.

The process is illustrated in the following diagram: