From cd35a98404f4fe3e01b6227bf24222e0c90568cb Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Tue, 18 Feb 2025 22:50:35 +0100 Subject: [PATCH 01/72] Initial work on governance structure --- docs/governance.md | 49 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/docs/governance.md b/docs/governance.md index 4a72f63538..9cc64042b0 100644 --- a/docs/governance.md +++ b/docs/governance.md @@ -1,5 +1,54 @@ # EESSI Governance +## Motivation and goals + +The EESSI open source project was started by a small group of HPC engineers and support staff, working towards a common goal: a shared software stack of optimized software, that supports a wide range of systems. Collaboration was done based on implicit rules, and the group was small enough to easily reach consensus-based solutions. As the community grew, we have formalized the implicit rules for collaboration in this governance document, thus allowing for a structured and formalized way in which _all_ community members can contribute to the project and gain influence on it's direction. + +The value of EESSI grows exponentially with two things: the amount of systems that make the EESSI software stack available, and the amount of software that is available in the EESSI software stack. Thus, the first goal of this governance is to make sure everyone in the community feels sufficiently included so that they are willing to contribute to EESSI (rather than build their own solution). + +The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because _trust_ in this process is important, both to infrastructure providers making the EESSI software stack is available on their systems, as well as by end-users of the software. Note that this concerns both large decisions (e.g. which architectures to support) and small decisions (e.g. whether to accept a certain contribution to add software to EESSI). + +To achieve both goals, our governance is based on the meritocracy governance model. + +## Roles and Responsibilities + + +To achieve both goals, our governance is based on the meritocracy governance model. ## Roles and Responsibilities - General note: - All roles affecting security (Infrastructure maintainers, Code maintainers, Deployers, Builders): how do we ensure security? - Should probably be a limited group of people, and at least 1 person in the current group should know the new person _personally_ before accepting into the group. Should probably state this explicitely in the governance +- For most teams, I think they can decide themselves who joins and who doesn't. I.e. builders can accept other builders. Questions: does it have to be unanimous? Other constraints set through policy (e.g. need to know someone personally) +- For the Steering committee: we could _start_ with self-appointed. Elections only make sense if there are multiple people who would even _want_ to fullfill this role. Otherwise, they can just distract from the work as they _are_ a lot of work for everyone (grooming candidates, having a voting system, who gets to vote, how do you make sure everyone is who they say - a person could have two GH handles and try to vote twice - etc. ### Steering Committee - Governance -- Arbitrage -- Consult on large technical decisions? Or does it take them? Or do we need a technical board? +- Policy +- Arbitrage. E.g. if a contributor and a builder/deployer/... disagree, the Steering committee does arbitrage. => How do we ensure that we act fairly when steering committee members are directly involved? Can the rest of the steering committee still judge fairly? +- Consult on large technical decisions? Or does it take them? Or do we need a technical board? Or is the idea that the steering committee sets the policies and e.g. the maintainers team is free to implement anything within the policy limits? Can the steering committee overrule the maintainers team? - How is the steering committee composed (election?) - How are people removed from the steering committee (next election? Step down? Unanimous vote by the others?) +The members of the _Interim Steering Committee_ are listed below. Each member of the _Interim Steering Committee_ also +nominate an alternate should they not be able to attend a meeting of the committee. + +* _Interim Steering Committee Lead_: Kenneth Hoste ([Ghent University](https://www.ugent.be/en)), [@boegel](https://github.com/boegel) + * _Alternate: Lara Peeters ([Ghent University](https://www.ugent.be/en)), :material-github: [@laraPPr](https://github.com/laraPPr)_ +* Alan O'Cais ([CECAM](https://www.cecam.org/), [University of Barcelona](https://web.ub.edu/inici)), :material-github: [@ocaisa](https://github.com/ocaisa) + * _Alternate: Davide Grassano ([CECAM](https://www.cecam.org/)), :material-github: [@crivella](https://github.com/crivella)_ +* Bob Dröge ([University of Groningen](https://www.rug.nl/)), :material-github: [@bedroge](https://github.com/bedroge) + * _Alternate: Henk-Jan Zilverberg ([University of Groningen](https://www.rug.nl/)), :material-github: [@zilverberg](https://github.com/zilverberg)_ +* Caspar van Leeuwen ([SURF](https://www.surf.nl/en)), :material-github: [@casparvl](https://github.com/casparvl) + * _Alternate: Satish Kamath ([SURF](https://www.surf.nl/en)), :material-github: [@satishskamath](https://github.com/satishskamath)_ +* Thomas Röblitz ([University of Bergen](https://www.uib.no/en)), [@trz42](https://github.com/trz42) + * _Alternate: Terje Kvernes ([University of Oslo](https://www.uio.no/english/)), :material-github: [@terjekv](https://github.com/terjekv)_ + +### Code owners +Owners in the Github sense, not in the legal sense +- Assign GH rights +- Deploy GH apps +- (Very?) high level of trust needed. Could get malicious things in through publicly visible means. Maybe also invisible (GH app configs?). + ### Code maintainers - Github -- How does one get rights? Who assigns them? Who takes them away? - How does one become code maintainer? How does one get removed from this group? +- High level of trust needed. These people can make build bots sneak in arbitrary things (but it is publicly visible in the code). ### Infrastructure maintainers -- Stratum 0, Stratum 1, build infrastructure +- Stratum 0, Stratum 1, build infrastructure, SMEE server (or is this not able to inject anything due to the secret we use on the webhook payload?) - Policy: we only ingest from infrastructured maintained by the Infrastructure maintainers +- Very high level of trust needed. These people can sneak in arbitrary things _without_ it being publicly visible (i.e. directly in stratum 0, or on build infrastructure through hooks, modification of the bot to package additional things in the tarball, etc). ### Deployers - Have the power to deploy software, i.e. tell the Stratum 0 to ingest software into the repository +- Within policy limits, deployers decide what gets deployed and what not +- Policy gets set by Steering Committee +- Policy: never deploy software that was not build on an infrastructure maintained by the Infrastructure Maintainers. +- Policy: never deploy software that was build by anyone that does _not_ have the Builders role. - How does one get this right? How is it removed? +- High level of trust needed. Can deploy malicious things, but would be publicly visible. ### Builders +- Has the power to command (at least one) build bot. +- Medium level of trust needed. Can not deploy malicious things, but could run malicious things on build infrastructure. + ### Contributors +- Anyone who makes PRs + ### Users +- Anyone who uses the EESSI software + EESSI recognises that formal governance is essential given the ambitions of the project, not just for EESSI itself but also to those who would adopt EESSI and/or fund its development. EESSI is, therefore, in the process of adopting a formal governance model. To facilitate this process it has created an _Interim Steering Committee_ whose role is to progress this adoption while also providing direction to the project. - -## Members of the _Interim Steering Committee_ - -The members of the _Interim Steering Committee_ are listed below. Each member of the _Interim Steering Committee_ also -nominate an alternate should they not be able to attend a meeting of the committee. - -* _Interim Steering Committee Lead_: Kenneth Hoste ([Ghent University](https://www.ugent.be/en)), [@boegel](https://github.com/boegel) - * _Alternate: Lara Peeters ([Ghent University](https://www.ugent.be/en)), :material-github: [@laraPPr](https://github.com/laraPPr)_ -* Alan O'Cais ([CECAM](https://www.cecam.org/), [University of Barcelona](https://web.ub.edu/inici)), :material-github: [@ocaisa](https://github.com/ocaisa) - * _Alternate: Davide Grassano ([CECAM](https://www.cecam.org/)), :material-github: [@crivella](https://github.com/crivella)_ -* Bob Dröge ([University of Groningen](https://www.rug.nl/)), :material-github: [@bedroge](https://github.com/bedroge) - * _Alternate: Henk-Jan Zilverberg ([University of Groningen](https://www.rug.nl/)), :material-github: [@zilverberg](https://github.com/zilverberg)_ -* Caspar van Leeuwen ([SURF](https://www.surf.nl/en)), :material-github: [@casparvl](https://github.com/casparvl) - * _Alternate: Satish Kamath ([SURF](https://www.surf.nl/en)), :material-github: [@satishskamath](https://github.com/satishskamath)_ -* Thomas Röblitz ([University of Bergen](https://www.uib.no/en)), [@trz42](https://github.com/trz42) - * _Alternate: Terje Kvernes ([University of Oslo](https://www.uio.no/english/)), :material-github: [@terjekv](https://github.com/terjekv)_ From 79d5b584ed4fa440e1c06ec9adc65c7d7fb98825 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Tue, 18 Feb 2025 23:21:06 +0100 Subject: [PATCH 03/72] Fix comment --- docs/governance.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/governance.md b/docs/governance.md index c36ec8e280..3c5c56ed74 100644 --- a/docs/governance.md +++ b/docs/governance.md @@ -8,7 +8,8 @@ The value of EESSI grows exponentially with two things: the amount of systems th The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because _trust_ in this process is important, both to infrastructure providers making the EESSI software stack is available on their systems, as well as by end-users of the software. Note that this concerns both large decisions (e.g. which architectures to support) and small decisions (e.g. whether to accept a certain contribution to add software to EESSI). -To achieve both goals, our governance is based on the meritocracy governance model. +To achieve both goals, our governance is based on the meritocracy governance model. + ## Roles and Responsibilities From adce82e792310f91c8d70184d44aa80afb5c8b1c Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Wed, 19 Feb 2025 16:41:16 +0100 Subject: [PATCH 04/72] Added remaining items --- docs/governance.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/docs/governance.md b/docs/governance.md index 3c5c56ed74..796c5bb7f8 100644 --- a/docs/governance.md +++ b/docs/governance.md @@ -85,9 +85,16 @@ Owners in the Github sense, not in the legal sense - Anyone who uses the EESSI software +## Support -EESSI recognises that formal governance is essential given the ambitions of the project, not just for EESSI -itself but also to those who would adopt EESSI and/or fund its development. +... Something on community support. Something on being open to professional support options... -EESSI is, therefore, in the process of adopting a formal governance model. To facilitate this process it has created an -_Interim Steering Committee_ whose role is to progress this adoption while also providing direction to the project. +## Decision making process + +... might need to check carefully what gets covered here, and what in the roles and responsibilities section. But probably this should state: deployers get to decide X. Maintainers Y. In principle every deployer has the power to take their own decisions. If any of these roles feel the decision may be controversial, they should contact the full team. A consensus-based approach is then preferred. If voting is needed, +1 / 0 / -1 are options, and a result larger than zero means it's adopted. Negative voters are strongly encouraged to come up with alternatives. + +... Discuss some appeal procedure (steering committee?) + +## Contribution process + +... Everyone can contribute after signing contributor agremeent? From 4d91f0ffc180d442c7ee11fc81c1f3a9e397f459 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Sun, 4 May 2025 14:54:09 +0200 Subject: [PATCH 05/72] Moved Governance to a subdir. Now separate charter, governance, and policy --- docs/governance/charter.md | 41 +++++++ docs/governance/governance.md | 160 ++++++++++++++++++++++++++ docs/governance/policies.md | 19 +++ docs/governance/steering_committee.md | 12 ++ mkdocs.yml | 5 +- 5 files changed, 236 insertions(+), 1 deletion(-) create mode 100644 docs/governance/charter.md create mode 100644 docs/governance/governance.md create mode 100644 docs/governance/policies.md create mode 100644 docs/governance/steering_committee.md diff --git a/docs/governance/charter.md b/docs/governance/charter.md new file mode 100644 index 0000000000..d86fd9e48b --- /dev/null +++ b/docs/governance/charter.md @@ -0,0 +1,41 @@ + + +# Project Charter + +## 1. Mission + +The EESSI project aims to build a common software stack that is: +- Cross-platform (laptop, Cloud VM, HPC Cluster) +- Ready-to-use (served over the internet, just mount-and-go) +- optimized for a wide range of hardware architectures (CPU, GPU, interconnects) + +## 2. Scope + +EESSI will focus on creating a repository of software installations. This requires: +- code to build and deploy new software into the repository +- code to make EESSI work on end-user systems +- infrastructure to build new software +- infrastructure to host the repository + +All of these (both code and infrastructure itself) are considered 'in scope' for the project. + + + +## 3. Membership + +There is currently no membership. Any individual or instution may participate by using the EESSI software stack, contributing to the EESSI software stack, making the EESSI software stack available on systems managed by them, etc. + +## 4. Review and Amendment +Changes to the charter require approval by the Steering Committee diff --git a/docs/governance/governance.md b/docs/governance/governance.md new file mode 100644 index 0000000000..75942b1086 --- /dev/null +++ b/docs/governance/governance.md @@ -0,0 +1,160 @@ + + +# Project Governance + +## 1. Guiding Principles + +The value of EESSI grows exponentially with two things: the amount of systems that make the EESSI software stack available, and the amount of software that is available in the EESSI software stack. Thus, the first goal of this governance is to make sure everyone in the community feels sufficiently included so that they are willing to contribute to EESSI (rather than build their own solution). + +The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because trust in this process is important, both to infrastructure providers making the EESSI software stack is available on their systems, as well as by end-users of the software. Note that this concerns both large decision, such as which architectures are supported in EESSI, as well as small decisions, such as whether to accept a certain contribution to add software to EESSI. + +To achieve both goals, our governance is based on the meritocracy governance model. + +## 2. Roles and Responsibilities + +Below, the roles and responsibilities related to the EESSI project are discussed. The group of people with a common role will be referred to as a Team in the remainder of this document. Each individual with a certain role will be referred to as a Team Member. + +### 2.1 EESSI Github organization & repository owners + +EESSI Github organization & repository owners are those individuals with `owner` rights on the EESSI Github organization or one of it's associated repositories. + +EESSI Github organization & repository owners shall be responsible for setting permisssions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing Github Apps for the EESSI build bots. + +### 2.2 EESSI Github organization & repository maintainers +EESSI Github organization & repository maintainers are individuals with write access (on or more) of the EESSI Github repositories. + +EESSI Github organization & repository maintainers shall be responsible for reviewing and merging PRs. + +### 2.3 EESSI Infrastructure maintainers +EESSI Infrastructure maintainers are those individuals that maintain the EESSI CVMFS Stratum 0, one of the _public_ EESSI CVMFS Stratum 1's, build infrastructure (hosting the EESSI build bot) and the SMEE server. + +Infrastructure maintainers shall be responsible for monitoring and maintaining their respective infrastructure, and provide access to those who needed it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Builders and Deployers as described in 2.4 and 2.5 if they so desire. + +### 2.4 Builders +Builders are those individuals that have permissions to build software for one or more of the EESSI build bots. + +Builders are responsible for triggering builds for contributors who want to add software to the EESSI software stack. They are also responsible for checking the PR, so as to avoid execution of malicious code on the EESSI build infrastructure. + +### 2.5 Deployers +Deployers are those individuals that have permissions to deploy software for one or more of the EESSI build bots. These individuals also have merge permissions on the `EESSI/staging` repository. + +Deployers are responsible for checking the produced tarballs, through the reports generated by the build bot (as part of the build step), as well as through checking the reports uploaded by the Stratum 0 in `EESSI/staging` PRs. They should ensure that the tarballs do not contain anything unexpected / malicious. + +### 2.6 Contributors + +Contributors are individuals that make a pull request to one of the repositories in the EESSI Github organization. + +Contributors that add software are responsible for checking that the license of the software they want to add allows it's use in EESSI (e.g. allows redistribution). Contributors are also responsible for making sure their PRs don't add any malicious code. + +### 2.7 System administrators of systems providing EESSI + +System administrators of systems providing EESSI are administrators of systems (such as, but not limited to cloud and HPC systems) that make the EESSI software stack available to their users. + +System administrators of systems providing EESSI are responsible for making sure that their system does not put any disproportional load on the public EESSI CernVM-FS infrastructure. In practice, this means that they are responsible for provisioning proper caching for their system, such as a private CernVM-FS Stratum 1, a proxy, and/or a properly sized local cache. + +### 2.8 End-Users + +End-Users are individuals that use any of the software provided by the EESSI software stack. + + +## 3. Decision-Making + +This section applies to the decision making procedure for the Teams discussed in Section 2. The Steering Committee has its own Decision-Making procedure. + +### 3.1 Consensus Seeking + +Decisions are made by seeking consensus. It is up to each individual to judge if something is controversial enough so that it needs to be discussed with their Team. If so, they should bring it up through the agreed-upon channels (see Section 4). + +### 3.2 Voting + +There is no formal voting for Teams, for two reasons: +1. The Teams may be too big to organize voting in a quick, practical way. +2. The obligation to take part in votes may discourage people to become part of these Teams, as it may be seen as a burden. + +Voting may nonetheless be used as a way to achieve consenses. For example, asking (a relevant subset of) the Team to vote may be one way to determine the majority opinion. Then, it can be discussed if the majority vote is an acceptable outcome to the Team. If so, consensus is achieved. + +### 3.3 Conflict Resolution + +If consensus cannot be reached within the Team, the Steering Committee can take the decision for them. This can be requested by the Team, or done at the initiative of the Steering Committee (if the Steering Committee feels such a decision is needed to move the project forward). + +Also, if multiple Teams claim ownership over an issue, the Steering Committee can decide which Team is allowed to decide over the issue. + +### 3.4 Overturning decisions + +The goal is for Teams to operate autonomously as much as possible. + +However, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort, in exceptional cases. Examples of when this may be considered is if the Steering Committee feels that a decision endangours the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. + +## 4. Meetings and Communication + +While each Team is allowed to use the communication channels that their Team jointly agrees upon, the following channels are suggested +- GitHub / GitLab issues +- Slack +- (Periodic or incidental) video calls + +## 5. Onboarding and Offboarding + +### 5.1 Adding Team Members + +Teams decide themselves how large their teams should ideally be. They also decide the procedure to add new Team members. + +As with all decisions the decision to add a Team member is subject to article 3.4. + +### 5.2 Removal + +Teams decide themselves decide the procedure to remove new Team members. + +As with all decisions the decision to remove a Team member is subject to article 3.4. + +## 6 Steering committte +### 6.1 Responsibilities + +The Steering Committee shall be responsible for: +- Setting the technical direction of the EESSI project and identifying key technical priorities +- Conflict resolution: if there is a conflict between the people with the aforementioned roles, the steering committee shall mediate the dispute and make a final decision if consensus cannot be reached +- The EESSI Charter (`charter.md`) +- The EESSI Governance (`governance.md`) +- The EESSI Policies (`policies.md`) + +### 6.2 Members and Chairs + +The Steering Committee is made up of community members with sustained and recognized contributions over time. Members take part in the Steering Committee as private individuals (i.e. they do not represent their employer(s)). + +Members will be removed from the committee if they resign. Furthermore, if a Member is inactive (i.e. does not participate in any of the Steering Committee Meetings for 6 months), the Member may be voted out by the other Steering Committee members. + +New Members are recommended by the Steering Committee. The Steering Committee will make the recommendation known to the community, and collect feedback on the recommendation. The Steering Committee then weighs the feedback, and votes on whether to accept the new member. In the selection process, the Steering Committee will consider the following: +- The Steering Committee should ideally consist of an odd number of Members +- No more than 30% of the Members should be employed by commercial entities + + + + + +All new members will appoint an alternate that may represent them and vote on their behalf in case they are unavailable. + +A Chair will be appointed by the Steering Committee to serve for a one-year term. + +### 6.3 Voting by the Steering Committee + +General decisions are taken by majority vote, provided that at least 75% of the Members cast a vote. Votes can be cast either in person, participating electronically, or via electronic vote (such as by e-mail). Members can cast a neutral vote, in which case the vote does count towards the quorum of 75%, but is not including in calculating the majority. Example: in a committee with 7 members, if 3 members vote in favour of a proposal, 2 votes against, and one votes neutral, the quorum is met (6 out of 7 members have voteded, i.e. >75%), and the majority (3 out of 5 non-neutral votes) is in favour, so the proposal is accepted. + +In case of a tie, the issue is discussed again, and a second vote is taken. All Members that voted in the first round need to have to opportunity to vote in the second round, which may mean that the vote needs to be postponed to a next meeting (e.g. because someone voted by e-mail, prior to the meeting). + +In case the quorum of 75% is not reached, the vote is postponed to a subsequent meeting. + +Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announched at least one week prior to the meeting, to give Members the opportunity to cast an Electronic vote if they cannot attend. + +To amend the Charter or Governance, a two-thirds majority of all Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at the meeting. There is no quorum for votes on ammendments to the Charter or Governance. + +### 6.4 Meetings + +The Steering Committee will meet as needed, but at least four times a year. The Chair is responsible for organizing the meeting. Any Member can request the Chair to organize a meeting. Meetings are announced at least 2 weeks in advance, unless all Members have agreed that a meeting on shorter notice is required. + +## 7. Code of Conduct + +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 diff --git a/docs/governance/policies.md b/docs/governance/policies.md new file mode 100644 index 0000000000..ab1df36763 --- /dev/null +++ b/docs/governance/policies.md @@ -0,0 +1,19 @@ +# EESSI Policies + +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_. +- ... + diff --git a/docs/governance/steering_committee.md b/docs/governance/steering_committee.md new file mode 100644 index 0000000000..24018aa713 --- /dev/null +++ b/docs/governance/steering_committee.md @@ -0,0 +1,12 @@ +The current (Interim) Steering Committee consists of: + +* _Interim Steering Committee Lead_: Kenneth Hoste ([Ghent University](https://www.ugent.be/en)), [@boegel](https://github.com/boegel) + * _Alternate: Lara Peeters ([Ghent University](https://www.ugent.be/en)), :material-github: [@laraPPr](https://github.com/laraPPr)_ +* Alan O'Cais ([CECAM](https://www.cecam.org/), [University of Barcelona](https://web.ub.edu/inici)), :material-github: [@ocaisa](https://github.com/ocaisa) + * _Alternate: Davide Grassano ([CECAM](https://www.cecam.org/)), :material-github: [@crivella](https://github.com/crivella)_ +* Bob Dröge ([University of Groningen](https://www.rug.nl/)), :material-github: [@bedroge](https://github.com/bedroge) + * _Alternate: Henk-Jan Zilverberg ([University of Groningen](https://www.rug.nl/)), :material-github: [@zilverberg](https://github.com/zilverberg)_ +* Caspar van Leeuwen ([SURF](https://www.surf.nl/en)), :material-github: [@casparvl](https://github.com/casparvl) + * _Alternate: Satish Kamath ([SURF](https://www.surf.nl/en)), :material-github: [@satishskamath](https://github.com/satishskamath)_ +* Thomas Röblitz ([University of Bergen](https://www.uib.no/en)), [@trz42](https://github.com/trz42) + * _Alternate: Terje Kvernes ([University of Oslo](https://www.uio.no/english/)), :material-github: [@terjekv](https://github.com/terjekv)_ diff --git a/mkdocs.yml b/mkdocs.yml index 9a8c47e21c..9562c6009a 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -77,7 +77,10 @@ nav: # - Community meeting (Sept'22): meetings/2022-09-amsterdam.md - Contact info: contact.md - Systems where EESSI is available: systems.md - - Governance: governance.md + - Governance: + - Charter: governance/charter.md + - Governance: governance/governance.md + - EESSI Policies: governance/policies.md - Blog: blog/index.md plugins: - blog: From 7a340ba11d934cae84871b2a7651156733b61dd9 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Sun, 4 May 2025 14:58:11 +0200 Subject: [PATCH 06/72] Added some more suggestions --- docs/governance/policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index ab1df36763..99fa00785b 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -15,5 +15,5 @@ EESSI Policies could be things like - 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')? From 135ee3cbef4170b6faab75e99ae5bd285bf270f9 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Sun, 4 May 2025 15:01:04 +0200 Subject: [PATCH 07/72] Add current steering committee --- mkdocs.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/mkdocs.yml b/mkdocs.yml index 9562c6009a..2aeeef5d06 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -81,6 +81,7 @@ nav: - Charter: governance/charter.md - Governance: governance/governance.md - EESSI Policies: governance/policies.md + - Current Steering Committee: governance/steering_committee.md - Blog: blog/index.md plugins: - blog: From 50321927971140459f443d6770277085244cbe89 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bob=20Dr=C3=B6ge?= Date: Tue, 6 May 2025 10:14:44 +0200 Subject: [PATCH 08/72] fix typo --- docs/governance/charter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index d86fd9e48b..3a94ce7704 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -35,7 +35,7 @@ All of these (both code and infrastructure itself) are considered 'in scope' for ## 3. Membership -There is currently no membership. Any individual or instution may participate by using the EESSI software stack, contributing to the EESSI software stack, making the EESSI software stack available on systems managed by them, etc. +There is currently no membership. Any individual or institution may participate by using the EESSI software stack, contributing to the EESSI software stack, making the EESSI software stack available on systems managed by them, etc. ## 4. Review and Amendment Changes to the charter require approval by the Steering Committee From f52646035e41e9c60d91439ccbfa303f065408c8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bob=20Dr=C3=B6ge?= Date: Tue, 6 May 2025 10:24:57 +0200 Subject: [PATCH 09/72] fix some more typos --- docs/governance/governance.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 75942b1086..30fdcaf02f 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -8,7 +8,7 @@ A project charter discusses _what it is and why it exists_, a governance discuss The value of EESSI grows exponentially with two things: the amount of systems that make the EESSI software stack available, and the amount of software that is available in the EESSI software stack. Thus, the first goal of this governance is to make sure everyone in the community feels sufficiently included so that they are willing to contribute to EESSI (rather than build their own solution). -The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because trust in this process is important, both to infrastructure providers making the EESSI software stack is available on their systems, as well as by end-users of the software. Note that this concerns both large decision, such as which architectures are supported in EESSI, as well as small decisions, such as whether to accept a certain contribution to add software to EESSI. +The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because trust in this process is important, both to infrastructure providers making the EESSI software stack is available on their systems, as well as by end-users of the software. Note that this concerns both large decisions, such as which architectures are supported in EESSI, as well as small decisions, such as whether to accept a certain contribution to add software to EESSI. To achieve both goals, our governance is based on the meritocracy governance model. @@ -23,7 +23,7 @@ EESSI Github organization & repository owners are those individuals with `owner` EESSI Github organization & repository owners shall be responsible for setting permisssions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing Github Apps for the EESSI build bots. ### 2.2 EESSI Github organization & repository maintainers -EESSI Github organization & repository maintainers are individuals with write access (on or more) of the EESSI Github repositories. +EESSI Github organization & repository maintainers are individuals with write access on (one or more of) the EESSI Github repositories. EESSI Github organization & repository maintainers shall be responsible for reviewing and merging PRs. @@ -73,7 +73,7 @@ There is no formal voting for Teams, for two reasons: 1. The Teams may be too big to organize voting in a quick, practical way. 2. The obligation to take part in votes may discourage people to become part of these Teams, as it may be seen as a burden. -Voting may nonetheless be used as a way to achieve consenses. For example, asking (a relevant subset of) the Team to vote may be one way to determine the majority opinion. Then, it can be discussed if the majority vote is an acceptable outcome to the Team. If so, consensus is achieved. +Voting may nonetheless be used as a way to achieve consensus. For example, asking (a relevant subset of) the Team to vote may be one way to determine the majority opinion. Then, it can be discussed if the majority vote is an acceptable outcome to the Team. If so, consensus is achieved. ### 3.3 Conflict Resolution @@ -85,7 +85,7 @@ Also, if multiple Teams claim ownership over an issue, the Steering Committee ca The goal is for Teams to operate autonomously as much as possible. -However, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort, in exceptional cases. Examples of when this may be considered is if the Steering Committee feels that a decision endangours the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. +However, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort, in exceptional cases. Examples of when this may be considered is if the Steering Committee feels that a decision endangers the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. ## 4. Meetings and Communication @@ -106,7 +106,7 @@ As with all decisions the decision to add a Team member is subject to article 3. Teams decide themselves decide the procedure to remove new Team members. -As with all decisions the decision to remove a Team member is subject to article 3.4. +As with all decisions, the decision to remove a Team member is subject to article 3.4. ## 6 Steering committte ### 6.1 Responsibilities @@ -140,11 +140,11 @@ A Chair will be appointed by the Steering Committee to serve for a one-year term General decisions are taken by majority vote, provided that at least 75% of the Members cast a vote. Votes can be cast either in person, participating electronically, or via electronic vote (such as by e-mail). Members can cast a neutral vote, in which case the vote does count towards the quorum of 75%, but is not including in calculating the majority. Example: in a committee with 7 members, if 3 members vote in favour of a proposal, 2 votes against, and one votes neutral, the quorum is met (6 out of 7 members have voteded, i.e. >75%), and the majority (3 out of 5 non-neutral votes) is in favour, so the proposal is accepted. -In case of a tie, the issue is discussed again, and a second vote is taken. All Members that voted in the first round need to have to opportunity to vote in the second round, which may mean that the vote needs to be postponed to a next meeting (e.g. because someone voted by e-mail, prior to the meeting). +In case of a tie, the issue is discussed again, and a second vote is taken. All Members that voted in the first round need to have the opportunity to vote in the second round, which may mean that the vote needs to be postponed to a next meeting (e.g. because someone voted by e-mail, prior to the meeting). In case the quorum of 75% is not reached, the vote is postponed to a subsequent meeting. -Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announched at least one week prior to the meeting, to give Members the opportunity to cast an Electronic vote if they cannot attend. +Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announced at least one week prior to the meeting, to give Members the opportunity to cast an Electronic vote if they cannot attend. To amend the Charter or Governance, a two-thirds majority of all Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at the meeting. There is no quorum for votes on ammendments to the Charter or Governance. From 91aa46885d51876f5912173db54f095e0a5fa280 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen <33718780+casparvl@users.noreply.github.com> Date: Tue, 6 May 2025 16:14:18 +0200 Subject: [PATCH 10/72] Update charter.md --- docs/governance/charter.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index d86fd9e48b..ffec5be339 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -26,10 +26,10 @@ The EESSI project aims to build a common software stack that is: EESSI will focus on creating a repository of software installations. This requires: - code to build and deploy new software into the repository - code to make EESSI work on end-user systems -- infrastructure to build new software -- infrastructure to host the repository +- infrastructure to build new software for software.eessi.io +- infrastructure to host the repository for software.eessi.io -All of these (both code and infrastructure itself) are considered 'in scope' for the project. +All of these (both code and infrastructure itself) are considered 'in scope' for the project. From 393248e23cf72417b68c6a17d6d84be0777f0ec1 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen <33718780+casparvl@users.noreply.github.com> Date: Tue, 6 May 2025 16:17:08 +0200 Subject: [PATCH 11/72] Update charter.md --- docs/governance/charter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index ffec5be339..d898901e26 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -29,7 +29,7 @@ EESSI will focus on creating a repository of software installations. This requir - infrastructure to build new software for software.eessi.io - infrastructure to host the repository for software.eessi.io -All of these (both code and infrastructure itself) are considered 'in scope' for the project. +All of these (both code and infrastructure itself) are considered 'in scope' for the project. From cc84b9fa31984a71f77ff36134978b1126fa80db Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Wed, 7 May 2025 11:26:46 +0200 Subject: [PATCH 12/72] Modified charter and governance after Steering Committee meeting of 6 May 2025 --- docs/governance.md | 100 ---------------------------------- docs/governance/charter.md | 9 +-- docs/governance/governance.md | 60 ++++++++++---------- 3 files changed, 37 insertions(+), 132 deletions(-) delete mode 100644 docs/governance.md diff --git a/docs/governance.md b/docs/governance.md deleted file mode 100644 index 796c5bb7f8..0000000000 --- a/docs/governance.md +++ /dev/null @@ -1,100 +0,0 @@ -# EESSI Governance - -## Motivation and goals - -The EESSI open source project was started by a small group of HPC engineers and support staff, working towards a common goal: a shared software stack of optimized software, that supports a wide range of systems. Collaboration was done based on implicit rules, and the group was small enough to easily reach consensus-based solutions. As the community grew, we have formalized the implicit rules for collaboration in this governance document, thus allowing for a structured and formalized way in which _all_ community members can contribute to the project and gain influence on it's direction. - -The value of EESSI grows exponentially with two things: the amount of systems that make the EESSI software stack available, and the amount of software that is available in the EESSI software stack. Thus, the first goal of this governance is to make sure everyone in the community feels sufficiently included so that they are willing to contribute to EESSI (rather than build their own solution). - -The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because _trust_ in this process is important, both to infrastructure providers making the EESSI software stack is available on their systems, as well as by end-users of the software. Note that this concerns both large decisions (e.g. which architectures to support) and small decisions (e.g. whether to accept a certain contribution to add software to EESSI). - -To achieve both goals, our governance is based on the meritocracy governance model. - - -## Roles and Responsibilities - - - -General note: -- All roles affecting security (Infrastructure maintainers, Code maintainers, Deployers, Builders): how do we ensure security? -- Should probably be a limited group of people, and at least 1 person in the current group should know the new person _personally_ before accepting into the group. Should probably state this explicitely in the governance -- For most teams, I think they can decide themselves who joins and who doesn't. I.e. builders can accept other builders. Questions: does it have to be unanimous? Other constraints set through policy (e.g. need to know someone personally) -- For the Steering committee: we could _start_ with self-appointed. Elections only make sense if there are multiple people who would even _want_ to fullfill this role. Otherwise, they can just distract from the work as they _are_ a lot of work for everyone (grooming candidates, having a voting system, who gets to vote, how do you make sure everyone is who they say - a person could have two GH handles and try to vote twice - etc. - -### Steering Committee - -- Governance -- Policy -- Arbitrage. E.g. if a contributor and a builder/deployer/... disagree, the Steering committee does arbitrage. => How do we ensure that we act fairly when steering committee members are directly involved? Can the rest of the steering committee still judge fairly? -- Consult on large technical decisions? Or does it take them? Or do we need a technical board? Or is the idea that the steering committee sets the policies and e.g. the maintainers team is free to implement anything within the policy limits? Can the steering committee overrule the maintainers team? -- How is the steering committee composed (election?) -- How are people removed from the steering committee (next election? Step down? Unanimous vote by the others?) - -The members of the _Interim Steering Committee_ are listed below. Each member of the _Interim Steering Committee_ also -nominate an alternate should they not be able to attend a meeting of the committee. - -* _Interim Steering Committee Lead_: Kenneth Hoste ([Ghent University](https://www.ugent.be/en)), [@boegel](https://github.com/boegel) - * _Alternate: Lara Peeters ([Ghent University](https://www.ugent.be/en)), :material-github: [@laraPPr](https://github.com/laraPPr)_ -* Alan O'Cais ([CECAM](https://www.cecam.org/), [University of Barcelona](https://web.ub.edu/inici)), :material-github: [@ocaisa](https://github.com/ocaisa) - * _Alternate: Davide Grassano ([CECAM](https://www.cecam.org/)), :material-github: [@crivella](https://github.com/crivella)_ -* Bob Dröge ([University of Groningen](https://www.rug.nl/)), :material-github: [@bedroge](https://github.com/bedroge) - * _Alternate: Henk-Jan Zilverberg ([University of Groningen](https://www.rug.nl/)), :material-github: [@zilverberg](https://github.com/zilverberg)_ -* Caspar van Leeuwen ([SURF](https://www.surf.nl/en)), :material-github: [@casparvl](https://github.com/casparvl) - * _Alternate: Satish Kamath ([SURF](https://www.surf.nl/en)), :material-github: [@satishskamath](https://github.com/satishskamath)_ -* Thomas Röblitz ([University of Bergen](https://www.uib.no/en)), [@trz42](https://github.com/trz42) - * _Alternate: Terje Kvernes ([University of Oslo](https://www.uio.no/english/)), :material-github: [@terjekv](https://github.com/terjekv)_ - -### Code owners -Owners in the Github sense, not in the legal sense -- Assign GH rights -- Deploy GH apps -- (Very?) high level of trust needed. Could get malicious things in through publicly visible means. Maybe also invisible (GH app configs?). - -### Code maintainers - -- Github -- How does one become code maintainer? How does one get removed from this group? -- High level of trust needed. These people can make build bots sneak in arbitrary things (but it is publicly visible in the code). - -### Infrastructure maintainers - -- Stratum 0, Stratum 1, build infrastructure, SMEE server (or is this not able to inject anything due to the secret we use on the webhook payload?) -- Policy: we only ingest from infrastructured maintained by the Infrastructure maintainers -- Very high level of trust needed. These people can sneak in arbitrary things _without_ it being publicly visible (i.e. directly in stratum 0, or on build infrastructure through hooks, modification of the bot to package additional things in the tarball, etc). - -### Deployers - -- Have the power to deploy software, i.e. tell the Stratum 0 to ingest software into the repository -- Within policy limits, deployers decide what gets deployed and what not -- Policy gets set by Steering Committee -- Policy: never deploy software that was not build on an infrastructure maintained by the Infrastructure Maintainers. -- Policy: never deploy software that was build by anyone that does _not_ have the Builders role. -- How does one get this right? How is it removed? -- High level of trust needed. Can deploy malicious things, but would be publicly visible. - -### Builders - -- Has the power to command (at least one) build bot. -- Medium level of trust needed. Can not deploy malicious things, but could run malicious things on build infrastructure. - -### Contributors - -- Anyone who makes PRs - -### Users - -- Anyone who uses the EESSI software - -## Support - -... Something on community support. Something on being open to professional support options... - -## Decision making process - -... might need to check carefully what gets covered here, and what in the roles and responsibilities section. But probably this should state: deployers get to decide X. Maintainers Y. In principle every deployer has the power to take their own decisions. If any of these roles feel the decision may be controversial, they should contact the full team. A consensus-based approach is then preferred. If voting is needed, +1 / 0 / -1 are options, and a result larger than zero means it's adopted. Negative voters are strongly encouraged to come up with alternatives. - -... Discuss some appeal procedure (steering committee?) - -## Contribution process - -... Everyone can contribute after signing contributor agremeent? diff --git a/docs/governance/charter.md b/docs/governance/charter.md index d898901e26..9247ecb150 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -19,19 +19,20 @@ blog about charters https://opensource.org/blog/what-is-open-governance-drafting The EESSI project aims to build a common software stack that is: - Cross-platform (laptop, Cloud VM, HPC Cluster) - Ready-to-use (served over the internet, just mount-and-go) -- optimized for a wide range of hardware architectures (CPU, GPU, interconnects) +- Optimized for a wide range of hardware architectures (CPU, GPU, interconnects) +- Easily extendable ## 2. Scope -EESSI will focus on creating a repository of software installations. This requires: +EESSI will focus on creating a repository of software installations (software.eessi.io). This requires: - code to build and deploy new software into the repository - code to make EESSI work on end-user systems - infrastructure to build new software for software.eessi.io - infrastructure to host the repository for software.eessi.io -All of these (both code and infrastructure itself) are considered 'in scope' for the project. +All of these (both code and infrastructure itself) are considered 'in scope' for the project. - +There are additional repositories under the eessi.io namespace, such as dev.eessi.io and riscv.eessi.io. All code related to those repositories is also considered part of the EESSI project. However, the repositories themselves (i.e. their content) and the infrastructure hosting them is not. ## 3. Membership diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 75942b1086..cb6fa66e23 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -14,7 +14,7 @@ To achieve both goals, our governance is based on the meritocracy governance mod ## 2. Roles and Responsibilities -Below, the roles and responsibilities related to the EESSI project are discussed. The group of people with a common role will be referred to as a Team in the remainder of this document. Each individual with a certain role will be referred to as a Team Member. +Below, the roles and responsibilities related to the EESSI project are discussed. The group of people with a common role will be referred to as a Team in the remainder of this document. Exceptions are Contributors, System administrators of systems providing EESSI and End-users (these are not considered to be Teams). Each individual in a Team will be referred to as a Team Member. ### 2.1 EESSI Github organization & repository owners @@ -22,23 +22,23 @@ EESSI Github organization & repository owners are those individuals with `owner` EESSI Github organization & repository owners shall be responsible for setting permisssions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing Github Apps for the EESSI build bots. -### 2.2 EESSI Github organization & repository maintainers -EESSI Github organization & repository maintainers are individuals with write access (on or more) of the EESSI Github repositories. +### 2.2 EESSI Github repository maintainers +EESSI Github repository maintainers are individuals with write access (on or more) of the EESSI Github repositories. -EESSI Github organization & repository maintainers shall be responsible for reviewing and merging PRs. +EESSI Github repository maintainers shall be responsible for reviewing and merging PRs. ### 2.3 EESSI Infrastructure maintainers EESSI Infrastructure maintainers are those individuals that maintain the EESSI CVMFS Stratum 0, one of the _public_ EESSI CVMFS Stratum 1's, build infrastructure (hosting the EESSI build bot) and the SMEE server. -Infrastructure maintainers shall be responsible for monitoring and maintaining their respective infrastructure, and provide access to those who needed it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Builders and Deployers as described in 2.4 and 2.5 if they so desire. +Infrastructure maintainers shall be responsible for monitoring and maintaining their respective infrastructure, and provide access to those who needed it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Deployers and Builders as described in 2.4 and 2.5 if they so desire. Furthermore, they are _not_ allowed to give access to others that are not part of the EESSI Infrastructure maintainers, Deployers or Builders teams. ### 2.4 Builders -Builders are those individuals that have permissions to build software for one or more of the EESSI build bots. +Builders are those individuals that have permissions to build software through one or more of the EESSI build bots. Builders are responsible for triggering builds for contributors who want to add software to the EESSI software stack. They are also responsible for checking the PR, so as to avoid execution of malicious code on the EESSI build infrastructure. ### 2.5 Deployers -Deployers are those individuals that have permissions to deploy software for one or more of the EESSI build bots. These individuals also have merge permissions on the `EESSI/staging` repository. +Deployers are those individuals that have permissions to deploy software through one or more of the EESSI build bots. These individuals also have merge permissions on the `EESSI/staging` repository. Deployers are responsible for checking the produced tarballs, through the reports generated by the build bot (as part of the build step), as well as through checking the reports uploaded by the Stratum 0 in `EESSI/staging` PRs. They should ensure that the tarballs do not contain anything unexpected / malicious. @@ -46,13 +46,13 @@ Deployers are responsible for checking the produced tarballs, through the report Contributors are individuals that make a pull request to one of the repositories in the EESSI Github organization. -Contributors that add software are responsible for checking that the license of the software they want to add allows it's use in EESSI (e.g. allows redistribution). Contributors are also responsible for making sure their PRs don't add any malicious code. +Contributors that add software are responsible for checking that the license of the software they want to add allows it's use in EESSI (e.g. allows redistribution). Contributors are also responsible for making sure their PRs don't add any malicious code. Finally, contributors should ensure that they adhere to the [Contribution Policy](../adding_software/contribution_policy.md). ### 2.7 System administrators of systems providing EESSI System administrators of systems providing EESSI are administrators of systems (such as, but not limited to cloud and HPC systems) that make the EESSI software stack available to their users. -System administrators of systems providing EESSI are responsible for making sure that their system does not put any disproportional load on the public EESSI CernVM-FS infrastructure. In practice, this means that they are responsible for provisioning proper caching for their system, such as a private CernVM-FS Stratum 1, a proxy, and/or a properly sized local cache. +System administrators of systems providing EESSI are responsible for making sure that their system does not put any disproportional load on the public EESSI CernVM-FS infrastructure. Typically, this means that they are responsible for provisioning proper caching for their system, such as a private CernVM-FS Stratum 1, a proxy, and/or a properly sized local cache. ### 2.8 End-Users @@ -65,7 +65,7 @@ This section applies to the decision making procedure for the Teams discussed in ### 3.1 Consensus Seeking -Decisions are made by seeking consensus. It is up to each individual to judge if something is controversial enough so that it needs to be discussed with their Team. If so, they should bring it up through the agreed-upon channels (see Section 4). +Decisions are made by seeking consensus. Each Team member is responsible for deciding whether an issue or decision is significant or sensitive enough to warrant discussions within their Team. If so, they should bring it up through the agreed-upon channels (see Section 4). ### 3.2 Voting @@ -75,9 +75,9 @@ There is no formal voting for Teams, for two reasons: Voting may nonetheless be used as a way to achieve consenses. For example, asking (a relevant subset of) the Team to vote may be one way to determine the majority opinion. Then, it can be discussed if the majority vote is an acceptable outcome to the Team. If so, consensus is achieved. -### 3.3 Conflict Resolution +### 3.3 Deadlock Resolution -If consensus cannot be reached within the Team, the Steering Committee can take the decision for them. This can be requested by the Team, or done at the initiative of the Steering Committee (if the Steering Committee feels such a decision is needed to move the project forward). +If consensus cannot be reached within the Team, the Steering Committee can take the decision for them. This can be requested by the Team, or done at the initiative of the Steering Committee (if they feel the lack of a decision is preventing the project from moving forward). Also, if multiple Teams claim ownership over an issue, the Steering Committee can decide which Team is allowed to decide over the issue. @@ -85,7 +85,7 @@ Also, if multiple Teams claim ownership over an issue, the Steering Committee ca The goal is for Teams to operate autonomously as much as possible. -However, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort, in exceptional cases. Examples of when this may be considered is if the Steering Committee feels that a decision endangours the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. +However, in exceptional cases, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort. Examples of when this may be considered is if the Steering Committee feels that a decision endangours the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. ## 4. Meetings and Communication @@ -95,16 +95,17 @@ While each Team is allowed to use the communication channels that their Team joi - (Periodic or incidental) video calls ## 5. Onboarding and Offboarding +This Section applies to the Teams described in Section 2. ### 5.1 Adding Team Members -Teams decide themselves how large their teams should ideally be. They also decide the procedure to add new Team members. +Teams decide themselves how large their teams should ideally be. They also decide the procedure to add new Team members. The procedure should reflect the sensitivity of the position, i.e. people with certain roles have the ability to (intentionally or unintentionally) compromise the integrity of the repository. For such roles, the procedure should make sure candidates are extensively vetted and trusted by both the Team as well as the EESSI community as a whole. As with all decisions the decision to add a Team member is subject to article 3.4. -### 5.2 Removal +### 5.2 Removing Team Members -Teams decide themselves decide the procedure to remove new Team members. +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. As with all decisions the decision to remove a Team member is subject to article 3.4. @@ -122,35 +123,38 @@ The Steering Committee shall be responsible for: The Steering Committee is made up of community members with sustained and recognized contributions over time. Members take part in the Steering Committee as private individuals (i.e. they do not represent their employer(s)). -Members will be removed from the committee if they resign. Furthermore, if a Member is inactive (i.e. does not participate in any of the Steering Committee Meetings for 6 months), the Member may be voted out by the other Steering Committee members. +Members will be removed from the committee if they resign. Furthermore, if a Member is inactive for 6 Months and does not reply to communication from the rest of the Steering Committee, the Member may be voted out by the other Steering Committee members (regular voting rules, as per section 6.3, apply). Finally, a Member may be voted out. In this case, the vote needs to be unanimous between the other Members. New Members are recommended by the Steering Committee. The Steering Committee will make the recommendation known to the community, and collect feedback on the recommendation. The Steering Committee then weighs the feedback, and votes on whether to accept the new member. In the selection process, the Steering Committee will consider the following: -- The Steering Committee should ideally consist of an odd number of Members +- The Steering Committee ideally consists of an odd number of Members - No more than 30% of the Members should be employed by commercial entities +- The number of Members working for the same company should be limited to 1 +- The number of Members from the same country should be limited to 2 +- The composition of the Steering Committee should reflect the EESSI community - +Note that if Members change jobs, or move to another country, some of the above criteria that were taken into account during selection may no longer be satisfied. It is up to the Steering Committee to decide if this is problematic, and if so, try to restore balance by requesting someone to resign. - - -All new members will appoint an alternate that may represent them and vote on their behalf in case they are unavailable. +All new Members will appoint an alternate that may represent them and vote on their behalf in case they are unavailable. If a Member resigns or is voted out from the Steering Committee, their alternate immediately loses any rights they had as an alternate. A Chair will be appointed by the Steering Committee to serve for a one-year term. ### 6.3 Voting by the Steering Committee -General decisions are taken by majority vote, provided that at least 75% of the Members cast a vote. Votes can be cast either in person, participating electronically, or via electronic vote (such as by e-mail). Members can cast a neutral vote, in which case the vote does count towards the quorum of 75%, but is not including in calculating the majority. Example: in a committee with 7 members, if 3 members vote in favour of a proposal, 2 votes against, and one votes neutral, the quorum is met (6 out of 7 members have voteded, i.e. >75%), and the majority (3 out of 5 non-neutral votes) is in favour, so the proposal is accepted. +General decisions are taken by majority vote, provided that at least 75% of the Members cast a vote. Votes can be cast either in person, participating electronically, or via electronic vote (such as by e-mail). Members can cast a neutral vote, in which case the vote does count towards the quorum of 75%, but is not including in calculating the majority. Example: in a committee with 7 members, if 3 members vote in favour of a proposal, 2 vote against, and one votes neutral, the quorum is met (6 out of 7 members have voteded, i.e. >75%), and the majority (3 out of 5 non-neutral votes) is in favour, so the proposal is accepted. Members can also abstain from voting, in which case they neither count towards the quorum or calculating the majority. Example: in a committee with 7 members, if 3 members vote in favor, 2 vote against, and one abstains from voting, the quorum of 6 (75% of 7 members, rounded up) is not met. + +In case of a tie, the issue is discussed again, and a second vote is taken. All Members that voted in the first round need to have to opportunity to vote in the second round, which may mean that the vote needs to be postponed to a next meeting (e.g. because one or more Members voted by e-mail, and are not present at the meeting). -In case of a tie, the issue is discussed again, and a second vote is taken. All Members that voted in the first round need to have to opportunity to vote in the second round, which may mean that the vote needs to be postponed to a next meeting (e.g. because someone voted by e-mail, prior to the meeting). +In case the quorum of 75% is not reached, the vote is postponed. -In case the quorum of 75% is not reached, the vote is postponed to a subsequent meeting. +A fully electronic vote (i.e. all Members vote electronically) can be organized by the Chair, in order to prevent having to delay a vote to the next meeting. Such a fully electronic vote is only valid once _all_ Members have cast their vote, or have explicitely stated that they abstain from voting. -Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announched at least one week prior to the meeting, to give Members the opportunity to cast an Electronic vote if they cannot attend. +Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announched at least one week prior to the meeting, to give Members the opportunity to cast an electronic vote if they cannot attend. -To amend the Charter or Governance, a two-thirds majority of all Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at the meeting. There is no quorum for votes on ammendments to the Charter or Governance. +To amend the Charter or Governance, a two-thirds majority of all Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at a meeting. There is no quorum for votes on ammendments to the Charter or Governance. ### 6.4 Meetings -The Steering Committee will meet as needed, but at least four times a year. The Chair is responsible for organizing the meeting. Any Member can request the Chair to organize a meeting. Meetings are announced at least 2 weeks in advance, unless all Members have agreed that a meeting on shorter notice is required. +The Steering Committee will meet as needed, but at least once per quarter. The Chair is responsible for organizing the meeting. Any Member can request the Chair to organize a meeting. Meetings are announced at least 2 weeks in advance, unless _all_ Members have agreed that a meeting on shorter notice is required. ## 7. Code of Conduct From 005d2b755978367759380b0a7f9d91fb48e3b857 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Wed, 7 May 2025 11:45:45 +0200 Subject: [PATCH 13/72] Make policies.md page reflect that we're not defining policies yet - we can do that in follow up PRs --- docs/governance/policies.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index 99fa00785b..a6ae43c42f 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -1,5 +1,8 @@ # EESSI Policies +No policies have been defined (yet) + + From 63ca7cf2f54551bd4db279a47e44806348bb712d Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Wed, 18 Jun 2025 16:37:05 +0200 Subject: [PATCH 14/72] Fix typos --- docs/governance/governance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 90204b4f08..52e973473a 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -20,7 +20,7 @@ Below, the roles and responsibilities related to the EESSI project are discussed EESSI Github organization & repository owners are those individuals with `owner` rights on the EESSI Github organization or one of it's associated repositories. -EESSI Github organization & repository owners shall be responsible for setting permisssions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing Github Apps for the EESSI build bots. +EESSI Github organization & repository owners shall be responsible for setting permissions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing Github Apps for the EESSI build bots. ### 2.2 EESSI Github repository maintainers EESSI Github repository maintainers are individuals with write access (one or more) of the EESSI Github repositories. @@ -146,7 +146,7 @@ In case of a tie, the issue is discussed again, and a second vote is taken. All In case the quorum of 75% is not reached, the vote is postponed. -A fully electronic vote (i.e. all Members vote electronically) can be organized by the Chair, in order to prevent having to delay a vote to the next meeting. Such a fully electronic vote is only valid once _all_ Members have cast their vote, or have explicitely stated that they abstain from voting. +A fully electronic vote (i.e. all Members vote electronically) can be organized by the Chair, in order to prevent having to delay a vote to the next meeting. Such a fully electronic vote is only valid once _all_ Members have cast their vote, or have explicitly stated that they abstain from voting. Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announced at least one week prior to the meeting, to give Members the opportunity to cast an electronic vote if they cannot attend. From e29464fc67ff3438c65221321f282828812f9529 Mon Sep 17 00:00:00 2001 From: Thomas Roeblitz Date: Wed, 18 Jun 2025 20:58:52 +0200 Subject: [PATCH 15/72] carefully hand-crafted ... aehm copiloted ... policies --- docs/governance/policies.md | 90 ++++++++++++++++++++++++++++++++++++- 1 file changed, 89 insertions(+), 1 deletion(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index a6ae43c42f..55f47f207c 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -1,6 +1,10 @@ + -No policies have been defined (yet) + + +# EESSI Project Policies + +This document outlines project-wide policies that guide the development, deployment, and maintenance of the EESSI software stack. These policies are set by the Steering Committee and apply across all Teams and repositories. In case of conflict, Project Policies override Team Policies. + +--- + +## 1. Policy Scope and Hierarchy + +- **Project Policies** are defined and maintained by the Steering Committee. +- **Team Policies** may be defined by individual Teams to formalize consensus-based decisions within their scope. +- In case of conflict, **Project Policies take precedence** over Team Policies. + +--- + +## 2. Build and Deployment Policies + +### 2.1 Architecture Support + +- EESSI aims to build and support software for all relevant hardware architectures. +- If a package is unavailable for a specific architecture, the system should provide a clear runtime message (e.g., via modulefile error). +- When optimization for a specific microarchitecture is not possible, a compatible fallback (e.g., zen3 for zen4) should be provided if available. + +### 2.2 Rebuild Policy + +- Software may be rebuilt in response to: + - Security vulnerabilities + - Dependency updates + - Infrastructure changes + - Community requests (subject to review) + +### 2.3 Removal Policy + +- Software may be removed if: + - It violates licensing terms + - It poses a security risk + - It is deprecated or superseded + - It is no longer maintainable or functional + +### 2.4 Optimization Policy + +- Optimization for performance is encouraged, especially for HPC environments. +- Where trade-offs are necessary, HPC compatibility and performance take precedence over Cloud or PC optimization. + +--- + +## 3. Contribution Policies + +### 3.1 Software Acceptance + +- Contributions of new software are accepted as long as they meet the [Contribution Policy](https://www.eessi.io/docs/adding_software/contribution_policy/). +- The default stance is: **"Yes, unless we can't."** + +### 3.2 Non-Software Contributions + +- Contributions to build logic, test suites, or infrastructure must be testable and documented. +- Specific requirements may be defined by the relevant Team. + +### 3.3 Security-Critical Roles + +- Roles with elevated access (e.g., infrastructure maintainers, deployers) are considered security-critical. +- New members in these roles must be personally known and trusted by at least one existing Team member. + +--- + +## 4. Transparency and Traceability + +### 4.1 Software Bill of Materials (SBOM) + +- 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. + +--- + +## 5. Platform Prioritization + +- In cases where technical choices must be made between HPC, Cloud, or PC environments: + - **HPC compatibility and performance are prioritized**, especially for optimization-related decisions. + - This does not imply exclusion of other platforms, but reflects the project's primary use case. + +--- + +_Last updated: [Insert Date]_ From 383d4559aeb7d0df8cb4970de6bf2bf53f9df988 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Thu, 19 Jun 2025 11:27:57 +0200 Subject: [PATCH 16/72] Update policies to include deprecation. Make a distinction between EESSI softwares stack versions and individual software. Remove some duplicate statements --- docs/governance/policies.md | 80 ++++++++++++++++++++++++------------- 1 file changed, 52 insertions(+), 28 deletions(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index 55f47f207c..dd13252d16 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -25,17 +25,17 @@ EESSI Policies could be things like - 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')? --> -# EESSI Project Policies +# Policy Scope and Hierarchy -This document outlines project-wide policies that guide the development, deployment, and maintenance of the EESSI software stack. These policies are set by the Steering Committee and apply across all Teams and repositories. In case of conflict, Project Policies override Team Policies. +- **Project Policies** are defined and maintained by the Steering Committee. +- **Team Policies** may be defined by individual Teams to formalize consensus-based decisions within their scope. +- In case of conflict, **Project Policies take precedence** over Team Policies. --- -## 1. Policy Scope and Hierarchy +# EESSI Project Policies -- **Project Policies** are defined and maintained by the Steering Committee. -- **Team Policies** may be defined by individual Teams to formalize consensus-based decisions within their scope. -- In case of conflict, **Project Policies take precedence** over Team Policies. +This document outlines project-wide policies that guide the development, deployment, and maintenance of the EESSI software stack. These policies are set by the Steering Committee and apply across all Teams and repositories. --- @@ -43,30 +43,55 @@ This document outlines project-wide policies that guide the development, deploym ### 2.1 Architecture Support -- EESSI aims to build and support software for all relevant hardware architectures. -- If a package is unavailable for a specific architecture, the system should provide a clear runtime message (e.g., via modulefile error). -- When optimization for a specific microarchitecture is not possible, a compatible fallback (e.g., zen3 for zen4) should be provided if available. +- EESSI aims to build and support software for a wide range of relevant hardware architectures. Currently supported architectures are listed [here](../software-layer/cpu_targets.md). +- If a package is unavailable for a specific architecture, a clear runtime message (e.g., via modulefile error) should be provided to the user. +- When optimization for a specific microarchitecture is not possible, a compatible fallback (e.g., zen3 for zen4) should be provided if available. A clear runtime warning will be printed. ### 2.2 Rebuild Policy -- Software may be rebuilt in response to: - - Security vulnerabilities - - Dependency updates - - Infrastructure changes - - Community requests (subject to review) +Reproducibility is important in scientific computing. Thus, we exercise restraint in rebuilding software. A list of scenarios in which software may be rebuilt is: + +- The software contained security vulnerabilities +- There were updates to the (list of) dependencies, e.g. some optional dependency was missing which restricted functionality of the original installation +- There were (unintended) differences between the software installations for different (micro)architectures +- The original installation (or a substantial part thereof) was found to be broken. Not that this does _not_ apply to small bugs. +- Mistakes in the original installation prevent it from being used as a dependency for other software + +Additionally, software may be rebuilt for other reasons if there is sufficient consensus within the EESSI Community that this is beneficial. + +In all cases, the value of rebuilding the software will be carefully weighed against the value of reproducibility. + +### 2.3 Deprecation Policy -### 2.3 Removal Policy +#### 2.3.1 Deprecation of EESSI software stack versions +At any given time, we aim to have at least two EESSI software stack versions in production. When a new version of the EESSI software stack is introduced _and_ sufficiently populated, the oldest stack will be deprecated. A clear runtime warning will be printed when an end-user initializes a deprecated EESSI software stack. -- Software may be removed if: - - It violates licensing terms - - It poses a security risk - - It is deprecated or superseded - - It is no longer maintainable or functional +#### 2.3.2 Deprecation of individual software installations -### 2.4 Optimization Policy +Installations of individual software packages in a (non-deprecated) EESSI software stack may be deprecated if they are no longer maintainable or functional. A clear runtime warning will be printed when an end-user tries to load a module for a deprecated software installation. -- Optimization for performance is encouraged, especially for HPC environments. -- Where trade-offs are necessary, HPC compatibility and performance take precedence over Cloud or PC optimization. +### 2.4 Removal Policy + +#### 2.4.1 Removal of EESSI software stack versions + +Since CernVM-FS Stratum 1 servers have to fully mirror the repository, old EESSI software stack versions will have to be removed to keep the storage footprint within reasonable limits. This will only be done after: +- The EESSI software stack version has been deprecated for at least 1 year +- The EESSI software stack version has been archived in _some_ form in which it can still be used by end-users (e.g. as a tarball, an exported CVMFS repository using CernVM-FS Shrinkwrap, or some other form). + +A clear runtime error will be printed when an end-user tries to initialize a removed EESSI software stack. + +#### 2.4.2 Removal of individual software installations + +An individual software installation in EESSI may be removed if: +- It violates licensing terms +- It poses a security risk +- It is no longer maintainable or functional. + +A clear runtime error will be printed when an end-user tries to load a module for a removed software installation. + +### 2.5 Optimization Policy + +Optimization for performance is strongly encouraged. For compiled software, this means we aim to have the compiler optimize for the supported hardware targets. --- @@ -82,11 +107,6 @@ This document outlines project-wide policies that guide the development, deploym - Contributions to build logic, test suites, or infrastructure must be testable and documented. - Specific requirements may be defined by the relevant Team. -### 3.3 Security-Critical Roles - -- Roles with elevated access (e.g., infrastructure maintainers, deployers) are considered security-critical. -- New members in these roles must be personally known and trusted by at least one existing Team member. - --- ## 4. Transparency and Traceability @@ -107,4 +127,8 @@ This document outlines project-wide policies that guide the development, deploym --- +# EESSI Team Policies + +There are currently no Team Policies yet. + _Last updated: [Insert Date]_ From 83b7e4b174f3712762d4354cf99e4b054f9b0379 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Thu, 19 Jun 2025 11:47:52 +0200 Subject: [PATCH 17/72] Add code of conduct --- docs/governance/code_of_conduct.md | 125 +++++++++++++++++++++++++++++ docs/governance/governance.md | 9 +-- 2 files changed, 129 insertions(+), 5 deletions(-) create mode 100644 docs/governance/code_of_conduct.md diff --git a/docs/governance/code_of_conduct.md b/docs/governance/code_of_conduct.md new file mode 100644 index 0000000000..74dddc853c --- /dev/null +++ b/docs/governance/code_of_conduct.md @@ -0,0 +1,125 @@ + +# Contributor Covenant Code of Conduct + +## Our Pledge + +We as members, contributors, and leaders pledge to make participation in our +community a harassment-free experience for everyone, regardless of age, body +size, visible or invisible disability, ethnicity, sex characteristics, gender +identity and expression, level of experience, education, socio-economic status, +nationality, personal appearance, race, caste, color, religion, or sexual +identity and orientation. + +We pledge to act and interact in ways that contribute to an open, welcoming, +diverse, inclusive, and healthy community. + +## Our Standards + +Examples of behavior that contributes to a positive environment for our +community include: + +* Demonstrating empathy and kindness toward other people +* Being respectful of differing opinions, viewpoints, and experiences +* Giving and gracefully accepting constructive feedback +* Accepting responsibility and apologizing to those affected by our mistakes, + and learning from the experience +* Focusing on what is best not just for us as individuals, but for the overall + community + +Examples of unacceptable behavior include: + +* The use of sexualized language or imagery, and sexual attention or advances of + any kind +* Trolling, insulting or derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or email address, + without their explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting + +## Enforcement Responsibilities + +Community leaders are responsible for clarifying and enforcing our standards of +acceptable behavior and will take appropriate and fair corrective action in +response to any behavior that they deem inappropriate, threatening, offensive, +or harmful. + +Community leaders have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct, and will communicate reasons for moderation +decisions when appropriate. + +## Scope + +This Code of Conduct applies within all community spaces, and also applies when +an individual is officially representing the community in public spaces. +Examples of representing our community include using an official email address, +posting via an official social media account, or acting as an appointed +representative at an online or offline event. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported to the EESSI Steering Committee via direct message to one of the +EESSI Steering Committee Members on the EESSI Slack channel. Please indicate +clearly that your message is about a (possible) breach of the code of conduct. +All complaints will be reviewed and investigated promptly and fairly. + +The EESSI Steering Committee Members are obligated to respect the privacy and +security of the reporter of any incident. + +## Enforcement Guidelines + +The EESSI Steering Committee will follow these Community Impact Guidelines in +determining the consequences for any action they deem in violation of this Code +of Conduct: + +### 1. Correction + +**Community Impact**: Use of inappropriate language or other behavior deemed +unprofessional or unwelcome in the community. + +**Consequence**: A private, written warning from community leaders, providing +clarity around the nature of the violation and an explanation of why the +behavior was inappropriate. A public apology may be requested. + +### 2. Warning + +**Community Impact**: A violation through a single incident or series of +actions. + +**Consequence**: A warning with consequences for continued behavior. No +interaction with the people involved, including unsolicited interaction with +those enforcing the Code of Conduct, for a specified period of time. This +includes avoiding interactions in community spaces as well as external channels +like social media. Violating these terms may lead to a temporary or permanent +ban. + +### 3. Temporary Ban + +**Community Impact**: A serious violation of community standards, including +sustained inappropriate behavior. + +**Consequence**: A temporary ban from any sort of interaction or public +communication with the community for a specified period of time. No public or +private interaction with the people involved, including unsolicited interaction +with those enforcing the Code of Conduct, is allowed during this period. +Violating these terms may lead to a permanent ban. + +### 4. Permanent Ban + +**Community Impact**: Demonstrating a pattern of violation of community +standards, including sustained inappropriate behavior, harassment of an +individual, or aggression toward or disparagement of classes of individuals. + +**Consequence**: A permanent ban from any sort of public interaction within the +community. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], +version 2.1, available at +[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]. + +Community Impact Guidelines were inspired by +[Mozilla's code of conduct enforcement ladder][Mozilla CoC]. diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 52e973473a..184593d318 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -99,13 +99,13 @@ This Section applies to the Teams described in Section 2. ### 5.1 Adding Team Members -Teams decide themselves how large their teams should ideally be. They also decide the procedure to add new Team members. The procedure should reflect the sensitivity of the position, i.e. people with certain roles have the ability to (intentionally or unintentionally) compromise the integrity of the repository. For such roles, the procedure should make sure candidates are extensively vetted and trusted by both the Team as well as the EESSI community as a whole. +Teams themselves decide how large their teams should ideally be. They also decide the procedure to add new Team members. The procedure should reflect the sensitivity of the position, i.e. people with certain roles have the ability to (intentionally or unintentionally) compromise the integrity of the repository. For such roles, the procedure should make sure candidates are extensively vetted and trusted by both the Team as well as the EESSI community as a whole. As with all decisions the decision to add a Team member is subject to article 3.4. ### 5.2 Removing Team Members -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. As with all decisions, the decision to remove a Team member is subject to article 3.4. @@ -150,15 +150,14 @@ A fully electronic vote (i.e. all Members vote electronically) can be organized Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announced at least one week prior to the meeting, to give Members the opportunity to cast an electronic vote if they cannot attend. -To amend the Charter or Governance, a two-thirds majority of all Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at a meeting. There is no quorum for votes on ammendments to the Charter or Governance. +To amend the Charter or Governance, a two-thirds majority of all Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at a meeting. There is no quorum for votes on amendments to the Charter or Governance. ### 6.4 Meetings The Steering Committee will meet as needed, but at least once per quarter. The Chair is responsible for organizing the meeting. Any Member can request the Chair to organize a meeting. Meetings are announced at least 2 weeks in advance, unless _all_ Members have agreed that a meeting on shorter notice is required. ## 7. Code of Conduct - -TODO: This project follows the [Contributor Covenant](https://www.contributor-covenant.org/) Code of Conduct. +The EESSI Code of Conduct can be found [here](code_of_conduct.md). ## 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 From 90c26e7f56b9b28fa9f9c44916c71051d9a5686a Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Thu, 19 Jun 2025 11:51:41 +0200 Subject: [PATCH 18/72] Add code of conduct to the website tree --- mkdocs.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/mkdocs.yml b/mkdocs.yml index 2aeeef5d06..1ae2eff89a 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -81,6 +81,7 @@ nav: - Charter: governance/charter.md - Governance: governance/governance.md - EESSI Policies: governance/policies.md + - Code of Conduct: governance/code_of_conduct.md - Current Steering Committee: governance/steering_committee.md - Blog: blog/index.md plugins: From 1757d52a3af12d2fd0023a962bae663430dc04ba Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 23 Jun 2025 14:19:04 +0200 Subject: [PATCH 19/72] Processed Kenneth's comments and suggestions --- docs/governance/charter.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index 93c93a4f5d..8435be344a 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -16,27 +16,32 @@ blog about charters https://opensource.org/blog/what-is-open-governance-drafting ## 1. Mission -The EESSI project aims to build a common software stack that is: +The [European Environment for Scientific Software Installations](https://www.eessi.io/docs/) (EESSI) project aims to build a common software stack that is + - Cross-platform (laptop, Cloud VM, HPC Cluster) - Ready-to-use (served over the internet, just mount-and-go) - Optimized for a wide range of hardware architectures (CPU, GPU, interconnects) -- Easily extendable +- Easily extendable with additional local installations +- Customizeable (e.g. site-spefici LMOD hooks, injecting a local MPI, etc) + +and can be used on any Linux (virtual) machine. ## 2. Scope -EESSI will focus on creating a repository of software installations (software.eessi.io). This requires: -- code to build and deploy new software into the repository -- code to make EESSI work on end-user systems +EESSI focusses on creating a [CernVM-FS repository](https://cvmfs.readthedocs.io/en/stable/cpt-repo.html) of software installations (software.eessi.io). This requires: + +- Source code to automate the process of building and deploying additional software installations in `software.eessi.io` +- Source code to provide a user-friendy interface on end-user systems - infrastructure to build new software for software.eessi.io -- infrastructure to host the repository for software.eessi.io +- infrastructure to host the CernVM-FS repository for software.eessi.io All of these (both code and infrastructure itself) are considered 'in scope' for the project. -There are additional repositories under the eessi.io namespace, such as dev.eessi.io and riscv.eessi.io. All code related to those repositories is also considered part of the EESSI project. However, the repositories themselves (i.e. their content) and the infrastructure hosting them is not. +There are additional CernVM-FS repositories under the eessi.io namespace, such as dev.eessi.io and riscv.eessi.io. All code and infrastructure related to those repositories (and any other CernVM-FS repositories under the eessi.io namespace) are also considered part of the EESSI project. ## 3. Membership -There is currently no membership. Any individual or institution may participate by using the EESSI software stack, contributing to the EESSI software stack, making the EESSI software stack available on systems managed by them, etc. +There is currently no membership. Any individual or institution may participate by using EESSI, contributing to EESSI, making EESSI available on systems managed by them, etc. ## 4. Review and Amendment -Changes to the charter require approval by the Steering Committee +Changes to the charter require approval by the Steering Committee. See the [relevant section of the Governance](../governance.md#voting-by-the-steering-committee). From 9b42ba0ad2e874d020c0b6ac9e9e378c7b91915e Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 23 Jun 2025 17:36:09 +0200 Subject: [PATCH 20/72] Processed Kenneths comments --- docs/governance/governance.md | 63 ++++++++++++++++++++++++----------- 1 file changed, 43 insertions(+), 20 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 184593d318..141ecf36a0 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -4,60 +4,80 @@ A project charter discusses _what it is and why it exists_, a governance discuss # Project Governance +As stated in the [Charter](charter.md), this project governance _only_ covers collaboration on the software.eessi.io CernVM-FS repository, it does not cover other CernVM-FS repositories under the eessi.io namespace. In other words, when the sections below mention the EESSI CernVM-FS repository, this implies the software.eessi.io repository specifically. Thus, this governance only addresses contributing to, building for, deploying to, ingesting in, providing, or using the software.eessi.io respository. + +The only exception to this is the Steering Committee, which has authority over all the eessi.io CernFM-FS repositories. + ## 1. Guiding Principles -The value of EESSI grows exponentially with two things: the amount of systems that make the EESSI software stack available, and the amount of software that is available in the EESSI software stack. Thus, the first goal of this governance is to make sure everyone in the community feels sufficiently included so that they are willing to contribute to EESSI (rather than build their own solution). +The value of EESSI grows exponentially with two things: the amount of systems that make EESSI available, and the amount of software that is available in EESSI. Thus, the first goal of this governance is to make sure everyone in the community feels sufficiently included so that they are willing to contribute to EESSI (rather than build their own solution). -The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because trust in this process is important, both to infrastructure providers making the EESSI software stack is available on their systems, as well as by end-users of the software. Note that this concerns both large decisions, such as which architectures are supported in EESSI, as well as small decisions, such as whether to accept a certain contribution to add software to EESSI. +The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because trust in this process is important, both to infrastructure providers making the EESSI software stack is available on their systems, as well as by end-users of the software. Note that this concerns both large decisions, such as which architectures are supported in EESSI, as well as small decisions, such as making a specific software package available in EESSI. -To achieve both goals, our governance is based on the meritocracy governance model. +To achieve both goals, our governance is based on the [meritocracy](https://en.wikipedia.org/wiki/Meritocracy) governance model. ## 2. Roles and Responsibilities Below, the roles and responsibilities related to the EESSI project are discussed. The group of people with a common role will be referred to as a Team in the remainder of this document. Exceptions are Contributors, System administrators of systems providing EESSI and End-users (these are not considered to be Teams). Each individual in a Team will be referred to as a Team Member. -### 2.1 EESSI Github organization & repository owners +### 2.1 Owners of the [EESSI GitHub organization](https://github.com/EESSI) & repositories -EESSI Github organization & repository owners are those individuals with `owner` rights on the EESSI Github organization or one of it's associated repositories. +The owners of the [EESSI GitHub organization](https://github.com/EESSI) & repositories are those individuals with `owner` rights on the EESSI GitHub organization or one of it's associated repositories. -EESSI Github organization & repository owners shall be responsible for setting permissions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing Github Apps for the EESSI build bots. +EESSI Github organization & repository owners are responsible for setting permissions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing Github Apps for the EESSI build bots. ### 2.2 EESSI Github repository maintainers EESSI Github repository maintainers are individuals with write access (one or more) of the EESSI Github repositories. -EESSI Github repository maintainers shall be responsible for reviewing and merging PRs. +EESSI Github repository maintainers are responsible for reviewing and merging PRs. ### 2.3 EESSI Infrastructure maintainers -EESSI Infrastructure maintainers are those individuals that maintain the EESSI CVMFS Stratum 0, one of the _public_ EESSI CVMFS Stratum 1's, build infrastructure (hosting the EESSI build bot) and the SMEE server. +EESSI Infrastructure maintainers are those individuals that maintain the Central Server for the EESSI CernVM-FS repository (the CernVM-FS Stratum 0), one of the _public_ mirror servers (CernVM-FS Stratum 1's), build infrastructure (e.g. hosting the EESSI build bot, the SMEE server). -Infrastructure maintainers shall be responsible for monitoring and maintaining their respective infrastructure, and provide access to those who needed it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Deployers and Builders as described in 2.4 and 2.5 if they so desire. Furthermore, they are _not_ allowed to give access to others that are not part of the EESSI Infrastructure maintainers, Deployers or Builders teams. +Infrastructure maintainers are responsible for monitoring and maintaining their respective infrastructure, and provide access to those who needed it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Deployers and Builders as described in 2.4 and 2.5. Furthermore, they are _not_ allowed to give access to others that are not part of the EESSI Infrastructure maintainers, Deployers or Builders teams. ### 2.4 Builders -Builders are those individuals that have permissions to build software through one or more of the EESSI build bots. +Adding software to EESSI requires three steps (see [the contribution workflow](../adding_software/overview.md) documentation): + +1. The software needs to be build +2. A tarball of the software installation needs to be uploaded to a central location (e.g. S3 bucket) where the Central Server for the EESSI CernVM-FS repository can pick it up +3. The Central Server for the EESSI CernVM-FS repository needs to ingest the tarball. See the documentation on [the contribution workflow](../adding_software/overview.md). -Builders are responsible for triggering builds for contributors who want to add software to the EESSI software stack. They are also responsible for checking the PR, so as to avoid execution of malicious code on the EESSI build infrastructure. +Builders are those individuals that have permissions to build software through one or more of the EESSI build bots, i.e. step 1 in this process. + +Builders are responsible for reviewing contributions. They should, for example, check that contributions adhere to the contribution guidelines, that a contribution will not trigger execution of any untintended or unwanted code, etc. They are also responsible for triggering builds for contributors who want to add software to the EESSI software stack. ### 2.5 Deployers -Deployers are those individuals that have permissions to deploy software through one or more of the EESSI build bots. These individuals also have merge permissions on the `EESSI/staging` repository. +Deployers are those individuals that have permissions to deploy software through one or more of the EESSI build bots to a central location (e.g. S3 bucket), i.e. they are essentially responsible for step 2 as it is described in Section 2.4. + +Deployers should check the file list of the produced tarballs (as it is reported by the build bot) for unexpected items. They should also check if all officially supported hardware targets have been built for. -Deployers are responsible for checking the produced tarballs, through the reports generated by the build bot (as part of the build step), as well as through checking the reports uploaded by the Stratum 0 in `EESSI/staging` PRs. They should ensure that the tarballs do not contain anything unexpected / malicious. +### 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 Section 2.4. -### 2.6 Contributors +Ingestors have merge permissions on the (private) `EESSI/staging` GitHub repository. -Contributors are individuals that make a pull request to one of the repositories in the EESSI Github organization. +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. -Contributors that add software are responsible for checking that the license of the software they want to add allows it's use in EESSI (e.g. allows redistribution). Contributors are also responsible for making sure their PRs don't add any malicious code. Finally, contributors should ensure that they adhere to the [Contribution Policy](../adding_software/contribution_policy.md). +### 2.7 Contributors -### 2.7 System administrators of systems providing EESSI +Contributors are individuals that make a contribution by opening a pull request to one of the repositories in the EESSI Github organization. + +Contributors that propose adding software to EESSI in their contributions are responsible for checking that the license of the software they want to add allows it's use in EESSI (e.g. allows redistribution). Contributors should also make an effort to ensure that their contributions don't add any malicious code. Finally, contributors should ensure that they adhere to the [Contribution Policy](../adding_software/contribution_policy.md). + +### 2.8 System administrators of systems providing EESSI System administrators of systems providing EESSI are administrators of systems (such as, but not limited to cloud and HPC systems) that make the EESSI software stack available to their users. -System administrators of systems providing EESSI are responsible for making sure that their system does not put any disproportional load on the public EESSI CernVM-FS infrastructure. Typically, this means that they are responsible for provisioning proper caching for their system, such as a private CernVM-FS Stratum 1, a proxy, and/or a properly sized local cache. +System administrators of systems providing EESSI should make sure that their system does not put any disproportional load on the public EESSI CernVM-FS infrastructure. Typically, this means that they should adhere to best practices for CernVM-FS caching in a way that fits the size and nature of their system (e.g. by setting up a private CernVM-FS Stratum 1, a proxy, and/or a properly sized local cache). -### 2.8 End-Users +System administrators have to agree to the EESSI [Terms of Use](terms_of_use.md). + +### 2.9 End-Users End-Users are individuals that use any of the software provided by the EESSI software stack. +End users have to agree to the EESSI [Terms of Use](terms_of_user.md). ## 3. Decision-Making @@ -160,4 +180,7 @@ The Steering Committee will meet as needed, but at least once per quarter. The C The EESSI Code of Conduct can be found [here](code_of_conduct.md). ## 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 +All commit messages for contributions should be signed by the contributor, i.e. they should contain the statement: "Signed-off-by: firstname lastname ". With that signature, the contributor agrees to the [Developer Certificate of Origin](https://developercertificate.org/). + +## 9. Review and Amendment +Changes to the governance require approval by the Steering Committee, as per the rules described the [Voting by the Steering Committee](governance.md#voting-by-the-steering-committee) section. From 18334ad9d61cef5df11cf894c2244f5844b8b226 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 23 Jun 2025 17:37:00 +0200 Subject: [PATCH 21/72] Add initial terms of use --- docs/governance/terms_of_use.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 docs/governance/terms_of_use.md diff --git a/docs/governance/terms_of_use.md b/docs/governance/terms_of_use.md new file mode 100644 index 0000000000..583808e67e --- /dev/null +++ b/docs/governance/terms_of_use.md @@ -0,0 +1,29 @@ +# EESSI – Terms of Use + +**Effective Date:** [Insert Date] + +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. + +## 2. Acceptable Use +Users must act responsibly and not misuse EESSI infrastructure or software. This includes refraining from unauthorized access, modification, or redistribution of components outside of the permitted licensing terms. + +## 3. Licensing +All software within EESSI is governed by its respective open-source or institutional license. Users must adhere to these licenses; EESSI does not override or alter them. + +## 4. Data Collection +Basic telemetry or usage data may be collected for monitoring and improvement of the project. This is handled in accordance with the **GDPR** and relevant EU data protection standards. + +## 5. No Guarantees +EESSI is provided “as-is.” Availability, performance, or correctness of the software stack is not guaranteed. Use is at your own risk. + +## 6. Liability +The EESSI maintainers and affiliated institutions are not liable for damages or losses arising from use of the software stack. + +## 7. Contributions and Collaboration +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]**. From 6862260b148786f5f6327a7b52d4c5d26f8402a9 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 23 Jun 2025 17:37:31 +0200 Subject: [PATCH 22/72] Add date to terms of use --- docs/governance/terms_of_use.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/terms_of_use.md b/docs/governance/terms_of_use.md index 583808e67e..6b3ba97de6 100644 --- a/docs/governance/terms_of_use.md +++ b/docs/governance/terms_of_use.md @@ -1,6 +1,6 @@ # EESSI – Terms of Use -**Effective Date:** [Insert Date] +**Effective Date:** 23 June 2025 By using the **European Environment for Scientific Software Installations (EESSI)**, you agree to the following terms: From e7fac73747110fabca43c968076f477c4c101eb9 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 23 Jun 2025 17:37:57 +0200 Subject: [PATCH 23/72] Revise section 2 of terms of use --- docs/governance/terms_of_use.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/docs/governance/terms_of_use.md b/docs/governance/terms_of_use.md index 6b3ba97de6..3bd9720215 100644 --- a/docs/governance/terms_of_use.md +++ b/docs/governance/terms_of_use.md @@ -8,7 +8,13 @@ By using the **European Environment for Scientific Software Installations (EESSI EESSI provides a shared scientific software stack for academic, research, and educational use. Access and usage are intended for non-commercial scientific computing. ## 2. Acceptable Use -Users must act responsibly and not misuse EESSI infrastructure or software. This includes refraining from unauthorized access, modification, or redistribution of components outside of the permitted licensing terms. +Users must act responsibly when accessing and using the EESSI infrastructure and software. In particular: + +- Do not overload or abuse the public EESSI mirror servers. Avoid excessive or automated requests that may disrupt service availability for other users. +- Use caching mechanisms where possible, and coordinate large-scale usage (e.g., automated deployments or CI pipelines) with the EESSI maintainers if in doubt. +- Refrain from unauthorized access, modification, or redistribution of software components outside the permitted licensing terms. + +Responsible use helps ensure reliable access for the entire scientific community. ## 3. Licensing All software within EESSI is governed by its respective open-source or institutional license. Users must adhere to these licenses; EESSI does not override or alter them. From 9db6ece8af312cf0fa88cf9297f7ed5cad885459 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 23 Jun 2025 17:42:34 +0200 Subject: [PATCH 24/72] Take out SBOM policy, replace with what we _can_ promise --- docs/governance/policies.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index dd13252d16..7eb6963564 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -111,11 +111,7 @@ Optimization for performance is strongly encouraged. For compiled software, this ## 4. Transparency and Traceability -### 4.1 Software Bill of Materials (SBOM) - -- 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. +EESSI aims to be transparant regarding how software was build. A combination of the git history, easybuild build logs, as well as the easybuild subdirectory within every installation (which provides the EasyConfig, EasyBlock, and any hooks used at installation time) provide a detailed description of how software was configured and built. --- @@ -131,4 +127,4 @@ Optimization for performance is strongly encouraged. For compiled software, this There are currently no Team Policies yet. -_Last updated: [Insert Date]_ +_Last updated: 23 June 2025_ From e1e4f772f39fea73a15c56dfd1860d64d9ac48bd Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 23 Jun 2025 17:44:04 +0200 Subject: [PATCH 25/72] Fix typos --- docs/governance/policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index 7eb6963564..1574c96b49 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -111,7 +111,7 @@ Optimization for performance is strongly encouraged. For compiled software, this ## 4. Transparency and Traceability -EESSI aims to be transparant regarding how software was build. A combination of the git history, easybuild build logs, as well as the easybuild subdirectory within every installation (which provides the EasyConfig, EasyBlock, and any hooks used at installation time) provide a detailed description of how software was configured and built. +EESSI aims to be transparent regarding how software was build. A combination of the git history, easybuild build logs, as well as the easybuild subdirectory within every installation (which provides the EasyConfig, EasyBlock, and any hooks used at installation time) provide a detailed description of how software was configured and built. --- From b24cbafc371a9bbad8b9039d08eb6531261d4ea4 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 23 Jun 2025 17:47:49 +0200 Subject: [PATCH 26/72] Fix typos --- docs/governance/charter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index 8435be344a..8c1c1cf9ed 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -22,7 +22,7 @@ The [European Environment for Scientific Software Installations](https://www.ees - Ready-to-use (served over the internet, just mount-and-go) - Optimized for a wide range of hardware architectures (CPU, GPU, interconnects) - Easily extendable with additional local installations -- Customizeable (e.g. site-spefici LMOD hooks, injecting a local MPI, etc) +- Customizable (e.g. site-spefici LMOD hooks, injecting a local MPI, etc) and can be used on any Linux (virtual) machine. From 4db5a89fb72622ecd68c6655d223fae616f8cc53 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 23 Jun 2025 17:50:16 +0200 Subject: [PATCH 27/72] Make overview page and redirect original governance page there --- mkdocs.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mkdocs.yml b/mkdocs.yml index 1ae2eff89a..963d537085 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -78,10 +78,12 @@ nav: - Contact info: contact.md - Systems where EESSI is available: systems.md - Governance: + - Overview: governance/index.md - Charter: governance/charter.md - Governance: governance/governance.md - EESSI Policies: governance/policies.md - Code of Conduct: governance/code_of_conduct.md + - Terms of Use: governance/terms_of_use.md - Current Steering Committee: governance/steering_committee.md - Blog: blog/index.md plugins: @@ -102,6 +104,7 @@ plugins: contributing_sw/deploying_software.md: adding_software/deploying_software.md contributing_sw/opening_pr.md: adding_software/opening_pr.md contributing_sw/overview.md: adding_software/overview.md + governance.md: governance/index.md software_layer/adding_software.md: adding_software/overview.md pilot.md: repositories/pilot.md gpu.md: site_specific_config/gpu.md From 3af41caeddae5d7e7553b593f866624585ff3029 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen <33718780+casparvl@users.noreply.github.com> Date: Thu, 31 Jul 2025 16:37:45 +0200 Subject: [PATCH 28/72] Update docs/governance/governance.md --- docs/governance/governance.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 141ecf36a0..54b5002aa3 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -143,7 +143,12 @@ The Steering Committee shall be responsible for: The Steering Committee is made up of community members with sustained and recognized contributions over time. Members take part in the Steering Committee as private individuals (i.e. they do not represent their employer(s)). -Members will be removed from the committee if they resign. Furthermore, if a Member is inactive for 6 Months and does not reply to communication from the rest of the Steering Committee, the Member may be voted out by the other Steering Committee members (regular voting rules, as per section 6.3, apply). Finally, a Member may be voted out. In this case, the vote needs to be unanimous between the other Members. +Membership of the Steering Committe can terminate in three ways: + +- A Member can resign +- A Member may be voted out. In this case, the vote needs to be unanimous between the other Members. +- If a Member is inactive for 6 Months and does not reply to communication from the rest of the Steering Committee, the Member may be voted out by the other Steering Committee members. In this case, regular voting rules, as per section 6.3, apply. + New Members are recommended by the Steering Committee. The Steering Committee will make the recommendation known to the community, and collect feedback on the recommendation. The Steering Committee then weighs the feedback, and votes on whether to accept the new member. In the selection process, the Steering Committee will consider the following: - The Steering Committee ideally consists of an odd number of Members From 681554bfcaf7d9165eb4f86b8adfe717d609ef7d Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 10:17:35 +0200 Subject: [PATCH 29/72] Fix typos --- docs/governance/governance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 54b5002aa3..39384bc391 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -4,7 +4,7 @@ A project charter discusses _what it is and why it exists_, a governance discuss # Project Governance -As stated in the [Charter](charter.md), this project governance _only_ covers collaboration on the software.eessi.io CernVM-FS repository, it does not cover other CernVM-FS repositories under the eessi.io namespace. In other words, when the sections below mention the EESSI CernVM-FS repository, this implies the software.eessi.io repository specifically. Thus, this governance only addresses contributing to, building for, deploying to, ingesting in, providing, or using the software.eessi.io respository. +As stated in the [Charter](charter.md), this project governance _only_ covers collaboration on the software.eessi.io CernVM-FS repository, it does not cover other CernVM-FS repositories under the eessi.io namespace. In other words, when the sections below mention the EESSI CernVM-FS repository, this implies the software.eessi.io repository specifically. Thus, this governance only addresses contributing to, building for, deploying to, ingesting in, providing, or using the software.eessi.io repository. The only exception to this is the Steering Committee, which has authority over all the eessi.io CernFM-FS repositories. @@ -143,7 +143,7 @@ The Steering Committee shall be responsible for: The Steering Committee is made up of community members with sustained and recognized contributions over time. Members take part in the Steering Committee as private individuals (i.e. they do not represent their employer(s)). -Membership of the Steering Committe can terminate in three ways: +Membership of the Steering Committee can terminate in three ways: - A Member can resign - A Member may be voted out. In this case, the vote needs to be unanimous between the other Members. From cf02ed964a32a2d51a7b4a4a55aa6bae4a195262 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 4 Aug 2025 10:26:29 +0200 Subject: [PATCH 30/72] tweaks to governance (sections 3-9) --- docs/governance/governance.md | 87 +++++++++++++++++++++++++---------- 1 file changed, 63 insertions(+), 24 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 39384bc391..afc2c2c3fd 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -4,9 +4,9 @@ A project charter discusses _what it is and why it exists_, a governance discuss # Project Governance -As stated in the [Charter](charter.md), this project governance _only_ covers collaboration on the software.eessi.io CernVM-FS repository, it does not cover other CernVM-FS repositories under the eessi.io namespace. In other words, when the sections below mention the EESSI CernVM-FS repository, this implies the software.eessi.io repository specifically. Thus, this governance only addresses contributing to, building for, deploying to, ingesting in, providing, or using the software.eessi.io repository. +As stated in the [Charter](charter.md), this project governance _only_ covers collaboration on the `software.eessi.io` CernVM-FS repository, it does not cover other CernVM-FS repositories under the eessi.io namespace. In other words, when the sections below mention the EESSI CernVM-FS repository, this implies the `software.eessi.io` repository specifically. Thus, this governance only addresses contributing to, building for, deploying to, ingesting in, providing, or using the `software.eessi.io` repository. -The only exception to this is the Steering Committee, which has authority over all the eessi.io CernFM-FS repositories. +The only exception to this is the Steering Committee, which has authority over all the `eessi.io` CernFM-FS repositories. ## 1. Guiding Principles @@ -71,45 +71,47 @@ System administrators of systems providing EESSI are administrators of systems ( System administrators of systems providing EESSI should make sure that their system does not put any disproportional load on the public EESSI CernVM-FS infrastructure. Typically, this means that they should adhere to best practices for CernVM-FS caching in a way that fits the size and nature of their system (e.g. by setting up a private CernVM-FS Stratum 1, a proxy, and/or a properly sized local cache). -System administrators have to agree to the EESSI [Terms of Use](terms_of_use.md). +System administrators agree to the [Terms of Use](terms_of_use.md) when making EESSI available on the systems they manage. ### 2.9 End-Users End-Users are individuals that use any of the software provided by the EESSI software stack. -End users have to agree to the EESSI [Terms of Use](terms_of_user.md). +End users agree to the [Terms of Use](terms_of_use.md) when using the software installations provided by EESSI. ## 3. Decision-Making This section applies to the decision making procedure for the Teams discussed in Section 2. The Steering Committee has its own Decision-Making procedure. ### 3.1 Consensus Seeking - + Decisions are made by seeking consensus. Each Team member is responsible for deciding whether an issue or decision is significant or sensitive enough to warrant discussions within their Team. If so, they should bring it up through the agreed-upon channels (see Section 4). ### 3.2 Voting - + There is no formal voting for Teams, for two reasons: + 1. The Teams may be too big to organize voting in a quick, practical way. 2. The obligation to take part in votes may discourage people to become part of these Teams, as it may be seen as a burden. Voting may nonetheless be used as a way to achieve consensus. For example, asking (a relevant subset of) the Team to vote may be one way to determine the majority opinion. Then, it can be discussed if the majority vote is an acceptable outcome to the Team. If so, consensus is achieved. ### 3.3 Deadlock Resolution - + If consensus cannot be reached within the Team, the Steering Committee can take the decision for them. This can be requested by the Team, or done at the initiative of the Steering Committee (if they feel the lack of a decision is preventing the project from moving forward). Also, if multiple Teams claim ownership over an issue, the Steering Committee can decide which Team is allowed to decide over the issue. ### 3.4 Overturning decisions - + The goal is for Teams to operate autonomously as much as possible. However, in exceptional cases, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort. Examples of when this may be considered is if the Steering Committee feels that a decision endangers the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. ## 4. Meetings and Communication - + While each Team is allowed to use the communication channels that their Team jointly agrees upon, the following channels are suggested + - GitHub / GitLab issues - Slack - (Periodic or incidental) video calls @@ -118,63 +120,100 @@ While each Team is allowed to use the communication channels that their Team joi This Section applies to the Teams described in Section 2. ### 5.1 Adding Team Members - + Teams themselves decide how large their teams should ideally be. They also decide the procedure to add new Team members. The procedure should reflect the sensitivity of the position, i.e. people with certain roles have the ability to (intentionally or unintentionally) compromise the integrity of the repository. For such roles, the procedure should make sure candidates are extensively vetted and trusted by both the Team as well as the EESSI community as a whole. As with all decisions the decision to add a Team member is subject to article 3.4. ### 5.2 Removing Team Members - + 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. As with all decisions, the decision to remove a Team member is subject to article 3.4. -## 6 Steering committte +## 6 Steering committtee + ### 6.1 Responsibilities The Steering Committee shall be responsible for: -- Setting the technical direction of the EESSI project and identifying key technical priorities + +- Outlining the technical direction of the EESSI project and setting priorities - Conflict resolution: if there is a conflict between the people with the aforementioned roles, the steering committee shall mediate the dispute and make a final decision if consensus cannot be reached -- The EESSI Charter (`charter.md`) -- The EESSI Governance (`governance.md`) -- The EESSI Policies (`policies.md`) +- The [EESSI Charter](charter.md) +- The [EESSI Governance](governance.md) +- The [EESSI Policies](policies.md) ### 6.2 Members and Chairs The Steering Committee is made up of community members with sustained and recognized contributions over time. Members take part in the Steering Committee as private individuals (i.e. they do not represent their employer(s)). +#### 6.2.1 Termination of membership + Membership of the Steering Committee can terminate in three ways: - A Member can resign - A Member may be voted out. In this case, the vote needs to be unanimous between the other Members. -- If a Member is inactive for 6 Months and does not reply to communication from the rest of the Steering Committee, the Member may be voted out by the other Steering Committee members. In this case, regular voting rules, as per section 6.3, apply. +- If a Member is inactive for 6 months and does not reply to communication from the rest of the Steering Committee, the Member may be voted out by the other Steering Committee members. In this case, regular voting rules, as per section 6.3, apply. + +#### 6.2.2 New members + +New Members must be recommended by one or more Steering Committee members. +The Steering Committee will make the recommendation known to the community, and collect feedback on the recommendation. +The Steering Committee then weighs the feedback, and votes on whether to accept the new member. -New Members are recommended by the Steering Committee. The Steering Committee will make the recommendation known to the community, and collect feedback on the recommendation. The Steering Committee then weighs the feedback, and votes on whether to accept the new member. In the selection process, the Steering Committee will consider the following: -- The Steering Committee ideally consists of an odd number of Members -- No more than 30% of the Members should be employed by commercial entities -- The number of Members working for the same company should be limited to 1 -- The number of Members from the same country should be limited to 2 -- The composition of the Steering Committee should reflect the EESSI community +In the selection process, the Steering Committee will consider the following: + +- The Steering Committee ideally consists of an odd number of Members; +- No more than 30% of the Members should be employed by commercial entities; +- The number of Members working for the same company should be limited to 1; +- The number of Members from the same country should be limited to 2; +- The composition of the Steering Committee should reflect the EESSI community; Note that if Members change jobs, or move to another country, some of the above criteria that were taken into account during selection may no longer be satisfied. It is up to the Steering Committee to decide if this is problematic, and if so, try to restore balance by requesting someone to resign. All new Members will appoint an alternate that may represent them and vote on their behalf in case they are unavailable. If a Member resigns or is voted out from the Steering Committee, their alternate immediately loses any rights they had as an alternate. +#### 6.2.3 Chair + A Chair will be appointed by the Steering Committee to serve for a one-year term. ### 6.3 Voting by the Steering Committee -General decisions are taken by majority vote, provided that at least 75% of the Members cast a vote. Votes can be cast either in person, participating electronically, or via electronic vote (such as by e-mail). Members can cast a neutral vote, in which case the vote does count towards the quorum of 75%, but is not including in calculating the majority. Example: in a committee with 7 members, if 3 members vote in favour of a proposal, 2 vote against, and one votes neutral, the quorum is met (6 out of 7 members have voteded, i.e. >75%), and the majority (3 out of 5 non-neutral votes) is in favour, so the proposal is accepted. Members can also abstain from voting, in which case they neither count towards the quorum or calculating the majority. Example: in a committee with 7 members, if 3 members vote in favor, 2 vote against, and one abstains from voting, the quorum of 6 (75% of 7 members, rounded up) is not met. +#### 6.3.1 Majority vote + +General decisions are taken by majority vote, provided that at least 75% of the Members cast a vote. + +#### 6.3.2 Ways of voting + +Votes can be cast either in person, participating electronically, or via electronic vote (such as by e-mail). + +#### 6.3.3 Neutral votes + +Members can cast a neutral vote, in which case the vote does count towards the quorum of 75%, but is not including in calculating the majority. Example: in a committee with 7 members, if 3 members vote in favour of a proposal, 2 vote against, and one votes neutral, the quorum is met (6 out of 7 members have voted, i.e. >75%), and the majority (3 out of 5 non-neutral votes) is in favour, so the proposal is accepted. + +#### 6.3.4 Abstaining + +Members can also abstain from voting, in which case they neither count towards the quorum or calculating the majority. Example: in a committee with 7 members, if 3 members vote in favor, 2 vote against, and one abstains from voting, the quorum of 6 (75% of 7 members, rounded up) is not met. + +#### 6.3.5 Ties In case of a tie, the issue is discussed again, and a second vote is taken. All Members that voted in the first round need to have the opportunity to vote in the second round, which may mean that the vote needs to be postponed to a next meeting (e.g. because one or more Members voted by e-mail, and are not present at the meeting). +#### 6.3.6 Failing to reach quorum + In case the quorum of 75% is not reached, the vote is postponed. +#### 6.3.7 Fully electronic vote + A fully electronic vote (i.e. all Members vote electronically) can be organized by the Chair, in order to prevent having to delay a vote to the next meeting. Such a fully electronic vote is only valid once _all_ Members have cast their vote, or have explicitly stated that they abstain from voting. +#### 6.3.8 Voting topics + Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announced at least one week prior to the meeting, to give Members the opportunity to cast an electronic vote if they cannot attend. +#### 6.3.9 Votes on amending Charter or Governance + To amend the Charter or Governance, a two-thirds majority of all Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at a meeting. There is no quorum for votes on amendments to the Charter or Governance. ### 6.4 Meetings From db475938280d093b147adf3e511dc339ff42f26a Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 4 Aug 2025 10:32:27 +0200 Subject: [PATCH 31/72] fix link to governance in charter --- docs/governance/charter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index 8c1c1cf9ed..ebb4c96782 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -44,4 +44,4 @@ There are additional CernVM-FS repositories under the eessi.io namespace, such a There is currently no membership. Any individual or institution may participate by using EESSI, contributing to EESSI, making EESSI available on systems managed by them, etc. ## 4. Review and Amendment -Changes to the charter require approval by the Steering Committee. See the [relevant section of the Governance](../governance.md#voting-by-the-steering-committee). +Changes to the charter require approval by the Steering Committee. See the [relevant section of the Governance](governance.md#voting-by-the-steering-committee). From f2ba53bbea8274542ba125b1825af1eb1e202d18 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 4 Aug 2025 10:32:47 +0200 Subject: [PATCH 32/72] don't link to EESSI GitHub org in section title --- docs/governance/governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index afc2c2c3fd..a8556e5a9d 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -20,7 +20,7 @@ To achieve both goals, our governance is based on the [meritocracy](https://en.w Below, the roles and responsibilities related to the EESSI project are discussed. The group of people with a common role will be referred to as a Team in the remainder of this document. Exceptions are Contributors, System administrators of systems providing EESSI and End-users (these are not considered to be Teams). Each individual in a Team will be referred to as a Team Member. -### 2.1 Owners of the [EESSI GitHub organization](https://github.com/EESSI) & repositories +### 2.1 Owners of the `EESSI` GitHub organization & repositories The owners of the [EESSI GitHub organization](https://github.com/EESSI) & repositories are those individuals with `owner` rights on the EESSI GitHub organization or one of it's associated repositories. From 16fb73abf0b42b43ac6eca06d5e1fdd1488aab21 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 4 Aug 2025 10:33:28 +0200 Subject: [PATCH 33/72] Github -> GitHub --- docs/governance/governance.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index a8556e5a9d..71a48f8f7c 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -24,12 +24,12 @@ Below, the roles and responsibilities related to the EESSI project are discussed The owners of the [EESSI GitHub organization](https://github.com/EESSI) & repositories are those individuals with `owner` rights on the EESSI GitHub organization or one of it's associated repositories. -EESSI Github organization & repository owners are responsible for setting permissions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing Github Apps for the EESSI build bots. +EESSI GitHub organization & repository owners are responsible for setting permissions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing GitHub Apps for the EESSI build bots. -### 2.2 EESSI Github repository maintainers -EESSI Github repository maintainers are individuals with write access (one or more) of the EESSI Github repositories. +### 2.2 EESSI GitHub repository maintainers +EESSI GitHub repository maintainers are individuals with write access (one or more) of the EESSI GitHub repositories. -EESSI Github repository maintainers are responsible for reviewing and merging PRs. +EESSI GitHub repository maintainers are responsible for reviewing and merging PRs. ### 2.3 EESSI Infrastructure maintainers EESSI Infrastructure maintainers are those individuals that maintain the Central Server for the EESSI CernVM-FS repository (the CernVM-FS Stratum 0), one of the _public_ mirror servers (CernVM-FS Stratum 1's), build infrastructure (e.g. hosting the EESSI build bot, the SMEE server). @@ -61,7 +61,7 @@ Ingestors should check the contents of the tarball as it is reported in the pull ### 2.7 Contributors -Contributors are individuals that make a contribution by opening a pull request to one of the repositories in the EESSI Github organization. +Contributors are individuals that make a contribution by opening a pull request to one of the repositories in the EESSI GitHub organization. Contributors that propose adding software to EESSI in their contributions are responsible for checking that the license of the software they want to add allows it's use in EESSI (e.g. allows redistribution). Contributors should also make an effort to ensure that their contributions don't add any malicious code. Finally, contributors should ensure that they adhere to the [Contribution Policy](../adding_software/contribution_policy.md). From 52446ff27ed438d48c253d2bf15e52d70e08bbe6 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 4 Aug 2025 10:34:11 +0200 Subject: [PATCH 34/72] fix sentence in section 2.2 of governance --- docs/governance/governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 71a48f8f7c..5dfa90a90e 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -27,7 +27,7 @@ The owners of the [EESSI GitHub organization](https://github.com/EESSI) & reposi EESSI GitHub organization & repository owners are responsible for setting permissions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing GitHub Apps for the EESSI build bots. ### 2.2 EESSI GitHub repository maintainers -EESSI GitHub repository maintainers are individuals with write access (one or more) of the EESSI GitHub repositories. +EESSI GitHub repository maintainers are individuals with write access to (one or more of) the EESSI GitHub repositories. EESSI GitHub repository maintainers are responsible for reviewing and merging PRs. From d4a45e5e3a6be18a98863e2986ca2292c6fcb3c6 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 4 Aug 2025 10:51:03 +0200 Subject: [PATCH 35/72] clarify sentence in section 2.3 + avoid linking to contribution workflow twice in section 2.4 --- docs/governance/governance.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 5dfa90a90e..feeec87aec 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -32,16 +32,16 @@ EESSI GitHub repository maintainers are individuals with write access to (one or EESSI GitHub repository maintainers are responsible for reviewing and merging PRs. ### 2.3 EESSI Infrastructure maintainers -EESSI Infrastructure maintainers are those individuals that maintain the Central Server for the EESSI CernVM-FS repository (the CernVM-FS Stratum 0), one of the _public_ mirror servers (CernVM-FS Stratum 1's), build infrastructure (e.g. hosting the EESSI build bot, the SMEE server). +EESSI Infrastructure maintainers are those individuals that maintain the Central Server for the EESSI CernVM-FS repository (the CernVM-FS Stratum 0), the _public_ mirror servers (CernVM-FS Stratum 1's), and EESSI build infrastructure (e.g. hosting the EESSI build bot). Infrastructure maintainers are responsible for monitoring and maintaining their respective infrastructure, and provide access to those who needed it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Deployers and Builders as described in 2.4 and 2.5. Furthermore, they are _not_ allowed to give access to others that are not part of the EESSI Infrastructure maintainers, Deployers or Builders teams. ### 2.4 Builders Adding software to EESSI requires three steps (see [the contribution workflow](../adding_software/overview.md) documentation): -1. The software needs to be build -2. A tarball of the software installation needs to be uploaded to a central location (e.g. S3 bucket) where the Central Server for the EESSI CernVM-FS repository can pick it up -3. The Central Server for the EESSI CernVM-FS repository needs to ingest the tarball. See the documentation on [the contribution workflow](../adding_software/overview.md). +1. The software needs to be built (compiled); +2. A tarball of the software installation needs to be uploaded to a central location (e.g. S3 bucket) where the Central Server for the EESSI CernVM-FS repository can pick it up; +3. The Central Server for the EESSI CernVM-FS repository needs to ingest the tarball. Builders are those individuals that have permissions to build software through one or more of the EESSI build bots, i.e. step 1 in this process. From 7f72cd4b18042cfc75cf699931c3d2285174b56c Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 4 Aug 2025 11:28:37 +0200 Subject: [PATCH 36/72] add governance/index.md --- docs/governance/index.md | 6 ++++++ docs/index.md | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) create mode 100644 docs/governance/index.md diff --git a/docs/governance/index.md b/docs/governance/index.md new file mode 100644 index 0000000000..b621d660fd --- /dev/null +++ b/docs/governance/index.md @@ -0,0 +1,6 @@ +- Charter: charter.md +- Governance: governance.md +- Policies: policies.md +- Code of Conduct: code_of_conduct.md +- Terms of Use: terms_of_use.md +- Current Steering Committee: steering_committee.md diff --git a/docs/index.md b/docs/index.md index 38aba6dba6..d149b164ac 100644 --- a/docs/index.md +++ b/docs/index.md @@ -20,7 +20,7 @@ personal workstations and cloud infrastructure. * [What is EESSI?](overview.md) * [Contact info](contact.md) -* [Governance](governance.md) +* [Governance](governance/index.md) For users: From a1029ae6ebfb50be2caf7b45a676d0b6cae07100 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 4 Aug 2025 11:29:04 +0200 Subject: [PATCH 37/72] rename menu item for Policies under Governance --- mkdocs.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mkdocs.yml b/mkdocs.yml index 963d537085..550ace02b2 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -81,7 +81,7 @@ nav: - Overview: governance/index.md - Charter: governance/charter.md - Governance: governance/governance.md - - EESSI Policies: governance/policies.md + - Policies: governance/policies.md - Code of Conduct: governance/code_of_conduct.md - Terms of Use: governance/terms_of_use.md - Current Steering Committee: governance/steering_committee.md From 9e48b26bb66d404a04e41aaa04efcea400d9c329 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 4 Aug 2025 11:29:14 +0200 Subject: [PATCH 38/72] small tweaks to policies --- docs/governance/policies.md | 59 ++++++++++++------------------------- 1 file changed, 19 insertions(+), 40 deletions(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index 1574c96b49..003338aff4 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -1,30 +1,3 @@ - - - - - - # Policy Scope and Hierarchy - **Project Policies** are defined and maintained by the Steering Committee. @@ -43,19 +16,19 @@ This document outlines project-wide policies that guide the development, deploym ### 2.1 Architecture Support -- EESSI aims to build and support software for a wide range of relevant hardware architectures. Currently supported architectures are listed [here](../software-layer/cpu_targets.md). -- If a package is unavailable for a specific architecture, a clear runtime message (e.g., via modulefile error) should be provided to the user. -- When optimization for a specific microarchitecture is not possible, a compatible fallback (e.g., zen3 for zen4) should be provided if available. A clear runtime warning will be printed. +- EESSI aims to build and support software for a wide range of relevant hardware architectures. Currently supported CPU microarchitectures are listed [here](../software_layer/cpu_targets.md). +- If a package is unavailable for a specific CPU microarchitecture, a clear runtime message (e.g., via modulefile error) should be provided to the user. +- When optimization for a specific CPU microarchitecture is not possible, a compatible fallback (e.g., zen3 for zen4) should be provided if available. A clear runtime warning will be printed. ### 2.2 Rebuild Policy Reproducibility is important in scientific computing. Thus, we exercise restraint in rebuilding software. A list of scenarios in which software may be rebuilt is: -- The software contained security vulnerabilities -- There were updates to the (list of) dependencies, e.g. some optional dependency was missing which restricted functionality of the original installation -- There were (unintended) differences between the software installations for different (micro)architectures -- The original installation (or a substantial part thereof) was found to be broken. Not that this does _not_ apply to small bugs. -- Mistakes in the original installation prevent it from being used as a dependency for other software +- The software installation contained security vulnerabilities; +- There were updates to the (list of) dependencies, e.g. some optional dependency was missing which restricted functionality of the original installation; +- There were (unintended) differences between the software installations for different (micro)architectures; +- The original installation (or a substantial part thereof) was found to be broken. Not that this does _not_ apply to small bugs; +- Mistakes in the original installation prevent it from being used as a dependency for other software. Additionally, software may be rebuilt for other reasons if there is sufficient consensus within the EESSI Community that this is beneficial. @@ -74,7 +47,10 @@ Installations of individual software packages in a (non-deprecated) EESSI softwa #### 2.4.1 Removal of EESSI software stack versions -Since CernVM-FS Stratum 1 servers have to fully mirror the repository, old EESSI software stack versions will have to be removed to keep the storage footprint within reasonable limits. This will only be done after: +Since CernVM-FS Stratum 1 servers have to fully mirror the repository, old EESSI software stack versions will have to be removed to keep the storage footprint within reasonable limits. + +This will only be done after: + - The EESSI software stack version has been deprecated for at least 1 year - The EESSI software stack version has been archived in _some_ form in which it can still be used by end-users (e.g. as a tarball, an exported CVMFS repository using CernVM-FS Shrinkwrap, or some other form). @@ -83,6 +59,7 @@ A clear runtime error will be printed when an end-user tries to initialize a rem #### 2.4.2 Removal of individual software installations An individual software installation in EESSI may be removed if: + - It violates licensing terms - It poses a security risk - It is no longer maintainable or functional. @@ -111,15 +88,17 @@ Optimization for performance is strongly encouraged. For compiled software, this ## 4. Transparency and Traceability -EESSI aims to be transparent regarding how software was build. A combination of the git history, easybuild build logs, as well as the easybuild subdirectory within every installation (which provides the EasyConfig, EasyBlock, and any hooks used at installation time) provide a detailed description of how software was configured and built. +EESSI aims to be transparent regarding how software was build. A combination of the git history, EasyBuild logs, as well as the `easybuild` subdirectory within every installation (which provides the easyconfig and patch files, easyblock, and any hooks used at installation time) provide a detailed description of how software was configured and built. --- ## 5. Platform Prioritization -- In cases where technical choices must be made between HPC, Cloud, or PC environments: - - **HPC compatibility and performance are prioritized**, especially for optimization-related decisions. - - This does not imply exclusion of other platforms, but reflects the project's primary use case. +**HPC compatibility and performance are prioritized**, +in cases where technical choices must be made between HPC, Cloud, or PC environments, +especially for optimization-related decisions. + +This does not imply exclusion of other platforms, but reflects the project's primary use case. --- From 217369f7d22b732386dd6cc9bf05f0cae65b1c28 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 11:50:17 +0200 Subject: [PATCH 39/72] Fix typo --- docs/governance/policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index 003338aff4..0616a3bc8e 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -27,7 +27,7 @@ Reproducibility is important in scientific computing. Thus, we exercise restrain - The software installation contained security vulnerabilities; - There were updates to the (list of) dependencies, e.g. some optional dependency was missing which restricted functionality of the original installation; - There were (unintended) differences between the software installations for different (micro)architectures; -- The original installation (or a substantial part thereof) was found to be broken. Not that this does _not_ apply to small bugs; +- The original installation (or a substantial part thereof) was found to be broken. Note that this does _not_ apply to small bugs; - Mistakes in the original installation prevent it from being used as a dependency for other software. Additionally, software may be rebuilt for other reasons if there is sufficient consensus within the EESSI Community that this is beneficial. From ea9647aeeba39522d966e6d2d645709167caa1ef Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 12:05:13 +0200 Subject: [PATCH 40/72] Changed references to sections into links --- docs/governance/governance.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index feeec87aec..79d21e8f34 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -16,7 +16,7 @@ The second goal of this governance is to make clear how and by whom decisions in To achieve both goals, our governance is based on the [meritocracy](https://en.wikipedia.org/wiki/Meritocracy) governance model. -## 2. Roles and Responsibilities +## 2. Roles and Responsibilities {#roles-and-responsibilities} Below, the roles and responsibilities related to the EESSI project are discussed. The group of people with a common role will be referred to as a Team in the remainder of this document. Exceptions are Contributors, System administrators of systems providing EESSI and End-users (these are not considered to be Teams). Each individual in a Team will be referred to as a Team Member. @@ -36,7 +36,7 @@ EESSI Infrastructure maintainers are those individuals that maintain the Central Infrastructure maintainers are responsible for monitoring and maintaining their respective infrastructure, and provide access to those who needed it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Deployers and Builders as described in 2.4 and 2.5. Furthermore, they are _not_ allowed to give access to others that are not part of the EESSI Infrastructure maintainers, Deployers or Builders teams. -### 2.4 Builders +### 2.4 Builders {#builders} Adding software to EESSI requires three steps (see [the contribution workflow](../adding_software/overview.md) documentation): 1. The software needs to be built (compiled); @@ -48,12 +48,12 @@ Builders are those individuals that have permissions to build software through o Builders are responsible for reviewing contributions. They should, for example, check that contributions adhere to the contribution guidelines, that a contribution will not trigger execution of any untintended or unwanted code, etc. They are also responsible for triggering builds for contributors who want to add software to the EESSI software stack. ### 2.5 Deployers -Deployers are those individuals that have permissions to deploy software through one or more of the EESSI build bots to a central location (e.g. S3 bucket), i.e. they are essentially responsible for step 2 as it is described in Section 2.4. +Deployers are those individuals that have permissions to deploy software through one or more of the EESSI build bots to a central location (e.g. S3 bucket), i.e. they are essentially responsible for step 2 as it is described in the [Builders](#builders) Section. Deployers should check the file list of the produced tarballs (as it is reported by the build bot) for unexpected items. They should also check if all officially supported hardware targets have been built for. ### 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 Section 2.4. +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. @@ -81,11 +81,11 @@ End users agree to the [Terms of Use](terms_of_use.md) when using the software i ## 3. Decision-Making -This section applies to the decision making procedure for the Teams discussed in Section 2. The Steering Committee has its own Decision-Making procedure. +This section applies to the decision making procedure for the Teams discussed in the [Roles and Responsibilities](#roles-and-responsibilities) Section. The Steering Committee has its own Decision-Making procedure (defined in the [Voting by the Steering Communittee](#voting-by-sc) Section). ### 3.1 Consensus Seeking -Decisions are made by seeking consensus. Each Team member is responsible for deciding whether an issue or decision is significant or sensitive enough to warrant discussions within their Team. If so, they should bring it up through the agreed-upon channels (see Section 4). +Decisions are made by seeking consensus. Each Team member is responsible for deciding whether an issue or decision is significant or sensitive enough to warrant discussions within their Team. If so, they should bring it up through the agreed-upon channels (see the [Meetings and Communication](#meetings-and-communication) Section). ### 3.2 Voting @@ -108,7 +108,7 @@ The goal is for Teams to operate autonomously as much as possible. However, in exceptional cases, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort. Examples of when this may be considered is if the Steering Committee feels that a decision endangers the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. -## 4. Meetings and Communication +## 4. Meetings and Communication {#meetings-and-communication} While each Team is allowed to use the communication channels that their Team jointly agrees upon, the following channels are suggested @@ -117,7 +117,7 @@ While each Team is allowed to use the communication channels that their Team joi - (Periodic or incidental) video calls ## 5. Onboarding and Offboarding -This Section applies to the Teams described in Section 2. +This Section applies to the Teams described in the [Roles and Responsibilities](#roles-and-responsibilities) Section. ### 5.1 Adding Team Members @@ -178,7 +178,7 @@ All new Members will appoint an alternate that may represent them and vote on th A Chair will be appointed by the Steering Committee to serve for a one-year term. -### 6.3 Voting by the Steering Committee +### 6.3 Voting by the Steering Committee {#voting-by-sc} #### 6.3.1 Majority vote From 50f5678d85a53bddd95e8c1cba4cb7f32d1f8821 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 12:25:28 +0200 Subject: [PATCH 41/72] Changes based on @boegel's review --- docs/governance/governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 79d21e8f34..8ca9004c1a 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -121,7 +121,7 @@ This Section applies to the Teams described in the [Roles and Responsibilities]( ### 5.1 Adding Team Members -Teams themselves decide how large their teams should ideally be. They also decide the procedure to add new Team members. The procedure should reflect the sensitivity of the position, i.e. people with certain roles have the ability to (intentionally or unintentionally) compromise the integrity of the repository. For such roles, the procedure should make sure candidates are extensively vetted and trusted by both the Team as well as the EESSI community as a whole. +Teams themselves decide how large their teams should ideally be. They also decide the procedure to add new Team members. The procedure should reflect the sensitivity of the position, i.e. people with certain roles have the ability to (intentionally or unintentionally) compromise the integrity of the EESSI infrastructure. For such roles, the procedure should make sure candidates are extensively vetted and trusted by both the Team as well as the EESSI community as a whole. As with all decisions the decision to add a Team member is subject to article 3.4. From 10d4c9d75882cd34f4772f1457c29b2a6348caf0 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen <33718780+casparvl@users.noreply.github.com> Date: Mon, 4 Aug 2025 12:26:26 +0200 Subject: [PATCH 42/72] Apply suggestions from code review Co-authored-by: Kenneth Hoste --- docs/governance/charter.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index ebb4c96782..84b047af96 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -22,18 +22,20 @@ The [European Environment for Scientific Software Installations](https://www.ees - Ready-to-use (served over the internet, just mount-and-go) - Optimized for a wide range of hardware architectures (CPU, GPU, interconnects) - Easily extendable with additional local installations -- Customizable (e.g. site-spefici LMOD hooks, injecting a local MPI, etc) +- Customizable (e.g. site-specific Lmod hooks, injecting a local MPI library, etc.) and can be used on any Linux (virtual) machine. ## 2. Scope -EESSI focusses on creating a [CernVM-FS repository](https://cvmfs.readthedocs.io/en/stable/cpt-repo.html) of software installations (software.eessi.io). This requires: +EESSI focusses on creating a [CernVM-FS repository](https://cvmfs.readthedocs.io/en/stable/cpt-repo.html) of software installations (`software.eessi.io`). + +This requires: - Source code to automate the process of building and deploying additional software installations in `software.eessi.io` - Source code to provide a user-friendy interface on end-user systems -- infrastructure to build new software for software.eessi.io -- infrastructure to host the CernVM-FS repository for software.eessi.io +- Infrastructure to build new software for `software.eessi.io` +- Infrastructure to host the CernVM-FS repository for `software.eessi.io` All of these (both code and infrastructure itself) are considered 'in scope' for the project. From 9522c004bc54547f897afc9fe7670e275741ca0c Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 12:27:43 +0200 Subject: [PATCH 43/72] Fix grammar --- docs/governance/governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 8ca9004c1a..27d1e6f803 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -131,7 +131,7 @@ Teams themselves decide the procedure to remove Team members. As for the procedu As with all decisions, the decision to remove a Team member is subject to article 3.4. -## 6 Steering committtee +## 6 Steering committee ### 6.1 Responsibilities From f182390f2e9dba248f3b01f569b90da538e510ff Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 12:37:01 +0200 Subject: [PATCH 44/72] Clarify what the procudure of removing members through unanimous vote is meant to resolve --- docs/governance/governance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 27d1e6f803..2a2a591f37 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -152,8 +152,8 @@ The Steering Committee is made up of community members with sustained and recogn Membership of the Steering Committee can terminate in three ways: - A Member can resign -- A Member may be voted out. In this case, the vote needs to be unanimous between the other Members. -- If a Member is inactive for 6 months and does not reply to communication from the rest of the Steering Committee, the Member may be voted out by the other Steering Committee members. In this case, regular voting rules, as per section 6.3, apply. +- A Member may be voted out. In this case, the vote needs to be unanimous between the other Members. This procedure is intended to provide a mechanism for addressing extraordinary circumstances where a members behavior or actions are deemed severely detrimental to the committee's function or reputation, and/or to the EESSI project. +- If a Member is inactive for 6 months and does not reply to communication from the rest of the Steering Committee, the Member may be voted out by the other Steering Committee members. In this case, [regular voting rules](#voting-by-sc) apply. #### 6.2.2 New members From 88e5bd481b2e15aa5a49cfa2f03e7ecad399e006 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen <33718780+casparvl@users.noreply.github.com> Date: Mon, 4 Aug 2025 12:53:14 +0200 Subject: [PATCH 45/72] Apply suggestions from code review Co-authored-by: Kenneth Hoste --- docs/governance/policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index 0616a3bc8e..c08bcc964f 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -81,7 +81,7 @@ Optimization for performance is strongly encouraged. For compiled software, this ### 3.2 Non-Software Contributions -- Contributions to build logic, test suites, or infrastructure must be testable and documented. +- Contributions to build logic, test suites, or infrastructure should be testable and documented. - Specific requirements may be defined by the relevant Team. --- From e92033266e6d28aca8d6124c5a7bbd34dfc5d07d Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen <33718780+casparvl@users.noreply.github.com> Date: Mon, 4 Aug 2025 14:56:28 +0200 Subject: [PATCH 46/72] Apply suggestions from code review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Bob Dröge --- docs/governance/charter.md | 2 +- docs/governance/governance.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index 84b047af96..c5a28387b0 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -39,7 +39,7 @@ This requires: All of these (both code and infrastructure itself) are considered 'in scope' for the project. -There are additional CernVM-FS repositories under the eessi.io namespace, such as dev.eessi.io and riscv.eessi.io. All code and infrastructure related to those repositories (and any other CernVM-FS repositories under the eessi.io namespace) are also considered part of the EESSI project. +There are additional CernVM-FS repositories under the `eessi.io` namespace, such as `dev.eessi.io` and `riscv.eessi.io`. All code and infrastructure related to those repositories (and any other CernVM-FS repositories under the `eessi.io` namespace) are also considered part of the EESSI project. ## 3. Membership diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 2a2a591f37..ffe54a97f1 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -6,7 +6,7 @@ A project charter discusses _what it is and why it exists_, a governance discuss As stated in the [Charter](charter.md), this project governance _only_ covers collaboration on the `software.eessi.io` CernVM-FS repository, it does not cover other CernVM-FS repositories under the eessi.io namespace. In other words, when the sections below mention the EESSI CernVM-FS repository, this implies the `software.eessi.io` repository specifically. Thus, this governance only addresses contributing to, building for, deploying to, ingesting in, providing, or using the `software.eessi.io` repository. -The only exception to this is the Steering Committee, which has authority over all the `eessi.io` CernFM-FS repositories. +The only exception to this is the Steering Committee, which has authority over all the `eessi.io` CernVM-FS repositories. ## 1. Guiding Principles From de709ae294d2b1028523ec34659f1fdbd75cc7cb Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen <33718780+casparvl@users.noreply.github.com> Date: Mon, 4 Aug 2025 15:31:35 +0200 Subject: [PATCH 47/72] Apply suggestions from code review --- docs/governance/governance.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index ffe54a97f1..51cab5635c 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -176,7 +176,11 @@ All new Members will appoint an alternate that may represent them and vote on th #### 6.2.3 Chair -A Chair will be appointed by the Steering Committee to serve for a one-year term. +A Chair will be appointed by the Steering Committee to serve for a one-year term. The Chair is responsible for organizing and leading the Steering Committee meetings (e.g. preparing and sending around an agenda, bringing items to a vote, counting the votes, ensuring meeting notes are kept and made available to the Steering Committee Members, etc). + +The Chair can appoint another Member to serve as acting Chair for a given meeting or period. + +If there is no Chair (e.g. because the Chair's term was completed, or the Chair stepped down from the Steering Committee), any Member can call for and organize a new meeting or electronic vote to appoint a new Chair. Whenever there is no Chair and there is a meeting, the first order of business will be to elect a new Chair. ### 6.3 Voting by the Steering Committee {#voting-by-sc} @@ -186,7 +190,11 @@ General decisions are taken by majority vote, provided that at least 75% of the #### 6.3.2 Ways of voting -Votes can be cast either in person, participating electronically, or via electronic vote (such as by e-mail). +Votes can be cast: + +- in-person; +- in a virtual meeting; +- via electronic vote (such as by e-mail, or through an approving review in GitHub). #### 6.3.3 Neutral votes @@ -210,11 +218,11 @@ A fully electronic vote (i.e. all Members vote electronically) can be organized #### 6.3.8 Voting topics -Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announced at least one week prior to the meeting, to give Members the opportunity to cast an electronic vote if they cannot attend. +Anything may be brought to a vote during the meeting. However, if known up-front, issues that need to be voted on are announced by the Chair at least one week prior to the meeting, to give Members the opportunity to cast an electronic vote if they cannot attend. #### 6.3.9 Votes on amending Charter or Governance -To amend the Charter or Governance, a two-thirds majority of all Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at a meeting. There is no quorum for votes on amendments to the Charter or Governance. +To amend the Charter, Governance or Project Policies, a two-thirds majority of *all* Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at a meeting. Since the majority vote is determined based on the total amount of Members (rather than the total amount of votes), there is no quorum for votes on amendments to the Charter, Governance or Project Policies. ### 6.4 Meetings From 842b0cece814fa3e8564748e15071130d00ef683 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 15:34:41 +0200 Subject: [PATCH 48/72] Fix anchors --- docs/governance/governance.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 51cab5635c..5242281cbb 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -16,7 +16,7 @@ The second goal of this governance is to make clear how and by whom decisions in To achieve both goals, our governance is based on the [meritocracy](https://en.wikipedia.org/wiki/Meritocracy) governance model. -## 2. Roles and Responsibilities {#roles-and-responsibilities} +## 2. Roles and Responsibilities { #roles-and-responsibilities } Below, the roles and responsibilities related to the EESSI project are discussed. The group of people with a common role will be referred to as a Team in the remainder of this document. Exceptions are Contributors, System administrators of systems providing EESSI and End-users (these are not considered to be Teams). Each individual in a Team will be referred to as a Team Member. @@ -36,7 +36,7 @@ EESSI Infrastructure maintainers are those individuals that maintain the Central Infrastructure maintainers are responsible for monitoring and maintaining their respective infrastructure, and provide access to those who needed it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Deployers and Builders as described in 2.4 and 2.5. Furthermore, they are _not_ allowed to give access to others that are not part of the EESSI Infrastructure maintainers, Deployers or Builders teams. -### 2.4 Builders {#builders} +### 2.4 Builders { #builders } Adding software to EESSI requires three steps (see [the contribution workflow](../adding_software/overview.md) documentation): 1. The software needs to be built (compiled); @@ -108,7 +108,7 @@ The goal is for Teams to operate autonomously as much as possible. However, in exceptional cases, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort. Examples of when this may be considered is if the Steering Committee feels that a decision endangers the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. -## 4. Meetings and Communication {#meetings-and-communication} +## 4. Meetings and Communication { #meetings-and-communication } While each Team is allowed to use the communication channels that their Team jointly agrees upon, the following channels are suggested @@ -182,7 +182,7 @@ The Chair can appoint another Member to serve as acting Chair for a given meetin If there is no Chair (e.g. because the Chair's term was completed, or the Chair stepped down from the Steering Committee), any Member can call for and organize a new meeting or electronic vote to appoint a new Chair. Whenever there is no Chair and there is a meeting, the first order of business will be to elect a new Chair. -### 6.3 Voting by the Steering Committee {#voting-by-sc} +### 6.3 Voting by the Steering Committee { #voting-by-sc } #### 6.3.1 Majority vote @@ -222,7 +222,7 @@ Anything may be brought to a vote during the meeting. However, if known up-front #### 6.3.9 Votes on amending Charter or Governance -To amend the Charter, Governance or Project Policies, a two-thirds majority of *all* Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at a meeting. Since the majority vote is determined based on the total amount of Members (rather than the total amount of votes), there is no quorum for votes on amendments to the Charter, Governance or Project Policies. +To amend the Charter, Governance or [Project Policies](policies.md#project-policies), a two-thirds majority of *all* Steering Committee Members needs to be in favour of the amendment. This is irrespective of the number of Members who have actually cast a vote, or are present at a meeting. Since the majority vote is determined based on the total amount of Members (rather than the total amount of votes), there is no quorum for votes on amendments to the Charter, Governance or Project Policies. ### 6.4 Meetings From 4ad0af3423c1863b4f9feea43cb00a3ad04a96fc Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 15:36:32 +0200 Subject: [PATCH 49/72] Add changelog --- docs/governance/policies.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index c08bcc964f..b2bc459b9a 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -1,3 +1,5 @@ +_Last updated: 08 August 2025_ + # Policy Scope and Hierarchy - **Project Policies** are defined and maintained by the Steering Committee. @@ -6,7 +8,7 @@ --- -# EESSI Project Policies +# EESSI Project Policies {#project-policies} This document outlines project-wide policies that guide the development, deployment, and maintenance of the EESSI software stack. These policies are set by the Steering Committee and apply across all Teams and repositories. @@ -106,4 +108,5 @@ This does not imply exclusion of other platforms, but reflects the project's pri There are currently no Team Policies yet. -_Last updated: 23 June 2025_ +# Changelog +- 04 August 2025: First version published From fb0e8e6f904fbc39c57cf88acc79c28edd90cb25 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 15:50:36 +0200 Subject: [PATCH 50/72] Clarify that commercial use _is_ permitted --- docs/governance/terms_of_use.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/governance/terms_of_use.md b/docs/governance/terms_of_use.md index 3bd9720215..0eb6a4fe88 100644 --- a/docs/governance/terms_of_use.md +++ b/docs/governance/terms_of_use.md @@ -1,11 +1,11 @@ # EESSI – Terms of Use -**Effective Date:** 23 June 2025 +**Effective Date:** 04 August 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)**](https://eessi.io), 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. +EESSI provides a shared scientific software stack for academic, research, and educational use. While access and usage are primarily intended for non-commercial scientific computing, commercial use is permitted. ## 2. Acceptable Use Users must act responsibly when accessing and using the EESSI infrastructure and software. In particular: From edb7325143cce81f03b60bd8494dd639ae036f8a Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 15:53:05 +0200 Subject: [PATCH 51/72] Changed Contact point to the docs page about support --- docs/governance/terms_of_use.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/terms_of_use.md b/docs/governance/terms_of_use.md index 0eb6a4fe88..b95a7441a1 100644 --- a/docs/governance/terms_of_use.md +++ b/docs/governance/terms_of_use.md @@ -32,4 +32,4 @@ The EESSI maintainers and affiliated institutions are not liable for damages or 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]**. +For support or inquiries, visit [https://www.eessi.io/docs/support](https://www.eessi.io/docs/support). From 3bd2970512df835ca3c8016d2345146408a7e175 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 16:04:35 +0200 Subject: [PATCH 52/72] Add contact details --- docs/governance/steering_committee.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/governance/steering_committee.md b/docs/governance/steering_committee.md index 24018aa713..df14fcf710 100644 --- a/docs/governance/steering_committee.md +++ b/docs/governance/steering_committee.md @@ -1,12 +1,12 @@ The current (Interim) Steering Committee consists of: -* _Interim Steering Committee Lead_: Kenneth Hoste ([Ghent University](https://www.ugent.be/en)), [@boegel](https://github.com/boegel) - * _Alternate: Lara Peeters ([Ghent University](https://www.ugent.be/en)), :material-github: [@laraPPr](https://github.com/laraPPr)_ -* Alan O'Cais ([CECAM](https://www.cecam.org/), [University of Barcelona](https://web.ub.edu/inici)), :material-github: [@ocaisa](https://github.com/ocaisa) - * _Alternate: Davide Grassano ([CECAM](https://www.cecam.org/)), :material-github: [@crivella](https://github.com/crivella)_ -* Bob Dröge ([University of Groningen](https://www.rug.nl/)), :material-github: [@bedroge](https://github.com/bedroge) - * _Alternate: Henk-Jan Zilverberg ([University of Groningen](https://www.rug.nl/)), :material-github: [@zilverberg](https://github.com/zilverberg)_ -* Caspar van Leeuwen ([SURF](https://www.surf.nl/en)), :material-github: [@casparvl](https://github.com/casparvl) - * _Alternate: Satish Kamath ([SURF](https://www.surf.nl/en)), :material-github: [@satishskamath](https://github.com/satishskamath)_ -* Thomas Röblitz ([University of Bergen](https://www.uib.no/en)), [@trz42](https://github.com/trz42) - * _Alternate: Terje Kvernes ([University of Oslo](https://www.uio.no/english/)), :material-github: [@terjekv](https://github.com/terjekv)_ +* _Interim Steering Committee Lead_: Kenneth Hoste ([Ghent University](https://www.ugent.be/en)), :material-github: [@boegel](https://github.com/boegel), e-mail: kenneth.hoste (at) ugent.be, Slack: Kenneth Hoste (HPC-UGent) - boegel + * _Alternate: Lara Peeters ([Ghent University](https://www.ugent.be/en)), :material-github: [@laraPPr](https://github.com/laraPPr), e-mail: lara.peeters (at) ugent.be, Slack: Lara Peeters (HPC-UGent)_ +* Alan O'Cais ([CECAM](https://www.cecam.org/), [University of Barcelona](https://web.ub.edu/inici)), :material-github: [@ocaisa](https://github.com/ocaisa), e-mail: alan.ocais (at) cecam.org, Slack: Alan O'Cais (CECAM) + * _Alternate: Davide Grassano ([CECAM](https://www.cecam.org/)), :material-github: [@crivella](https://github.com/crivella), e-mail: davide.grassano (at) epfl.ch, Slack: Davide Grassano_ +* Bob Dröge ([University of Groningen](https://www.rug.nl/)), :material-github: [@bedroge](https://github.com/bedroge), e-mail: b.e.droge (at) rug.nl, Slack: Bob Dröge (HPC UGroningen) + * _Alternate: Henk-Jan Zilverberg ([University of Groningen](https://www.rug.nl/)), :material-github: [@zilverberg](https://github.com/zilverberg), e-mail: h.j.zilverberg (at) rug.nl, Slack: Henk-Jan Zilverberg (HPC UGroningen)_ +* Caspar van Leeuwen ([SURF](https://www.surf.nl/en)), :material-github: [@casparvl](https://github.com/casparvl), e-mail: caspar.vanleeuwen (at) surf.nl, Slack: Caspar van Leeuwen (SURF) + * _Alternate: Satish Kamath ([SURF](https://www.surf.nl/en)), :material-github: [@satishskamath](https://github.com/satishskamath), e-mail: satish.kamath (at) surf.nl, Slack: Satish Kamath_ +* Thomas Röblitz ([University of Bergen](https://www.uib.no/en)), [@trz42](https://github.com/trz42), e-mail: thomas.roblitz (at) uib.no, Slack: Thomas Röblitz (UiB) - trz42 + * _Alternate: Terje Kvernes ([University of Oslo](https://www.uio.no/english/)), :material-github: [@terjekv](https://github.com/terjekv), e-mail: terjekv (at) math.uio.no, Slack: Terje Kvernes (UiO) - terjekv_ From 955a9f93f351be0e4029640f37605cdf0842c6cc Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 16:05:40 +0200 Subject: [PATCH 53/72] Change index, see if this resolves @boegels loading issue --- docs/governance/index.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/governance/index.md b/docs/governance/index.md index b621d660fd..bc276075e7 100644 --- a/docs/governance/index.md +++ b/docs/governance/index.md @@ -1,6 +1,6 @@ -- Charter: charter.md -- Governance: governance.md -- Policies: policies.md -- Code of Conduct: code_of_conduct.md -- Terms of Use: terms_of_use.md -- Current Steering Committee: steering_committee.md +- [Charter](charter.md) +- [Governance](governance.md) +- [Policies](policies.md) +- [Code of Conduct](code_of_conduct.md) +- [Terms of Use](terms_of_use.md) +- [Current Steering Committee](steering_committee.md) From c868b76a0b23e79c5fd5fce6b45f1f6f77f5e2da Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 16:08:33 +0200 Subject: [PATCH 54/72] Fix anchor --- docs/governance/policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index b2bc459b9a..819b7738db 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -8,7 +8,7 @@ _Last updated: 08 August 2025_ --- -# EESSI Project Policies {#project-policies} +# EESSI Project Policies { #project-policies } This document outlines project-wide policies that guide the development, deployment, and maintenance of the EESSI software stack. These policies are set by the Steering Committee and apply across all Teams and repositories. From 351e9351398299f94718b7a4fb8b3c4172c000b1 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 16:10:15 +0200 Subject: [PATCH 55/72] Fix links --- docs/governance/code_of_conduct.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/governance/code_of_conduct.md b/docs/governance/code_of_conduct.md index 74dddc853c..e3cb93bed8 100644 --- a/docs/governance/code_of_conduct.md +++ b/docs/governance/code_of_conduct.md @@ -117,9 +117,9 @@ community. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], +This Code of Conduct is adapted from the [Contributor Covenant][https://www.contributor-covenant.org/], version 2.1, available at -[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]. +[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][https://www.contributor-covenant.org/version/2/1/code_of_conduct.html]. Community Impact Guidelines were inspired by -[Mozilla's code of conduct enforcement ladder][Mozilla CoC]. +[Mozilla's code of conduct enforcement ladder][https://github.com/mozilla/diversity]. From 555dcfea6c70c68107dbd32dc55246774816e1c7 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 16:16:21 +0200 Subject: [PATCH 56/72] Fix external links --- docs/governance/code_of_conduct.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/governance/code_of_conduct.md b/docs/governance/code_of_conduct.md index e3cb93bed8..e60cfe20c7 100644 --- a/docs/governance/code_of_conduct.md +++ b/docs/governance/code_of_conduct.md @@ -117,9 +117,9 @@ community. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][https://www.contributor-covenant.org/], +This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/), version 2.1, available at -[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][https://www.contributor-covenant.org/version/2/1/code_of_conduct.html]. +[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html](https://www.contributor-covenant.org/version/2/1/code_of_conduct.html). Community Impact Guidelines were inspired by -[Mozilla's code of conduct enforcement ladder][https://github.com/mozilla/diversity]. +[Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity). From 2e21fd7d3adf03ab7c9500850867b996f5d35d0c Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 4 Aug 2025 16:22:05 +0200 Subject: [PATCH 57/72] Remove redirect --- mkdocs.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/mkdocs.yml b/mkdocs.yml index 413640a4df..5fa809a360 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -107,7 +107,6 @@ plugins: contributing_sw/deploying_software.md: adding_software/deploying_software.md contributing_sw/opening_pr.md: adding_software/opening_pr.md contributing_sw/overview.md: adding_software/overview.md - governance.md: governance/index.md software_layer/adding_software.md: adding_software/overview.md pilot.md: repositories/pilot.md # https://www.eessi.io/docs/pilot is mentioned in the EESSI open access paper gpu.md: site_specific_config/gpu.md From 7ecd576f5965c23e25a3d8fb0d8f7d776c47bba1 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen <33718780+casparvl@users.noreply.github.com> Date: Mon, 25 Aug 2025 10:49:05 +0200 Subject: [PATCH 58/72] Apply grammar and spelling suggestions from review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Adam Huffman Co-authored-by: Bob Dröge --- docs/governance/governance.md | 26 +++++++++++++------------- docs/governance/policies.md | 4 ++-- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 5242281cbb..3eb767197f 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -12,7 +12,7 @@ The only exception to this is the Steering Committee, which has authority over a The value of EESSI grows exponentially with two things: the amount of systems that make EESSI available, and the amount of software that is available in EESSI. Thus, the first goal of this governance is to make sure everyone in the community feels sufficiently included so that they are willing to contribute to EESSI (rather than build their own solution). -The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because trust in this process is important, both to infrastructure providers making the EESSI software stack is available on their systems, as well as by end-users of the software. Note that this concerns both large decisions, such as which architectures are supported in EESSI, as well as small decisions, such as making a specific software package available in EESSI. +The second goal of this governance is to make clear how and by whom decisions in EESSI are taken. This is because trust in this process is important, both to infrastructure providers making the EESSI software stack available on their systems, as well as for end-users of the software. Note that this concerns both large decisions, such as which architectures are supported in EESSI, as well as small decisions, such as making a specific software package available in EESSI. To achieve both goals, our governance is based on the [meritocracy](https://en.wikipedia.org/wiki/Meritocracy) governance model. @@ -22,7 +22,7 @@ Below, the roles and responsibilities related to the EESSI project are discussed ### 2.1 Owners of the `EESSI` GitHub organization & repositories -The owners of the [EESSI GitHub organization](https://github.com/EESSI) & repositories are those individuals with `owner` rights on the EESSI GitHub organization or one of it's associated repositories. +The owners of the [EESSI GitHub organization](https://github.com/EESSI) & repositories are those individuals with `owner` rights on the EESSI GitHub organization or one of its associated repositories. EESSI GitHub organization & repository owners are responsible for setting permissions on the code repositories, compliant to the defined roles and responsibilities. They are also responsible for managing GitHub Apps for the EESSI build bots. @@ -34,7 +34,7 @@ EESSI GitHub repository maintainers are responsible for reviewing and merging PR ### 2.3 EESSI Infrastructure maintainers EESSI Infrastructure maintainers are those individuals that maintain the Central Server for the EESSI CernVM-FS repository (the CernVM-FS Stratum 0), the _public_ mirror servers (CernVM-FS Stratum 1's), and EESSI build infrastructure (e.g. hosting the EESSI build bot). -Infrastructure maintainers are responsible for monitoring and maintaining their respective infrastructure, and provide access to those who needed it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Deployers and Builders as described in 2.4 and 2.5. Furthermore, they are _not_ allowed to give access to others that are not part of the EESSI Infrastructure maintainers, Deployers or Builders teams. +Infrastructure maintainers are responsible for monitoring and maintaining their respective infrastructure, and provide access to those who need it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Deployers and Builders as described in 2.4 and 2.5. Furthermore, they are _not_ allowed to give access to others that are not part of the EESSI Infrastructure maintainers, Deployers or Builders teams. ### 2.4 Builders { #builders } Adding software to EESSI requires three steps (see [the contribution workflow](../adding_software/overview.md) documentation): @@ -45,31 +45,31 @@ Adding software to EESSI requires three steps (see [the contribution workflow](. Builders are those individuals that have permissions to build software through one or more of the EESSI build bots, i.e. step 1 in this process. -Builders are responsible for reviewing contributions. They should, for example, check that contributions adhere to the contribution guidelines, that a contribution will not trigger execution of any untintended or unwanted code, etc. They are also responsible for triggering builds for contributors who want to add software to the EESSI software stack. +Builders are responsible for reviewing contributions. They should, for example, check that contributions adhere to the contribution guidelines, that a contribution will not trigger execution of any unintended or unwanted code, etc. They are also responsible for triggering builds for contributors who want to add software to the EESSI software stack. ### 2.5 Deployers Deployers are those individuals that have permissions to deploy software through one or more of the EESSI build bots to a central location (e.g. S3 bucket), i.e. they are essentially responsible for step 2 as it is described in the [Builders](#builders) Section. Deployers should check the file list of the produced tarballs (as it is reported by the build bot) for unexpected items. They should also check if all officially supported hardware targets have been built for. -### 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. +### 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. -Ingestors have merge permissions on the (private) `EESSI/staging` GitHub repository. +Ingesters 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. +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. ### 2.7 Contributors Contributors are individuals that make a contribution by opening a pull request to one of the repositories in the EESSI GitHub organization. -Contributors that propose adding software to EESSI in their contributions are responsible for checking that the license of the software they want to add allows it's use in EESSI (e.g. allows redistribution). Contributors should also make an effort to ensure that their contributions don't add any malicious code. Finally, contributors should ensure that they adhere to the [Contribution Policy](../adding_software/contribution_policy.md). +Contributors that propose adding software to EESSI in their contributions are responsible for checking that the license of the software they want to add allows its use in EESSI (e.g. allows redistribution). Contributors should also make an effort to ensure that their contributions don't add any malicious code. Finally, contributors should ensure that they adhere to the [Contribution Policy](../adding_software/contribution_policy.md). ### 2.8 System administrators of systems providing EESSI System administrators of systems providing EESSI are administrators of systems (such as, but not limited to cloud and HPC systems) that make the EESSI software stack available to their users. -System administrators of systems providing EESSI should make sure that their system does not put any disproportional load on the public EESSI CernVM-FS infrastructure. Typically, this means that they should adhere to best practices for CernVM-FS caching in a way that fits the size and nature of their system (e.g. by setting up a private CernVM-FS Stratum 1, a proxy, and/or a properly sized local cache). +System administrators of systems providing EESSI should make sure that their system does not put any disproportionate load on the public EESSI CernVM-FS infrastructure. Typically, this means that they should adhere to best practices for CernVM-FS caching in a way that fits the size and nature of their system (e.g. by setting up a private CernVM-FS Stratum 1, a proxy, and/or a properly sized local cache). System administrators agree to the [Terms of Use](terms_of_use.md) when making EESSI available on the systems they manage. @@ -106,7 +106,7 @@ Also, if multiple Teams claim ownership over an issue, the Steering Committee ca The goal is for Teams to operate autonomously as much as possible. -However, in exceptional cases, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort. Examples of when this may be considered is if the Steering Committee feels that a decision endangers the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. +However, in exceptional cases, the Steering Committee _can_ overrule a decision made by any of the Teams. This power should only be used as a last resort. Examples of when this may be considered include if the Steering Committee feels that a decision endangers the integrity or sustainability of the project, or goes against the policies the Steering Committee has defined. Even then, the Steering Committee should first engage in a discussion with a Team to see if consensus can be achieved on changing the decision. ## 4. Meetings and Communication { #meetings-and-communication } @@ -152,7 +152,7 @@ The Steering Committee is made up of community members with sustained and recogn Membership of the Steering Committee can terminate in three ways: - A Member can resign -- A Member may be voted out. In this case, the vote needs to be unanimous between the other Members. This procedure is intended to provide a mechanism for addressing extraordinary circumstances where a members behavior or actions are deemed severely detrimental to the committee's function or reputation, and/or to the EESSI project. +- A Member may be voted out. In this case, the vote needs to be unanimous between the other Members. This procedure is intended to provide a mechanism for addressing extraordinary circumstances where a member's behavior or actions are deemed severely detrimental to the committee's function or reputation, and/or to the EESSI project. - If a Member is inactive for 6 months and does not reply to communication from the rest of the Steering Committee, the Member may be voted out by the other Steering Committee members. In this case, [regular voting rules](#voting-by-sc) apply. #### 6.2.2 New members @@ -170,7 +170,7 @@ In the selection process, the Steering Committee will consider the following: - The number of Members from the same country should be limited to 2; - The composition of the Steering Committee should reflect the EESSI community; -Note that if Members change jobs, or move to another country, some of the above criteria that were taken into account during selection may no longer be satisfied. It is up to the Steering Committee to decide if this is problematic, and if so, try to restore balance by requesting someone to resign. +Note that if Members change jobs, or move to another country, some of the above criteria that were taken into account during selection may no longer be satisfied. It is up to the Steering Committee to decide if this is problematic, and if so, try to restore balance by requesting someone's resignation. All new Members will appoint an alternate that may represent them and vote on their behalf in case they are unavailable. If a Member resigns or is voted out from the Steering Committee, their alternate immediately loses any rights they had as an alternate. diff --git a/docs/governance/policies.md b/docs/governance/policies.md index 819b7738db..0c01af1363 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -90,7 +90,7 @@ Optimization for performance is strongly encouraged. For compiled software, this ## 4. Transparency and Traceability -EESSI aims to be transparent regarding how software was build. A combination of the git history, EasyBuild logs, as well as the `easybuild` subdirectory within every installation (which provides the easyconfig and patch files, easyblock, and any hooks used at installation time) provide a detailed description of how software was configured and built. +EESSI aims to be transparent regarding how software was built. A combination of the git history, EasyBuild logs, as well as the `easybuild` subdirectory within every installation (which provides the easyconfig and patch files, easyblock, and any hooks used at installation time) provide a detailed description of how software was configured and built. --- @@ -106,7 +106,7 @@ This does not imply exclusion of other platforms, but reflects the project's pri # EESSI Team Policies -There are currently no Team Policies yet. +There are no Team Policies yet. # Changelog - 04 August 2025: First version published From 2e6f72cccca826e2c73b8ecfad92b1ef11505231 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 25 Aug 2025 10:54:59 +0200 Subject: [PATCH 59/72] Remove 'a' from 'a governance', that's not proper English --- docs/governance/charter.md | 2 +- docs/governance/governance.md | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index c5a28387b0..7260f98bf3 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -1,5 +1,5 @@ # Project Governance From 5ea8adef7133be91354bb31c34271618721cff02 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 25 Aug 2025 11:19:00 +0200 Subject: [PATCH 60/72] Rephrased the country consideration, and also added the motivation for each of the considerations --- docs/governance/governance.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 0375519507..c59c2716bd 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -165,11 +165,11 @@ The Steering Committee then weighs the feedback, and votes on whether to accept In the selection process, the Steering Committee will consider the following: -- The Steering Committee ideally consists of an odd number of Members; -- No more than 30% of the Members should be employed by commercial entities; -- The number of Members working for the same company should be limited to 1; -- The number of Members from the same country should be limited to 2; -- The composition of the Steering Committee should reflect the EESSI community; +- The Steering Committee ideally consists of an odd number of Members (to reduce chances of a tie when voting); +- No more than 30% of the Members should be employed by commercial entities (to avoid that the project becomes dominated by commercial interests); +- The number of Members working for the same company should be limited to 1 (to avoid that the project becomes dominated by a single company, or a small group of companies); +- The number of Members with the same country of residence should be limited to 2 (to reflect the international nature of the project); +- The composition of the Steering Committee should reflect the EESSI community (to ensure that the community's interests are represented); Note that if Members change jobs, or move to another country, some of the above criteria that were taken into account during selection may no longer be satisfied. It is up to the Steering Committee to decide if this is problematic, and if so, try to restore balance by requesting someone's resignation. From 99f8b75f73a9a104cfccee3aca3576df79522d26 Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 25 Aug 2025 11:25:03 +0200 Subject: [PATCH 61/72] Make the alternate optional, and give the option of appointing an alternate for a single meeting, or until further notice --- docs/governance/governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index c59c2716bd..725ed55575 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -173,7 +173,7 @@ In the selection process, the Steering Committee will consider the following: Note that if Members change jobs, or move to another country, some of the above criteria that were taken into account during selection may no longer be satisfied. It is up to the Steering Committee to decide if this is problematic, and if so, try to restore balance by requesting someone's resignation. -All new Members will appoint an alternate that may represent them and vote on their behalf in case they are unavailable. If a Member resigns or is voted out from the Steering Committee, their alternate immediately loses any rights they had as an alternate. +Members may appoint an alternate that may represent them and vote on their behalf in case they are unavailable. To alternate is appointed by a Member simply by informing the Chair. An alternate may be appointed for a single meeting, or until further notice. If a Member resigns or is voted out from the Steering Committee, their alternate immediately loses any rights they had as an alternate. #### 6.2.3 Chair From d46cacc4369bdc68173b51c0baf43b81046ec96f Mon Sep 17 00:00:00 2001 From: Caspar van Leeuwen Date: Mon, 25 Aug 2025 11:27:34 +0200 Subject: [PATCH 62/72] Remove contribution agreement section for now --- docs/governance/governance.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 725ed55575..f5572c30d6 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -232,8 +232,10 @@ The Steering Committee will meet as needed, but at least once per quarter. The C ## 7. Code of Conduct The EESSI Code of Conduct can be found [here](code_of_conduct.md). + +## 8. Review and Amendment Changes to the governance require approval by the Steering Committee, as per the rules described the [Voting by the Steering Committee](governance.md#voting-by-the-steering-committee) section. From 10f7ae8079aceeef8eec3208293dc625e147e590 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:21:21 +0200 Subject: [PATCH 63/72] company -> employer --- docs/governance/governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index f5572c30d6..272afa70db 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -167,7 +167,7 @@ In the selection process, the Steering Committee will consider the following: - The Steering Committee ideally consists of an odd number of Members (to reduce chances of a tie when voting); - No more than 30% of the Members should be employed by commercial entities (to avoid that the project becomes dominated by commercial interests); -- The number of Members working for the same company should be limited to 1 (to avoid that the project becomes dominated by a single company, or a small group of companies); +- The number of Members working for the same employer should be limited to 1 (to avoid that the project becomes dominated by a single employer, or a small group of employers); - The number of Members with the same country of residence should be limited to 2 (to reflect the international nature of the project); - The composition of the Steering Committee should reflect the EESSI community (to ensure that the community's interests are represented); From 926800bdc7eb1e25c9c2fa3dc0e854534a85f550 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:24:22 +0200 Subject: [PATCH 64/72] rephrase motivation w.r.t. employer limit --- docs/governance/governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 272afa70db..c795e11430 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -167,7 +167,7 @@ In the selection process, the Steering Committee will consider the following: - The Steering Committee ideally consists of an odd number of Members (to reduce chances of a tie when voting); - No more than 30% of the Members should be employed by commercial entities (to avoid that the project becomes dominated by commercial interests); -- The number of Members working for the same employer should be limited to 1 (to avoid that the project becomes dominated by a single employer, or a small group of employers); +- The number of Members working for the same employer should be limited to 1 (to avoid that the project becomes dominated by a single company or institution, or a small group thereof); - The number of Members with the same country of residence should be limited to 2 (to reflect the international nature of the project); - The composition of the Steering Committee should reflect the EESSI community (to ensure that the community's interests are represented); From 546b91a024e93d8f70ee99e54a0569f13344708d Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:29:33 +0200 Subject: [PATCH 65/72] no registered membership --- docs/governance/charter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/charter.md b/docs/governance/charter.md index 7260f98bf3..b48986f350 100644 --- a/docs/governance/charter.md +++ b/docs/governance/charter.md @@ -43,7 +43,7 @@ There are additional CernVM-FS repositories under the `eessi.io` namespace, such ## 3. Membership -There is currently no membership. Any individual or institution may participate by using EESSI, contributing to EESSI, making EESSI available on systems managed by them, etc. +There is currently no registered membership. Any individual or institution may participate by using EESSI, contributing to EESSI, making EESSI available on systems managed by them, etc. ## 4. Review and Amendment Changes to the charter require approval by the Steering Committee. See the [relevant section of the Governance](governance.md#voting-by-the-steering-committee). From f45ad04a38f8cd69a0b9cfaf84119cd58c1750bd Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:31:21 +0200 Subject: [PATCH 66/72] also mention domain registration --- docs/governance/governance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index c795e11430..a7ef183e85 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -33,7 +33,7 @@ EESSI GitHub repository maintainers are individuals with write access to (one or EESSI GitHub repository maintainers are responsible for reviewing and merging PRs. ### 2.3 EESSI Infrastructure maintainers -EESSI Infrastructure maintainers are those individuals that maintain the Central Server for the EESSI CernVM-FS repository (the CernVM-FS Stratum 0), the _public_ mirror servers (CernVM-FS Stratum 1's), and EESSI build infrastructure (e.g. hosting the EESSI build bot). +EESSI Infrastructure maintainers are those individuals that maintain the Central Server for the EESSI CernVM-FS repository (the CernVM-FS Stratum 0), the _public_ mirror servers (CernVM-FS Stratum 1's), the EESSI build infrastructure (e.g. hosting the EESSI build bot), and/or manage the domain registration(s) connected to EESSI. Infrastructure maintainers are responsible for monitoring and maintaining their respective infrastructure, and provide access to those who need it according to the Roles and Responsibilities described here. Note that maintainers of build infrastructure have the right to limit access to a _subset_ of the Deployers and Builders as described in 2.4 and 2.5. Furthermore, they are _not_ allowed to give access to others that are not part of the EESSI Infrastructure maintainers, Deployers or Builders teams. From 70c9ad7e331c5bc739431a67a07b9742b29ce430 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:33:50 +0200 Subject: [PATCH 67/72] vager staging repo --- docs/governance/governance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index a7ef183e85..621024188c 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -56,9 +56,9 @@ Deployers should check the file list of the produced tarballs (as it is reported ### 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 have merge permissions on the (private) EESSI GitHub repository used for staging. -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. +Ingesters should check the contents of the tarball as it is reported in the pull requests in the staging repository. This essentially provides a second check (next to that done by Deployers) on the contents of the tarball. ### 2.7 Contributors From da0c262837118b9edaf62e4f2af174aab288a753 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:35:55 +0200 Subject: [PATCH 68/72] also list Terms of Use under responsibilities of SC --- docs/governance/governance.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 621024188c..05c41fb6a2 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -143,6 +143,7 @@ The Steering Committee shall be responsible for: - The [EESSI Charter](charter.md) - The [EESSI Governance](governance.md) - The [EESSI Policies](policies.md) +- The [EESSI Terms of Use](terms_of_use.md) ### 6.2 Members and Chairs From 95f189641cd1afed789bb6e9015a8d0918beacff Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:36:56 +0200 Subject: [PATCH 69/72] fix typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Thomas Röblitz Co-authored-by: Bob Dröge --- docs/governance/governance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/governance/governance.md b/docs/governance/governance.md index 05c41fb6a2..a14634895e 100644 --- a/docs/governance/governance.md +++ b/docs/governance/governance.md @@ -82,7 +82,7 @@ End users agree to the [Terms of Use](terms_of_use.md) when using the software i ## 3. Decision-Making -This section applies to the decision making procedure for the Teams discussed in the [Roles and Responsibilities](#roles-and-responsibilities) Section. The Steering Committee has its own Decision-Making procedure (defined in the [Voting by the Steering Communittee](#voting-by-sc) Section). +This section applies to the decision making procedure for the Teams discussed in the [Roles and Responsibilities](#roles-and-responsibilities) Section. The Steering Committee has its own Decision-Making procedure (defined in the [Voting by the Steering Committee](#voting-by-sc) Section). ### 3.1 Consensus Seeking @@ -174,7 +174,7 @@ In the selection process, the Steering Committee will consider the following: Note that if Members change jobs, or move to another country, some of the above criteria that were taken into account during selection may no longer be satisfied. It is up to the Steering Committee to decide if this is problematic, and if so, try to restore balance by requesting someone's resignation. -Members may appoint an alternate that may represent them and vote on their behalf in case they are unavailable. To alternate is appointed by a Member simply by informing the Chair. An alternate may be appointed for a single meeting, or until further notice. If a Member resigns or is voted out from the Steering Committee, their alternate immediately loses any rights they had as an alternate. +Members may appoint an alternate that may represent them and vote on their behalf in case they are unavailable. An alternate is appointed by a Member simply by informing the Chair. The alternate may be appointed for a single meeting, or until further notice. If a Member resigns or is voted out from the Steering Committee, their alternate immediately loses any rights they had as an alternate. #### 6.2.3 Chair From 0bbe956c2eb68582ec2804c393c7f658e6cbeeb4 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:41:22 +0200 Subject: [PATCH 70/72] laptops & workstations instead of "PC" --- docs/governance/policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/policies.md b/docs/governance/policies.md index 0c01af1363..d92e5945b1 100644 --- a/docs/governance/policies.md +++ b/docs/governance/policies.md @@ -97,7 +97,7 @@ EESSI aims to be transparent regarding how software was built. A combination of ## 5. Platform Prioritization **HPC compatibility and performance are prioritized**, -in cases where technical choices must be made between HPC, Cloud, or PC environments, +in cases where technical choices must be made between HPC, Cloud, or laptops & workstations, especially for optimization-related decisions. This does not imply exclusion of other platforms, but reflects the project's primary use case. From 4912828e141bb11ae83e0a082dd08ec88d560825 Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:42:16 +0200 Subject: [PATCH 71/72] quotes fix Co-authored-by: ocaisa --- docs/governance/terms_of_use.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/terms_of_use.md b/docs/governance/terms_of_use.md index b95a7441a1..28d666d038 100644 --- a/docs/governance/terms_of_use.md +++ b/docs/governance/terms_of_use.md @@ -23,7 +23,7 @@ All software within EESSI is governed by its respective open-source or instituti Basic telemetry or usage data may be collected for monitoring and improvement of the project. This is handled in accordance with the **GDPR** and relevant EU data protection standards. ## 5. No Guarantees -EESSI is provided “as-is.” Availability, performance, or correctness of the software stack is not guaranteed. Use is at your own risk. +EESSI is provided "as-is". Availability, performance, or correctness of the software stack is not guaranteed. Use is at your own risk. ## 6. Liability The EESSI maintainers and affiliated institutions are not liable for damages or losses arising from use of the software stack. From 94e3810fca24d107be9b6b82bd5588ba3d6f2a1c Mon Sep 17 00:00:00 2001 From: Kenneth Hoste Date: Mon, 25 Aug 2025 12:43:26 +0200 Subject: [PATCH 72/72] fix effective date for ToU --- docs/governance/terms_of_use.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/governance/terms_of_use.md b/docs/governance/terms_of_use.md index 28d666d038..f57f63afb9 100644 --- a/docs/governance/terms_of_use.md +++ b/docs/governance/terms_of_use.md @@ -1,6 +1,6 @@ # EESSI – Terms of Use -**Effective Date:** 04 August 2025 +**Effective Date:** 25 August 2025 By using the [**European Environment for Scientific Software Installations (EESSI)**](https://eessi.io), you agree to the following terms: