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

contributing: use references for links 

This avoids cluttering the prose with URLs.
This commit is contained in:
Simon Ser 2021-08-30 15:11:45 +02:00 committed by Simon Zeni
parent 2ddd8e8036
commit ea800b7418
1 changed files with 16 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
CONTRIBUTING.md
View File

@ -1,9 +1,8 @@
# Contributing to wlroots # Contributing to wlroots
Contributing just involves sending a pull request. You will probably be more Contributing just involves sending a pull request. You will probably be more
successful with your contribution if you visit successful with your contribution if you visit [#sway-devel on Libera Chat]
[#sway-devel on Libera Chat](https://web.libera.chat/?channels=#sway-devel) upfront and upfront and discuss your plans.
discuss your plans.
Note: rules are made to be broken. Adjust or ignore any/all of these as you see 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. fit, but be prepared to justify it to your peers.
@ -82,20 +81,18 @@ or similar.
The subsequent lines should be separated from the subject line by a single The subsequent lines should be separated from the subject line by a single
blank line, and include optional details. In this you can give justification blank line, and include optional details. In this you can give justification
for the change, [reference Github for the change, [reference Github issues], or explain some of the subtler
issues](https://help.github.com/articles/closing-issues-via-commit-messages/), details of your patch. This is important because when someone finds a line of
or explain some of the subtler details of your patch. This is important because code they don't understand later, they can use the `git blame` command to find
when someone finds a line of code they don't understand later, they can use the out what the author was thinking when they wrote it. It's also easier to review
`git blame` command to find out what the author was thinking when they wrote your pull requests if they're separated into logical commits that have good
it. It's also easier to review your pull requests if they're separated into commit messages and justify themselves in the extended commit description.
logical commits that have good commit messages and justify themselves in the
extended commit description.
As a good rule of thumb, anything you might put into the pull request As a good rule of thumb, anything you might put into the pull request
description on Github is probably fair game for going into the extended commit description on Github is probably fair game for going into the extended commit
message as well. message as well.
See [here](https://chris.beams.io/posts/git-commit/) for more details. See [How to Write a Git Commit Message] for more details.
## Code Review ## Code Review
@ -119,9 +116,8 @@ process is:
## Style Reference ## 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], but with a
style](https://www.kernel.org/doc/Documentation/process/coding-style.rst), but few notable differences.
with a few notable differences.
Try to keep your code conforming to C11 and POSIX as much as possible, and do Try to keep your code conforming to C11 and POSIX as much as possible, and do
not use GNU extensions. not use GNU extensions.
@ -397,3 +393,8 @@ static void subsurface_handle_surface_destroy(struct wl_listener *listener,
subsurface_destroy(subsurface); subsurface_destroy(subsurface);
} }
``` ```
[#sway-devel on Libera Chat]: https://web.libera.chat/?channels=#sway-devel
[reference Github issues]: https://help.github.com/articles/closing-issues-via-commit-messages/
[How to Write a Git Commit Message]: https://chris.beams.io/posts/git-commit/
[kernel style]: https://www.kernel.org/doc/Documentation/process/coding-style.rst