Commit 6e2334c1e5 for openssl.org
commit 6e2334c1e5b47af2e00af3ea9bdf0561eb107135
Author: Matt Caswell <matt@openssl.foundation>
Date: Thu Aug 27 10:05:22 2026 +0100
Strengthen the guidance on bulk submission of pull requests
The previous wording asked contributors planning "many pull requests"
to start with a sample of three or four and open an issue explaining
their process. It relied on the contributor recognising in advance
that they were about to submit many, and someone working through a
backlog one item at a time might never make that judgement.
State the limit as a property of what is open at any one time rather
than of the contributor's intentions, and say what happens when it is
exceeded. Ask for the three or four to be chosen by importance: the
submitter is the only person who has seen the whole list, so an
unranked pile moves the triage onto the reviewers.
Assisted-by: Claude:claude-opus-5
Reviewed-by: Milan Broz <mbroz@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.foundation>
Merge-date: Tue Sep 1 14:28:51 2026
Merged-from: https://github.com/openssl/openssl/pull/32544
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8101e47114..e4ade85d9b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -19,13 +19,40 @@ open an issue for it before starting work, to get comments from the community.
Someone may be already working on the same thing,
or there may be special reasons why a feature is not implemented.
-Similarly, if you plan to submit many pull requests, please start with
-a representative sample (no more than 3 or 4) and open an issue
-explaining your process. The OpenSSL project has limited resources,
-especially when it comes to reviewers, so we appreciate advanced
-communication before submitting many pull requests. In addition,
-contributors should personally evaluate potential patches generated by
-automated tools.
+Do not submit changes in bulk. Review, not authorship, is the scarce
+resource in this project: every pull request consumes the attention of
+at least two committers, and a batch of them submitted together does not get
+reviewed any faster than the same batch submitted over months. It
+merely displaces the review of everyone else's work, including security
+fixes.
+
+Nor is the answer to bundle them together. A pull request carrying
+twenty unrelated fixes is harder to review than any one of them alone,
+cannot be merged a piece at a time, and leaves every change in it blocked
+behind the one a reviewer disagrees with. Each pull request should address
+one logical change (perhaps spread across multiple commits); what has to give
+is how many you submit, not how much you put in each one.
+
+Keep to no more than three or four open pull requests at a time, and let
+those be reviewed to completion before opening more. If you are working
+through a list of candidate changes, then choose those three or four
+deliberately: send us the ones you consider most important, rather than the
+first on the list or the quickest to write, and explain in each why it
+matters. You know your list; we do not, and without that ranking the
+judgement of what to look at first falls on the reviewers. Pull requests
+opened well in excess of this may be closed without review, with a request to
+resubmit at a sustainable rate.
+
+This applies regardless of how good the individual changes are, and it
+is not satisfied by spacing submissions out over a few hours or days.
+
+You are the author of everything you submit, whatever produced the first
+draft of it. Before opening a pull request you must have read the
+change in full, understood why it is correct, built and tested it
+yourself, and satisfied yourself that the problem it fixes is real. You
+must be prepared to answer a reviewer's questions about any line of it. The
+`Assisted-by:` trailer (see below) discloses that a tool was used; it does not
+transfer responsibility for the result.
Provide a clear description of the issue or feature being addressed,
including any relevant implementation details and, for performance