foster/forgejo
1
0
Fork 0
mirror of https://codeberg.org/forgejo/forgejo.git synced 2024-11-25 08:59:31 -05:00
Code Issues Wiki Activity

Add a pragraph to the k8s PR guide to contributors guide

Browse source
This commit is contained in:
Thomas Boerger 2016-11-28 16:57:42 +01:00
parent b3abc2775f
commit 8def53ffcc
No known key found for this signature in database
GPG key ID: 5A388F55283960B6
1 changed files with 6 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
CONTRIBUTING.md
View file

@ -30,6 +30,12 @@ Before sending code out for review, run all the tests for the whole tree to make
Changes to Gitea must be reviewed before they are accepted, no matter who makes the change even if an owner or a maintainer. We use GitHub's pull request workflow to do that and we also use [LGTM](http://lgtm.co) to ensure every PR is reviewed by at least 2 maintainers. Changes to Gitea must be reviewed before they are accepted, no matter who makes the change even if an owner or a maintainer. We use GitHub's pull request workflow to do that and we also use [LGTM](http://lgtm.co) to ensure every PR is reviewed by at least 2 maintainers.
Please try to make your pull request easy to review for us. Please read the "[How to get faster PR reviews](https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md)" guide, it got useful tips for any project you may want to contribute. See some of the points:
* Make small pull requests. The smaller, the faster to review and the more likely it will be merged soon.
* Don't make changes unrelated to your PR. Maybe there are typos on some comments, maybe refactoring would welcome on a function... but if that is not related to you PR, please make *another* PR for that.
* Split big pull requests in multiple. An incremental change will be faster to review than a huge PR.
## Sign your work ## Sign your work
The sign-off is a simple line at the end of the explanation for the patch. Your signature certifies that you wrote the patch or otherwise have the right to pass it on as an open-source patch. The rules are pretty simple: If you can certify [DCO](DCO), then you just add a line to every git commit message: The sign-off is a simple line at the end of the explanation for the patch. Your signature certifies that you wrote the patch or otherwise have the right to pass it on as an open-source patch. The rules are pretty simple: If you can certify [DCO](DCO), then you just add a line to every git commit message: