We'd love to accept your patches and contributions to this project. There are just a few guidelines to follow.
When contributing to this project, you must agree that you have authored the content, that you have the necessary rights to the content and that the content you contribute may be provided under the APACHE LICENSE, VERSION 2.0.
If you are looking to help to with a code contribution, our project uses Go Lang. If you don't feel ready to make a code contribution yet, no problem! You can also check out the documentation https://github.com/score-spec/docs.
If you are interested in making a code contribution and would like to learn more about the technologies that we use, check out the list below.
Never made an open-source contribution before? Wondering how contributions work in our project? Here's a quick rundown!
- Find an issue that you are interested in addressing or a feature that you would like to add.
- Fork the repository associated with the issue to your local GitHub organization. This means that you will have a copy of the repository under your-GitHub-username/repository-name.
- Clone the repository to your local machine using git clone.
- Create a new branch for your fix using git checkout -b your-branch-name.
- Make the appropriate changes for the issue you are trying to address or the feature that you want to add.
- Use git add insert-paths-of-changed-files-here to add the file contents of the changed files to the "snapshot" git uses to manage the state of the project, also known as the index.
- Use git commit -s -m "Insert a brief message of the changes made here" to store the contents of the index with a descriptive message.
- Push the changes to the remote repository using git push origin your-branch-name.
- Submit a pull request to the upstream repository.
- Title the pull request with a brief description of the changes made and the issue or bug number associated with your change. For example, you can title an issue like so, "Added more log outputting to resolve #4352".
- In the description of the pull request, explain the changes that you made, any issues you think exist with the pull request you made, and any questions you have for the maintainer. It's OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you resolve any problems and improve it!
- Wait for the pull request to be reviewed by a maintainer.
- Introduce changes to the pull request if the reviewing maintainer recommends them.
- Merge your pull request once approved.
- Celebrate your success after your pull request is merged!
All submissions, including submissions by project members, require review.
Score uses GitHub pull requests for this purpose.
The general workflow for code contributions:
- Submit/find an issue in this repository.
- Clone the relevant repo.
- Make your code change.
- Write tests and update docs.
- Build and test locally.
- Submit a pull request.
- Iterate as needed.
- Your PR will be approved and merged.
If you need help, you can create an issue.
A good bug report shouldn't leave others needing to chase you up for more information. Therefore, we ask you to investigate carefully, collect information and describe the issue in detail in your report. Please complete the following steps in advance to help us fix any potential bug as fast as possible.
- Make sure that you are using the latest version.
- Determine if your bug is really a bug and not an error on your side for example using incompatible environment components/versions (Make sure that you have read the documentation. If you are looking for support.
- To see if other users have experienced (and potentially already solved) the same issue you are having, check if there is not already a bug report existing for your bug.
- Also make sure to search the internet (including Stack Overflow) to see if users outside the GitHub community have discussed the issue.
- Collect information about the bug:
- Stack trace (Traceback).
- OS, Platform and Version (Windows, Linux, macOS, x86, ARM).
- Version of the interpreter, compiler, SDK, runtime environment, package manager, depending on what seems relevant.
- Possibly your input and the output.
- Can you reliably reproduce the issue?
Our Code of Conduct means that you are responsible for treating everyone on the project with respect and courtesy, regardless of their identity. If you are the victim of any inappropriate behavior or comments as described in our Code of Conduct, we are here for you and will do the best to ensure that the abuser is reprimanded appropriately, per our code.
For information on our community guidelines, see CONTRIBUTING.md.