CHT Product Repository Checklist

Checklist to consider when creating CHT Product repositories under Medic’s GitHub organization account

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:

Source Control

The main branch 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:
- LICENSE specifying AGPL-3.0 (example)
- README.md.
main branch is always shippable.

Code Reviews

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:

CI/CD

Repository runs GitHub Actions CI with automated build and test on each PR.

Testing

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.

Observability

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.

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 dependent, don’t make sense on their own, must be versioned together, etc. If not, default to a new repo to reduce complexity.