diff --git a/docs/governance.md b/docs/governance.md deleted file mode 100644 index 4a72f63538..0000000000 --- a/docs/governance.md +++ /dev/null @@ -1,23 +0,0 @@ -# EESSI Governance - -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)_ diff --git a/docs/governance/charter.md b/docs/governance/charter.md new file mode 100644 index 0000000000..b48986f350 --- /dev/null +++ b/docs/governance/charter.md @@ -0,0 +1,49 @@ + + +# Project Charter + +## 1. Mission + +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 with additional local installations +- 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: + +- 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` + +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. + +## 3. Membership + +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). diff --git a/docs/governance/code_of_conduct.md b/docs/governance/code_of_conduct.md new file mode 100644 index 0000000000..e60cfe20c7 --- /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](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). + +Community Impact Guidelines were inspired by +[Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity). diff --git a/docs/governance/governance.md b/docs/governance/governance.md new file mode 100644 index 0000000000..a14634895e --- /dev/null +++ b/docs/governance/governance.md @@ -0,0 +1,242 @@ + + +# 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. + +The only exception to this is the Steering Committee, which has authority over all the `eessi.io` CernVM-FS repositories. + +## 1. Guiding Principles + +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 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. + +## 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. + +### 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 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. + +### 2.2 EESSI GitHub repository maintainers +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. + +### 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), 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. + +### 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); +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. + +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 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 GitHub repository used for staging. + +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 + +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 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 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. + +### 2.9 End-Users + +End-Users are individuals that use any of the software provided by the EESSI software stack. + +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 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 + +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 + +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 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 } + +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 +This Section applies to the Teams described in the [Roles and Responsibilities](#roles-and-responsibilities) Section. + +### 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 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. + +### 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 committee + +### 6.1 Responsibilities + +The Steering Committee shall be responsible for: + +- 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 Terms of Use](terms_of_use.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. 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 + +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. + +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 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); + +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. 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 + +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 } + +#### 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: + +- 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 + +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 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, 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 + +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 +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. diff --git a/docs/governance/index.md b/docs/governance/index.md new file mode 100644 index 0000000000..bc276075e7 --- /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/governance/policies.md b/docs/governance/policies.md new file mode 100644 index 0000000000..d92e5945b1 --- /dev/null +++ b/docs/governance/policies.md @@ -0,0 +1,112 @@ +_Last updated: 08 August 2025_ + +# 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. + +--- + +# 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. + +--- + +## 2. Build and Deployment Policies + +### 2.1 Architecture Support + +- 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 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. 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. + +In all cases, the value of rebuilding the software will be carefully weighed against the value of reproducibility. + +### 2.3 Deprecation 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. + +#### 2.3.2 Deprecation of individual software installations + +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. + +### 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. + +--- + +## 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 should be testable and documented. +- Specific requirements may be defined by the relevant Team. + +--- + +## 4. Transparency and Traceability + +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. + +--- + +## 5. Platform Prioritization + +**HPC compatibility and performance are prioritized**, +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. + +--- + +# EESSI Team Policies + +There are no Team Policies yet. + +# Changelog +- 04 August 2025: First version published diff --git a/docs/governance/steering_committee.md b/docs/governance/steering_committee.md new file mode 100644 index 0000000000..df14fcf710 --- /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)), :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_ diff --git a/docs/governance/terms_of_use.md b/docs/governance/terms_of_use.md new file mode 100644 index 0000000000..f57f63afb9 --- /dev/null +++ b/docs/governance/terms_of_use.md @@ -0,0 +1,35 @@ +# EESSI – Terms of Use + +**Effective Date:** 25 August 2025 + +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. 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: + +- 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. + +## 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://www.eessi.io/docs/support](https://www.eessi.io/docs/support). 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: diff --git a/mkdocs.yml b/mkdocs.yml index f0152200d0..5fa809a360 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -80,7 +80,14 @@ nav: - Contact info: contact.md - Training: training/index.md - Systems where EESSI is available: systems.md - - Governance: governance.md + - Governance: + - Overview: governance/index.md + - Charter: governance/charter.md + - Governance: governance/governance.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 - Blog: blog/index.md plugins: - blog: