Commit 2ce1e0b2 authored by Silvan Mosberger's avatar Silvan Mosberger
Browse files

CONTRIBUTING.md: Typos and formatting 



- Fix sentence about meeting contributing standards
- pkgs -> packages
- Use emoji's because GitHub renders the :*: things weird sometimes
- Move a dot

Co-authored-by: default avatarRémi NICOLE <minijackson@users.noreply.github.com>
parent 237799aa

CONTRIBUTING.md

+9 −9
Original line number Diff line number Diff line
@@ -189,7 +189,7 @@ It’s important to test any executables generated by a build when you change or 


#### Meets Nixpkgs contribution standards



The last checkbox is fits the guidelines in this `CONTRIBUTING.md` file. The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.

The last checkbox is about whether it fits the guidelines in this `CONTRIBUTING.md` file. This document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.



### Rebasing between branches (i.e. from master to staging)

[rebase]: #rebasing-between-branches-ie-from-master-to-staging
@@ -288,7 +288,7 @@ To manually create a backport pull request, follow [the standard pull request pr 
  > **Warning**

  > Do not use the `nixos-YY.MM` branch, that is a branch pointing to the tested release channel commit



- Instead of making manually making and committing the changes, use [`git cherry-pick -x`](https://git-scm.com/docs/git-cherry-pick) for each commit from the pull request you'd like to backport.

- Instead of manually making and committing the changes, use [`git cherry-pick -x`](https://git-scm.com/docs/git-cherry-pick) for each commit from the pull request you'd like to backport.

  Either `git cherry-pick -x <commit>` when the reason for the backport is obvious (such as minor versions, fixes, etc.), otherwise use `git cherry-pick -xe <commit>` to add a reason for the backport to the commit message.

  Here is [an example](https://github.com/nixos/nixpkgs/commit/5688c39af5a6c5f3d646343443683da880eaefb8) of this.
@@ -336,8 +336,8 @@ It is possible for community members that have enough knowledge and experience o 


In case the PR is stuck waiting for the original author to apply a trivial

change (a typo, capitalisation change, etc.) and the author allowed the members

to modify the PR, consider applying it yourself. (or commit the existing review

suggestion) You should pay extra attention to make sure the addition doesn't go

to modify the PR, consider applying it yourself (or commit the existing review

suggestion). You should pay extra attention to make sure the addition doesn't go

against the idea of the original PR and would not be opposed by the author.



<!--
@@ -440,10 +440,10 @@ Here's an overview of the different branches: 


| branch | `master` | `staging` | `staging-next` |

| --- | --- | --- | --- |

| Used for development | :heavy_check_mark: | :heavy_check_mark: | :x: |

| Built by Hydra | :heavy_check_mark: | :x: | :heavy_check_mark: |

| [Mass rebuilds][mass-rebuild] | :x: | :heavy_check_mark: | :warning: Only to fix Hydra builds |

| Critical security fixes | :heavy_check_mark: for non-mass-rebuilds | :x: | :heavy_check_mark: for mass-rebuilds |

| Used for development | ✔️ | ✔️ | ❌ |

| Built by Hydra | ✔️ | ❌ | ✔️ |

| [Mass rebuilds][mass-rebuild] | ❌ | ✔️ | ⚠️  Only to fix Hydra builds |

| Critical security fixes | ✔️ for non-mass-rebuilds | ❌ | ✔️ for mass-rebuilds |

| Automatically merged into | `staging-next` | - | `staging` |

| Manually merged into | - | `staging-next` | `master` |
@@ -550,7 +550,7 @@ Pull requests should not be squash merged in order to keep complete commit messa 


### Release notes



If you removed pkgs or made some major NixOS changes, write about it in the release notes for the next stable release in [`nixos/doc/manual/release-notes`](./nixos/doc/manual/release-notes).

If you removed packages or made some major NixOS changes, write about it in the release notes for the next stable release in [`nixos/doc/manual/release-notes`](./nixos/doc/manual/release-notes).



### File naming and organisation