EESSI Governance

docs/governance/charter.md

@@ -0,0 +1,42 @@
+<!-- 
+A project charter discusses _what it is and why it exists_, a governance discusses _how it operates_.
+
+Examples
+
+https://docs.clearlydefined.io/docs/community/charter
+https://openssf.org/about/charter/
+https://github.com/cncf/foundation/blob/main/charter.md
+https://github.com/mochajs/mocha/blob/main/PROJECT_CHARTER.md
+https://github.com/nodejs/TSC/blob/main/TSC-Charter.md
+Combined charter - governance https://github.com/camaraproject/Governance/blob/main/ProjectCharter.md
+blog about charters https://opensource.org/blog/what-is-open-governance-drafting-a-charter-for-an-open-source-project
+-->
+
+# Project Charter
+
+## 1. Mission
+<!-- Describe the project's purpose and the problem it addresses. Include a short mission statement. -->
+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)
+- Easily extendable
+
+## 2. Scope
+<!-- Define what is within the scope of the project and what is explicitly out of 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
+- 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.
+
+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
+<!-- Who can join or participate? Are there any requirements (e.g., code contributions, voting eligibility)? -->
+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

docs/governance/governance.md

@@ -0,0 +1,164 @@
+<!-- 
+A project charter discusses _what it is and why it exists_, a governance discusses _how it operates_.
+-->
+
+# Project Governance
+
+## 1. Guiding Principles
+<!-- Optional section to state high-level principles like openness, meritocracy, consensus, etc. -->
+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, 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. 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
+<!-- Define who contributors are and what they can do (e.g., file issues, submit PRs). -->
+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 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.
+
+### 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 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 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 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.
+
+### 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. 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. 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
+
+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
+<!-- Describe how decisions are reached: rough consensus, lazy consensus, etc. -->
+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
+<!-- Detail when voting is used, who can vote, quorum rules, and thresholds. -->
+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
+<!-- Define how disputes are escalated and resolved. -->
+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
+<!-- Steering committee overruling a group? -->
+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
+<!-- Define how and where the team communicates, and how meetings (if any) are run. -->
+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 Section 2.
+
+### 5.1 Adding Team Members
+<!-- Describe the process for adding new 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 Removing Team Members
+<!-- Describe under what conditions someone may be removed (e.g., inactivity, conduct). -->
+Teams decide themselves decide the procedure to remove new Team members. As for the procedure of adding Team Members, the procedure to remove Team Members should reflect the sensitivity of the position.
+
+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 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 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.
+
+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.
+
+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).
+
+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.
+
+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.
+
+### 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
+<!-- Reference your Code of Conduct or provide a brief summary. -->
+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

docs/governance/policies.md

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