Skip to content

Latest commit

 

History

History
90 lines (73 loc) · 4.19 KB

CONTRIBUTING.md

File metadata and controls

90 lines (73 loc) · 4.19 KB

Contributing

Thank you for your interest in supporting this project. These guideline should help you interacting with other contributors. Make sure to also read the Code of Conduct (which is GitHub's default CoC).

Improvement workflow

This project's development is organized using git flow. Main development runs on the development branch, releases can be found on the master branch. Please use the naming scheme feature/** or refactor/** for your branches with dashes to separate words, e.g. feature/graphical-ast. This makes it simpler for everyone to see where this branch belongs. It also triggers the GitHub Actions workflows which in turn run the tests and report the coverage. Submitted code should always be tested, or there should be a good explanation why it is not feasible in the situation at hand.

Open tasks can be found on the project boards on GitHub (To Do). Feel free to pick one and notify the others via the attached issue. If you find something that you think could or should be improved, please open a new issue before spending your time on writing actual code. Issues will be used for discussing the proposed changes and as a central point to comprehend changes made to this library. After the issue was accepted it is added to the project board to the To Do panel. Eventually, the improvement is either implemented by the main developer(s) or a volunteer contributor via a pull request to the development branch. In case the improvement is security-related make sure you read the SECURITY policy first.

Commit Message Guidelines

Short (72 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert.

Further paragraphs come after blank lines.

* Bullet points are okay, too.
* Typically an asterisk is used for the bullet, followed by a
  single space. Use a hanging indent.

Example for a commit message

Create an ASTNodeFactory

This step was necessary to decouple...

A properly formed git commit subject line should always be able to complete the following sentence

If applied, this commit will <your subject line here>

Rules for a great git commit message style

  • Separate subject from body with a blank line
  • Do not end the subject line with a period
  • Capitalize the subject line and each paragraph
  • Use the imperative mood in the subject line
  • Wrap lines at 72 characters
  • Use the body to explain what and why you have done something. In most cases, you can leave out details about how a change has been made.

Information in commit messages

  • Describe why a change is being made.
  • How does it address the issue?
  • What effects does the patch have?
  • Do not assume the reviewer understands what the original problem was.
  • Do not assume the code is self-evident/self-documenting.
  • Read the commit message to see if it hints at improved code structure.
  • The first commit line is the most important.
  • Describe any limitations of the current code.
  • Do not include patch set-specific comments.

Details for each point and good commit message examples can be found on https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages

References in commit messages

If the commit refers to an issue, add this information to the commit message header or body. e.g. the GitHub web platform automatically converts issue ids (e.g. #123) to links referring to the related issue. In header:

[#123] Refer to GitHub issue…

In body:

…
#123 is addressed by ...

Sources

Code Formatter

The style used for the java source files is the Google style. Make sure to apply it before every commit, e.g. using pre-commit hooks.