8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes

[kevinrushforth]

This PR updates the CONTRIBUTING.md guide to address the following:

1. Clarify the process for adding new features / API changes, specifically that they must be discussed on the mailing list as the first step.
2. Add a link to the mailing list in the section regarding contributing bug fixes.
3. Remove the text about cross-linking the PR and JBS issue, and add a note that the Skara tooling takes care of this
4. Remove the section about manually resolving the JBS issue, and add a note that the Skara bot automatically does this when the PR is integrated.
5. Suggest the use of the "/reviewers 2" and "/csr" commands when appropriate
6. Update the note regarding which JDK(s) to use.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8231601: Update CONTRIBUTING.md to clarify process for contributing features plus Skara changes

Download

$ git fetch https://git.openjdk.java.net/jfx pull/303/head:pull/303
$ git checkout pull/303

[bridgekeeper]

👋 Welcome back kcr! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[nlisker]

Additional comments:

1. "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before "not".
2. "Line width is no more than 120 characters" I remember that it was 130 or 135 somewhere.
3. "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use them extensively.
4. ./gradlew all test will cause failure on webkit tests if it was not built.

[mlbridge]

Webrevs

• 02: Full - Incremental (9ee77cf)
• 01: Full - Incremental (becd269)
• 00: Full (9840ffe)

[kevinrushforth]

Regarding your additional comments:

• "Use Unix-style (LF) line endings not DOS-style (CRLF)" needs a comma before "not".

Fixed.

• "Line width is no more than 120 characters" I remember that it was 130 or 135 somewhere.

You're probably remembering an old version, but it's been 120 for a while now.

• "Wildcard imports (import foo.bar.baz.*) are forbidden" Junit imports use them extensively.

Fixed to add an exception for wildcard static imports in tests.

• ./gradlew all test will cause failure on webkit tests if it was not built.

Added a note about this and a pointer to the Web Testing doc.

[kevinrushforth]

/reviewers 2

[openjdk]

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

[nlisker]

The "New features / API additions" repeats some things already stated. Is it to make each section independent?

[kevinrushforth]

I wanted the "New features / API additions" section to stand on its own. Once thing that might be redundant now is the following sentence in the "Contributing code and documentation changes" section:

"Feature requests, in particular, must be discussed ahead of time and will require significant effort on your part."

I think that could be removed or incorporated in "New features / API additions".

[nlisker]

I think that "Contributing to the OpenJFX codebase" should be renamed to something related to a style guide. Then split the testing part to its own subsection.

Also, I still find it confusing that "New features / API additions" is not under the code contribution section. There seems to be 2 main sections: reporting bugs / requesting features - these don't involve code, just talk; then there is contributing code, which covers the process for setup, submissions of bugs fixes, submission of features/API, style, and testing (in some order). Wouldn't this be a better flow?

[kevinrushforth]

Yes, I do think the flow could be better. I'll need to put this on hold for a while, but when I get back to it, I'll look at your suggestions and see if I can come up with something that will improve the flow.

Btw, the thinking behind putting the "New features / API additions" sections at the end (sort of like an appendix) is that I didn't want it to get in the way of the "here's how you sumbit and review a PR" for bug fixes, which is the more common case. I don't think it achieves that in its current form.

[kleopatra]

not sure whether it belongs here, or whether or not it's obviously implied but: I would like to see a bit of clarification on testing of contributions. Right now the sentence might be interpreted to be about running available tests:

Test your changes
Run the test suite to make sure that nothing is broken.

add something like:

• For most code changes, new tests covering those changes are mandatory.