RFR: Section on sponsoring [v2]

[Jesper Wilhelmsson]

On Mon, 6 Feb 2023 01:21:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated text to cover more usecases.
>
> src/guide/contributing-to-an-open-jdk-project.md line 29:
> 
>> 27: When you sign the OCA, please make sure that you specify your GitHub user name in the `Username` field of the OCA. If you try to create a PR before you have signed the OCA, or if you didn't specify your GitHub user name, you'll get instructions telling you to do so, and the PR won't be published until this is done. OCA registration is a manual process. Please allow for up to several days to have your OCA application processed, even though it's normally processed swiftly. An alphabetical list of all of the assigned OpenJDK usernames may be found on the [OpenJDK people](https://db.openjdk.org/people) list.
>> 28: 
>> 29: You only need to sign the OCA once in order to cover all changes that you might contribute to any Oracle-sponsored open-source community. If you've already signed the OCA or the former SCA (Sun Contributor Agreement) for any Oracle-sponsored open-source community, then you do not need to sign it again in order to contribute to OpenJDK. Please note that you don't need to sign an OCA if you work at Oracle or a company which has negotiated an equivalent agreement.
> 
> Not sure if this needs to clarify signing as an individual versus being covered by an employers OCA. But the probably needs to be stated somewhere in the first paragraph:
> 
> "If you have not signed the OCA and are not an employee of a Company that has an OCA covering you, then ..."

Isn't that already covered by the last sentence?
"Please note that you don't need to sign an OCA if you work at Oracle or a company which has negotiated an equivalent agreement."

> src/guide/contributing-to-an-open-jdk-project.md line 61:
> 
>> 59: :::
>> 60: 
>> 61: Only the best patches submitted will actually make it all the way into the JDK code base. The goal is not to take in the maximum number of contributions possible, but rather to accept only the highest-quality contributions. The JDK is used daily by millions of people and thousands of businesses, often in mission-critical applications, and so we can't afford to accept anything less than the very best.
> 
> "Only the best" is not really a defining criteria here. This paragraph really overlaps with the following paragraph. First the idea must be appropriate and agreed that a patch is needed, then the quality of the patch itself will be assessed using various criteria depending on the exact nature of the patch.

I rephrased it somewhat.

> src/guide/sponsoring-a-change.md line 3:
> 
>> 1: # Sponsoring a Change
>> 2: 
>> 3: New developers in the OpenJDK community doesn't have the permissions needed to push changes to the repositories. This is a feature that ensures that all developers get familiar with the code, processes, and community before being allowed to actually make changes. To get the first changes in, the new Contributor needs the help of a Sponsor. The Sponsor's role is to offer constructive advice and eventually push the sponsored contribution into the repository.
> 
> s/doesn't/don't/ in first sentence.
> 
> This definition of sponsor seems to be from the old days when you basically needed someone from Sun/Oracle to help shepherd your change through. These days any of the reviewers will offer advice and may become the eventual sponsor of the commit. So I don't think this section really applies any more i.e. sponsoring-a-change.md doesn't need to exist.

I fixed the typo.

It is indeed a text from the old days. Sponsoring is still a thing though so we should have some description of what it means and what to expect from a sponsor. It's a fairly short section, and it may be that some of it can be cut or rephrased to better suit the present. If it becomes much shorter it may fit better as a sub-section under "Contributing to an OpenJDK Project".
Shortening this text is not at the top of my priority list right now though. I just want to get something that is good enough to change the "Sponsoring" link in the OpenJDK sidebar to refer to the guide. That said, if someone else takes a stab at making this text even more up to date I'd be happy to review and sponsor that change :-)

> src/guide/sponsoring-a-change.md line 5:
> 
>> 3: New developers in the OpenJDK community doesn't have the permissions needed to push changes to the repositories. This is a feature that ensures that all developers get familiar with the code, processes, and community before being allowed to actually make changes. To get the first changes in, the new Contributor needs the help of a Sponsor. The Sponsor's role is to offer constructive advice and eventually push the sponsored contribution into the repository.
>> 4: 
>> 5: There are many different reasons to sponsor a change and depending on the situation the exact steps involved may differ significantly. A developer hired into a larger team of experienced OpenJDK developers is likely to get the required information in new hire training or similar and will likely need less help from a sponsor than the entusiast sitting at home with no prior experience of large scale software development. This text aims to highlight the steps involved in sponsoring a change but can't cover all possible scenarios. As always, common sense takes precedence where the assumptions made here doesn't apply to your use case.
> 
> typo: entusiast

Fixed.

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

PR: https://git.openjdk.org/guide/pull/97