Contributing

You have found a bug or you have an idea for a cool new feature? Contributing code is a great way to give something back to the open source community. Before you dig right into the code there are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.

Getting started

  • Make sure you have a GitHub account[1].
  • Find the corresponding repository on GitHub[2].
  • Submit a GitHub issue in the repository to request a change, assuming one does not already exist.
    • Clearly describe the issue including steps to reproduce when it is a bug.
    • Include screenshots and outputs whenever relevant.
    • If known, explain what should be changed to fix the problem.
    • If possible, specify how to test the new feature.
  • Fork[3] and check out your forked repository.

Making changes

  • Ensure your fork of the repository is up-to-date (use GitHub's fork sync feature[4], and pull to your local clone of the repository).
  • Create a topic branch for your isolated work, named feature/short-description (the name is prefixed with feature/ even if your change fixes a bug).
    • Usually you should base your branch on the main branch.
    • A good topic branch name can be the GitHub issue id (#nnn) plus a short description, e.g. feature/issue-53-fix-https-certificate.
    • If you have submitted multiple issues, try to maintain separate branches and pull requests.
    • Check our branching model[5] for more details.
  • 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 GitHub issue.
    • Example: Issue #53: Changed the implementation of the keystore
  • Respect the original code style (tabs, spaces, line width, etc.):
    • Create minimal diffs – disable On Save actions like Reformat Source Code or Organize Imports. If you feel the source code should be reformatted or refactored somehow, create a separate PR for this change first. Smaller changes are more likely to get approved by reviewers!
  • Make sure you have added the necessary tests for your changes.
  • Run all the tests before submitting a PR to ensure nothing else was accidentally broken.
  • Build the project site (if any) and verify the configured code quality reports (in the Project Reports section).

Making trivial changes

Cosmetic or trivial changes in a project, like indentation, white spaces, typos, or minor refactoring don't require creating a dedicated GitHub issue, but they must not be mixed with other significant changes: a separate commit and separate Pull Request must be submitted.

In this case, the topic branch should be named trivial/short-description.

Submitting changes

  • Push your changes to a topic branch in your fork of the repository.
  • Submit a Pull Request (PR) to the corresponding repository in the notdeaddev organization.
    • Verify Files Changed shows only your intended changes and does not include additional files or changes like white spaces, etc.
    • Make sure all automatic checks are successful.
    • Verify comments produced automatically by code quality automatic checks.
  • When implementing additional changes after reviewers suggestions, simply commit and push such changes. Never squash or rebase commits that you have already pushed!
  • Once your PR is merged (if approved), sync your forked repository[4], pull these changes to your locally cloned repository and delete your branch.

Happy coding! 😊

Additional resources

No results.