Add project quality checklist

[tompluess]

This PR is a proposal of how we could implement quality assurance in our projects.

any alternative proposals are welcome!

[lukaseppler]

Suggesting to put this in a doc folder instead of root.

[tompluess]

Suggesting to put this in a doc folder instead of root.

👍 done.

[crackofdusk]

In my mind this is not something you copy to every project.

The workflow I imagine is you do some of these things during the initial setup (static analysis, deployment, monitoring, moco, trello, server access, backups). The rest comes later one (tests, documentation), but you check at certain milestones if the project adheres to the original/single source of the checklist.

For example, I would expect that there is a ticket in the backlog about going through the checklist and adding missing documentation.

[tompluess]

In my mind this is not something you copy to every project.

The workflow I imagine is you do some of these things during the initial setup (static analysis, deployment, monitoring, moco, trello, server access, backups). The rest comes later one (tests, documentation), but you check at certain milestones if the project adheres to the original/single source of the checklist.

For example, I would expect that there is a ticket in the backlog about going through the checklist and adding missing documentation.

I agree that there should be tasks in the backlog about doing the items on the checklist.

If we do not have the checklist itself under source control, how would we then see on one sight where we are regarding our expected quality tasks, and especially what's missing?

[crackofdusk]

If we do not have the checklist itself under source control, how would we then see on one sight where we are regarding our expected quality tasks, and especially what's missing?

The idea would be to go through all items again and check whether they are up-to-date (maybe the charta checklist changed in the meantime?)

Furthermore, the outcome of many items is a sentence or a section in the readme. A well-written and well-structured readme will provide you a quick overview by means of its form.

For example, in the current pull request, instead of adding a copy of the checklist, I would add the following to the readme:

• a link to the semaphore pipeline page at the top;
• a "Deployment" section which explains that staging is automatically deployed and where that is configured (.semaphore/semaphore.yml) in case one wants to, say, make that a manual step or add a new environment.

This way, next time I go over the checklist in the charta, I can easily see there is a deployment pipeline and check on it.