EESSI Governance #456

casparvl · 2025-05-07T09:43:31Z

To be agreed on by the Steering Committee. I think the most practical is if we keep iterating / wait until every one of us has given an approving review

…olicy

… May 2025

…we can do that in follow up PRs

bedroge · 2025-05-07T11:35:07Z

@casparvl I've fixed some typos in casparvl#1 and casparvl#2.

fix typo

fix some more typos

casparvl · 2025-05-07T14:11:22Z

Oh yeah, thanks, merged!

ocaisa · 2025-06-18T19:40:09Z

docs/governance/governance.md

+
+### 5.2 Removing Team Members
+<!-- Describe under what conditions someone may be removed (e.g., inactivity, conduct). -->
+Teams decide themselves decide the procedure to remove new Team members. As for the procedure of adding Team Members, the procedure to remove Team Members should reflect the sensitivity of the position.


Suggested change

Teams decide themselves decide the procedure to remove new Team members. As for the procedure of adding Team Members, the procedure to remove Team Members should reflect the sensitivity of the position.

Teams themselves decide the procedure to remove Team members. As for the procedure of adding Team Members, the procedure to remove Team Members should reflect the sensitivity of the position.

ocaisa · 2025-06-18T19:48:32Z

docs/governance/governance.md

+TODO: This project follows the [Contributor Covenant](https://www.contributor-covenant.org/) Code of Conduct.
+
+## 8. Contribution Agreement
+TODO: Should refer to some Contribution Agreement. Is contributing only possible after signing this agremeent? If so, that should be stated here


Linux projects have a standard approach here which doesn't involve signing a CA

Suggested change

TODO: Should refer to some Contribution Agreement. Is contributing only possible after signing this agremeent? If so, that should be stated here

TODO: Should refer to some Contribution Agreement. Is contributing only possible after signing this agreement? If so, that should be stated here

Hm, that sounds attractive, since it means we don't need a lawyer to draw up something for us :)

carefully hand-crafted ... aehm copiloted ... policies

…SSI softwares stack versions and individual software. Remove some duplicate statements

casparvl · 2025-06-19T09:30:39Z

docs/governance/policies.md

+
+- EESSI is committed to providing a complete SBOM for all deployed software.
+- The SBOM should include versioning, licensing, and dependency information.
+- Preferred formats include SPDX or CycloneDX.


I'm not sure if we can already meet the latter two points. If not, does it make sense to include them? I don't think so. Or at least we should make clear it's not currently the case, but is a long term goal.

docs/governance/code_of_conduct.md

boegel · 2025-06-19T10:21:07Z

mkdocs.yml

+    - Governance: governance/governance.md
+    - EESSI Policies: governance/policies.md
+    - Code of Conduct: governance/code_of_conduct.md
+    - Current Steering Committee: governance/steering_committee.md


We should either set up an auto-redirect for eessi.io/docs/governance to the moved steering_comittee URL, or set up a simple index.md in /governance with bullets that points to the subpages.

boegel · 2025-08-04T08:41:58Z

docs/governance/terms_of_use.md

@@ -0,0 +1,35 @@
+# EESSI – Terms of Use
+
+**Effective Date:** 23 June 2025


I would change this to:

Suggested change

**Effective Date:** 23 June 2025

**Last change:** 23 June 2025

and then also have a Changelog at the end (which for now can just mention something like "No changes since initial publication of this Terms of Use on ")

Effective Date is the correct legal term here. It signifies when the (i.e. this version of the) Terms and Conditions have become applicable. It doesn't just signify the change: you can make a change and decide it will only become effective 1 month from now, if that's what you want.

boegel · 2025-08-04T08:42:27Z

docs/governance/terms_of_use.md

+
+**Effective Date:** 23 June 2025
+
+By using the **European Environment for Scientific Software Installations (EESSI)**, you agree to the following terms:


Suggested change

By using the **European Environment for Scientific Software Installations (EESSI)**, you agree to the following terms:

By using the [**European Environment for Scientific Software Installations (EESSI)**](https://eessi.io), you agree to the following terms:

Fixed in fb0e8e6

boegel · 2025-08-04T08:43:33Z

docs/governance/terms_of_use.md

+By using the **European Environment for Scientific Software Installations (EESSI)**, you agree to the following terms:
+
+## 1. Purpose  
+EESSI provides a shared scientific software stack for academic, research, and educational use. Access and usage are intended for non-commercial scientific computing.


We need to be careful with our wording here, I think...

As such, this doesn't forbid the use of EESSI for "commercial scientific computing" (whatever that may mean)

I guess as it is now, it's OK?

Clarified phrasing: fb0e8e6

boegel · 2025-08-04T08:45:28Z

docs/governance/terms_of_use.md

+Contributions are welcome and governed by the project’s contribution guidelines. By contributing, you agree your input may be publicly shared and reused under compatible open-source licenses.
+
+## 8. Contact  
+For support or inquiries, visit [https://eessi.github.io](https://eessi.github.io) or contact the maintainers via **[Insert Email or GitHub]**.


To fix, maybe just point to https://www.eessi.io/docs/support ?

boegel · 2025-08-04T08:46:19Z

docs/governance/policies.md

+<!--
+# EESSI Policies
+-->
+
+<!--
+No policies have been defined (yet) ==> see draft based on the thoughts below
+-->
+
+<!--
+Should we have separate policies that Teams themselves can set? I.e. distinguish Project and Team policies, where project policies are set by the Steering Committee and Team policies by the respective Teams? Team policies could be ways to formalize concensus-based decisions. Clearly, if Team policies and Project policies contract, Project policy should come first.
+
+EESSI Policies could be things like
+
+- Should build for all architectures
+  - If something isn't available for an architecture, the end-user should be informed at runtime, e.g. through an error printed by a modulefile
+  - If something cannot be optimized for a micro-architecture, do we provide a less-optimized form (e.g. doesn't build for zen4 but does for zen3, so we provide zen3)?
+- Something on the fact that we try to provide a full software Bill-of-Materials for all software we deploy?
+- Acceptance of new software for the EESSI repository is "Yes, unless we can't" or "Yes, as long as it meets the Contribution Policy", i.e. we'll accept _anything_ that's reasonable?
+- Rebuild policy: when do we rebuild?
+- Removal policy: when do we remove?
+- Something on optimization?
+- Something on contributions _other_ than software for the EESSI repository (i.e. build logic, test suite, build bot). Should a requirement be that we can test it? Or is this too specific and should it be Team Policy?
+- Include our current Contribution Policy? Or should that be separate? (it's maybe more a Team Policy?) https://www.eessi.io/docs/adding_software/contribution_policy/
+- For security-critical roles (we should define which roles are security critical!), we only adopt new people that we (i.e. at least one person in that Team) knows _personally_.
+- Whenever technical choices need to be made between (optimizing for) HPC, Cloud, or a PC, we prioritize HPC usage (?). I.e. if we can choose between two implementations, and one would break usage on HPC, and another would break Cloud usage, and there is no implementation that works on both, we prioritize HPC? Or do we NOT make this explicit? Or: do we only make it explicit for _optimization_ related stuff (but not for 'it works' vs 'it does not work')?
+-->


boegel · 2025-08-04T08:50:07Z

mkdocs.yml

+    - Overview: governance/index.md
+    - Charter: governance/charter.md
+    - Governance: governance/governance.md
+    - EESSI Policies: governance/policies.md


Suggested change

- EESSI Policies: governance/policies.md

- Policies: governance/policies.md

docs/governance/governance.md

docs/governance/policies.md

boegel · 2025-08-04T09:27:31Z

docs/governance/policies.md

+
+There are currently no Team Policies yet.
+
+_Last updated: 23 June 2025_


I would replace this with a "Changlog" section, and mention on top when this page was last updated and point to the changelog for details?

tweaks to governance (sections 3-9), charter, policies

Co-authored-by: Kenneth Hoste <[email protected]>

… is meant to resolve

docs/governance/charter.md

Co-authored-by: Kenneth Hoste <[email protected]>

docs/governance/governance.md

Co-authored-by: Bob Dröge <[email protected]>

docs/governance/governance.md

bedroge · 2025-08-07T13:36:38Z

docs/governance/governance.md

+### 2.6 Ingestors
+Ingestors are those individuals that have permissions to ingest a tarball into the EESSI CernVM-FS repository, i.e. they are essentially responsible for step 3 as it is described in the [Builders](#builders) Section.
+
+Ingestors have merge permissions on the (private) `EESSI/staging` GitHub repository.
+
+Ingestors should check the contents of the tarball as it is reported in the pull requests in the `EESSI/staging` repository. This essentially provides a second check (next to that done by Deployers) on the contents of the tarball.


I was just making a github team for a new staging repo, and was wondering which name you used for this role. While using it, I started wondering if it shouldn't be ingesters. According to an AI friend:

Both ingester and ingestor are correct and commonly used, though "ingester" is the more widely accepted and preferred term, according to Wiktionary. Both words refer to something that ingests, whether it's a person, an animal, or a machine. While "ingestor" is also a valid word, "ingester" is more frequently encountered in contemporary usage, particularly in technical contexts

Suggested change

### 2.6 Ingestors

Ingestors are those individuals that have permissions to ingest a tarball into the EESSI CernVM-FS repository, i.e. they are essentially responsible for step 3 as it is described in the [Builders](#builders) Section.

Ingestors have merge permissions on the (private) `EESSI/staging` GitHub repository.

Ingestors should check the contents of the tarball as it is reported in the pull requests in the `EESSI/staging` repository. This essentially provides a second check (next to that done by Deployers) on the contents of the tarball.

### 2.6 Ingesters

Ingesters are those individuals that have permissions to ingest a tarball into the EESSI CernVM-FS repository, i.e. they are essentially responsible for step 3 as it is described in the [Builders](#builders) Section.

Ingesters have merge permissions on the (private) `EESSI/staging` GitHub repository.

Ingesters should check the contents of the tarball as it is reported in the pull requests in the `EESSI/staging` repository. This essentially provides a second check (next to that done by Deployers) on the contents of the tarball.

Caspar van Leeuwen and others added 12 commits February 18, 2025 22:50

Initial work on governance structure

cd35a98

Add some more notes

f83bc59

Fix comment

79d5b58

Added remaining items

adce82e

Moved Governance to a subdir. Now separate charter, governance, and p…

4d91f0f

…olicy

Added some more suggestions

7a340ba

Add current steering committee

135ee3c

fix typo

5032192

fix some more typos

f526460

Update charter.md

91aa468

Update charter.md

393248e

Modified charter and governance after Steering Committee meeting of 6…

cc84b9f

… May 2025

casparvl changed the title ~~Governance~~ EESSI Governance May 7, 2025

Make policies.md page reflect that we're not defining policies yet - …

005d2b7

…we can do that in follow up PRs

casparvl added 3 commits May 7, 2025 16:08

Merge pull request #1 from bedroge/patch-1

4cddbb5

fix typo

Merge branch 'governance' into patch-2

573ed87

Merge pull request #2 from bedroge/patch-2

5a52291

fix some more typos

Caspar van Leeuwen and others added 2 commits June 18, 2025 16:37

Fix typos

63ca7cf

carefully hand-crafted ... aehm copiloted ... policies

e29464f

ocaisa reviewed Jun 18, 2025

View reviewed changes

casparvl and others added 2 commits June 19, 2025 10:17

Merge pull request #3 from trz42/policy_draft

ca4fd63

carefully hand-crafted ... aehm copiloted ... policies

Update policies to include deprecation. Make a distinction between EE…

383d455

…SSI softwares stack versions and individual software. Remove some duplicate statements

casparvl commented Jun 19, 2025

View reviewed changes

Add code of conduct

83b7e4b

casparvl commented Jun 19, 2025

View reviewed changes

docs/governance/code_of_conduct.md Show resolved Hide resolved

Add code of conduct to the website tree

90c26e7

boegel reviewed Jun 19, 2025

View reviewed changes

boegel requested changes Aug 4, 2025

View reviewed changes

boegel and others added 10 commits August 4, 2025 11:28

add governance/index.md

7f72cd4

rename menu item for Policies under Governance

a1029ae

small tweaks to policies

9e48b26

Merge pull request #4 from boegel/governance

cd1435f

tweaks to governance (sections 3-9), charter, policies

Fix typo

217369f

Changed references to sections into links

ea9647a

Changes based on @boegel's review

50f5678

Apply suggestions from code review

10d4c9d

Co-authored-by: Kenneth Hoste <[email protected]>

Fix grammar

9522c00

Clarify what the procudure of removing members through unanimous vote…

f182390

… is meant to resolve

bedroge reviewed Aug 4, 2025

View reviewed changes

docs/governance/charter.md Outdated Show resolved Hide resolved

Apply suggestions from code review

88e5bd4

Co-authored-by: Kenneth Hoste <[email protected]>

boegel reviewed Aug 4, 2025

View reviewed changes

docs/governance/governance.md Outdated Show resolved Hide resolved

casparvl commented Aug 4, 2025

View reviewed changes

docs/governance/governance.md Outdated Show resolved Hide resolved

Apply suggestions from code review

e920332

Co-authored-by: Bob Dröge <[email protected]>

casparvl commented Aug 4, 2025

View reviewed changes

docs/governance/governance.md Outdated Show resolved Hide resolved

casparvl and others added 12 commits August 4, 2025 15:31

Apply suggestions from code review

de709ae

Fix anchors

842b0ce

Add changelog

4ad0af3

Clarify that commercial use _is_ permitted

fb0e8e6

Changed Contact point to the docs page about support

edb7325

Add contact details

3bd2970

Change index, see if this resolves @boegels loading issue

955a9f9

Merge branch 'main' into governance

6a371eb

Fix anchor

c868b76

Fix links

351e935

Fix external links

555dcfe

Remove redirect

2e21fd7

bedroge reviewed Aug 7, 2025

View reviewed changes

	Teams decide themselves decide the procedure to remove new Team members. As for the procedure of adding Team Members, the procedure to remove Team Members should reflect the sensitivity of the position.
	Teams themselves decide the procedure to remove Team members. As for the procedure of adding Team Members, the procedure to remove Team Members should reflect the sensitivity of the position.

	TODO: Should refer to some Contribution Agreement. Is contributing only possible after signing this agremeent? If so, that should be stated here
	TODO: Should refer to some Contribution Agreement. Is contributing only possible after signing this agreement? If so, that should be stated here

		@@ -0,0 +1,35 @@
		# EESSI – Terms of Use

		Effective Date: 23 June 2025

	Effective Date: 23 June 2025
	Last change: 23 June 2025


		Effective Date: 23 June 2025

		By using the European Environment for Scientific Software Installations (EESSI), you agree to the following terms:

	By using the European Environment for Scientific Software Installations (EESSI), you agree to the following terms:
	By using the [European Environment for Scientific Software Installations (EESSI)](https://eessi.io), you agree to the following terms:

	- EESSI Policies: governance/policies.md
	- Policies: governance/policies.md


		There are currently no Team Policies yet.

		_Last updated: 23 June 2025_

EESSI Governance #456

Are you sure you want to change the base?

EESSI Governance #456

Uh oh!

Conversation

casparvl commented May 7, 2025

Uh oh!

bedroge commented May 7, 2025

Uh oh!

casparvl commented May 7, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!