blankie
/
wlroots
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Update CONTRIBUTING.md

This commit is contained in:
Drew DeVault 2017-12-27 10:39:53 -05:00
parent a79dc7df51
commit 4267ee2bf3
1 changed files with 35 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
CONTRIBUTING.md
View File

@ -5,6 +5,9 @@ successful with your contribution if you visit
[#sway-devel](https://webchat.freenode.net/?channels=sway-devel) on [#sway-devel](https://webchat.freenode.net/?channels=sway-devel) on
irc.freenode.net upfront and discuss your plans. irc.freenode.net upfront and discuss your plans.
Note: rules are made to be broken. Adjust or ignore any/all of these as you see
fit, but be prepared to justify it to your peers.
## Pull Requests ## Pull Requests
If you already have your own pull request habits, feel free to use them. If you If you already have your own pull request habits, feel free to use them. If you
@ -24,6 +27,15 @@ branch. Instead, when you start working on a feature, do this:
4. `git push -u origin add-so-and-so-feature` 4. `git push -u origin add-so-and-so-feature`
5. Make a pull request from your feature branch 5. Make a pull request from your feature branch
When you submit your pull request, your commit log should do most of the talking
when it comes to describing your changes and their motivation. In addition to
this, your pull request's comments will ideally include a test plan that the
reviewers can use to (1) demonstrate the problem on master, if applicable and
(2) verify that the problem no longer exists with your changes applied (or that
your new features work correctly). Document all of the edge cases you're aware
of so we can adequately test them - then verify the test plan yourself before
submitting.
## Commit Messages ## Commit Messages
Please strive to write good commit messages. Here's some guidelines to follow: Please strive to write good commit messages. Here's some guidelines to follow:
@ -50,7 +62,27 @@ message as well.
See [here](https://chris.beams.io/posts/git-commit/) for more details. See [here](https://chris.beams.io/posts/git-commit/) for more details.
## Coding Style ## Code Review
When your changes are submitted for review, one or more core committers will
look over them. Smaller changes might be merged with little fanfare, but larger
changes will typically see review from several people. Be prepared to receive
some feedback - you may be asked to make changes to your work. Our code review
process is:
1. **Triage** the pull request. Do the commit messages make sense? Is a test
plan necessary and/or present? Add anyone as reviewers that you think should
be there (using the relevant GitHub feature, if you have the permissions, or
with an @mention if necessary).
2. **Review** the code. Look for code style violations, naming convention
violations, buffer overflows, memory leaks, logic errors, non-portable code
(including GNU-isms), etc. For significant changes to the public API, loop in
a couple more people for discussion.
3. **Execute** the test plan, if present.
4. **Merge** the pull request when all reviewers approve.
5. **File** follow-up tickets if appropriate.
## Style Reference
wlroots is written in C with a style similar to the [kernel wlroots is written in C with a style similar to the [kernel
style](https://www.kernel.org/doc/Documentation/process/coding-style.rst), but style](https://www.kernel.org/doc/Documentation/process/coding-style.rst), but
@ -102,7 +134,8 @@ Try to break the line in the place which you think is the most appropriate.
### Line Length ### Line Length
Try to keep your lines under 80 columns, but you can go up to 100 if it Try to keep your lines under 80 columns, but you can go up to 100 if it
improves readability. improves readability. Don't break lines indiscriminately, try to find nice
breaking points so your code is easy to read.
### Names ### Names