Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: minor typos in guidance docs #196

Merged
merged 1 commit into from
May 29, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions maintainer_guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,11 @@ Here are a few tips for repository maintainers.
* Stay on top of your pull requests. PRs that languish for too long can become difficult to merge.
* Work from your own fork. As you are making contributions to the project, you should be working from your own fork just as outside contributors do. This keeps the branches in github to a minimum and reduces unnecessary CI runs.
* Try to proactively label issues and pull requests with labels
* Actively review pull requests as the are submitted
* Actively review pull requests as they are submitted
* Triage issues once in a while in order to keep the repository alive.
* If some issues are stale for too long because they are no longer valid/relevant or because the discussion reached no significant action items to perform, close them and invite the users to reopen if they need it.
* If some PRs are no longer valid due to conflicts, but the PR is still needed, ask the contributor to rebase their PR
* If some issues and PRs are still relevant, use labels to help organize tasks
* If some PRs are no longer valid due to conflicts, but the PR is still needed, ask the contributor to rebase their PR.
* If some issues and PRs are still relevant, use labels to help organize tasks.
* If you find an issue that you want to create a pull request for, be sure to assign it to yourself so that other maintainers don't start working on it at the same time.

## Landing Pull Requests
Expand All @@ -26,7 +26,7 @@ When landing pull requests, be sure to check the first line uses an appropriate

## Branch Management

The `master` branch is is the bleeding edge. New major versions of the module
The `master` branch is the bleeding edge. New major versions of the module
are cut from this branch and tagged. If you intend to submit a pull request
you should use `master HEAD` as your starting point.

Expand Down
3 changes: 2 additions & 1 deletion pr_guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,7 @@ you might create a branch named `48-fix-http-agent-error`.
```console
git fetch upstream
git reset --hard upstream/master
git checkout FETCH_HEAD
git checkout -b 48-fix-http-agent-error
```

Expand Down Expand Up @@ -82,7 +83,7 @@ Use your real name (sorry, no pseudonyms or anonymous contributions.)

The sign-off is a signature line at the end of your commit message. Your
signature certifies that you wrote the patch or otherwise have the right to pass
it on as open-source code. See [developercertificate.org](http://developercertificate.org/))
it on as open-source code. See [developercertificate.org](http://developercertificate.org/)
for the full text of the certification.

Be sure to have your `user.name` and `user.email` set in your git config.
Expand Down