Spelling #22
Open
Spelling #22
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Josh Soref <[email protected]>
Signed-off-by: Josh Soref <[email protected]>
Signed-off-by: Josh Soref <[email protected]>
Signed-off-by: Josh Soref <[email protected]>
Signed-off-by: Josh Soref <[email protected]>
Signed-off-by: Josh Soref <[email protected]>
Signed-off-by: Josh Soref <[email protected]>
jsoref
commented
Jun 18, 2025
|
|
||
| ## Before You Contribute | ||
|
|
||
| We welcome and encourage contributions from the community. Please read the gRPC project [governance](https://github.com/grpc/grpc-community/blob/master/governance.md) document. Contributions should be made via pull requests. Pull requests will be reviewed by one or more maintainers and merged when acceptable. Please read the following guidelines carefully to maximize the chances of your PR being merged. |
There was a problem hiding this comment.
A number of places linked to /master/ a branch that no longer exists.
I've changed all the ones where the branch is now main but left a couple where the repository hasn't renamed its default branch. At some point, it seems like it'd be nice if the remaining repositories switched over...
| * If you have non-trivial contributions, please consider adding an entry to the AUTHORS.md file in the concerned repository listing the copyright holder for the contribution (yourself, if you are signing the individual CLA, or your company, for corporate CLAs) in the same PR as your contribution. This needs to be done only once for each company or individual. Please keep this file in alphabetical order. | ||
| * Maintain clean commit history and use meaningful commit messages. PRs with messy commit history are difficult to review and won't be merged. Use rebase -i upstream/master to curate your commit history and/or to bring in latest changes from master but avoid rebasing in the middle of a code review. | ||
| * Keep your PR up to date with upstream/master. If there are merge conflicts, we can't really merge your change. | ||
| * Maintain clean commit history and use meaningful commit messages. PRs with messy commit history are difficult to review and won't be merged. Use `git rebase -i upstream/master` or `git rebase -i upstream/main` to curate your commit history and/or to bring in latest changes from `master`/`main` but avoid rebasing in the middle of a code review. |
There was a problem hiding this comment.
This information was out of date as this repository has switched, but I ran across this text because this page was linked from other repositories, so it seems like both should be mentioned. That said, it's probably more correct to list main first as that's the branch used here.
| In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the maintainers can be called in to resolve the issue by voting. The same PR can be used or a separate PR can be opened in the concerned repository for voting. The title of a PR related to voting should be prefixed with “[vote]”. Such PRs should remain open for a minimum of two weeks unless a decision has been reached sooner. A formal voting on the PR is not required if majority of the maintainers have already agreed in other forums or meetings. In such cases, a detailed comment must be added by a maintainer before approving or rejecting the PR. In such a case, only an existing maintainer can ask for a formal vote to challenge the decision. Each maintainer can cast a maximum of one vote regardless of the number of repositories the maintainer is listed in. A simple majority is required to approve the PR. Only the maintainers listed in MAINTAINERS.md file of the concerned repository may vote on the PR. For cross-repository issues, the PR can be opened in [grpc-community](https://github.com/grpc/grpc-community) or [proposal](https://github.com/grpc/proposal) repositories. The list of maintainers in these repositories is a superset of the list of maintainers in all other repositories in the gRPC Github organization. For ease of maintenance only a few senior maintainers will have write access to grpc-community and proposal repositories. | ||
| In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the maintainers can be called in to resolve the issue by voting. The same PR can be used or a separate PR can be opened in the concerned repository for voting. The title of a PR related to voting should be prefixed with “[vote]”. Such PRs should remain open for a minimum of two weeks unless a decision has been reached sooner. A formal voting on the PR is not required if majority of the maintainers have already agreed in other forums or meetings. In such cases, a detailed comment must be added by a maintainer before approving or rejecting the PR. In such a case, only an existing maintainer can ask for a formal vote to challenge the decision. Each maintainer can cast a maximum of one vote regardless of the number of repositories the maintainer is listed in. A simple majority is required to approve the PR. Only the maintainers listed in MAINTAINERS.md file of the concerned repository may vote on the PR. For cross-repository issues, the PR can be opened in [grpc-community](https://github.com/grpc/grpc-community) or [proposal](https://github.com/grpc/proposal) repositories. The list of maintainers in these repositories is a superset of the list of maintainers in all other repositories in the gRPC GitHub organization. For ease of maintenance only a few senior maintainers will have write access to grpc-community and proposal repositories. |
There was a problem hiding this comment.
-gRPC Github organization.
+gRPC GitHub organization.| @@ -29,15 +29,15 @@ All decisions affecting gRPC, big and small, follow the same 3 steps: | |||
| * Step 2: Discuss the pull request. Anyone can do this. | |||
| * Step 3: Maintainers merge or refuse the pull request. | |||
|
|
|||
| In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the maintainers can be called in to resolve the issue by voting. The same PR can be used or a separate PR can be opened in the concerned repository for voting. The title of a PR related to voting should be prefixed with “[vote]”. Such PRs should remain open for a minimum of two weeks unless a decision has been reached sooner. A formal voting on the PR is not required if majority of the maintainers have already agreed in other forums or meetings. In such cases, a detailed comment must be added by a maintainer before approving or rejecting the PR. In such a case, only an existing maintainer can ask for a formal vote to challenge the decision. Each maintainer can cast a maximum of one vote regardless of the number of repositories the maintainer is listed in. A simple majority is required to approve the PR. Only the maintainers listed in MAINTAINERS.md file of the concerned repository may vote on the PR. For cross-repository issues, the PR can be opened in [grpc-community](https://github.com/grpc/grpc-community) or [proposal](https://github.com/grpc/proposal) repositories. The list of maintainers in these repositories is a superset of the list of maintainers in all other repositories in the gRPC Github organization. For ease of maintenance only a few senior maintainers will have write access to grpc-community and proposal repositories. | |||
| In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the maintainers can be called in to resolve the issue by voting. The same PR can be used or a separate PR can be opened in the concerned repository for voting. The title of a PR related to voting should be prefixed with “[vote]”. Such PRs should remain open for a minimum of two weeks unless a decision has been reached sooner. A formal voting on the PR is not required if majority of the maintainers have already agreed in other forums or meetings. In such cases, a detailed comment must be added by a maintainer before approving or rejecting the PR. In such a case, only an existing maintainer can ask for a formal vote to challenge the decision. Each maintainer can cast a maximum of one vote regardless of the number of repositories the maintainer is listed in. A simple majority is required to approve the PR. Only the maintainers listed in MAINTAINERS.md file of the concerned repository may vote on the PR. For cross-repository issues, the PR can be opened in [grpc-community](https://github.com/grpc/grpc-community) or [proposal](https://github.com/grpc/proposal) repositories. The list of maintainers in these repositories is a superset of the list of maintainers in all other repositories in the gRPC GitHub organization. For ease of maintenance only a few senior maintainers will have write access to grpc-community and proposal repositories. | |||
|
|
|||
| ## The gRFC Process | |||
|
|
|||
| We use [gRFCs](https://github.com/grpc/proposal/blob/master/README.md) for any substantial changes to gRPC. This process involves an upfront design that will provide increased visibility to the community. If you're considering a PR that will bring in a new feature across several languages, affect how gRPC is implemented, or may be a breaking change; then you should start with a gRFC. We've got the process documented in [proposal](https://github.com/grpc/proposal) repository and have a [template](https://github.com/grpc/proposal/blob/master/GRFC-TEMPLATE.md) for you to get started. | |||
There was a problem hiding this comment.
This is one of the repositories that hasn't switched from master to main
|
|
||
| ## The gRFC Process | ||
|
|
||
| We use [gRFCs](https://github.com/grpc/proposal/blob/master/README.md) for any substantial changes to gRPC. This process involves an upfront design that will provide increased visibility to the community. If you're considering a PR that will bring in a new feature across several languages, affect how gRPC is implemented, or may be a breaking change; then you should start with a gRFC. We've got the process documented in [proposal](https://github.com/grpc/proposal) repository and have a [template](https://github.com/grpc/proposal/blob/master/GRFC-TEMPLATE.md) for you to get started. | ||
|
|
||
| ## How To Contribute | ||
|
|
||
| See the general guidelines [here](https://github.com/grpc/grpc-community/blob/master/CONTRIBUTING.md) on how to contribute to gRPC project. If you want to become a maintainer see the section below. |
There was a problem hiding this comment.
Do not use (click) here links
For more information, see:
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.