Yaltik
/
hy
2
0
Fork 0
Code Pull Requests Releases Activity

Misc language fixes/rewording for CONTRIBUTING.rst

This commit is contained in:
Ryan Gonzalez 2017-06-14 15:28:47 -05:00
parent 0baffaa360
commit febac43239
1 changed files with 31 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
CONTRIBUTING.rst
View File

@ -4,29 +4,27 @@ Contributor Guidelines
Contributions are welcome and greatly appreciated. Every little bit
helps in making Hy better. Potential contributions include:
- Reporting bugs
- Fixing bugs
- Requesting features
- Adding features
- Writing tests for outstanding bugs or untested features
- Reporting and fixing bugs.
- Requesting features.
- Adding features.
- Writing tests for outstanding bugs or untested features.
- You can mark tests that Hy can't pass yet as xfail_.
- Cleaning up the code
- Improving the documentation
- Cleaning up the code.
- Improving the documentation.
- Answering questions on `the IRC channel`_, `the mailing list`_, or
`Stack Overflow`_
`Stack Overflow`_.
- Evangelizing for Hy in your organization, user group, conference, or
bus stop
bus stop.
Issues
~~~~~~
To report bugs or request features, search the `issue tracker`_ to
In order to report bugs or request features, search the `issue tracker`_ to
check for a duplicate. (If you're reporting a bug, make sure you can
reproduce it with the very latest, bleeding-edge version of Hy from
the ``master`` branch on GitHub. Bugs in stable versions of Hy are
fixed on ``master`` before the fix makes it into a new stable
release.) Then make a new issue.
release.) If there aren't any, then you can make a new issue.
It's totally acceptable to create an issue when you're unsure whether
something is a bug or not. We'll help you figure it out.
@ -38,10 +36,10 @@ Pull requests
Submit proposed changes to the code or documentation as pull requests
(PRs) on GitHub_. Git can be intimidating and confusing to the
uninitiated. `This getting-started guide`_ may be helpful. But if
you're overwhelmed by Git or GitHub or the rules below, don't sweat
it; we want to keep the barrier to contribution low, so we're happy to
help you with these finicky things, or do them for you if necessary.
uninitiated. `This getting-started guide`_ may be helpful. However, if
you're overwhelmed by Git, GitHub, or the rules below, don't sweat
it. We want to keep the barrier to contribution low, so we're happy to
help you with these finicky things or do them for you if necessary.
Deciding what to do
-------------------
@ -52,7 +50,7 @@ fix, so they may be good targets for your first PR for Hy.
If you're proposing a major change to the Hy language, or you're
unsure of the proposed change, create an issue to discuss it before
you write any code. This will allow others to give feedback on your
idea, and possibly avoid wasted work.
idea, and it can possibly avoid wasted work.
File headers
------------
@ -79,9 +77,9 @@ revert other commits in the same PR (``git rebase`` is your friend).
Avoid committing spurious whitespace changes.
Format commit messages as follows. The first line should describe the
overall change in 50 characters or less. If you wish to add more
information, separate it from the first line with a blank line.
The first line of a commit message should describe the overall change in 50
characters or less. If you wish to add more information, separate it from the
first line with a blank line.
Testing
-------
@ -92,10 +90,10 @@ testing a bug that has a GitHub issue, include a comment with the URL
of the issue.
No PR may be merged if it causes any tests to fail. You can run the
test suite and check the style of your code with ``make d``. You can
purge the byte-compiled versions of the test files with ``git
clean -dfx tests/`` You can run the tests while skipping the slow
tests in ``test_bin.py`` with ``pytest --ignore=tests/test_bin.py``.
test suite and check the style of your code with ``make d``. The byte-compiled
versions of the test files can be purged using ``git clean -dfx tests/``.
If you want to run the tests while skipping the slow ones in ``test_bin.py``,
use ``pytest --ignore=tests/test_bin.py``.
NEWS and AUTHORS
----------------
@ -119,18 +117,18 @@ If the PR fulfills one or more issues, then the body text of the PR
(case-insensitive) wording, because when a PR containing such text is
merged, GitHub automatically closes the mentioned issues, which is
handy. Conversely, avoid this exact language if you want to mention
an issue without closing it (because e.g. you've partly but not
an issue without closing it (e.g. because you've partly but not
entirely fixed a bug).
Before any PR is merged, it must be approved by one or more members of
Hy's core team, none of whom may be the author of the PR. Changes to
the documentation, or trivial changes to code, need to be approved by
**one** member. All other PRs need to be approved by **two** members.
Before any PR is merged, it must be approved by members of Hy's core team,
excluding the PR's author. Changes to the documentation, or trivial changes
to code, need to be approved by **one** member; all other PRs need to be
approved by **two** members.
Anybody may perform the merge. Merging should create a merge commit
(don't squash, because that would remove separation between logically
separate commits, and don't fast-forward, because that would throw
away the history of the commits as a separate branch), which should
Anybody on the team may perform the merge. Merging should create a merge commit
(don't squash unless necessary, because that would remove separation between
ogically separate commits, and don't fast-forward, because that would throw
away the history of the commits as a separate branch)which should
include the PR number in the commit message.
Contributor Code of Conduct