commit 2c4cd11a9e45847f9194a5dbc6f5400634fb68aa · pyrox.dev/nixpkgs

+18 -3
CONTRIBUTING.md
···

       91
       91
        
       

     

       92
       92
        
       6. [Create a pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request#creating-the-pull-request) from the new branch in your Nixpkgs fork to the upstream Nixpkgs repository.

     

       93
       93
        
          Use the branch from step 1 as the PR's base branch.

     

       94
       94
       -
          Go through the [pull request template](#pull-request-template).

     

       94
       94
       +
          Go through the [pull request template][pr-template].

     

       95
       95
        
       

     

       96
       96
        
       7. Respond to review comments and potentially to CI failures and merge conflicts by updating the PR.

     

       97
       97
        
          Always keep it in a mergeable state.

     
···

       526
       526
        
       Simple package version updates need to include the attribute name, old and new versions, as well as a reference to the release notes or changelog.

     

       527
       527
        
       Package upgrades with more extensive changes require more verbose commit messages.

     

       528
       528
        
       

     

       529
       529
       -
       Pull requests should not be squash-merged, as this discards information including detail from commit messages, GPG signatures, and authorship.

     

       530
       530
       -
       Many pull requests don't make sense as a single commit anyway.

     

       529
       529
       +
       ## Review and Merge conventions

     

       530
       530
       +
       

     

       531
       531
       +
       Comments on Pull Requests are considered non-blocking by default.

     

       532
       532
       +
       Every blocking comment must be explicitly marked as such by using GitHub's "Request Changes" review type.

     

       533
       533
       +
       A reviewer who submits a blocking review should be available for discussion and re-review.

     

       534
       534
       +
       An abandoned review may be dismissed after reasonable time was given at the discretion of the merger.

     

       535
       535
       +
       

     

       536
       536
       +
       All suggestions for change, blocking or not, should be acknowledged before merge.

     

       537
       537
       +
       This can happen implicitly by applying the suggestion, or explicitly by rejecting it.

     

       538
       538
       +
       

     

       539
       539
       +
       To make changes on commit structure and commit messages or apply simple suggestions, committers are encouraged to [checkout the PR](https://cli.github.com/manual/gh_pr_checkout) and push directly to the contributor's branch before merging.

     

       540
       540
       +
       Committers will carefully weigh the cost of another review cycle against the feelings of the contributor when pushing to their branch.

     

       541
       541
       +
       They should also transparently communicate which changes they made.

     

       542
       542
       +
       If a contributor does not want committers to push to their branch, they must uncheck the "Allow edits and access to secrets by maintainers" box explicitly.

     

       543
       543
       +
       

     

       544
       544
       +
       > [!WARNING]

     

       545
       545
       +
       > Committers: Branches created via `gh pr checkout` can't be pushed with `--force-with-lease`, so do a sanity check before pushing.

     

       531
       546
        
       

     

       532
       547
        
       ## Code conventions

     

       533
       548
        
       [code-conventions]: #code-conventions