repo documentation guidelines

Purpose

To ensure that this repo sets an example for a well maintained and supported product, that is user centric and self service orientated.

Guidelines

Repo Setup

1. Does the readme include a section for how to collaborate with the team? This could be a link to the Rocketchat channel or something like that. It should be more that just a code of conduct file or a contributing guidelines file, which leave the only means of connecting with the team to be through PR comments.
2. Does the repo documentation include info that written for people who are not on the development team? e.g. A description of the Product Vision or some high level description of the purpose of the repo, or some benefits it can provide.
3. Is the Wiki enabled? if the only documentation that is on the repo is the versioned files, then there will be a barrier for the product owners and scrum masters to contribute information and general lessons learned information in the transparent Github location. The wiki helps to avoid having good documentation end up hidden on a private documentation site like confluence.
4. Has the Project Features been enabled to show the public what is being worked on at that moment? (Yes)
5. Has a repo lifecycle badge and have search tags been implemented, so that we are sending a message that want people to find the repo, and we want them to know about the state that the repo is at for them to be able to use it?

Repo Health

1. Are reusable components identified? Does it explain how to use them?
2. Are learnings being documented in the wiki? So other don't make the same mistakes
3. Are there github issues being add and closed? (yes) this shows to the community that collaboration is happening and issues are being acted upon
4. Are additional repo badges present showing code health (Testing Status, Code Analysis grades, code coverage, licence)
5. Is a community of developers starting to form around the product, i.e. multiple developers committing to the code? (yes)