We're glad you want to contribute myprj! This document will help answer common questions you may have during your first contribution. Please, try to follow these guidelines when you do so.
Not every contribution comes in the form of code. Submitting, confirming, and triaging issues is an important task for any project. We use GitHub to track all project issues. If you discover bugs, have ideas for improvements or new features, please start by opening an issue on this repository. We use issues to centralize the discussion and agree on a plan of action before spending time and effort writing code that might not get used.
- Check that the issue has not already been reported
- Check that the issue has not already been fixed in the latest code
(a.k.a.
master) - Select the appropriate issue type and open an issue with a descriptive title
- Be clear, concise, and precise using grammatically correct, complete sentences in your summary of the problem
- Include the output of
mdl -Vormdl --version - Include any relevant code in the issue
Myprj follows a forking workflow, and we have a simple process for contributions:
- Open an issue on the project repository, if appropriate
- If you're adding or making changes to rules, read the Development docs
- Follow the forking workflow
steps:
- Fork the project ( http://github.com/myprj/myprj/fork )
- Create your feature branch (
git checkout -b my-new-feature) - Commit your changes (
git commit -am 'Add some feature') - Push to the branch (
git push origin my-new-feature)
- Create a GitHub Pull Request for your change, following all pull request requirements and any instructions in the pull request template
- Participate in a Code Review with the project maintainers on the pull request
Unsure where to begin contributing to Myprj? 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.
Myprj strives to ensure high quality for the project. In order to promote this, we require that all pull requests to meet these specifications:
- Tests: To ensure high quality code and protect against future regressions, we require tests for all new/changed functionality in Myprj. Test positive and negative scenarios, try to break the new code now.
- Green CI Tests: We use GitHub Actions to test all pull requests. We require these test runs to succeed on every pull request before being merged.
Code review takes place in GitHub pull requests. See this article if you're not familiar with GitHub Pull Requests.
Once you open a pull request, project maintainers will review your code and respond to your pull request with any feedback they might have. The process at this point is as follows:
- A review is required from at least one of the project maintainers. See the master maintainers document for Myprj project at https://github.com/myprj/myprj/blob/master/MAINTAINERS.md.
- Your change will be merged into the project's
masterbranch, and all commits will be squashed during the merge.
If you would like to learn about when your code will be available in a release of Myprj, read more about Myprj Release Cycles.
We release Myprj as a python package to Pypi and maintain a Dockerfile
Myprj follows the Semantic Versioning standard.
Our standard version numbers look like X.Y.Z and translates to:
Xis a major release: has changes that may be incompatible with prior major releasesYis a minor release: adds new functionality and bug fixes in a backwards compatible mannerZis a patch release: adds backwards compatible bug fixes
Exception: Versions < 1.0 may introduce backwards-incompatible changes in a minor version