RFR: Get agreement before PR

[Jesper Wilhelmsson]

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.

I think we need to take a step back and look at who the intended audience is and how the Developers' Guide is intended to be used. The primary target audience is developers who want to start contributing to OpenJDK and have little or no previous experience of doing so. Sure, many parts of the guide are step-by-step descriptions of how to do various things in JBS etc, and are likely relevant to experienced contributors as well, as many things like backing out a change and such aren't things you do on a daily basis. But still, the part of the guide we are currently looking at is unlikely to be read by someone who has been around long enough to become Committer for instance. So this is as much about setting expectations as it is about detailing how people should work.

Many OpenJDK developers know from experience that there is an implicit broad consensus for some types of changes in some areas of the code. Many OpenJDK developers know from discussions through other channels that there is a broad consensus for specific changes in specific areas - e.g. something might have been discussed at a committers workshop or similar venue. Some changes get broad consensus through local discussions at an office where several OpenJDK developers work together on a daily basis or through project team meetings. There are many ways to get a broad consensus but in reality only the mailing list is the option available to someone who is an unknown independent developer who wish to join the OpenJDK community. This is why the mailing list is presented as the viable option in this text. This should not be interpreted as "lack of discussion on the mailing list = lack of discussion". Trust me, even small changes made by experienced developers will get shot down if they have
 n't been discussed and agreed on before the PR is presented.

The text here could be phrased differently to cover more ways to get consensus, or explain various exceptions to the guidelines, but I see no benefit of doing so. We don't want a developer to get the impression that a first-timer can show up with a PR with a small one-line bug fix and just get a quick fix into the code. That's not how we work. I'm sure you understand why, but for reference I'll put this link here: https://openjdk.org/guide/#why-is-my-change-rejected

When it comes to replying to PRs or mail threads in a timely maner one must be realistic and understand that
* most OpenJDK developers have limited time
* most experienced OpenJDK developers are actively working in some specific project and are unlikely to have time for changes not related to that specific project
* most experienced OpenJDK developers are employed by a company and may be constrained by company policies dictating what paid company time should be spent on
* no experienced OpenJDK developer will look at an implementation of a solution to a problem before being convinced that it's the right problem to solve, and it's the right solution to that problem
* no experienced OpenJDK developer will approve a change without spending significant time on understanding the affected area, the change, and all its implications

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

PR Comment: https://git.openjdk.org/guide/pull/150#issuecomment-2878154106