Automate creation of standards overview pages

[mbuechse]

resolves #97

[mbuechse]

Preview: https://docs-staging.scs.community/standards/standards/overview/

[fkr]

One thing that comes immediately to mind: the colors are not explained.
Am far from having a clue about how visually-impaired people would see this page, but I think, if we color-code the status of the standard in the overview table, this should also be apparent to visually-impaired people.

[maxwolfs]

Great!

Regarding the Colors:

One thing that comes immediately to mind: the colors are not explained. Am far from having a clue about how visually-impaired people would see this page, but I think, if we color-code the status of the standard in the overview table, this should also be apparent to visually-impaired people.

good point! I was unsure during drafting this and now I also have a better proposal. We could add the Icons for Draft, Merged and Draft and still use the color codings:

[fkr]

Excellent suggestion @maxwolfs

[mbuechse]

Once SovereignCloudStack/standards#388 is merged, I can remove all the md files under standards/. 🎉

[mbuechse]

I changed the emojis. Still not perfect, but no longer color-coded, and probably not too hard to figure out (and we can always add a legend/key to the symbols):

[mbuechse]

Added a first draft of generated scope overview:

[mbuechse]

Rebuilt because v2 has turned obsolete last night. We should do nightly builds...

[anjastrunk]

Suggested change

	- infastructure as a service (IaaS)
	- Infastructure as a Service (IaaS)

[mbuechse]

I don't want to capitalize the word service, because it's just a regular word. Wikipedia agrees: https://en.wikipedia.org/wiki/As_a_service

[anjastrunk]

Suggested change

	- Kubernetes as a service (KaaS)
	- Kubernetes as a Service (KaaS)

[anjastrunk]

In Scopes and versions, three state of standards are called draft, stable and deprecated.
In SCS Compatible IaaS, the same three states are called obsolete, effective, and preview. The same applies all tables under "Standards".

To avoid any confusion, we should be consisted and I prefer draft, stable and deprecated

[anjastrunk]

See my comments

[maxwolfs]

When I try to run everything in a newly clone repo locally with npm install the .gitignore lines 16, 28 and 29 are somehow not working. All generated files are tracked. Any idea?

[mbuechse]

In Scopes and versions, three state of standards are called draft, stable and deprecated. In SCS Compatible IaaS, the same three states are called obsolete, effective, and preview. The same applies all tables under "Standards".

To avoid any confusion, we should be consisted and I prefer draft, stable and deprecated

This is a real problem. I think we should distinguish between two concepts:

• the editorial state of the version: this can be draft, stable, or deprecated.
• the effectiveness of the version given the current date: this can be preview, effective, obsolete (better words welcome).

For example, the version can be deprecated with a deprecation date in the future, and then the version is still effective. Marking it deprecated in this table would be misleading from my POV.

[mbuechse]

If we want to merge the two concepts, we obtain five states, I think:

• preview (ineffective and draft)
• soon-to-be-effective (ineffective and stable)
• effective (effective and stable)
• soon-to-be-obsolete (effective and deprecated)
• obsolete (ineffective and deprecated)

Again: better words welcome!

[mbuechse]

Sorry, I made a mistake. The situation that I described does not apply to certification scope versions, but to individual standards. There we have a field status that can be Proposal, Draft, Stable, Deprecated, or Rejected, together with fields for stabilized_on and deprecated_on. For scope versions, no such status field exists, so there is no such editorial status.

[mbuechse]

Still, with certificate scope versions, even without any explicit status field, we have the following:

• no stabilized_on --> preview
• stabilized_on in the future --> soon-to-be-effective
• stabilized_on not in the future and deprecated_on not present --> effective
• stabilized_on not in the future and deprecated_on in the future --> soon-to-be-obsolete
• stabilized_on not in the future and deprecated_on not in the future --> obsolete

[mbuechse]

When I try to run everything in a newly clone repo locally with npm install the .gitignore lines 16, 28 and 29 are somehow not working. All generated files are tracked. Any idea?

I fixed it. The lines were not sufficient.

[maxwolfs]

LGTM, Great work! From my POV the status messages fit now.

I have noted the optimisation possibilities of collecting content from same repos in the package.json and splitting the track intro content from the code. But IMO nice-to-haves that do not block this from being merged.