RFR: Get agreement before PR

[Markus KARG]

On Wed, 7 May 2025 11:14:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I think you may be over reading this.  When someone sends mail with a proposal for some feature or API then there is no obligation for anyone to respond. Lack of a timely response should not be interpreted as agreement with the proposal. The phrase "The absence of dissent is not the presence of consent" comes to mind. It may be annoying to not get a timely response from maintainers in specific areas but this shouldn't mean it's time to create a PR and start reviewing code and changes.  Code first and "code is king" may be how many projects work but here, and especially for APIs, the code will often have negative value because it distracts from the bigger questions.
>> 
>> One thing that has kinda worked on a few occasions is where a PR is created with an API and no implementation code, the intention being to focus on the API and avoid the distraction of folks trying to micro optimize before it's clear whether the proposal will get traction.
>
> Maybe the text in the guide should be more clear that changes can sit anywhere on a long scale from "trivial one-line bug fixes" to "suggestions of entirely new APIs", and that this newly added comment applies to changes on the heavier side of this scale, rather than the lighter and trivial fixes. 
> 
> For these, I agree with @mkarg that it might be better just to present a PR (especially if there already exists a JBS issue with a clear specification of what is wrong) than to clog the mailing lists with unnecessary discussion about the merits of such a fix. 
> 
> Where to draw the line then is the big question... The guide can certainly ask people to rather err on the side of socializing the idea first, rather than publishing PRs.

Looking back at the 30 years I am contributing to / leading lots of open source projects, my experience is that **for all non-API / non-spec changes** (except *very large* code changes) it is often easier to explain the target or a PR *with actual code at hand*. For example, "hidden constraints and assumptions, stability and quality, maintainability, compatibility, and conformance to specifications" rather often can get *better* identified if a draft PR *exists already*. *Draft*-PRs are exactly the vehicly that what would fill the gap missing in the process here.

Having said that, I think the line should be drawn here:
* *Draft*-PRs MAY be filed *without* broad concensus on the mailing list, e. g. to have "some code at hand" for the sake of *getting* that broad concensus by referencing them from mailing list postings. *This helps getting a better understanding of the actual intent of small implementation-only changes, which are often hard to express **unambiguously** in plain text.*
* PRs MAY be filed *without* broad concensus on the mailing list *iff* these are neither API changes / spec changes, neither are "very large" code changes. *This helps getting internal refactorings etc. done rather quickly instead of queing them for weeks and months.*
* API changes and spec changes need a CSR anyways, which *implies* a discussion on the mailing list anyways.
* "very large" code changes MUST get announced on the mailing list upfront, and all committers are encouraged to actively comment on them as soon as possible, without a timely restriction.
* *All other* PRs SHOULD get announced on the mailing list, but it still SHOULD be allowed to file time *before* there is broad concensus on the mailing list. This allows "implied silent approval" which de facto is an existing phenomenon and should not get ignored.

-------------

PR Review Comment: https://git.openjdk.org/guide/pull/150#discussion_r2083450265