Feat: Potential ambiguity evaluating criteria. Proposal for expanding acceptance syntax

[janhalen]

Ambiguity:

When a report is left with som unchecked points in the table, there is a possibility of ambiguity. It can be interpreted as both "this criteria is not relevant for this product", "this is not yet evaluated" or "the product does NOT meet this requirement" og maybe there is some doubt when trying to evaluate the criteria against the actual product.

Proposal:

To make it 100% clear i suggest we expand the possible syntax. As we currently use GitHub as our Git Web portal, I have based the solution GitHub flavoured markdown, this can be a potential risk if this version of the template is to be moved and evaluated else where the emojis used are not available or are not rendered.

This solution also solves the existing challenge of rendering checkmarks in MarkDown tables, as the emojis render perfectly as opposed to a "- [ ]" syntax that does not render inside of a Markdown table. Refer to this gist

I propose we adapt the following syntax:

When the box is left empty - The criteria has not been evaluated ✅ - The criteria is fullfilled
❌ - The criteria is NOT fulfilled ➖ - The criteria is not relevant for this product ❓ - There is doubt on how to evaluate this criteria

[janhalen]

@zorp: Any comments, before test implementation?

[janhalen]

Discusion: What markdown features are avaliable cross platform ?

Remove the TIP if github is the only place it is rendered.