feat(#1029): Add repository checklist (#1030)

Co-authored-by: Gareth Bowen <gareth@medic.org>
Co-authored-by: Ashley <8253488+mrjones-plip@users.noreply.github.com>

content/en/contribute/code/repository-checklist.md

@@ -0,0 +1,66 @@
+---
+title: "CHT Product Repository Checklist"
+linkTitle: "CHT Product Repository Checklist"
+weight: 5
+description: >
+  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](https://github.com/medic), the contributor(s) should use the [cht-repo-template](https://github.com/medic/cht-repo-template) repository containing the following configurations:
+
+### Source Control
+- [ ] The `main` branch is locked via [branch protection rules](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule).
+- [ ] Merges are done through PRs.
+- [ ] Automatically delete head branches.
+- [ ] Issue templates exist.
+- [ ] PR template exists.
+- [ ] PRs reference related issues.
+- [ ] Commit formats follow the [guidelines]({{< ref "workflow/#commits" >}}). 
+- [ ] Secrets are not part of the commit history or made public.
+- [ ] The following files exist:
+    - `LICENSE` specifying AGPL-3.0 ([example](https://github.com/medic/cht-core/blob/master/LICENSE))
+    - `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](https://github.com/medic/eslint-config) 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.
+
+### 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.
+
+## More info
+
+This policy was inspired by [Microsoft's Engineering Fundamentals Checklist](https://microsoft.github.io/code-with-engineering-playbook/ENG-FUNDAMENTALS-CHECKLIST/).