docs/source/community/governance.md
PyTorch adopts a technical governance structure that is hierarchical.
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.
Modules are defined as GitHub repositories within the PyTorch org, or as directories within the core repository pytorch/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:
The core maintainers are expected to have a deep understanding of the PyTorch code base and design philosophies. Their responsibilities include:
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.
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.
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 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.
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:
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.
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:
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.
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 the pytorch/pytorch repository.
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:
The core maintainers take final decisions on the proposal, articulating the reasoning behind the decision publicly.
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.
Every pull request needs to be reviewed by either the CODEOWNERS or by an appropriate core reviewer who is able to review any changes in the repo. A core reviewer is an individual chosen by the core maintainers who has the authority to approve changes across the repository.
Substantial changes in a given interest area require a GitHub issue to be opened for discussion. This includes:
Core and module maintainers ultimately approve these changes.
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.
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 to [email protected] for marketing support.