Firstly, we would like to thank you for expressing interest in contributing to a Cod project. Without people like you, the Cod ecosystem wouldn't be where it is.
In order to contribute to this project, it is your duty to read through this file. By reading all the pertinent information, you can make sure that you are making meaningful contributions and that you aren't wasting anyone's time. In return, we will reciprocate your respect in addressing your issue, addressing changes, and helping you finalize pull requests.
For the most part, we are willing to accept any kind of contributions. A nonexhaustive list of contributions we will accept are documentation improvements, bug reports and feature requests, writing code, and many more.
Generally, we won't turn someone away who is attempting to contribute. However, it is a good idea to make an issue anyway, so that the maintainers can discuss the proposition, give feedback, and ultimately accept or decline it.
In order to maintain an open and welcoming community, a few ground rules must be set. These help us to make sure anyone can feel welcomed when making a contribution.
Expectations:
- Be welcoming and accepting of any contribution. See the Code of Conduct for more information.
- If applicable, make sure that all tests pass.
- Create an issue for any proposed changes.
If you've found a bug or have a feature request, create an issue. The issue creation guide will walk you through the process of submitting a bug report or feature request.
If you create an issue which doesn't follow the templates, you will be told to refer to this guide and the issue will be closed. The only exception to this rule is if the issue does not fall under any of the templates, in which case you can open a blank issue.
One thing to note is that we use the Gitflow Workflow. This defines the structure of the branches and the interactions between them. It can be a good thing to keep this in mind when choosing where to start making a contribution if you plan on contributing directly to the code.
If you want to contribute directly to the project, that's great! The first step of doing so is to find or create an issue (as defined in the where to start section) that describes your idea. This should follow the feature request template and provide all the revelant information. Failure to reference a proper feature request issue will result in a message refering you to this guide and the issue being closed.
Once the feature request issue has been made and discussed, you are ready to work on it. Before you start working, wait for a reply to make sure your proposition fits within the scope of the project. After you've gotten feedback, you are ready to fork and begin work on your change.
When you are ready to create the pull request, create it and fill out the template. If your change is large or could span over a bit of time, feel free to make a work-in-progress pull request. If you make a work-in-progress pull request, be sure to make is apparent that it is indeed a work-in-progress.
If you have made a change already without first making an issue, that's okay! The first step is to check the issues to see if one exists that falls under your change. If not, make a new issue that outlines what you've done (be sure to follow a template!). Once you have gotten feedback on the issue, you can create your pull request.
Before a contribution is accepted, we will review the change. This is to ensure that it is up to our standards.
The code review process intially starts when an issue is made. Maintainers will read through and discuss the issue in the comments. If there is information missing or malformed, a reference will usually be made to this document. However, if the problem isn't too large, the maintianer might just ask for the information.
Next, code review takes place in the pull request. Maintainers will review the pull request to make sure the code is up to our standards. Again, if there is a problem, a reference may be made to this document or a new change may be requested.
Once the maintainers have reviewed and approved the contribution, it can be accepted. When a pull request is merged that solves an issue, the issue will be closed as well.
If you've made an issue or pull request and have been waiting for a response for a week or more, feel free to bump it or ping a maintainer. We can get quite busy at times, and occasionally we miss a thing or two, so a friendly reminder can help get the contribution back on track.
If you are bumping or pinging, make sure you are polite and respectful. For a bump, a simple comment saying "Bump" is adequate. For a ping, a simple comment saying "cc @[username]" works fine. If you are rude, you may be told to be patient and your contribution may be put on the back burners.