Restructure directories (SovereignCloudStack#2)

* restructure directories

Signed-off-by: maxwolfs <[email protected]>

* fix links

Signed-off-by: maxwolfs <[email protected]>

* add empty folders to provide conceptual structure

Signed-off-by: maxwolfs <[email protected]>

Signed-off-by: maxwolfs <[email protected]>

GLOSSARY.md

@@ -135,4 +135,3 @@ A Ceph OSD (Object Storage Daemon) logically represents a storage device in a Ce
 |SCS Integrator|The SCS Integrator assists in or is building up a standardized cloud environment. The SCS Integrator can be 2nd or 3rd level support for the SCS Operator.|
 |SCS Project|The SCS Project oversees the overall activities around the Sovereign Cloud Stack.|
 |SCS Developer|The SCS Developer actively contributes to technical elements of the Sovereign Cloud Stack.|
-

README.md

@@ -2,29 +2,21 @@
 
 [![Creative Commons Attribution-ShareAlike 4.0 International](https://licensebuttons.net/l/by-sa/4.0/88x31.png)](http://creativecommons.org/licenses/by-sa/4.0/)
 
-> :warning: The /Docs repository has been split up into:
->
-> 1. [standards](https://github.com/SovereignCloudStack/standards) repository – containing ADRs and related files.
-> 2. [release-notes](https://github.com/SovereignCloudStack/release-notes) repository – containing only SCS Release Notes.
-> 3. This [docs](https://github.com/SovereignCloudStack/docs) repository – containing the entry point for documentation to SCS.
->
-> The [docs](https://github.com/SovereignCloudStack/docs) and [release-notes](https://github.com/SovereignCloudStack/release-notes) are also part of the SCS rendered documentation page [Documentation Page](https://docs.scs.community/) which is built from [docs-page](https://github.com/SovereignCloudStack/docs-page) source
-
-# What is SCS? Why should I care?
+## What is SCS? Why should I care?
 
 Please see our [public web site](https://scs.community/) and specifically
-the [About SCS](https://scs.community/About/) page.
+the [About SCS](https://scs.community/About/) page and our [documentation page](https://docs.scs.community/).
 SCS describes a standard as well as a reference implementation of this standard.
 
-# The reference implementation
+## The reference implementation
 
-## Get it and test it: Testbed
+### Get it and test it: Testbed
 
 The easiest way to get in touch with SCS is to deploy a SCS cloud virtually.
 
 This means that you set up a SCS test installation including all the infrastructure
 pieces such as database, message queueing, ceph, monitoring and logging, IAM, the
-[OpenStack](https://openstack.org/) core services, and (soon) the Container layer 
+[OpenStack](https://openstack.org/) core services, and (soon) the Container layer
 on top of an existing
 IaaS platform. Currently, only OpenStack is supported as IaaS under the SCS cloud
 (so you end up using OpenStack on top of OpenStack -- with nested virtualization
@@ -45,65 +37,65 @@ You can easily deploy the container layer on top of the testbed (or a production
 SCS cloud of course) checking out the code from
 [k8s-cluster-api-provider](https://github.com/SovereignCloudStack/k8s-cluster-api-provider/).
 
-# Existing SCS Clouds
+## Existing SCS Clouds
 
 A few production clouds are already based on SCS: betacloud and pluscloud open.
 More will come soon.
 
 The SCS Community partners (PlusServer, Wavecon, etc.) are providing pro-bono
 resources to further the development of the Project. The resources provided can
-be found [here](Contributor-Docs/partners/cloud-resources.md).
+be found [here](community/contribute/cloud-resources/cloud-resources.md).
 
 CityNetwork, Open Telekom Cloud, OVH clouds are also known to support the
 testbed well. (There are a few caveats with the latter two, but those are
-documented and no blockers.) Read above mentioned 
+documented and no blockers.) Read above mentioned
 [Requirements:Cloud access](https://docs.osism.de/testbed/deployment.html#cloud-access)
 subsections.
 
-# Development of SCS
+## Development of SCS
 
 The work done in SCS is supposed to be fed back upstream -- into the relevant
 CNCF projects, into OpenStack, into kolla-ansible, into OSISM and others.
 An OSISM deployment thus will bring you all the SCS greatness in the base
 layer.
 Whenever possible SCS works directly in the upstream projects. While the SCS
-projects tracks the efforts across the released in [epics and userstories](https://github.com/orgs/SovereignCloudStack/projects),
+projects tracks the efforts across the released in [epics and userstories](https://github.com/orgs/SovereignCloudStack/projects/6),
 the work on the code happens upstream - as such these repositories are usually
 not found in the SCS namespace.
 
-# Releases and Roadmap
+## Releases and Roadmap
 
-## Release 0 (2021-07-15)
+### Release 0 (2021-07-15)
 
 SCS R0 has been released on 2021-07-15 and bundles the work
 accomplished by the community prior to the full start of the project.
 
-See [Release Notes for R0](Release-Notes/Release0.md) for more information.
+See [Release Notes for R0](https://github.com/SovereignCloudStack/release-notes/blob/main/Release0.md) for more information.
 
-## Release 1 (2021-09-29)
+### Release 1 (2021-09-29)
 
 R1 came quickly after R0 and was the first release to ship a production ready k8s stack
 (with k8s cluster API), some identity federation integration and much improved
 preconfiguration for monitoring and logging.
 
-See [Release Notes for R1](Release-Notes/Release1.md) for more information.
+See [Release Notes for R1](https://github.com/SovereignCloudStack/release-notes/blob/main/Release1.md) for more information.
 
-## Release 2 (2022-03-23)
+### Release 2 (2022-03-23)
 
 This release delivers vast improvements for bare metal automation
 and the features in the container layers.
 
-See [Release Notes for R2](Release-Notes/Release2.md) for more information.
+See [Release Notes for R2](https://github.com/SovereignCloudStack/release-notes/blob/main/Release2.md) for more information.
 
-## Release 3 (2022-09-21)
+### Release 3 (2022-09-21)
 
 Release 3 features user federation, increase in deployment and upgrade
 velocity by improving automated test coverage as well as bringing disk encryption
 based on tang from the state of a technical preview to be fully supported.
 
-See [Release Notes for R3](Release-Notes/Release3.md) for more information.
+See [Release Notes for R3](https://github.com/SovereignCloudStack/release-notes/blob/main/Release3.md) for more information.
 
-## Roadmap
+### Roadmap
 
 We have a 6 month release cadence -- R4 will follow in March 2023.
 Until then, we will provide bugfixes and security fixes for R3.
@@ -112,15 +104,15 @@ We do work towards a model where our partners can actually follow our main
 development branches -- right now, our CI needs a bit more coverage though
 to make this safe.
 
-# Contribute and Connect
+## Contribute and Connect
 
 Please see the [SCS contributor guide](https://scs.community/docs/contributor/).
 
-# Standards, Conformity and Certification
+## Standards, Conformity and Certification
 
 We intend to work on a conformity test suite.
 
-Right now, we are basically relying on upstream tests -- 
+Right now, we are basically relying on upstream tests --
 [RefStack](https://refstack.openstack.org/) (to perform
 the [OpenStack trademark certification](https://refstack.openstack.org/#/guidelines)
 tests formerly known as DefCore) and the Kubernetes CNCF conformance tests run through
@@ -129,16 +121,16 @@ tests formerly known as DefCore) and the Kubernetes CNCF conformance tests run t
 We have two specific standards aligned within the SCS community (and have also
 sought feedback from the broader Gaia-X and OpenStack communities):
 
-* [SCS Flavor naming and standard flavors standard](Design-Docs/flavor-naming.md)
+- [SCS Flavor naming and standard flavors standard](https://github.com/SovereignCloudStack/standards/blob/main/Design-Docs/flavor-naming.md)
 
-* [SCS Image naming and metadata standard](Design-Docs/Image-Properties-Spec.md)
+- [SCS Image naming and metadata standard](https://github.com/SovereignCloudStack/standards/blob/main/Design-Docs/Image-Properties-Spec.md)
 
-Beyond this, we have a [draft document](Design-Docs/SCS-Spec.md) that captures our
+Beyond this, we have a [draft document](https://github.com/SovereignCloudStack/standards/blob/main/Design-Docs/SCS-Spec.md) that captures our
 view on how SCS compatible environments should look like. This one has not yet
 seen sufficient review to be eligible for standardization. However, we appreciate
 feedback (raise issues and PRs or start discussions).
 
-# Issues and bugs
+## Issues and bugs
 
 Please raise issues on github. If you can identify the affected component,
 raise the issue against the relevant repository in the SovereignCloudStack
@@ -150,22 +142,21 @@ please don't forget to sign off your contributions (see
 
 When reporting bugs, it is very useful to include some standard information
 typically needed to analyze:
-* What state of software (SCS) were you testing? What version numbers ... ?
-* How does your environment look like (hardware, operating systems, etc.)?
-* What did you do?
-* What did you expect? What happened instead?
-* Have you done this successfully before? What changed?
-* Can this be reproduced? Occasionally? Reliably? How?
-* Any analysis you have done? Experiments and their results? Log files?
 
+- What state of software (SCS) were you testing? What version numbers ... ?
+- How does your environment look like (hardware, operating systems, etc.)?
+- What did you do?
+- What did you expect? What happened instead?
+- Have you done this successfully before? What changed?
+- Can this be reproduced? Occasionally? Reliably? How?
+- Any analysis you have done? Experiments and their results? Log files?
 
-# Other resources
+## Other resources
 
 Please check our main [web page](https://scs.community/).
 If you are an onboarded SCS community member, find here a link to our
 [nextcloud](https://scs.sovereignit.de/) (login required).
 
 Our community interacts through our [github organization](https://github.com/sovereignCloudStack/),
 on [mailing lists](https://scs.sovereignit.de/mailman3/postorius/lists/) as well as
-chats [matrix.org:SCS](#scs-general:matrix.org).
-
+chats [matrix.org:SCS](scs-general:matrix.org).

contribute/README.md → community/contribute/README.md

@@ -26,13 +26,3 @@ Entrypoint for getting onboarded.
 - Guides
   - [GitHub](https://github.com/SovereignCloudStack)
   - [Contributor Guide](https://scs.community/docs/contributor/)
-
-### ToDo's
-
-Based on the discussion within https://github.com/SovereignCloudStack/Docs/pull/58.
-
-- [ ] establish a Community Board and discuss proposals on a montly basis
-- [ ] find a tool (Jekyll framework maybe) to deliver the Docs repo as a website
-- [ ] discuss the meaningfullness of an onboarding channel in the desired instant messaging tool
-- [ ] Having a single URL for all services?
-

contribute/collaboration.md → community/contribute/collaboration.md

@@ -72,22 +72,21 @@ use Zuul as our main pipeline solution.
 
 ### How to make a repo use Zuul
 
-- Make Zuul aware of your repository in this repo: https://github.com/SovereignCloudStack/zuul_deployment
+- Make Zuul aware of your repository in this [repo](https://github.com/SovereignCloudStack/zuul_deployment)
 - Create a file *.zuul.yaml*
-    - An example can be found here: https://github.com/SovereignCloudStack/zuul-sandbox/blob/main/.zuul.yaml
-    - You can have a job section containing *self-defined* jobs which you need to write on your own
-    - You have to have a project section containing
-        - the default-branch name
-        - the merge-mode which should be used to auto-merge
-        - the jobs to run in each pipeline (gh_check, gh_gate, gh_post, gh_tag)
-        - these pipelines are triggered by events which can be looked up here: https://github.com/SovereignCloudStack/zuul_config/blob/main/zuul.d/gh_pipelines.yaml
-        - some default jobs can be found here: https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks
+  - An example can be found [here](https://github.com/SovereignCloudStack/zuul-sandbox/blob/main/.zuul.yaml)
+  - You can have a job section containing *self-defined* jobs which you need to write on your own
+  - You have to have a project section containing
+    - the default-branch name
+    - the merge-mode which should be used to auto-merge
+    - the jobs to run in each pipeline (gh_check, gh_gate, gh_post, gh_tag)
+    - these pipelines are triggered by events which can be looked up [here](https://github.com/SovereignCloudStack/zuul_config/blob/main/zuul.d/gh_pipelines.yaml)
+    - some default jobs can be found [here](https://opendev.org/zuul/zuul-jobs/src/branch/master/playbooks)
 - If you have *self-defined* jobs, you need to create a folder *.playbooks*
-    - this folder containers ansible playbooks which will be triggered
-
+  - this folder containers ansible playbooks which will be triggered
 
 ### General information about Zuul
 
 Zuul does not take anything for granted. If you need to have something installed,
 you should install it via ansible. Our test-machines are basically pimped
-docker-containers, so we might run into issues some time. But for now, things work pretty good.
+docker-containers, so we might run into issues some time. But for now, things work pretty good.

contribute/dco-and-licenses.md → community/contribute/dco-and-licenses.md

@@ -4,7 +4,7 @@ The Developer Certificate of Origin (DCO) is a lightweight way for contributors
 to certify that they wrote or otherwise have the right to submit the code they
 are contributing to the Sovereign Cloud Stack.
 
-```
+```bash
 By making a contribution to this project, I certify that:
 
 (a) The contribution was created in whole or in part by me and I
@@ -41,15 +41,15 @@ Own documentation content is licensed under [Creative Commons BY-SA 4.0](https:/
 Contributors sign-off that they adhere to these requirements by adding a `Signed-off-by`
 line to commit messages.
 
-```
+```bash
 My fancy commit message
 
 Signed-off-by: Christian Berendt <[email protected]>
 ```
 
 Git has a `-s` command line option to append this automatically to your commit message:
 
-```
+```bash
 git commit -s -m 'My fancy commit message'
 ```
 
@@ -63,4 +63,4 @@ Considerations behind the choice of AGPLv3, CC-BY-SA and the usage of the DCO ca
 
 - <https://developercertificate.org/>
 - <https://julien.ponge.org/blog/developer-certificate-of-origin-versus-contributor-license-agreements/>
-- <https://lwn.net/Articles/592503/>
+- <https://lwn.net/Articles/592503/>