Skip to content

Commit 6ec4634

Browse files
vsochvsoch
committed
feat: governance document
Problem: to better encourage open source and community participation, we need a clear governance document. Solution: add RFC 48 for governance. This will need to be updated with rfc 47 (post merge) Signed-off-by: vsoch <vsoch@users.noreply.github.com>
1 parent 1dd7183 commit 6ec4634

File tree

3 files changed

+160
-0
lines changed

3 files changed

+160
-0
lines changed

‎index.rst‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -300,6 +300,12 @@ resource range defined by a min/max/operand/operator combination.
300300
This specification describes a compact form for expressing an RFC 14 jobspec
301301
resources list that can be provided to several Flux commands by a user.
302302

303+
:doc:`spec_48`
304+
~~~~~~~~~~~~~~
305+
306+
This document describes the rules for the development and community management
307+
of the Flux Framework project (governance).
308+
303309
.. Each file must appear in a toctree
304310
.. toctree::
305311
:hidden:
@@ -348,3 +354,4 @@ resources list that can be provided to several Flux commands by a user.
348354
spec_44
349355
spec_45
350356
spec_46
357+
spec_48

‎spec_48.rst‎

Lines changed: 149 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,149 @@
1+
.. github display
2+
GitHub is NOT the preferred viewer for this file. Please visit
3+
https://flux-framework.rtfd.io/projects/flux-rfc/en/latest/spec_48.html
4+
5+
48/Flux Framework Project Governance
6+
####################################
7+
8+
This document describes the rules for the development and community management of the Flux Framework project.
9+
10+
.. list-table::
11+
:widths: 25 75
12+
13+
* - **Name**
14+
- github.com/flux-framework/rfc/spec_48.rst
15+
* - **Forked from**
16+
- https://github.com/jlcanovas/gh-best-practices-template
17+
* - **Editor**
18+
- Vanessa Sochat <sochat1@llnl.gov>
19+
* - **State**
20+
- draft
21+
22+
Language
23+
********
24+
25+
.. include:: common/language.rst
26+
27+
Related Standards
28+
*****************
29+
30+
- :doc:`spec_1`
31+
- :doc:`spec_3`
32+
- :doc:`spec_7`
33+
- :doc:`spec_47`
34+
35+
Goals
36+
*****
37+
38+
The goal of this governance document is to clearly define the roles, responsibilities, and decision-making mechanisms for the Flux Framework project to ensure consistent, transparent, and sustainable development.
39+
40+
Design
41+
******
42+
43+
Project Governance
44+
==================
45+
46+
The development and community management of the project will follow the governance rules described in this document.
47+
48+
Project Maintainers
49+
-------------------
50+
51+
Project maintainers have admin access to the GitHub repository. The team of project maintainer is the following:
52+
53+
* `Tom Scogland <scogland1@llnl.gov>`_
54+
* `Mark Grondona <grondona1@llnl.gov>`_
55+
* `Jim Garlick <garlick1@llnl.gov>`_
56+
57+
1. Roles
58+
--------
59+
60+
This project includes the following roles.
61+
62+
1.1. Maintainer
63+
^^^^^^^^^^^^^^^
64+
**Maintainers** are responsible for organizing activities around developing, maintaining, and updating the Project. Project maintainers will review and merge pull requests.
65+
66+
1.2. Collaborator
67+
^^^^^^^^^^^^^^^^^
68+
Any member willing to participate in the development of the project will be considered as a **collaborator**. Collaborators may propose changes to the project's source code. The mechanism to propose such a change is a GitHub pull request. A collaborator proposing a pull request is considered a **contributor**.
69+
70+
2. Development Workflow
71+
-----------------------
72+
73+
The project adheres to a modern development philosophy centered on open standards and consistency.
74+
75+
* **Development Approach**: Modern development workflow centered on **test-driven development**, open standards, and consistent release cycles.
76+
* **Release Cadence**: Releases are targeted monthly, coordinated with the **TOSS** (Tri-Lab Operating System Stack) operating system update schedule.
77+
* **Versioning**: Components use **Semantic Versioning** for tagged releases on GitHub.
78+
* **Continuous Integration/Delivery**: Comprehensive **CI/CD** is enforced across all repositories using **GitHub Actions**.
79+
* **Testing**:
80+
* **Unit testing** is standard practice.
81+
* **Integration tests** are implemented using **sharness**.
82+
* **End-to-End (E2E) tests** are conducted using **Kind/Minikube**.
83+
84+
3. Distribution Channels
85+
------------------------
86+
87+
Flux Framework components are available via multiple channels to support diverse HPC, cloud, and developer environments.
88+
89+
* **HPC/Source**: **Source tarballs** and **Spack packages** (``spack install flux-core``).
90+
* **Containers/Cloud**:
91+
* Projects include dedicated **Developer container environments**.
92+
* Component containers are released alongside source code.
93+
* The **flux-operator** is distributed via YAML files and Container Images, and **Helm Charts** for Cloud/Kubernetes deployments.
94+
* **Language Ecosystems**: **Python (pypi)** packages are distributed for Flux Python bindings.
95+
* **Package Managers (In Progress)**: Efforts are underway to provide **rpms** and **debian packages**.
96+
97+
4. Governance & Standards
98+
-------------------------
99+
100+
4.1. RFC Process
101+
^^^^^^^^^^^^^^^^
102+
Major architectural changes and protocol definitions must follow the Flux **Request for Comments (RFC) process**, fostering a "spec-first" philosophy.
103+
104+
4.2. Decision Making
105+
^^^^^^^^^^^^^^^^^^^^
106+
The project uses a **lazy consensus model** for most changes and standard issue resolutions.
107+
108+
4.3. Maintainer Review
109+
^^^^^^^^^^^^^^^^^^^^^^
110+
**Maintainer review is required** for all Pull Requests prior to merging.
111+
112+
5. Issue Governance
113+
-------------------
114+
115+
5.1.
116+
^^^^
117+
Both collaborators and project maintainers may propose issues. The participation in the issue discussion is open and must follow the `Code of Conduct <spec_47>`_.
118+
119+
5.2.
120+
^^^^
121+
The group of project maintainers will be responsible for assigning labels to issues, as well as assign the issue to a project maintainer or contributor.
122+
123+
5.3.
124+
^^^^
125+
The group of project maintainers commit to give an answer to any issue in a period of time of **48 hours**.
126+
127+
6. Pull Request Governance
128+
--------------------------
129+
130+
6.1.
131+
^^^^
132+
Both collaborators and project maintainers may propose pull requests. When a collaborator proposes a pull request, is considered contributor.
133+
134+
6.2.
135+
^^^^
136+
Pull requests should comply with the template provided. The assignment of labels and assignees to the pull request is the responsibility of the project maintainers.
137+
138+
6.3.
139+
^^^^
140+
The group of project maintainers commit to give an answer to any pull request in a period of time of **48 hours**.
141+
142+
6.4.
143+
^^^^
144+
The decision of accepting (or rejecting) a pull request will be taken by the group of project maintainers. The decision will be based on the following criteria:
145+
146+
* Two project maintainers must approve a pull request before the pull request can be merged.
147+
* One project maintainer approval is enough if the pull request has been open for more than **14 days**.
148+
* Approving a pull request indicates that the contributor accepts responsibility for the change.
149+
* If a project maintainer opposes a pull request, the pull request cannot be merged (i.e., *veto* behavior). Often, discussions or further changes result in collaborators removing their opposition.

‎spell.en.pws‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -505,3 +505,7 @@ setpgrp
505505
killpg
506506
posix
507507
waitable
508+
Sochat
509+
Tri
510+
Kubernetes
511+
assignees

0 commit comments

Comments
 (0)