Skip to content

Latest commit

 

History

History
31 lines (22 loc) · 2.25 KB

CONTRIBUTING.md

File metadata and controls

31 lines (22 loc) · 2.25 KB
Raw

#Contributing to Mr. Gerkins

We are always looking for ways to make Mr. Gerkins better. There are many "repository management" tasks out there that Mr. Gerkins can automate. We love your contributions. In case you are eager to contribute to the code base and are not sure where to start, have a look at the help wanted or the issues and start work on an item from either of those sources.

Making Proposals/ Discussion Forum

We welcome proposals to add new features/ abilities to Mr. Gerkins. But before you start putting the idea to code, do discuss with us on out slack channel or by raising an issue. If you want to discuss anything pertaining to Mr. Gerkins do hit us up on our slack channel.

##Bugs We all despise bugs. So if you are plagued by a bug or defect, do raise it with us. You can do this by creating an issue.

##Contribution Process The standard way of contributing ideas, features or bug fixes is by raising pull requests (PR).

  • Fork our repository.
  • Make modifications to the develop branch. In case of bug fixes, raise a PR against the master branch.
  • Do add unit tests and ensure that test coverage is maintained.
  • If the change impacts documentation, kindly update the documentation to keep it relevant.
  • Ensure that a commit represents a logical unit of the change you are making. Kindly squash commits that are too small. Ensure that the commit messages are relevant to the changes made.
  • Raise a PR once you are done with your changes. For bug fixes the PR should be against master branch. For features raise it against develop branch. Kindly provide a brief description of changes in the description of the PR. In case there is a corresponding issue, please reference it in the PR description.
  • We'll review your pull requests and use github to communicate comments. Keep an eye on the PR/associated email for our comments.
  • We merge the pull request the review and follow up action itmes are complete, and close the issue.

##Traceability

Generally, it is a good practice to reflect a single issue in a pull request. Multiple issues fixed by a single pull request will be accepted iff these cannot be separated into individual pull requests reflecting each issue separately.

Looking forward to your contributions to Mr. Gerkins!s