Like Process RFCs, this RFC is merely a proposal. We are submitting this pre-RFC to collect feedback from the community. We encourage everyone to reply and help us improve this proposal.
Many of TVM’s development processes have been historically established in an ad-hoc fashion by TVM Committers and PMC Members to meet the needs of the community at the time. Today, some of them have been left implicitly documented and maintained as tribal knowledge. This was a perfectly acceptable way to operate as a smaller community, but it is introducing new challenges as we grow.
TVM already has a fairly diverse set of use cases and contributors. Meanwhile, both TVM Committers and PMC Members have gotten busier and busier, making it harder for them to ensure that our development processes are working for all members of the community. Additionally, it can be hard for a TVM Committer or PMC Member to assess the needs of everyone in the community, since many processes which require write access (e.g. updating CI dependencies) can seem smoother to them than they really are for the community at large.
Taking a step back, we are concerned that the ad-hoc way in which TVM’s development practices are established might make it difficult for newcomers to suggest improvements or even understand current practices. We feel justified in this concern because we also observe that TVM is a complex project and newcomers frequently need help knowing where to start on a particular task.
As a concrete example, CI has historically been a process completely maintained by tribal knowledge of the PMC. If we want to codify new changes to our CI processes, it is not clear how a contributor could suggest, ratify, and rollout such a change without joining the PMC.
In the spirit of Apache, we want to enable more of the community to help shape and grow the community without first having to join the PMC before being able to influence the community.
In order to address these challenges, this RFC proposes we define a process to allow anyone in the community to propose and ratify changes to TVM development processes.
We propose a new type of RFC: a Process RFC for suggesting community-wide changes in the TVM development process.
A Process RFC is an RFC that proposes changes in the TVM development processes rather than the technical direction of TVM.
Examples of development processes include:
- The code-review tool being used, or conventions around code-review
- The release cadence, or other aspects of the release process with a community component (e.g. allowing community members to ratify a pre-release)
- The RFC process itself
Examples of things that are not development processes (and which therefore should be changed using an ordinary RFC are):
- The release process itself
- The set of tests or lint tools ran in TVM CI
- The test suite used for a particular target
The goals of a Process RFC are different from those of an ordinary RFC:
- Introduce a change in the TVM community, not in the technical architecture of TVM
- Result in a clear acceptance decision instead of soft-consensus on the mailing list or GitHub.
- Result in clear documentation about accepted processes so new community members can learn how to properly follow community adopted processes.
A Process RFC goes through the following discussion and voting process:
The proposer (which can be anyone, including new contributors) will post the Process RFC onto the Discuss forum.
A TVM committer will be assigned (either self-assigned or by the PMC) to be the shepherd of the process RFC. The shepherd should ensure the RFC has received adequate review and feedback by TVM committers.
When either the shepherd or the author of the Process RFC feel that all the arguments have been presented, one of them will call for final comments. In general, the initial comment period should last at least a week, and the final comment period should last exactly one week.
During the final comment period, folks should wrap up any debates. In general, commenters should aim to submit one additional comment to summarize their position for or against their RFC.
Also during the final comment period, all contributors are invited to vote on the RFC. The shepherd should start a new GitHub Issue in apache/tvm whose name starts with “[VOTE]” per Apache guidelines. Votes can be submitted by posting a comment in this voting issue. Votes may be changed during the final comment period. If this happens, contributors are encouraged to include brief justification.
PMC members are encouraged not to cast a vote until the end of the final comment period (see next point). PMC members are strongly encouraged to follow the will of the community. Votes which differ with the majority opinion should include justification.
At the end of the final comment period, the shepherd will count the votes and deem the RFC either accepted, rejected.
- Voting rules follow the ASF guidelines for procedural votes. Per the ASF guidelines, if the sum of the votes of those participating PMC members is positive, the RFC is considered accepted.
- Otherwise, the RFC is considered rejected.
If the RFC is approved, the proposer is responsible (but can delegate with mutual agreement) for converting the RFC to process documentation which will be committed to the official Apache TVM documentation. The shepherd should ensure that the accepted Process RFC is being implemented.
The Process RFC should be committed to
apache/tvm-rfcswith any revisions which arose from discussion. Once both the RFC is committed and the TVM process documentation is updated, the community may then adopt the newly-changed process.
Process RFCs do not need to follow the RFC template structure. In general, process RFCs should aim to include:
- A summary of the problem, with specifics as needed
- A description of the proposed change
- Alternatives considered
- Open questions and topics for discussion
This adds more process than we currently have, but an overwhelming piece of feedback from the community is that is not clear who can, and should make these changes. Then when changes are proposed what the timeline, ratification, and rollout processes are.
To avoid burdening the community, this process is not intended to deviate far from the RFC process already adopted by the community earlier this year. However, changes in developer processes are inherently more impactful than technical RFCs. Process changes require buy-in from the entire TVM community, rather than merely a group of community members most involved with the relevant section of the product.
Over the traditional RFC process, Process RFCs are additionally subject to:
- A shepherd to oversee the RFC, which we feel is helpful when the proposer is not familiar with TVM community processes
- A final comment period, which we feel is necessary to ensure that any discussion wraps up in preparation for a vote.
- A vote, which we feel is important in order to measure consensus and ensure the community is prepared to follow the proposed process changes.
Regarding the final comment period and time limit: there is precedent in other communities to use disagree-and-commit mechanisms to ensure that timely consensus is reached and that processes eventually result in an outcome, even if its clear postponement or rejection.
The Rust RFC process which we drew some inspiration from has used a final comment period to ensure that as the number of RFCs have grown that timely, and definitive decisions are made.
- Is this process a reasonable burden to add to the community?
- Are the voting process and comment periods reasonable?