| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
It wasn't entirely clear if the list was acceptable or not from the
wording.
|
| |
|
|
| |
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
|
| | |
|
| |
|
|
|
|
| |
Particularities about style should be enforced at the tooling level (linters,
code beautifiers etc.). Otherwise, it adds more weight on the PR reviewing,
distracting both authors and reviewers from the substance of the changes.
|
| |
|
|
| |
This needs a rewrite at some point..
|
| |
|
|
|
|
|
|
|
| |
- Fix sentence about meeting contributing standards
- pkgs -> packages
- Use emoji's because GitHub renders the :*: things weird sometimes
- Move a dot
Co-authored-by: Rémi NICOLE <minijackson@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
| |
- Contributing without a GitHub account
- Mention OfBorg
- nix.useSandbox -> nix.settings.sandbox
- nixpkgs-review is good for not just version updates
Co-authored-by: Rémi NICOLE <minijackson@users.noreply.github.com>
|
| |
|
|
|
| |
Yeah I'm totally getting lazy with the commits, but it's really hard and
takes a long time..
|
| | |
|
| | |
|
| |
|
|
|
| |
Right into the "How to propose a change" section, because that's where
it's relevant
|
| |
|
|
|
| |
How to force push to PR's is already explained in the
"How to propose a change" section at the beginning
|
| | |
|
| | |
|
| |
|
|
| |
Will be cleaned up in the next commit
|
| | |
|
| |
|
|
| |
Can't be rendered in GitHub markdown, replacing it with a Git branch diagram using mermaid
|
| | |
|
| |
|
|
|
| |
Moving and collecting bits into the appropriate places, also writing
some new sentences
|
| |
|
|
| |
Removing paragraphs from the other sections that aren't necessary anymore
|
| |
|
|
|
| |
It's not conventions about how to do coding, it's about what the code
should look like
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The -new version was assembled in the previous commits
|
| |
|
|
|
| |
So that the CONTRIBUTING-new.md can take its place and Git detect the
rename
|
| |
|
|
|
| |
This isn't relevant to contributors specifically, it applies to all
users
|
| |
|
|
|
| |
No content was changed, new titles are wrapped with () to signal that
they will need to be decided on in a future commit.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
As a beginning contributor, it is far from obvious where to find tests,
how to run individual tests locally for quick development, and which
tests do what. The new "Testing changes" section aims to help with all
of these.
Co-authored-by: Emily <git@emilylange.de>
|
| |\
| |
| | |
CONTRIBUTING.md: remove historical trivia
|
| | |
| |
| |
| |
| |
| |
| | |
The transition to markdown is done now and the historical trivia is not
helpful for first time contributers who are the primary audience for
this document. Telling the user to edit a file by editing a file is
superfluous.
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
with manual chapters no longer needing pandoc for their conversion to
xml we can get rid of this source of confusion, and its huge cache of
xml files.
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Co-authored-by: Naïm Favier <n@monade.li>
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change improves the recommendation for good commit messages to
include release notes on package bumps.
Including the release notes increases the likelihood that they will be
taken into consideration during review. Having them included in the
review is important to be able to judge whether changes made during a
version bump are sensible, sufficient or complete.
The burden of retrieving the release notes for arbitrary package bumps
should not rest on the relatively small group of reviewers.
Signed-off-by: Martin Weinelt <hexa@darmstadt.ccc.de>
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Makes the instructions easier to remember (and type) using the
`git rebase --onto A...B` syntax to find the merge base between A and B
(which has been in git for at least 10 years).
We also assume that the merge base between staging and master is also
the merge base between staging and the current branch (since it is based
on master), and giving master as the <upstream> branch makes git
consider the commits in the current branch that are not in master, so
there's no need to compute the merge base between master and the current
branch.
In the same spirit of discouraging copy-and-paste, use a placeholder
name for the current branch instead of `$(git branch --show-current)`.
|
| | | |
|
| |/ |
|
| | |
|