Nix Project Board Workflow: Triage, Discussion, Review, and Assignment

- [most popular pull requests](https://github.com/NixOS/nix/pulls?q=is%3Apr+is%3Aopen+sort%3Areactions-%2B1-desc) - [oldest issues](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc) - [most popular issues](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) Team members can also add pull requests or issues they would like the whole team to consider. To ensure process quality and reliability, all non-trivial pull requests must be triaged before merging. If there is disagreement on the general idea behind an issue or pull request, it is moved to [To discuss](#to-discuss). Otherwise, the issue or pull request in questions get the label [`idea approved`](https://github.com/NixOS/nix/labels/idea%20approved). For issues this means that an implementation is welcome and will be prioritised for review. For pull requests this means that: - Unfinished work is encouraged to be continued. - A reviewer is assigned to take responsibility for getting the pull request merged. The item is moved to the [Assigned](#assigned) column. - If needed, the team can decide to do a collarorative review. Then the item is moved to the [In review](#in-review) column, and review session is scheduled. What constitutes a trivial pull request is up to maintainers' judgement. ### To discuss Pull requests and issues that are deemed important and controversial are discussed by the team during discussion meetings. This may be where the merit of the change itself or the implementation strategy is contested by a team member. Whenever the discussion opens up questions about the process or this team's goals, this may indicate that the change is too large in scope. In that case it is taken off the board to be reconsidered by the author or broken down into smaller pieces that are less far-reaching and can be reviewed independently. As a general guideline, the order of items to discuss is determined as follows: - Prioritise pull requests over issues Contributors who took the time to implement concrete change proposals should not wait indefinitely. - Prioritise fixing bugs and testing over documentation, improvements or new features The team values stability and accessibility higher than raw functionality. - Interleave issues and PRs This way issues without attempts at a solution get a chance to get addressed. ### 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. If significant changes are requested or reviewers cannot come to a conclusion in reasonable time, the pull request is [marked as draft](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request#converting-a-pull-request-to-a-draft). ### Assigned 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-discuss) or [In review](#in-review) to involve the team again. ### Flowchart The process is illustrated in the following diagram: ```mermaid flowchart TD discuss[To discuss] review[To review] New --> |Disagreement on idea| discuss New & discuss --> |Consensus on idea| review review --> |Consensus on implementation| Assigned Assigned --> |Implementation issues arise| review Assigned --> |Remaining issues fixed| Merged ```

This section describes the workflow for pull requests and issues on the Nix project board, detailing the progression from triage ('No Status') to discussion ('To discuss'), collaborative review ('In review'), individual assignment ('Assigned'), and ultimately, merging. It outlines the criteria for moving items between columns, the prioritization of pull requests over issues, bug fixes over new features, and collaborative review sessions for spreading knowledge and establishing common values. The process includes a flowchart visualizing the movement of items based on team consensus, implementation issues, and the resolution of remaining issues.