PyTorch Governance | Mechanics (original) (raw)

Created On: Mar 11, 2019 | Last Updated On: Apr 16, 2025

Summary#

PyTorch adopts a technical governance structure that is hierarchical.

• A community of contributors who file issues, make pull requests, and contribute to the project.
• A small set of module maintainers drive each module of the PyTorch project.
• They are overseen by core maintainers, who drive the overall project direction.
• The core maintainers have a lead core maintainerwho is the catch-all decision maker.

All maintainers are expected to have a strong bias towards PyTorch’s design philosophy.

Beyond the maintainers, the community is encouraged to contribute, file issues, make proposals, review pull requests and be present in the community. Given contributions and willingness to invest, anyone can be accepted as a maintainer and provided write access or ownership of parts of the codebase.

Technical governance is strictly separated from business governance. Separating technical from business governance ensures that there is no way for any person or company to “buy their way into” the technical guidance of the project. Additionally, membership in the technical governance process is for individuals, not companies. That is, there are no seats reserved for specific companies, and membership is associated with the person rather than the company employing that person.

Module Maintainers#

Modules are defined as GitHub repositories within the PyTorch org, or as directories within the core repositorypytorch/pytorch. Each module will have its own maintainer group. Maintainer groups are responsible for reviewing and approving commits, improving design, and changing the scope of the module. Each maintainer group may adopt its own rules and procedures for making decisions (majority vote being default). Module maintainers have the right to dispute decisions made by other module maintainers – especially if it affects them. When disputes are made, the module maintainer group should provide a reasonable and public explanation of the dispute, the relevant arguments, and the resolution. In the exceptional cases where module maintainers cannot come to a conclusion themselves, they will escalate to core maintainers for review. The escalations are resolved by the core maintainers in accordance with their rules and procedures.

Each maintainer group should publish publicly available communication for their module (a vision, rough roadmap, design docs, any disputes and dispute resolutions) so that contributors and other interested parties understand the future direction of the project and can participate in discussion.

Responsibilities of the maintainer includes:

• Triaging high priority issues of the module
• Triaging and reviewing and landing high priority pull requests of the module
• Supporting public documentation related to the module
• Running public developer meetings

Core Maintainers#

The core maintainers are expected to have a deep understanding of the PyTorch code base and design philosophies. Their responsibilities include:

• Articulating a cohesive long-term vision for the project
• Negotiating and resolving contentious issues in ways acceptable to all parties involved
• Receiving broad requests for changes from stakeholders of PyTorch and evaluating / accepting them (small module-level requests are handled by module maintainers)

The core maintainers as a group have the power to veto any decision made at a Module maintainer level. The core maintainers have power to resolve disputes as they see fit. The core maintainers should publicly articulate their decision-making, and give a clear reasoning for their decisions, vetoes and dispute resolution.

The core maintainers are admins of the PyTorch GitHub Org and are listed in Maintainers.

Lead Core Maintainer (BDFL)#

There may be decisions in which the core maintainers cannot come to a consensus. To make such difficult decisions, the core maintainers have an assigned and publicly declared Lead Core Maintainer amongst them, also commonly known in open-source governance models as a BDFL.

The Lead Core Maintainer should publicly articulate their decision-making, and give a clear reasoning for their decisions. The Lead Core Maintainer is also responsible for confirming or removing core maintainers.

Nominating, Confirming and Removing Maintainers#

The Principles#

• Membership in module maintainer groups is given to individualson merit basis after they demonstrated strong expertise of the component through contributions, reviews and discussions and are aligned with how the component fits in overall PyTorch direction.
• For membership in the maintainer group the individual has to demonstrate strong and continued alignment with the overall PyTorch principles.
• No term limits for module maintainers or core maintainers
• Light criteria of moving module maintenance to ‘emeritus’ status if they don’t actively participate over long periods of time. Each module maintainer group may define the inactive period that’s appropriate for that module.
• The membership is for an individual, not a company.

The Process for Nomination#

• Each module has its own process. Please contact module maintainers for more information. However, if there is no process identified, you can file a request to the core maintainers by submitting this form. Core maintainers are meeting every three months.
• If you are submitting a request to the core maintainers, the information in your request must include the following items:
  • The nominees depth and breadth of code, review and design contributions on the module
  • Testimonials (positive and negative) of the nominee’s interactions with the maintainers, users, and the community
  • General testimonials of support from the maintainers
• The core maintainers then evaluate all information and make a final decision to Confirm or Decline the nomination. The decision of the core maintainers has to be articulated well and would be public.

The Process for Removal#

• Similar to the process for nomination, anyone in the community can nominate a person to be removed from a Module maintainer position or a Core maintainer position.
• A person can also self-nominate to be removed
• The core maintainers (excluding persons with conflict of interest) will request or put together more information around the following:
  • Their activity (or lack of) on the project
  • Their changing thinking of the space, which results in conflict with the overall direction of the project
  • Other information that makes them unfit to be a maintainer, such as Code of Conduct issues, their activity outside the scope of the project that conflicts with the project’s values
  • Conflicts of interest: filial or romantic relationships
• The core maintainers then evaluate all information and make a final decision to Confirm or Decline the removal. The decision of the core maintainers has to be articulated well and would be public.

Nominating Core Maintainers#

• Any core or module maintainer can nominate someone to become a core maintainer
• The lead maintainer (BDFL) is responsible for evaluating the nomination.
• The lead maintainer requests or puts together more information around the strength of the candidate to be a core maintainer:
  • Letters of support from other core and module maintainers
  • General letters of support from stakeholders within the PyTorch community
  • Any new relevant information that is befitting for the candidacy
• The lead maintainer evaluates all information and makes a final decision to Confirm or Decline the nomination, with a clear public articulation of their reasoning behind the decision.

Removing the Lead Core Maintainer and Nominating a New Lead Core Maintainer#

• A super-majority of core maintainers (75%) can choose to remove the Lead Core Maintainer
• After a removal of the Lead Core Maintainer or in unforeseen circumstances (such as permanent unavailability of the Lead Core Maintainer), the core maintainers follow a Ranked-Choice voting method to elect a new Lead Core Maintainer.

Add, Remove, and Re-Scope Modules and Projects#

The core maintainers together are responsible for taking decisions on adding, removing and re-scoping new modules in the PyTorch org, either as new repositories in the PyTorch GitHub org, or as folders in thepytorch/pytorchrepository.

They invite proposals from members in the community (including themselves) for such changes. The proposals are open-ended, but should have some basic ground-work to make a convincing case to make change. The following is an example approach to this process:

1. Interview researchers / stakeholders, talk to community, gather issues;
2. Read papers, attend conferences, build example pipelines based on experience;
3. Create a state of the world - make sure this change is necessary, for example adding a new project or module is worth the maintenance cost; or removing a project or module will not remove too much value from PyTorch;
4. Create a proposal; the proposal covers the maintainership, development and community plan once the proposal is approved.

The core maintainers take final decisions on the proposal, articulating the reasoning behind the decision publicly.

Decision Making#

Uncontroversial Changes#

Primary work happens through issues and pull requests on GitHub. Maintainers should avoid pushing their changes directly to the PyTorch repository, instead relying on pull requests. Approving a pull request by a core or module maintainer allows it to be merged without further process. Core and module maintainers, as listed on the Maintainerspage and within CODEOWNERSultimately approve these changes.

Notifying relevant experts about an issue or a pull request is important. Reviews from experts in the given interest area are strongly preferred, especially on pull request approvals. Failure to do so might end up with the change being reverted by the relevant expert.

Controversial Decision Process#

Substantial changes in a given interest area require a GitHub issue to be opened for discussion. This includes:

• Any semantic or syntactic change to the PyTorch framework or library.
• Backwards-incompatible changes to the Python or C++ API.
• Additions to the core framework or library, including substantial new functionality within an existing library.
• Removal of core features or platform support

Core and module maintainers ultimately approve these changes.

General Project Policies#

PyTorch has been established as PyTorch a Series of LF Projects, LLC. Policies applicable to PyTorch and participants in PyTorch, including guidelines on the usage of trademarks, are located at https://www.lfprojects.org/policies/.

PyTorch participants acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the project. Except as described below, all code contributions to the project must be made using the 3-Clause-BSD License available here:https://opensource.org/licenses/BSD-3-Clause (the “Project License”). All outbound code will be made available under the Project License. The Maintainers may approve the use of an alternative open license or licenses for inbound or outbound contributions on an exception basis.

FAQ#

Q: What if I would like to own (or partly own) a part of the project such as a feature area or domain library, for example Linear Algebra or Torch Vision **?**This is absolutely possible. The first step is to start contributing to the existing project area and supporting its health and success. In addition to this, you can make a proposal through a GitHub issue for new functionality or changes to improve the project area.

Q: What if I am a company looking to use PyTorch internally for development, can I be granted or purchase a board seat to drive the project direction? No, the PyTorch project is strictly driven by the a maintainer project philosophy and clearly separates technical governance from business governance. However, if you want to be involved in sponsorship and support, you can become involved in the PyTorch Foundation (PTF) and sponsorship through this. You can also have individual engineers look to become maintainers, but this is not guaranteed and is merit-based.

Q: Does the PyTorch project support grants or ways to support independent developers using or contributing to the project? No, not at this point. We are however looking at ways to better support the community of independent developers around PyTorch. If you have suggestions or inputs, please reach out on the PyTorch forums to discuss.

Q: How do I contribute code to the project? If the change is relatively minor, a pull request on GitHub can be opened up immediately for review and merge by the project committers. For larger changes, please open an issue to make a proposal to discuss prior. Please also see the PyTorch Contributor Wiki for contribution for a walkthrough.

Q: Can I become a committer on the project? Unfortunately, the current commit process to PyTorch involves an interaction with Facebook infrastructure that can only be triggered by Facebook employees. We are however looking at ways to expand the committer base to individuals outside of Facebook and will provide an update when the tooling exists to allow this.

Q: What if I would like to deliver a PyTorch tutorial at a conference or otherwise? Do I need to be ‘officially’ a committer to do this? No, we encourage community members to showcase their work wherever and whenever they can. Please reach out tomarketing@pytorch.orgfor marketing support.