hedgedoc/CONTRIBUTING.md

Contributing to HedgeDoc

Thanks for your help in improving the HedgeDoc project!

Please note we have a code of conduct, please follow it in all your interactions with the project.

Ways of contributing

Do you have questions about the project?

• Feel free to post your question on our community forum or join our matrix community chat.

Did you find a bug?

• Ensure the bug wasn't already reported by searching on GitHub under Issues.

• If you're unable to find an open issue addressing the problem, open a new one. Be sure to use one of the templates we provide if your request applies to them.

Did you write a patch that fixes a bug?

• Open a new GitHub pull request with the patch. See the section submitting a pull request for details on this.

• Ensure the PR description is precise about the problem and your solution. Just fill out our template. That should cover the most important information.

• Please note that we only accept PRs for the 1.x releases if they fix critical issues. If you are unsure if your fix is critical, it's best to ask us before you start coding.

• Choose the correct base branch:
  The code for 1.x lives in the master branch. docs.hedgedoc.org is also deployed from there until 2.0 is released.
  HedgeDoc 2.x is developed in the develop branch.

Do you intend to add a new feature or change an existing one?

• Suggest your idea via a new GitHub issue. After a confirmation about your idea, you can start writing code. Our maintainers and other project developers can provide useful details about the architecture and show you relevant issues and discussions.

Do you want to work on translations?

• If you want to improve a translation or add a new translation altogether, we handle those via POEditor.

HedgeDoc is a volunteer effort. We encourage you to pitch in and help us to make this project even better.

Certificate of Origin

By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. The DCO is a legally binding statement, please read it carefully.

If you can certify it, then just add a line to every git commit message:

  Signed-off-by: Random J Developer <random@developer.example.org>

Use your real name (sorry, no pseudonyms or anonymous contributions).

How to sign-off commits

The sign-off message can either be added by hand to your commit message or automatically by git.

This is accomplished by using the -s or --signoff option on your regular commit command.

e.g.

git commit -s

or

git commit --signoff

This will use the name and email you configured in git.

Find out how you can change your name and email in this guide from GitHub

How to amend a sign-off

The last commit on any given branch can be amended to include the sign-off message like this:

git commit --amend --signoff

Amend a sign-off to multiple commits

Assuming you have the upstream hedgedoc repo as upstream:

Run git fetch upstream to get the latest content from the upstream repository and then use git rebase --signoff upstream/master or git rebase --signoff upstream/develop to rebase all commits in your current branch, that are different from upstream you try to merge with, and sign them off.

If you've already pushed these commits to GitHub, you'll need to force push your branch after this with git push --force-with-lease.

Changelog snippets

PRs that fix a bug or add a new feature or enhancement should add a corresponding changelog entry. The changelog can be found at public/docs/release-notes.md. If there is no section for the next release yet, just add one using ## <i class="fa fa-tag"></i> 1.x.x <i class="fa fa-calendar-o"></i> UNRELEASED. The version and date will be filled later by the maintainers.
Add a short description for your change in the Features, Enhancements or Bugfixes section, creating the section if needed. Have a look at previous entries for inspiration. You are welcome to add a (by [@your_username](https://github.com/your_username)) note to your entry.

Submitting a Pull Request

1. Submit an issue describing your proposed change. We will try to respond to your issue promptly.
2. Fork this repo, develop and test your code changes. Ensure you follow the commit guidelines (see below) and signed all your commits (see above for details).
3. Submit a pull request against this repo's develop branch for 2.x or the master branch for 1.x.
4. Your branch may be merged once all configured checks pass.

Commit guidelines

• Follow these rules when writing a commit message:

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. If you worked on a specific part of the application, you can prefix your commit message with that Example: " MediaService: Get media backend from configuration"
  4. Capitalize the subject line
  5. Do not end the subject line with a period
  6. Use the imperative mood in the subject line
  7. Wrap the body at 72 characters
  8. Use the body to explain what and why vs. how

  These are inspired by https://chris.beams.io/posts/git-commit/

• Split your change into small, atomic commits. This helps reviewing the changes and enables the use of git bisect.

• Ensure the commit history is easy to follow. Use git rebase -i to sort and squash your commits if neccessary.

• If your branch includes fixup commits (like "Fix typo...", "Fix tests..."), use git rebase -i to clean them up before submitting a pull request.

• When refactoring something, take care to not include any functional changes into the same commit. Mixing refactoring and functional changes makes it hard to find the cause of regressions.