This document defines the governance structure for the Flyte project.
Flyte, a graduated LF AI&Data Foundation project, is committed to building an open, inclusive, productive and self-governing open source community focused on building a scalable and resilient platform for Machine Learning and Data Processing workloads. This document aims to define how community should work together to achieve this goal.
The following table lists the roles we use within the Flyte community. The table describes:
- General responsibilities expected by individuals in each role
- Requirements necessary to join or stay in a given role
- How the role manifests in terms of permissions and privileges.
| Role | Responsibilities | Requirements | Privileges | Scope |
|---|---|---|---|---|
| Community member | Follow the LF AI & Data Foundation Code of Conduct | None |
Can submit PRs and issues from forks Can join Flyte Slack workspace Can take part in community discussions |
Github organization |
| Collaborator | Inherits from Community member role | |||
|
Report and sometimes resolve issues Answer questions from other community members Submit feedback on issues and PRs |
One or several of the below: Attend community meetings regularly At least a merged contribution Active on Slack posting/answering questions Promote the project creating content/delivering talks/demos |
Can submit PR reviews May close/open/reassign Issues May request PR reviews Can mark duplicate Issues/PRs |
Specific repo(s) under flyteorg | |
| Committer | Inherits from Collaborator role | |||
|
Follow the project's contributing guide Occasionally submit PRs Test releases and patches and submit reviews Triage issues in the scoped repo Participate on Working Groups under their scoped repo |
One or several of the below: Multiple PRs merged Run or helps run events Promote the project in public |
May request changes to PRs May review, approve PRs (non-binding), and merge approved PRs Can create/edit releases May push branches |
Specific repo(s) under flyteorg | |
| Maintainer | Inherits from Committer Role | |||
|
Ensure contributions align with project goals and meet the project's quality standards Help cut new releases Mentor new contributors |
Must be an existing contributor Highly experienced and active reviewer Demonstrates a broad knowledge of the project across multiple areas |
Can review and approve PRs (binding) Can merge PRs May vote on RFCs (non-binding) May represent the project in public as a Maintainer |
Specific repo(s) under flyteorg | |
| Steering Committee | Inherits from Collaborator Role | |||
|
Set priorities and roadmap for the project Mentor new contributors and maintainers Vote on governance, role, RFCs, and other project-wide changes |
Must be an existing maintainer Highly active maintainer and participant in multiple functional areas |
Org-wide permissions Binding vote on RFCs Represent the project in other communities and upstream organizations
|
Github organization | |
You do not need to be a member of the Flyte team to contribute. Anyone can help by using and talking about Flyte, participating in discussions, answering questions on Slack/Stack Overflow, opening issues, submitting PRs, etc. All of these are fantastic and welcome contributions to the project.
Collaborators are individuals who demonstrate an active interest in the project and are willing to help other community members.
New contributors may be self-nominated or nominated by existing contributors by completing the following steps:
- Submit a new issue to the
communityrepo using thecontributor nominationlabel - Assign current maintainers to the issue. If unsure, check MAINTAINERS.md
- Once submitted, new collaborators must be elected by a supermajority of that project’s (repository) maintainers in no more than 14 days.
- If a new collaborator is accepted, they will receive an invitation to join the
flyteorgGithub organization, inheriting the permissions defined for the Collaborator role in that repository or repositories.
Flyte Committers are those who make regular contributions to the project (documentation, code reviews, responding to issues, participation in proposal discussions, contributing code, etc.) and receive Write access to the repo in their scope.
New committers may be self-nominated or nominated by existing committers by completing the following steps:
- Submit a new issue to the
communityrepo using thecommitter nominationlabel - Assign current maintainers to the issue. If unsure, check MAINTAINERS.md
- Once submitted, new committers must be elected by a supermajority of that project’s (repository) maintainers in no more than 14 days.
- If a new committer is accepted, they will receive an invitation to join the
flyteorgGithub organization, inheriting the permissions defined for the Contributor role in that repository or repositories.
Maintainers are in charge of the day to day maintenance of the team's projects.
They review and approve (binding) PRs, merge PRs, and may cast non-binding votes on RFCs, ensuring contributions align with project goals and meet the project's quality standards.
Note: while the level of complexity and effort varies from repo to repo, currently maintaining Flyte is a full-time job. There are a number of individuals in the community that meet and even surpass the criteria to be nominated and accepted as Flyte Maintainers. Still, the Technical Steering Committee Chair and core Maintainers consider it too much of an ask to assign the responsibilities of maintaining Flyte to volunteers who give away from their work and even personal time, especially considering the current processes involved in maintainer-level tasks like, for example, cutting a new release. That’s why the Maintainer role is currently designed for individuals for whom maintaining Flyte is their primary job responsibility. This is not a limitation for Technical Steering Committee members who inherit the Maintainer privileges and expected responsibilities. Additionally, it is meant to be a temporary control to prevent burnout at higher levels of the contributor ladder. The Flyte Maintainers are committed to work on improving the processes, repo structure, and code ownership to lower the barriers and ensure that, in the near future, the path to Maintainership can be completed by anyone, regardless of their affiliation.
-
Maintainers can be removed by a supermajority of the current team's maintainers or can resign by notifying one of the current team's maintainers.
-
In extenuating circumstances, i.e. long term absence of a maintainer, technical steering committee members may act as maintainers.
The Steering Committee Members are responsible for the direction of the project (roadmap), and cross-cutting concerns such as:
- Reviewing and deciding on new sub-projects to add to Flyte
- Create Special Interest Groups or Working Groups to focus on cross-project technical issues and requirements
- Voting on role changes (eg adding new Steering Committee member)
- Voting on updating this document
- Voting on RFCs that impact any of the above responsibilities.
If and when contributors' commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs moving to emeritus status (completely stepping away from the project).
Contact the Maintainers about changing to Emeritus status, or reducing your contributor level.
NOTE: The current list of maintainers and TSC members lives in MAINTAINERS
The Flyte project is comprised of the following types of subgroups:
- Special Interest Groups (SIGs)
- Subprojects
- Working Groups (WGs)
Special Interest Groups are formed by members from multiple companies and organizations, with a common goal of advancing the project with respect a specific topic. Every identifiable subpart of the project (e.g. repository, subdirectory, API, test, issue, PR) is intended to be owned by some SIG.
Areas covered by SIGs are defined in terms of the level of cross-collaboration and code ownership required to meet their goals:
- Horizontal SIGs: deal with project-wide priorities as defined by the Technical Steering Committee, potentially owning multiple technical assets (repositories, etc)
- Domain-specific SIGs: more focused on particular components of the project, including work towards developing or improving integrations with other projects.
Every SIG should have one SIG chair at any given time, appointing a co-chair when considered necessary. SIG chairs are intended to be organizers and facilitators, responsible for the operation of the SIG and for communication and coordination with the other SIGs, the Steering Committee, and the broader community.
Each SIG must have a charter that specifies its scope (topics, subsystems, code repos and directories), responsibilities and areas of authority.
SIGs are voluntary groups which operate in the open and anyone can join.
- Copy the template into a new file under
/community/sig-YOURSIG/charter.md - Fill out the template for your SIG
- Create a PR with the results of the previous step
- Notify in the #contribute channel and ask Technical Steering Committee members for review/approval
- Once accepted by supermajority of the TSC, the SIG will be ratified by merging the PR
Designed to facilitate discussions/work regarding topics that are short-lived or that span multiple SIGs, Working Groups are distinct from SIGs in that they are intended to:
- facilitate collaboration across SIGs
- facilitate an exploration of a problem / solution through a group with minimal governmental overhead
- It has a clear goal measured through a specific deliverable or deliverables
- It is temporary in nature and will be disbanded after reaching its stated goal(s)
- Answer the following questions:
- What is the exact problem this group is trying to solve?
- What is the artifact that this group will deliver, and to whom?
- How does the group know when the problem solving process is completed, and it is time for the Working Group to dissolve?
- Who are all of the stakeholder SIGs involved in this problem this group is trying to solve?
- What are the meeting mechanics (frequency, duration, roles)? Meetings are suggested but not mandatory for Working Groups
- Does the goal of the Working Group represent the needs of the project as a whole, or is it focused on the interests of a narrow set of contributors or companies?
- Who will chair the group, and ensure it continues to meet these requirements?
- Is diversity well-represented in the Working Group?
- Document your answers in a PR on
groups.yaml - Request reviews from Technical Steering Committee Members. A new WG is approved by a supermajority of TSC active members.
- Once merged, the WG is officially chartered until it either completes its stated goal, or disbands voluntarily.
NOTE: Working groups should strive to make regular reports to stakeholder SIGs or the broader community in order to ensure the mission is still aligned with the current state.
In the event that the SIG is unable to regularly establish consistent quorum or otherwise fulfill its responsibilities
- after 3 or more months it SHOULD be retired
- after 6 or more months it MUST be retired
Working Groups will be disbanded if either of the following is true:
- Its original goal was accomplished and results were communicated
- There is no longer a Lead (with a 6 week grace period)
- None of the communication channels for the Working Group have been in use for the goals outlined at the founding of the Working Group (with a 3 month grace period)
A supermajority is defined as two-thirds of members in the group (66%). A supermajority of Maintainers is required for certain decisions as outlined above. Voting on decisions can happen on the mailing list, GitHub, Slack, email, or via a voting service, when appropriate. Maintainers can either vote "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes when supermajority is met. An abstain vote equals not voting at all.