RFR: Get agreement before PR

[Markus KARG]

On Mon, 5 May 2025 19:05:41 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Added a note on getting proper agreement on a change before creating a PR for it.

src/guide/contributing-to-an-open-jdk-project.md line 61:

> 59: Once the OCA is signed, please restrain your urge to create a PR just a little while longer. In order to prepare the community for your patch, please socialize your idea on the relevant [mailing lists]. Almost all changes, and in particular any API changes, must go this route and have a broad agreement in place before there is any point in presenting code. To understand the criteria by which your patch is going to be judged, please read [Why is My Change Rejected?] below. In short, hidden constraints and assumptions, stability and quality, maintainability, compatibility, and conformance to specifications must be considered before your PR is ready to be submitted. If you don't understand the constraints for acceptance, you might be surprised when your PR is rejected.
> 60: 
> 61: Please note that lack of engagement should not be interpreted as supporting the proposal. Lack of engagement might be better interpreted as people are busy or maybe that the problem isn't compelling or high priority enough to spend time on right now. If you didn't get the desired attention and the required agreement in your mail thread, **do not** proceed to create a PR.

By all due respect, but that wording effectively would have prevented *lots* of actually merged and appreciated PRs in the past -- even and in particular those from the core team members themselves, who often are *just few* people, acting on Gentleman's Agreement but not by "broad" agreement. In particular for smaller, well-understood fixes, there typically is no "broad" agreement, but "silent agreement", as everybody is fine with a fix. Hence, we should not stop ourselves *unless needed*. A discussion is fine *and needed* **for API changes**. A discussion *before showing code* for small fixes makes no sense at all and makes things overly complex, as how would you discuss whether it is fine to fix a code line without showing that codeline?

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

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