CHT Product Repository Checklist
Repository Creation Checklist
When creating a new CHT Product repository under Medic’s GitHub organization, the contributor(s) should use the cht-repo-template repository containing the following configurations:
mainbranch is locked via branch protection rules.
- Merges are done through PRs.
- Automatically delete head branches.
- Issue templates exist.
- PR template exists.
- PRs reference related issues.
- Commit formats follow the guidelines.
- Secrets are not part of the commit history or made public.
- The following files exist:
LICENSEspecifying AGPL-3.0 (example)
mainbranch is always shippable.
- The PR template contains a code review checklist.
- A reviewer for a PR merge is enforced by policy.
- A linter is set up.
The PR and issue template content can be adjusted according to the product’s purpose.
Additionally, the person who creates the repository might need to share repository access with appropriate teams (this may require admin access).
Items to consider when developing the CHT Product
To ensure quality, the CHT Products should also follow the guidelines below:
- Repository runs GitHub Actions CI with automated build and test on each PR.
- Unit tests and successful builds for PR merges are set up.
- Unit tests cover the majority of the code.
- If applicable, integration tests run to test the solution e2e.
- Application faults and errors are logged.
- Logging configuration can be modified without code changes (eg: verbose mode).
Medic GitHub repository FAQ
Q: Who can create a repository?
A: Anyone under Medic GitHub organization.
Q: Is it OK to create a CHT/Medic-related work repository under a personal GitHub account?
A: If what you are working on is temporary and just for you then it is fine to create a repository under your personal account (it is the equivalent of having a script on your local machine), as long as it contains an Open-Source Software License. However, default to the Medic account so the other team members can collaborate on it.
Q: When to make a repo public vs private?
A: Repositories should be public unless there is very good reason to make it private (e.g. the repository contains partner details that cannot be disclosed to public). Always keep in mind that it is much easier to start public than change to public later.
Q: When to create a new repository vs adding a directory in existing (monolithic)?
A: It depends on the nature of the code. Some things to consider are: is the new code and the old code dependant, don’t make sense on their own, must be versioned together, etc. If not, default to a new repo to reduce complexity.
This policy was inspired by Microsoft’s Engineering Fundamentals Checklist.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.