mmo-ref/dep-protobuf
1
0
Fork 0
mirror of https://github.com/protocolbuffers/protobuf synced 2026-08-26 02:23:14 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Add instructions for documentation changes to CONTRIBUTING.md.

Browse source 
PiperOrigin-RevId: 788964909
This commit is contained in:
Protobuf Team Bot 2025-07-30 10:58:25 -07:00 • committed by Copybara-Service
parent d50e76dad9
commit 8568171911
1 changed files with 41 additions and 36 deletions
Download patch file Download diff file Expand all files Collapse all files

77
CONTRIBUTING.md
View file

@ -63,48 +63,53 @@ For each pull request, a protobuf team member will be assigned to review the
pull request. For minor cleanups, the pull request may be merged right away
after an initial review. For larger changes, you will likely receive multiple
rounds of comments and it may take some time to complete. We will try to keep
our response time within 7-days but if you don’t get any response in a few
days, feel free to comment on the threads to get our attention. We also expect
you to respond to our comments within a reasonable amount of time. If we don’t
hear from you for 2 weeks or longer, we may close the pull request. You can
still send the pull request again once you have time to work on it.
our response time within 7-days but if you don’t get any response in a few days,
feel free to comment on the threads to get our attention. We also expect you to
respond to our comments within a reasonable amount of time. If we don’t hear
from you for 2 weeks or longer, we may close the pull request. You can still
send the pull request again once you have time to work on it.
Once a pull request is merged, we will take care of the rest and get it into
the final release.
## Pull Request Guidelines
* If you are a Googler, it is preferable to first create an internal CL and
have it reviewed and submitted. The code propagation process will deliver the
change to GitHub.
* Create small PRs that are narrowly focused on addressing a single concern.
We often receive PRs that are trying to fix several things at a time, but if
only one fix is considered acceptable, nothing gets merged and both author's
& reviewer's time is wasted. Create more PRs to address different concerns and
everyone will be happy.
* For speculative changes, consider opening an issue and discussing it first.
If you are suggesting a behavioral or API change, make sure you get explicit
support from a protobuf team member before sending us the pull request.
* Provide a good PR description as a record of what change is being made and
why it was made. Link to a GitHub issue if it exists.
* Don't fix code style and formatting unless you are already changing that
line to address an issue. PRs with irrelevant changes won't be merged. If
you do want to fix formatting or style, do that in a separate PR.
* Unless your PR is trivial, you should expect there will be reviewer comments
that you'll need to address before merging. We expect you to be reasonably
responsive to those comments, otherwise the PR will be closed after 2-3 weeks
of inactivity.
* 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/main to curate your commit history and/or to bring in latest
changes from main (but avoid rebasing in the middle of a code review).
* Keep your PR up to date with upstream/main (if there are merge conflicts,
we can't really merge your change).
* All tests need to be passing before your change can be merged. We recommend
you run tests locally before creating your PR to catch breakages early on.
Ultimately, the green signal will be provided by our testing infrastructure.
The reviewer will help you if there are test failures that seem not related
to the change you are making.
* If you are a Googler, it is preferable to first create an internal CL and
have it reviewed and submitted. The code propagation process will deliver
the change to GitHub.
* For documentation changes, submit pull requests to the
[protocolbuffers/protocolbuffers.github.io](https://github.com/protocolbuffers/protocolbuffers.github.io)
repository. We don't currently have an ingest flow for docs, but we will
replicate changes internally and push them out to docs within a couple of
weeks of accepting the changes.
* Create small PRs that are narrowly focused on addressing a single concern.
We often receive PRs that are trying to fix several things at a time, but if
only one fix is considered acceptable, nothing gets merged and both author's
& reviewer's time is wasted. Create more PRs to address different concerns
and everyone will be happy.
* For speculative changes, consider opening an issue and discussing it first.
If you are suggesting a behavioral or API change, make sure you get explicit
support from a protobuf team member before sending us the pull request.
* Provide a good PR description as a record of what change is being made and
why it was made. Link to a GitHub issue if it exists.
* Don't fix code style and formatting unless you are already changing that
line to address an issue. PRs with irrelevant changes won't be merged. If
you do want to fix formatting or style, do that in a separate PR.
* Unless your PR is trivial, you should expect there will be reviewer comments
that you'll need to address before merging. We expect you to be reasonably
responsive to those comments, otherwise the PR will be closed after 2-3
weeks of inactivity.
* 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/main to curate your commit history and/or to bring in latest
changes from main (but avoid rebasing in the middle of a code review).
* Keep your PR up to date with upstream/main (if there are merge conflicts, we
can't really merge your change).
* All tests need to be passing before your change can be merged. We recommend
you run tests locally before creating your PR to catch breakages early on.
Ultimately, the green signal will be provided by our testing infrastructure.
The reviewer will help you if there are test failures that seem not related
to the change you are making.
## Reviewer Guidelines