Thank you for taking the time to contribute! Together, we will create something amazing.
Before contributing, be sure to read through the code of conduct for contribution
In the interest of fostering an open and welcoming community, we encourage all people to contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests, and participating in other activities.
Help on Test Automation is always welcome and there is always something that can be improved. For example, documentation (like the text you are reading now) can always use improvement, code can always be clarified, variables or functions can always be renamed or commented on, and there is always a need for more test coverage. If you see something that you think should be fixed, take ownership! Here is how you get started:
To start working on code, please refer to the GitHub Workflow.
When contributing, always start with issues. After picking up an issue, writing code, or updating a document, your work will be reviewed and merged. For more information, check out the following document: Types of Issue and Issue States.
Pull requests are often simply referred to as "PR". In general, we follow the standard github pull request process.
The project team will provide structured labels to your PR, which need to be updated based on your PR status. Look to the below table for guidance. For Pull Request Labels, click here.
Before sending pull requests, make sure your changes have passed all tests.
There are two aspects of code review: giving and receiving.
It will be easier for your pull request to receive reviews if you consider the criteria the reviewers follow while working. Remember to:
- Follow the project coding conventions
- Write detailed commit messages
- Break large changes into a logical series of smaller patches, which are easy to understand individually and combine to solve a broader issue
- Label PRs with appropriate pull request labels to indicate status for maintainers
Note: if your pull request isn't getting enough attention, you can contact the maintainer to find a reviewer
Testing is the responsibility of all contributors.
Issue and pull request labels
This section lists the labels we use to help us track and manage issues and pull requests.
GitHub search makes it easy to use labels for finding groups of issues or pull requests you're interested in.
If you have suggestions for new labels, please open an issue on the project source code repository. If you notice a missing label on a repository, then please open an issue on that repository.
| Label name | View Issues in Repository 🔎 | Description |
| --- | --- | --- | --- |
| bug | view | Confirmed bugs or reports that are very likely to be bugs |
| enhancement | view | Feature requests |
| help-wanted | view | The project core team would appreciate help from the community in resolving these issues |
| wontfix | view | The project core team has decided not to fix these issues for now, either because they're working as intended or for some other reason |
| invalid | view | Invalid Issues (e.g. user errors) |
| Label name | View Issues in Repository 🔎 | Description |
| --- | --- | --- | --- |
| work-in-progress | view | Pull requests that are in progress, more changes will follow |
| needs-review | view | Pull requests that need code review and approval from maintainers |
| under-review | view |Pull requests being reviewed by maintainers |
| requires-changes | view | Pull requests that need to be updated based on review comments and then reviewed again |
| needs-testing | view | Pull requests that need manual testing |