Finalizing and Submitting Pull Requests, Contributing to the Manual, and Getting Help

* Link to relevant changes in other projects, so that others can understand the full context of the change in the future when you or someone else will change or troubleshoot the code. This is especially important when your change is based on work done in other repositories. Example: ``` This is based on the work of @user in <url>. This solution took inspiration from <url>. Co-authored-by: User Name <user@example.com> ``` When cherry-picking from a different repository, use the `-x` flag, and then amend the commits to turn the hashes into URLs. * Make sure to have [a clean history of commits on your branch by using rebase](https://www.digitalocean.com/community/tutorials/how-to-rebase-and-update-a-pull-request). * [Mark the pull request 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) if you're not done with the changes. 6. Do not expect your pull request to be reviewed immediately. Nix maintainers follow a [structured process for reviews and design decisions](https://github.com/NixOS/nix/tree/master/maintainers#project-board-protocol), which may or may not prioritise your work. Following this checklist will make the process smoother for everyone: - [ ] Fixes an [idea approved](https://github.com/NixOS/nix/labels/idea%20approved) issue - [ ] Tests, as appropriate: - Functional tests – [`tests/functional/**.sh`](./tests/functional) - Unit tests – [`src/*/tests`](./src/) - Integration tests – [`tests/nixos/*`](./tests/nixos) - [ ] User documentation in the [manual](./doc/manual/source) - [ ] API documentation in header files - [ ] Code and comments are self-explanatory - [ ] Commit message explains **why** the change was made - [ ] New feature or incompatible change: [add a release note](https://nix.dev/manual/nix/development/development/contributing.html#add-a-release-note) 7. If you need additional feedback or help to getting pull request into shape, ask other contributors using [@mentions](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#mentioning-people-and-teams). ## Making changes to the Nix manual The Nix reference manual is hosted on https://nixos.org/manual/nix. The underlying source files are located in [`doc/manual/source`](./doc/manual/source). For small changes you can [use GitHub to edit these files](https://docs.github.com/en/repositories/working-with-files/managing-files/editing-files) For larger changes see the [Nix reference manual](https://nix.dev/manual/nix/development/development/contributing.html). ## Getting help Whenever you're stuck or do not know how to proceed, you can always ask for help. We invite you to use our [Matrix room](https://matrix.to/#/#nix-dev:nixos.org) to ask questions.

This section covers the final steps for submitting a Nix pull request, including linking to related changes, maintaining a clean commit history, and marking the PR as a draft if incomplete. It advises contributors not to expect immediate reviews due to the maintainers' structured process. It provides a checklist to ensure a smooth review process, including testing, documentation, clear code and comments, explanatory commit messages, and release notes for new features. It also suggests using @mentions for feedback and help. Additionally, it explains how to make changes to the Nix manual, either through GitHub for small edits or by following the reference manual for larger changes. Finally, it encourages contributors to seek help in the Matrix room when needed.