diff options
Diffstat (limited to 'CONTRIBUTING.md')
| -rw-r--r-- | CONTRIBUTING.md | 60 |
1 files changed, 34 insertions, 26 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 46ab3f8838..8ef6d78d40 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,11 +1,13 @@ # Contributing to Neovim -If you need additional support see [the wiki][wiki]. +## Getting started -## Getting started contributing - -- Look for the [`entry-level`][entry] Issue Label. It marks easier issues. -- Take a look at [Waffle][waffle]. It'll show who is working on what isssues. +- Help us review [open pull requests](https://github.com/neovim/neovim/pulls)! +- Look for [**entry-level**][entry] issues to work on. + - [**documentation**](https://github.com/neovim/neovim/labels/documentation) + improvements are also very helpful. +- Look at [Waffle][waffle] to see who is working on what issues. +- Refer to the [the wiki][wiki] for detailed guidance. ### What not to do @@ -20,23 +22,20 @@ excessive noise to `git blame`. ## Pull requests -### For all PRs - - Make it clear in the issue tracker what you are working on. - Be descriptive in your PR message: what is it for, why is it needed, etc. - Don't make cosmetic changes to unrelated files in the same PR. #### Tagging in the issue tracker -When submitting pull requests, include one of the following 'tags' in the title: +When submitting pull requests, include one of the following tokens in the title: * `[WIP]` - Work In Progress. The pull request will change, and there is no need to review it yet. * `[RFC]` - Request For Comment. The request needs reviewing and/or comments. * `[RDY]` - The request is ready to be merged. The request must have been reviewed by at least one person and have no outstanding issues. -* Default label is assumed to be `[WIP]` as long as there's no indication - otherwise. +* Default label is assumed to be `[WIP]` if there's no indication otherwise. #### Branching & history @@ -52,34 +51,43 @@ When submitting pull requests, include one of the following 'tags' in the title: #### Testing - We are unlikely to merge your PR if the Travis build fails. -- The Travis build does not currently run the tests under valgrind, but we would - strongly encourage you to do so locally. +- The Travis build does not currently run the tests under valgrind, but you + are encouraged to do so locally. #### Coding style -All code changes should follow the [Neovim style guide][style]. +Code changes should follow the [Neovim style guide][style]. Please run [`clint.py`][clint] to detect style errors. It is not perfect and may have false positives and negatives. To have `clint.py` ignore certain special cases, put `// NOLINT` at the end of the line. -#### Commit messages - -Follow the [Tim Pope Convention][commit] (@tpope) for commit messages. Most -importantly, do the following: - -- Keep the first line a summary of 50 characters or less. -- Write the summary in the [imperative mood][imperative]. -- Write a more detailed explanation (after a blank line) that explains more in - depth (only if necessary). +#### Commit guidelines + +The purpose of these guidelines is to *make reviews easier* and make the VCS logs more valuable. + +- Try to keep the first line under 70 characters. +- Include further description, if necessary, after a blank line. + - Don't make it too verbose by including obvious things. + - But don't spare clarifications for anything that could be not so obvious. + Some commit messages are pages long, and that's fine if there's no better + place for those comments to live. + - **Recommended:** Prefix logically-related commits with a consistent + identifier at the beginning of each commit message. + [For example](https://github.com/neovim/neovim/commits?author=elmart), + the following commits are related by task (*Introduce vim namespace*) and + scope (*Contrib YCM*). + <br/> `Introduce vim namespace: Contrib YCM: Fix style issues.` + <br/> `Introduce vim namespace: Contrib YCM: Fix build dir calculation` + - Subtasks can be *activity-oriented* (doing different things on the same area) + or *scope-oriented* (doing the same thing on different areas). + - Granularity helps, but it's conceptual size that matters, not extent size. +- Use the imperative voice: "Fix bug" rather than "Fixed bug" or "Fixes bug." -Take a look at @elmart's [commits on Neovim][elmart] for examples. [clint]: clint.py -[commit]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html [entry]: https://github.com/neovim/neovim/issues?labels=entry-level&state=open -[elmart]: https://github.com/neovim/neovim/commits?author=elmart -[imperative]: http://en.wikipedia.org/wiki/Imperative_mood +[imperative]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html [style]: http://neovim.org/develop/style-guide.xml [waffle]: https://waffle.io/neovim/neovim [wiki]: https://github.com/neovim/neovim/wiki/Contributing |