Thank you for investing your time in contributing to our project!
This project and everyone participating in it follows our Code of Conduct (found at the root of this repository). By participating, you are also expected to uphold its standards and are subject to its enforcement guidelines.
You agree that your contributions will be licensed under the MIT License by contributing.
We use GitHub issues associated with each project to track the work related to that project. Check the issue comments/labels to see whether someone else has indicated that they are working on it. If the issue has been assigned, it is not available to pick up.
All code or documentation contributions should be associated with an open issue. If an issue does not exist for the area you wish to work on, one should be created first.
Check if the bug report, feature or documentation contribution does not already have an open issue. If not, a new issue can be created using the linked issue template here. The issue will automatically populate with the template text.
The issue should describe the new feature request and why it is needed for a new feature request. For bug reports, please provide as much information as possible so that the others can reproduce it.
The issue should then be approved by the team and assigned labels before assigning a member to work on it.
The labels available for issues fall under four categories: priority, status,type and team. All issues must have one of each category at all times, except for the team label if the issue is more general. The team working on the relevant issue should decide the priority label. During development, please update the issue as required. For example, if the issue is blocked, then update the description with a link to the issue blocking it. For more information about issue labelling see the following wiki page Issue Labels on the front end repo.
This project uses the fork and pull workflow. For more details see this video.
- Fork and clone the main project repository
- Create a new branch off main when starting work on a new issue.
- Commit your changes in the feature branch in your local clone.
- Update your local repository with the most recent code from the main repository. Remember to rebase often
- Test your changes (if applicable) – run all existing and new tests, and make sure the application works as expected.
- Create a pull request. (See below sections for a template)
- Another team member must review and approve the pull request.
- Merge your changes
Pull requests should be created to merge all changes. The pull request form should auto fill with the template PR file. Other team members will review the proposed code and suggest changes as required. Discussions about the code should be kept to the relevant issue/PR so that all team members can see and benefit from it.
Team members in the relevant sub-team will review the code submitted for PR. Team members will review code for readability, style, bugs, test coverage and completion of acceptance criteria. The reviewers should also ensure that the application works as expected. All previous tests pass, and new features have associated unit tests.
All code should be formatted using ESLint and Prettier in the front-end repository to ensure consistency in the project. Commit message names should be descriptive. There is currently no strict convention for branch naming. Still, it is recommended that the branch name is meaningful and descriptive.
Different contributors own the different parts of the project. The owners of each sub-team should review PRs related to their area of the project.