felixfoertsch/tildes
1
0
Fork 0
mirror of https://gitlab.com/tildes/tildes.git synced 2026-04-16 06:18:34 +02:00
Code Issues Packages Projects Releases Wiki Activity

Fix link re-directing to development page

Browse Source
This commit is contained in:
Carlos E. Garcia
2021-01-24 22:49:50 +00:00
committed by Deimos
parent 071f1e04f6
commit d00a59ffa4
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
CONTRIBUTING.md
View File

@@ -48,7 +48,7 @@ Once you've selected an issue to work on, please leave a comment saying so. This
After you've finished making your changes, there are a few things to check before proposing your changes as a merge request. After you've finished making your changes, there are a few things to check before proposing your changes as a merge request.
First, ensure that all the checks (tests, mypy and code-style) pass successfully. Merge requests that fail any of the checks will not be accepted. For more information, see this section of the development docs: https://docs.tildes.net/instructions/development#running-checks-on-your-code First, ensure that all the checks (tests, mypy and code-style) pass successfully. Merge requests that fail any of the checks will not be accepted. For more information, see this section of the development docs: https://docs.tildes.net/development/general-development#running-checks-on-your-code
Squash your changes into logical commits. For many changes there should only be a single commit, but some can be broken into multiple logical sections. The commit messages should follow [the formatting described in this article](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), with the summary line written in the imperative form. The summary line should make sense if you were to use it in a sentence like "If applied, this commit will \_\_\_\_\_\_\_\_". For example, "Add a new X", "Fix a bug with Y", and so on. Squash your changes into logical commits. For many changes there should only be a single commit, but some can be broken into multiple logical sections. The commit messages should follow [the formatting described in this article](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), with the summary line written in the imperative form. The summary line should make sense if you were to use it in a sentence like "If applied, this commit will \_\_\_\_\_\_\_\_". For example, "Add a new X", "Fix a bug with Y", and so on.