Skip to content

Latest commit

 

History

History
80 lines (57 loc) · 4.24 KB

CONTRIBUTING.md

File metadata and controls

80 lines (57 loc) · 4.24 KB
Raw

Contributing

First off all, thanks for taking the time to contribute! 💪

The following is a set of guidelines for contributing to Series Rush. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Table Of Contents

Submission Process

The following guidelines on the submission process are provided to help you be more effective when submitting code to the project.

The project's master branch is closed. So, when development is complete (ideally on your forked repository), a patch set should be submitted via GitHub pull requests. A review of the patch set will take place. When accepted, the patch set will be merged into the master branch.

Please submit all patches in public by opening a pull request. Patches sent privately to any contributor will not be considered. Because the project is an Open Source project, be prepared for feedback and criticism-it happens to everyone-. If asked to rework your code, be persistent and resubmit after making changes.

Reporting Bugs

Before creating bug reports, please check the issues as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible. Fill out the required template, the information it asks for helps us resolve issues faster.

Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.

How to submit a good bug report

Provide the following information by filling in the bug report template.

  • Explain the problem and include additional details to help maintainers reproduce the problem:
    • Use a clear and descriptive title for the issue to identify the problem.
    • Describe the exact steps which reproduce the problem in as many details as possible.
    • Provide specific examples to demonstrate the steps.
    • Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
    • Explain which behavior you expected to see instead and why.
    • Include screenshots which show you following the described steps and clearly demonstrate the problem.
  • Include details about your configuration and environment.
  • Provide more context:
    • Did the problem start happening recently or was this always a problem?
    • Can you reliably reproduce the issue? If not, provide details about how often the problem happens and under which conditions it normally happens.

Suggesting Enhancements

Before creating enhancement suggestions, please check the issues or pull requests lists as you might find out that you don't need to create one. When you are creating an enhancement suggestion, please include as many details as possible. Fill in the template, including the steps that you imagine you would take if the feature you're requesting existed.

How to submit a good enhancements suggestion

Create an issue in repository and provide the following information by filling in the feature request template

  • Use a clear and descriptive title for the issue to identify the suggestion.
  • Describe the solution you'd like a clear and concise description of what you want to happen.
  • Describe alternatives you've considered if the original idea is not possible for some reason.

Styleguides

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature").
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...").
  • Reference issues and pull requests liberally at the end of the first line.
  • Describe the commit changes in details if the title is not enough.