title: TPA-RFC-1: RFC process
Summary: policy decisions should be made in an online concensus building process with a 2 days to 2 weeks delay, and formally documented in this wiki.
In the sysadmin team (AKA "TPA"), decisions can be made by individuals in their daily work, in the regular online or in-person meetings, or through an asynchronous online decision making process. This proposal documents the latter decision making process and also serves as an example of such proposal.
The idea behind this process is to include people for major changes so that we don't get into a "hey wait we did what?" situation later. It also allows decisions to be moved outside of meetings to have a faster decision making process.
We already have the possibility of doing such changes right now, but it's unclear how that process works or if it works at all. This is therefore a formalization of this process.
We do understand that people can make mistakes and might improvise sometimes, especially if process is not currently doumented.
This procedure aims to provide process for complex questions that:
- might impact more than one system
- define a contract between clients or other team members
- add or replace tools or languages to the stack
- build or rewrite something from scratch
When in doubt, use the process.
It is not designed for day-to-day judgement calls and regular operations that do not fundamentally change our work processes.
It also does not cover the larger Tor Project policies as a whole. When there is a conflict between the policies defined here and the larger Tor policies, the latter policies overrule.
Decisions in the above scope should be written as a formal proposal, explaining the purpose and a formal deadline, along with any relevant background information. Such proposals are brought up to seek feedback from peers in good faith, and assume trust between team members.
Proposals should be written in a Markdown document in a wiki with revision history (currently this wiki).
A notification of the proposal must also be sent by email to the team
email@example.com). If the proposal
affects other teams outside of TPA, it should also be created as a
"ticket" in the ticket tracking software (currently "Trac") so that
other teams can provide feedback.
Each proposal has a unique identifier made up of the string
and a unique, incremental number. This proposal, for example, is
TPA-RFC-1 and the next one would be
When the proposal is first written and the notification is sent, the
proposal is considered a
draft. It then enters a discussion period
during which changes can be proposed and objections can be
raised. That period ranges from 2 business days and two weeks and is
picked in good faith by the proposer based on the urgency of the
Objections must be formulated constructively and justified with reasonable technical or social explanations. The goal of this step is to communicate potential negative impacts and evaluate if they outweight the possible benefits of the proposal.
If the negative impacts outweigh the benefits, a constructive objection must also propose changes can be made to the proposal to mitigate those problems.
A proposal is in any of the following states:
Once the discussion period has passed and no objection is raised, the
draft is adopted and becomes a
If objections are raised and no solution is found, the proposal is
Some policies can be completely overriden using the current policy
process, including this policy, in which case the old policy because
Note that a policy can be modified by later proposals. The older
policy is modified only when the new one becomes
TPA-RFC-X proposes changes to a previous
proposal. In that case, the text of
TPA-RFC-N would be modified when
and only if
TPA-RFC-X becomes a
standard. The older
would also stay a
Examples of ideas relevant for the RFC process:
- replacing Munin with grafana and prometheus #29681
- setting defaut locale to C.UTF-8 #33042
- using Ganeti as a clustering solution
- using setup-storage as a disk formatting system
- setting up a loghost
- switching from syslog-ng to rsyslog
- changes to the RFC process
- setting up a new Ganeti node (part of the roadmap)
- performing security updates (routine)
- picking a different hardware configuration for the new ganeti node (process wasn't documented explicitely, we accept honest mistakes)
Considering that the proposal was discussed and informally approved at the February 2020 team meeting, this proposal will be adopted within one week unless an objection is raised, which is on 2020-02-14 20:00UTC.
This proposal is currently in the
This process is similar to the Network Team Meta Policy except it doesn't require a majority "+1" votes to go ahead. In other words, silence is consent.