Merge branch 'main' into feat/scs-0102-v2

Author: garloff

Community-Governance/2025-12-project-board-nominees.md

@@ -4,10 +4,10 @@ For the term 2025-12 - 2026-12 the following people are nominated / have nominat
 
 | Name, Firstname     | Github Handle  | E-Mail                              |
 | ------------------- | -------------- | ----------------------------------- |
+| Bayr, Michael       | @michaelbayr   | <[email protected]>                   |
+| Berendt, Christian  | @berendt       | <[email protected]>                |
 | Garloff, Kurt       | @garloff       | <[email protected]>                    |
 | Klare, Jan          | @jklare        | <[email protected]>                  |
-| Schoone, Jan        | @jschoone      | <[email protected]>          |
 | Pilka, Martin       | @mpilka        | <[email protected]>        |
 | Schöchlin, Marc     | @scoopex       | <[email protected]>      |
-| Bayr, Michael       | @michaelbayr   | <[email protected]>                   |
-| Berendt, Christian  | @berendt       | <[email protected]>                |
+| Schoone, Jan        | @jschoone      | <[email protected]>          |

Community-Governance/2026-01-project-board-termin-2026.md

@@ -0,0 +1,11 @@
+# Project Board Term 2026
+
+Spokesperson:
+
+| Name, Firstname         | Github Handle  | E-Mail                              | Remark                         |
+| ----------------------- | -------------- | ----------------------------------- |---------------------------------
+| Bayr, Michael           | @michaelbayr   | <[email protected]>                   | Elected by Community           |
+| Garloff, Kurt           | @garloff       | <[email protected]>                    | Elected by Community           |
+| Klare, Jan              | @jklare        | <[email protected]>                  | Elected by Community           |
+| Kronlage-Dammers, Felix | @fkr           | <[email protected]>              | Represents Forum SCS-Standards |
+| Schoone, Jan            | @jschoone      | <[email protected]>          | Elected by Community           |

Standards/scs-0001-v1-sovereign-cloud-standards.md

@@ -168,6 +168,7 @@ In addition, the following OPTIONAL sections should be considered:
 
 The lifecycle of an SCS document goes through the following phases:
 Draft, Stable, Deprecated, and Rejected.
+(Supplements mark a deviation; more on that below.)
 
 ```mermaid
 graph TD
@@ -212,7 +213,8 @@ to get in touch with the SCS community.
 Community participants are encouraged to present their proposal to the SCS community early on.
 Note that the proposal draft's content does not need to be finished in any way at this stage.
 
-The pull request for the proposal MUST add exactly one SCS document,
+The pull request for the proposal MUST add exactly one SCS document of any type,
+plus potentially any number of supplements to the former document (if applicable),
 in the `Standards` folder.
 In the proposal phase,
 the document number MUST be replaced with `xxxx` in the file name,
@@ -251,7 +253,8 @@ To propose major update to a Stable SCS document,
 a community participant creates a pull request on GitHub
 against the [standards repository in the SovereignCloudStack organisation][scs-standards-repo].
 
-The pull request MUST add exactly one SCS document,
+The pull request MUST add exactly one SCS document of any type,
+plus potentially any number of supplements to the former document (if applicable),
 in the `Standards` folder.
 The document number MUST be the same as the document it is updating,
 and the major version number MUST be incremented by 1.

Standards/scs-0005-v1-project-governance.md

@@ -1,8 +1,9 @@
 ---
 title: Governance of the SCS community
 type: Procedural
-status: Stable
+status: Deprecated
 stabilized_at: 2025-01-16
+deprecated_at: 2025-12-16
 track: Global
 description: |
   SCS-0005 outlines the structure and governance of the SCS community by the SCS Project Board and how this is elected.

Standards/scs-0005-v2-project-governance.md

@@ -0,0 +1,168 @@
+---
+title: Governance of the SCS community
+type: Procedural
+status: Stable
+stabilized_at: 2025-12-16
+replaces: scs-0005-v1-project-governance.md
+track: Global
+description: |
+  This is version 2 of the SCS-0005 and outlines the structure and governance of
+  the SCS community by the SCS Project Board and how this is elected.
+---
+
+## Introduction
+
+The [Sovereign Cloud Stack (SCS)](https://scs.community) provides standards
+for a range of cloud infrastructure types as well as a modular open-source
+reference implementation.
+The project is governed by the _SCS Project Board_.
+
+## Role of the _SCS Project Board_
+
+The role of the _SCS Project Board_ is the overall governance of the SCS Community and Project.
+This happens together with the _Forum SCS-Standards_ of the Open Source Business Alliance. To further
+underline this alignment, the _Forum SCS-Standards_ is part of the _SCS Project Board_.
+The _SCS Project Board_ itself is elected by the _SCS Community_.
+
+### Definitions
+
+#### _SCS Project_
+
+The _SCS Project_ is the Open-Source project that consists of the software, documentation, documents, blog posts as well as the people ("_SCS Community_") working on this.
+
+#### _SCS Community_
+
+The collective of people, companies, and organizations promoting the idea of the _SCS Project_ as well as the people working on the various aspects.
+
+#### _SCS GitHub Organization_
+
+The _SCS GitHub Organization_ is this: [https://github.com/sovereigncloudstack](https://github.com/sovereigncloudstack)
+
+### Roles in the _SCS GitHub Organization_
+
+#### Members
+
+Joining the SCS GitHub Organization as a contributor results in being assigned the **member role** in the organization. Members are contributors or collaborators who:
+
+- Actively contribute to projects within the organization.
+- Have repository-specific access based on their contributions.
+- Are eligible to vote in elections and nominate candidates for the _SCS Project Board_.
+- Must adhere to the [Code of Conduct](https://github.com/SovereignCloudStack/.github/blob/main/CODE_OF_CONDUCT.md).
+
+#### Owners
+
+Members of the _SCS Project Board_ are also designated as **owners** of the SCS GitHub organization. Owners have administrative privileges, including:
+
+- Managing organization-level settings.
+- Onboarding new members.
+- Enforcing compliance with governance and community standards.
+
+This alignment ensures that governance roles in the SCS Project Board directly translate into operational responsibilities within the GitHub organization.
+
+## Joining the SCS GitHub Organization
+
+Since being part of the GitHub organization comes with a set of responsibilities, joining the SCS GitHub Organization can be done by:
+
+- being invited by the _SCS Project Board_
+- submitting a request to be onboarded as a member to the _SCS Project Board_
+- have existing members of the GitHub organization nominate you
+
+One of these items is sufficient.
+
+Actively contributing to one or several of the projects under the governance of the SCS project board should typically result in a membership. Please be aware of our [Code of Conduct](https://github.com/SovereignCloudStack/.github/blob/main/CODE_OF_CONDUCT.md).
+
+## Election of the _SCS Project Board_
+
+### Term
+
+The _SCS Project Board_ is elected for the term of one calendar year. Elections are done
+within the last six weeks of the calendar year.
+
+### Seats on the board
+
+The _SCS Project Board_ contains five seats. One of these seats is filled by
+the delegate of the _Forum SCS-Standards_. The other four seats are voted upon.
+
+#### Conflict of Interest and Organizational Diversity
+
+To ensure balanced representation and avoid conflicts of interest, no more than one seat on the SCS Project
+Board elected by the community may be held by individuals affiliated with the same organization, company,
+or employer at any given time. This limitation applies only to the elected seats, not to the seat filled by
+the delegate of the Forum SCS-Standards.
+
+If two or more candidates from the same organization are among the top-ranked choices in an election:
+
+- Only the highest-ranked candidate from that organization will be elected.
+- The remaining seat(s) will be filled by the next highest-ranked candidate(s) from different organizations.
+
+If an existing board member changes their organizational affiliation during their term, resulting in multiple board
+members from the same organization, one of the affected members must resign their seat. The affected members may mutually
+agree on who will resign. If no agreement can be reached within 30 days of the affiliation change, the member who received
+fewer votes in the most recent election will be required to resign. A replacement will be determined according to the most
+recent election results, selecting the next eligible candidate from a different organization.
+
+#### Resignation
+
+Resignation can happen for several reasons, such as:
+
+- Elected member may sustainably no longer be willing or able to serve on the project board.
+- Elected member needs to resign due to conflict of interest (see above for organizational diversity rules).
+
+When a board member resigns, the next eligible candidate from the last election will automatically join the board,
+if they accept it and does not conflict with the organizational diversity rules. In case no more candidates exist,
+the board will continue to exist with one fewer member. If the number of elected board members falls below three,
+an extraordinary election will be scheduled for the rest of the term. Resigned members are encouraged to suggest
+new candidates. The search for candidates should at least allow for two weeks and the election announced at least
+three weeks in advance of happening and run for a week.
+
+### Nominations
+
+Every person who is part of the Sovereign Cloud Stack GitHub organization can be
+nominated for the board. Likewise, one can nominate oneself.
+The nomination is done by adding the person with the required data to the file corresponding to the term in the "Community-Governance" folder in the [Standards](https://github.com/sovereignCloudStack/standards/) repository. Obviously, the person, that is to be nominated, should be asked before being added to the file.
+
+### Eligible for voting
+
+Every person who is a member of the GitHub organization "Sovereign Cloud Stack" is eligible for voting. In order to be able to vote an onboarding onto the Identity Management of the SCS community needs to happen.
+
+### Electoral management
+
+The voting process is governed by the _Forum SCS-Standards_.
+Voting is done using the [Condorcet Internet Voting Service](https://civs1.civs.us/). This is the same system as is [being used by the OpenInfra foundation](https://wiki.openstack.org/wiki/Election_Officiating_Guidelines#Running_the_election_itself).
+
+### Voting period
+
+The voting will be open for a week.
+
+### Announcement
+
+The voting will be announced on the `scs-members` mailing list as well as on the
+[General & Announcements](https://matrix.to/#/#scs-general:matrix.org) Matrix channel.
+Enlisted voters will receive e-mails to the email address used in the SCS community's
+Identity Management system.
+
+### Mechanisms
+
+Each eligible voter is asked to rank the candidates according to their priorities.
+The four favorite choices among all voters will be elected into the _SCS Project Board_.
+In case there are four or fewer nominees for the election, no formal vote will
+be conducted, and all nominees will be elected into the _SCS Project Board_.
+
+## Roles in the _SCS Project Board_
+
+Among the elected Project Board a spokesperson is nominated. The spokesperson is
+elected by a simple majority vote among the members of the project board. The
+spokesperson is elected for the whole term.
+
+## Version history
+
+- Version 1 existed without major changes since 16.01.2025
+- Version 2 extends the detail of the _SCS Project Board_ election by:
+  - adding a section to avoid conflict of interest and ensure organizational
+    diversity
+  - adding a section to define the election mechanism if members of the board
+    resign
+  - specifying how to proceed when four or fewer candidates are nominated for
+    the elections
+  - using objective criteria (election results) for affiliation conflict resolution
+  - defining a minimum quorum (3 elected members) for extraordinary elections

Standards/scs-0100-v1-flavor-naming.md

@@ -321,7 +321,7 @@ Extensions need to be specified in the above-mentioned order.
 These are flavors expected to exist on standard SCS clouds (x86-64).
 
 We expect disk sizes to be 5, 10, 20, 50, 100, 200, 500, 1000GB, 2000GB.
-We expect a typical CPU:Mem[GiB] ratio of 1:4.
+We expect a typical CPU\:Mem[GiB] ratio of 1:4.
 
 | vCPU:RAM ratio | Mandatory Flavors          |
 | -------------- | -------------------------- |
@@ -422,7 +422,7 @@ considered broken by the SCS team.
 
 ## Validation
 
-There is a script in [flavor_name_check.py](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/flavor-naming/flavor-name-check.py)
+There is a script in [flavor-name-check.py](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/scs_0100_flavor_naming/flavor-name-check.py)
 which can be used to decode, validate and construct flavor names.
 This script must stay in sync with the specification text.
 

Standards/scs-0100-v2-flavor-naming.md

@@ -224,7 +224,7 @@ so users can expect some level of parallelism and independence.
 These are flavors that must exist on standard SCS clouds (x86-64).
 
 We expect disk sizes to be 5, 10, 20, 50, 100, 200, 500, 1000GB, 2000GB.
-We expect a typical CPU:Mem[GiB] ratio of 1:4.
+We expect a typical CPU to Mem[GiB] ratio of 1 to 4.
 
 | vCPU:RAM ratio | Mandatory Flavors          |
 | -------------- | -------------------------- |
@@ -295,7 +295,7 @@ to suggest extensions that we can discuss and add to the official scheme.
 
 ## Validation
 
-There is a script in [`flavor_name_check.py`](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/flavor-naming/flavor-name-check.py)
+There is a script in [`flavor-name-check.py`](https://github.com/SovereignCloudStack/standards/blob/main/Tests/iaas/scs_0100_flavor_naming/flavor-name-check.py)
 which can be used to decode, validate and construct flavor names.
 This script must stay in sync with the specification text.
 

Standards/scs-0103-v1-standard-flavors.md

@@ -149,7 +149,7 @@ In addition, the following properties must be set (in the `extra_specs`):
 
 ### Remarks
 
-We expect the most used vCPU:RAM[GiB] ratio to be 1:4.
+We expect the most used vCPU\:RAM[GiB] ratio to be 1:4.
 
 Note that all vCPUs of SCS standard flavors are oversubscribed — the smallest `1L-1`
 flavor allows for heavy oversubscription (note the `L`), and thus can be offered very

Standards/scs-0210-v2-k8s-version-policy.md

@@ -4,6 +4,7 @@ type: Standard
 stabilized_at: 2024-02-08
 status: Stable
 track: KaaS
+replaces: scs-0210-v1-k8s-new-version-policy.md
 ---
 
 ## Introduction

Tests/chk_adrs.py

@@ -131,6 +131,18 @@ def check_front_matter(self, fn, front, filenames):
         ]
         if errors:
             self.emit(f"in {fn}: syntax errors with key(s) {', '.join(errors)}")
+        # special check for replaces field if major version > 1
+        if fn[9:12] not in ("vN-", "v1-"):
+            replaces = front.get("replaces")
+            if replaces is None:
+                self.emit(f"in {fn}: missing replaces field")
+            else:
+                if isinstance(replaces, str):
+                    print(f"WARNING: in {fn}: replaces field not a list", file=sys.stderr)
+                    replaces = [replaces]
+                missing = [fn for fn in replaces if fn not in filenames]
+                if missing:
+                    self.emit(f"in {fn}: original version(s) {','.join(missing)} not found")
         # now do cross-field checks
         status = front.get("status")
         if "replaced_by" in front and status not in ("Deprecated", "Rejected"):