Skip to content

Latest commit

 

History

History
79 lines (48 loc) · 4.15 KB

CONTRIBUTING.md

File metadata and controls

79 lines (48 loc) · 4.15 KB

Contributing Notes

First off, thank you for considering contributing to rMock.

Why have these guidelines?

Following these guidelines helps to communicate that you respect developing this open source project. It also aides in setting up a uniform process for all issues and requests that come in and get merged.

What ways can you contribute?

Improving documentation, bug triaging, or writing tutorials, adding features, fixing bugs are all ways you could contribute to. Any new ideas toward contribution are welcome.

Your first contribution

Unsure where to begin? You can start by looking through these beginner and help-wanted issues: Beginner issues - issues which should only require a few lines of code, and a test or two. Help wanted issues - issues which should be a bit more involved than beginner issues. Both issue lists are sorted by total number of comments. While not perfect, number of comments is a reasonable proxy for impact a given change will have.

[source: Atom] Need more inspiration? [1] Read the Docs

Here are a couple of friendly tutorials you can include: http://makeapullrequest.com/ and http://www.firsttimersonly.com/

Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.

At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first 😸

If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.

Getting started

  1. Create your own fork of the code
  2. Do the changes in your fork
  3. If you like the change and think the project could use it, send in a pull request for it. It will be reviewed and finalized to be merged in.

Report bugs

Please use the template below for filing bugs

When filing an issue, make sure to answer these five questions:

  1. What version are you using?
  2. What device model and OS version was this issue noted in?
  3. What did you do?
  4. What did you expect to see?
  5. What did you see instead?

Suggest a feature

If you find yourself wishing for a feature that doesn't exist in rMock, you are probably not alone. There are bound to be others out there with similar needs. Open an issue on our issues list on GitHub which describes the feature you would like to see, why you need it, and how it should work.

Pull request rules and review process

The code is reviewed by one of the admins on the project regularly. Feedback is always given in the form of comments in the same thread. Once the PR has been approved, it would be scheduled to be merged into a release branch soon after.

Creating a pull request

  1. Please leave the issue heading as the title of the PR. Mention the issue no in front of the title if it has one. Ex: #123454321 - Replace copy of the object with a clone
  2. Explain very briefly on what change was made and how to test the changes made
  3. Add any useful information that may be necessary for anyone else to test and review the PR

Giving feedback

Please keep your feedback to be polite and professional. Always explain clearly as to what the issue is and give a possible solution or hint as to what could fix it.

Community

You can open up issues within the issues section on github. This is actively monitored by the admin.

You can directly send a message to the admin over twitter as well.

Code Style

The code style is not elaborately described. Try and follow to the code conventions currently in place in our repo.

Commit Message Style

We follow semantic commits style for our commit messages. Please follow the same commit message style for all your contributions. You can take a look at the commit history to see how it looks or learn what it is from the link below.

Semantic Commits [1] Semantic Commits