48/Flux Framework Project Governance

This document describes the governance model for the Flux Framework project, outlining the principles, roles, and procedures that guide its development and community management.

Name	github.com/flux-framework/rfc/spec_48.rst
Forked from	https://github.com/jlcanovas/gh-best-practices-template
Editor	Vanessa Sochat <sochat1@llnl.gov>
State	draft

Language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Related Standards

• 1/C4.1 - Collective Code Construction Contract

• 2/Flux Licensing and Collaboration Guidelines

• 7/Flux Coding Style Guide

• 47/Flux Framework Contributor Code of Conduct

Goals

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.

Project Governance

The “project” refers to the flux-framework GitHub organization and all the repositories hosted within it.

The development and community management of the project will follow the governance rules described in this document.

Roles

1/C4.1 - Collective Code Construction Contract defines the following roles for each GitHub repository within the flux-framework organization:

Contributor

A person who wishes to provide a patch. Contributors have a baseline level of access to the repository, defined by the repository Maintainers.

Maintainer

A person who holds the maximum privilege level to a repository. Maintainers approve Contributor changes and guide development. The file MAINTAINERS.md within each repository defines the GitHub identities of the Maintainers. Maintainers MAY grant additional repository level privileges to Contributors. A simple majority of Maintainers may approve the addition or removal of Maintainers from the repository.

In addition, we define the following role for the project:

Administrator

A person that holds maximum privilege level to the flux-framework organization and all its repositories. Administrators provide technical direction for the project, create and remove repositories, and participate in the Linux Foundation Technical Steering Committee for flux-framework. The organization README.md defines the GitHub identities of Administrators.

Github Administration

The project is currently hosted on GitHub. The project roles defined above SHALL be implemented on Github as follows:

Project	Github Org	Github Repo	Notes
Administrator	owner	admin (effective)	Toggle owner/member on entry in org People drop-down.
Maintainer	none	admin	Add org level reponame-maintainers team and give it repo level direct access with the admin role.
Contributor	none	TBD	Maintainers manage this level of access

Development Workflow

The project adheres to a modern development philosophy centered on open standards and consistency. See details in the RFC 1 Development Process.

Governance & Standards

RFC Process

See the Evolution of Public Contracts section of RFC 1.

Decision Making

The project uses a lazy consensus model for most changes and standard issue resolutions.

Maintainer Review

Maintainer review is required for all Pull Requests prior to merging.

Issue Governance

• Both contributors and project maintainers may propose issues. The participation in the issue discussion is open and must follow the RFC 47 Code of Conduct.

• The group of project maintainers will be responsible for assigning labels to issues, as well as for assigning the issue to a project maintainer or contributor. The merge-when-passing label MAY be applied by a maintainer to allow a pull request to be automatically merged once it has met all requirements.

• The group of project maintainers SHOULD commit to responding to any issue within 72 hours of the issue’s creation.

Pull Request Governance

• Both contributors and project maintainers may propose pull requests.

• Pull requests SHOULD describe the contribution. The assignment of labels and assignees to the pull request is the responsibility of the project maintainers.

• The group of project maintainers SHOULD provide feedback to any pull request within 72 hours of the pull request’s creation.

• The decision of accepting (or rejecting) a pull request will be taken by the group of project maintainers. The criteria and process for making the decision is described in the RFC 1 Development Process.