Certification status in compliance overview#1241
Conversation
Signed-off-by: Marvin Frommhold <depressiveRobot@users.noreply.github.com>
depressiveRobot
added
the
documentation
| Version numbers are suffixed by a symbol depending on state: * for _draft_, † for _warn_ (soon to be deprecated), and †† for _deprecated_. | ||
| The following environments are regularly checked for SCS compliance. | ||
|
|
||
| Officially certified environments are marked with an X in the “Certified” column and are linked to the respective certification status page. |
There was a problem hiding this comment.
I'd very much prefer to see them in their own table, or at least to group the rows.
There was a problem hiding this comment.
Not sure about this, we already have 2 tables on there.
There was a problem hiding this comment.
This was my thought too. A further separation would mean four different tables. And with more certifications (e.g. Paas), it would be six or more tables. That's why I decided on a column.
There was a problem hiding this comment.
From my POV, there is a very clear qualitative difference between those offerings that are certified and those that we merely watch for the fun of it.
There are so many options here:
- keep each table mixed, but at least group the rows (as I already proposed)
- move non-certified entries to an entirely separate page
- put all layers into one table (again with rows grouped), and then make separate tables for certified vs. fun
To me, each of these options appears more favorable than what is currently in this PR.
There was a problem hiding this comment.
I agree here with @mbuechse with one aspect: I think we don't yet make it clear enough what the difference is. What is even the use case of being in the compliance monitor, and why is that not the same thing as being certified? That's something we have to explain for people having no knowledge of SCS.
Different tables can support this by giving us the chance to introduce the respective next table with 1-2 sentences.
We can potentially also achieve that in a different way, so I'm not gonna veto the idea of keeping 2 tables.
I just vote for making the difference between certification and no certification clearer.
There was a problem hiding this comment.
Putting the non-certified environments on a separate page would be logical, because this page is embedded into the docs page under the heading "Certification" (and the subheading "Compliant cloud environments" that is put to shame by the red entries underneath)
There was a problem hiding this comment.
I think with sub-headings it would be a good compromise. E.g. certified first, "not certified but still checked" second
There was a problem hiding this comment.
I have implemented multiple tables now with more explanations, see e51d043
| {#- #} [{{ results | pick(kaas, 'group-scaleup') | summary }}]({{ detail_url('group-scaleup', kaas) }}) {# -#} | ||
| | | ||
| | [Syself Autopilot](https://syself.com/platform) | KaaS offering based on ClusterStacks | Syself GmbH | {# #} | ||
| | [Syself Autopilot](https://syself.com/platform) | KaaS offering based on ClusterStacks (1 SCS configuration) | Syself GmbH | [X](https://sovereigncloudstack.org/en/certified-solution/syself-gmbh/) |
There was a problem hiding this comment.
This is a redirect to the Syself page, whereas the corresponding URL for Scaleup is not a redirect, but a page on sovereigncloudstack.org. I find this a bit confusing.
I think the 'touch target' is a bit small for a link that is just labelled "X". I would prefer to put this link on the name in the first column.
There was a problem hiding this comment.
I "fixed" the touch target by using the "name" column to link to the official certification status pages.
For Syself there is currently no official certification status page. That's why it's redirecting. However, the link is valid. The same applies for REGIO.cloud. The status pages will be fixed on sovereigncloudstack.org soon.
| -#} | ||
|
|
||
| Version numbers are suffixed by a symbol depending on state: * for _draft_, † for _warn_ (soon to be deprecated), and †† for _deprecated_. | ||
| The following environments are regularly checked for SCS compliance. |
There was a problem hiding this comment.
This is most probably true. What's stated further below, under each subheading, is most probably false: "This is a list of [...] clouds that we test on a nightly basis".
There was a problem hiding this comment.
I have changed the explanations accordingly.
Signed-off-by: Marvin Frommhold <depressiveRobot@users.noreply.github.com>
Signed-off-by: Marvin Frommhold <depressiveRobot@users.noreply.github.com>
|
I agree, a separate page would be logical. However, it would hamper the findability of compliant environments. Additionally, having all compliant environments on a single page reflects a higher adoption rate, which I think supports the public image of SCS. That's why I've now implemented multiple tables in e51d043, which as mentioned before allows us to provide more fine-granular explanations per table. With the additional explanations, the difference between certified and non-certified environments should now be much clearer. |
Signed-off-by: Marvin Frommhold <depressiveRobot@users.noreply.github.com>
Signed-off-by: Marvin Frommhold <depressiveRobot@users.noreply.github.com>
|
This is how it looks now: 
|
4 participants
This PR adds a new column "Certified" with a short explanation to the compliant cloud environments overview (aka Compliance Monitor). If an environment is certified, it is also linked to the respective certification status page.
This was discussed in the last Forum SCS-Standards call.
Please (auto)merge if successfully reviewed.