Add contributing file from user feedback

This commit is contained in:
Gary D. Gregory 2025-01-27 09:18:37 -05:00
parent c71f418d0d
commit fe13532762

View File

@ -60,18 +60,21 @@ Making Changes
-------------- --------------
+ Create a _topic branch_ for your isolated work. + Create a _topic branch_ for your isolated work.
* Usually you should base your branch on the `master` branch. * Usually you should base your branch from the `master` branch.
* A good topic branch name can be the JIRA bug ID plus a keyword, e.g. `LANG-123-InputStream`. * A good topic branch name can be the JIRA bug ID plus a keyword, for example, `LANG-123-InputStream`.
* If you have submitted multiple JIRA issues, try to maintain separate branches and pull requests. * If you have submitted multiple JIRA issues, try to maintain separate branches and pull requests.
+ Make commits of logical units. + Make commits of logical units.
* Make sure your commit messages are meaningful and in the proper format. Your commit message should contain the key of the JIRA issue. * Make sure your commit messages are meaningful and in the proper format. Your commit message should contain the key of the JIRA issue.
* e.g. `LANG-123: Close input stream earlier` * For example, `[LANG-123] Close input stream earlier`
+ Respect the original code style: + Respect the original code style:
+ Only use spaces for indentation. + Only use spaces for indentation; you can check for unnecessary whitespace with `git diff` before committing.
+ Create minimal diffs - disable _On Save_ actions like _Reformat Source Code_ or _Organize Imports_. If you feel the source code should be reformatted create a separate PR for this change first. + Create minimal diffs - disable _On Save_ actions like _Reformat Source Code_ or _Organize Imports_. If you feel the source code should be reformatted create a separate PR for this change first.
+ Check for unnecessary whitespace with `git diff` -- check before committing. + Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible but is a best-practice.
+ Make sure you have added the necessary tests for your changes, typically in `src/test/java`. Unit tests are typically in the `src/test/java` directory.
+ Run all the tests with `mvn clean verify` to ensure nothing else was accidentally broken. + Run a successful build using the default [Maven](https://maven.apache.org/) goal with `mvn`; that's `mvn` on the command line by itself.
+ Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
+ Each commit in the pull request should have a meaningful subject line and body. Note that commits might be squashed by a maintainer on merge.
Making Trivial Changes Making Trivial Changes
---------------------- ----------------------
@ -79,7 +82,7 @@ Making Trivial Changes
The JIRA tickets are used to generate the changelog for the next release. The JIRA tickets are used to generate the changelog for the next release.
For changes of a trivial nature to comments and documentation, it is not always necessary to create a new ticket in JIRA. For changes of a trivial nature to comments and documentation, it is not always necessary to create a new ticket in JIRA.
In this case, it is appropriate to start the first line of a commit with '(doc)' instead of a ticket number. In this case, it is appropriate to start the first line of a commit with '[doc]' or '[javadoc]' instead of a ticket number.
Submitting Changes Submitting Changes