Skip to content

Latest commit

 

History

History
35 lines (31 loc) · 3.19 KB

CONTRIBUTING.md

File metadata and controls

35 lines (31 loc) · 3.19 KB
Raw

Content

  1. General rules
  2. Issues
  3. Pull Requests
  4. Tutorials

General rules

  • Use proper grammar. If no one can read it, no one can help you.
  • Use proper Markdown. If you have never used markdown before, you can learn it in 3 minutes.

Issues

  • Watch the tutorial if you have never used GitHub Issues before. It only takes 3 minutes!
  • Check existing issues for your issue. Duplicating an issue is slower for both parties so search through open and closed issues to see if what you’re running into has been addressed already.
  • Create an issue for your issue. Don't post a comment on an existing issue. Only use comments to add information to existing issues.
  • Create multiple issues if you have multiple issues. Don't put every single problem you ever had in life into one issue. That makes it impossible organize your issues and will likely get your issue ignored or removed.
  • Be clear about your problem: What was the expected outcome, what happened instead? Detail how someone else can recreate the problem.
  • Include system details like the Java version and operating system you’re using.
  • Include screenshots if your problem is visible. Drag & drop the image directly into your issue.
  • Paste error output or logs in your issue or in a Gist. If pasting them in the issue, wrap it in three backticks so that it renders nicely.

Pull Requests

  • Read the tutorial if you have never forked a repository before.
  • Fork the repository and clone it locally.
  • Pull in changes from the original often so that you stay up to date. That way, when you submit your pull request, merge conflicts will be less likely.
  • Create a branch for your edits.
  • Be clear about what problem is occurring and how someone can recreate that problem or why your feature will help. Then be equally as clear about the steps you took to make your changes.
  • It’s best to test. Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don’t break the existing project.
  • Include screenshots of the before and after if your changes include visible differences. Drag and drop the images into the body of your pull request.
  • Keep the style of the project to the best of your abilities. This may mean using indents, semi colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.

Tutorials