github/hedgedoc
1
0
Fork 0
mirror of https://github.com/hedgedoc/hedgedoc.git synced 2024-11-22 09:46:30 -05:00
Code Issues Projects Releases Packages Wiki Activity
hedgedoc/CONTRIBUTING.md
David Mehren 90674fb80e
Docs: Emphasize the difference between branches 
To further reduce confusion between the `develop` and `master` branches,
this commit adds more information about them in the README
and the contribution docs.

Signed-off-by: David Mehren <git@herrmehren.de>
2021-01-30 18:37:45 +01:00

5 KiB
Raw Blame History

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?

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).

If you set your user.name and user.email git configs, you can sign your commit automatically with git commit -s. You can also use git aliases like git config --global alias.ci 'commit -s'. Now you can commit with git ci and the commit will be signed.

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.