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.

Sign up for GitHub

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

Jump to bottom

document the kinds of patches the repo is open to #8900

Merged
merged 3 commits into from
Oct 13, 2021
Merged

document the kinds of patches the repo is open to #8900

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c60aee6
document the kinds of patches the repo is open to
elharo Aug 24, 2021
0ba60d6
be more amenable to optimizations
elharo Oct 13, 2021
9e2b675
fix typo
elharo Oct 13, 2021
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
Next Next commit
document the kinds of patches the repo is open to 
@fowles
  • Loading branch information
@elharo
elharo committed Aug 24, 2021
commit c60aee6d17da2508c868d1c0a1b607a3ab0310ec
26 changes: 24 additions & 2 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,9 +1,31 @@
# Contributing to Protocol Buffers

We welcome your contributions to protocol buffers. This doc describes the
We welcome some types of contributions to protocol buffers. This doc describes the
process to contribute patches to protobuf and the general guidelines we
expect contributors to follow.

## What We Accept

* Bug fixes with unit tests demonstrating the problem are very welcome.
We also appreciate bug reports, even when they don't come with a patch.
Bug fixes without tests are usually not accepted.
* New APIs and features with adequate test coverage and documentation
may be accepted if they do not compromise backwards
compatibility. However there's a fairly high bar of usefulness a new public
method must clear before it will be accepted. Features that are fine in
isolation are often rejected because they don't have enough impact to justify the
conceptual burden and ongoing maintenance cost. It's best to file an issue
and get agreement from maintainers on the value of a new feature before
working on a PR.
* Performance improvements are rarely accepted. The ones that are accepted
must be heavily benchmarked in both open source and Google internal systems.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is a fair representation. I think Performance improvements like bug fixes will be accepted with good benchmarks justifying them (assuming they do not increase complexity signficantly).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

* Changes to existing APIs are almost never accepted. Stability and
backwards compatibility are paramount. In the unlikely event a breaking change
is required, it must usually be implemented in google3 first.
* Changes to the wire and text formats are never accepted. Any breaking change
to these formats would have to be implemented as a completely new format.
We cannot begin generating protos that cannot be parsed by existing code.

## Before You Start

We accept patches in the form of github pull requests. If you are new to
Expand Down Expand Up @@ -58,7 +80,7 @@ the final release.
* 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
& review's time is wasted. Create more PRs to address different concerns and
& 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
Expand Down