Contribution Guideline
- Serm Kulvatunyou
- athanasios.dimitriadis
This document guides you through the process of contributing to Score. It is assumed that you have a basic understanding of GitHub.
Quick links
Below are some useful links you should also consider during your contribution to Score:
Code of Conduct
Contributor License Agreement (CLA)
Developer’s Guide
Pull Requests
Report a bug
Propose a feature
How to become a contributor
Contributor License Agreements
Before sending your pull requests, please fill out either the individual or corporate Contributor License Agreement (CLA).
If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an individual CLA.
If you work for a company that wants to allow you to contribute your work, then you'll need to sign a corporate CLA.
Follow either of the two links above to access the appropriate CLA and instructions for how to sign and return it. Once we receive it, we'll be able to accept your pull requests. The other option is to sign and include your CLA in your pull request.
NOTE: Only original source code from you and other people that have signed the CLA can be accepted into the main repository.
Contributing code
If you have improvements to Score’s code which is related to features or bugs, send us your pull request. All contributions should be connected to an existing issue or feature.
If you want to contribute to an existing issue, visit the "issues" tab and start looking through interesting issues. If you are not sure of where to start, then start by trying one of the smaller/easier issues here i.e., issues with the "good first issue" label and then take a look at the issues with the "contributions welcome" label. These are issues that we believe are particularly well suited for outside contributions, often because we probably won't get to them right now. If you decide to start on an issue, make sure that no one is currently working on the issue and leave a comment so that other people know that you're working on it.
If you want to contribute to a feature, visit the "issues" tab and check if it already exists. You can find proposed features as issues with the label “enhancement”. To start working on this feature, make sure that no one is currently working on the feature and leave a comment under it so that other people know that you're working on it.
Should you have any new bug to report or feature to propose, see Report a bug and Propose a feature accordingly.
Contribution guidelines and standards
Before sending your pull request for review, make sure your changes are consistent with the following guidelines.
General guidelines
As every pull request requires testing, we discourage submitting pull requests for minor fixes such as one typo, one warning, etc. We recommend fixing the same issue at the file level at least (e.g.: fix all typos in a file, fix all compiler warning in a file, etc.). Please make sure that you always keep a single commit in each branch.
Since we use and test Score via Google Chrome, please ensure that your contribution is rendered well in this browser.
For more information about how to submit a pull request, see the Pull Requests section.
License
In short, when you submit code changes, your submissions are understood to be under the same MIT License that covers the project. Our copyright statement with a reference to the MIT license should be included at the top of new files.
//we need to verify what the statement should look like because we have this “copyright reserved” and in our License as well “Copyright (c) 2019 The Open Applications Group Inc. “//
Coding style
Changes to Score code should conform to the following coding styles:
Pull Requests for Code
Once you are completed with your code, submit a Pull Request so it can be reviewed. Score team members will be assigned to review your pull requests. You may be contacted if any further clarification is needed.
Once the pull requests are approved and pass continuous integration checks, your pull request will be merged on Score’s GitHub.
Score team may decide to not accept your pull request if they realize that it is not align with the project's goals or it contain suspicious code. This will be handled on a case-by-case basis.
Please consider the following recommendations for each pull request:
· Branch: Fork Score’s GitHub repository and create your branch from main branch. Afterward, create a new branch and start working on your branch only so each pull request should contain a new branch for each issue or feature.
· Description: Please include a detailed description in your pull request. You may want to add screenshots or any other information you want to communicate to Score team.
· Tag the issue: Add a tag in the form #[issue_number] to refer to the issue that the pull request is related to. This tag should be included in every commit. Tagging ensures that the main branch is in releasable state and changes can be reverted easily.
· Include author/s: You can include the author/s of the pull request. Authors can be also included when you commit the code.
· Checking: Click the Preview tab before submitting the pull request in order to ensure that everything is correctly rendered. If not, go back to the editing view and make the necessary changes.
Report a bug
Score team members use GitHub issues to track public bugs. You can find existing bugs as issues with label “bug” in the GitHub issues tab. Before reporting a bug, please ensure that the bug has not been reported yet.
To report a new bug, create a new issue and label it as “bug”. The name of the bug should be descriptive and concise while its description should be in the following format.
A quick summary and/or background
User role (e.g., developer or end user)
Steps to reproduce the bug. Please provide detailed steps for a Score team member to recreate the bug. If it is a server related bug (e.g., 500 error/exception), it is very helpful to provide the stack trace as well.
What actually happens
What should happen (i.e., expected behavior)
Notes (optional)
Screenshot/Video (optional)
Propose a feature
· Make a pull request first for the feature (i.e., Test Cases and Test Assertion for the feature)
· Approve pull request for the feature
· Then start coding
· Pull request for the code including unit tests, and Selenium tests
Features are issues label as “enhancement”. Features can be completely new functionalities or minor improvements to existing functionalities.
You can find existing proposed featured in the GitHub issues tab. Before proposing a new feature, please ensure that it has not been proposed yet. In case it has been already proposed and you want to propose some enhancements on that feature, please leave a comment and
The name of the feature should be descriptive and concise while its description should contain the following information.
A quick summary and/or background
A step-by-step description of the proposed feature in as many details as possible. This will allow contributors to understand the expected behavior of the feature.
An explanation why this feature would be useful
Contact me or not?
Mockups (optional)