1# The Cirq RFC process
2
3New major Cirq feature begins life as a Request for Comment (RFC).
4
5An RFC is a document that describes a requirement and the proposed changes that will solve it. Specifically, the RFC will:
6
7*   Be formatted according to the [RFC template](https://tinyurl.com/cirq-rfc-template) in a Google Doc
8*   A github issue is submitted with the link to the Google Doc
9*   Be subject to discussion and a review meeting prior to acceptance.
10
11The purpose of a Cirq Request for Comments (RFC) is to engage the Cirq community in development, by getting feedback from stakeholders and experts,
12and communicating design changes broadly.
13
14
15## What constitutes a major feature
16
17Major features can be one of the following:
18*   Features that drastically change the user experience or workflow of Cirq.
19*   Features that create new library dependencies for Cirq.
20*   New simulators, samplers, protocols, devices, or packages.
21*   Features that drastically change performance of Cirq.
22*   Features that maintainers disagree/debate about.
23
24The following are NOT major features:
25
26*   Fixing a bug.
27*   Extending the functionality of an existing method in a natural way.
28
29If you are not sure if a feature constitute as a “major feature”, just submit a Github issue with a description,
30and one of the maintainers will flag the issue as a major feature if necessary.
31
32## How to submit an RFC
33
34
351. Before submitting an RFC, discuss your aims with project contributors and maintainers and get early feedback. \
36Open a [feature request](https://github.com/quantumlib/Cirq/issues/new?assignees=&labels=kind%2Ffeature-request&template=feature_request.md&title=) \
37and have a discussion with the maintainers. Mention that you are willing to write an RFC.
382. [Join the cirq-dev Google Group](https://groups.google.com/forum/#!forum/cirq-dev) to get an invitation to our weekly Cirq Cynq meeting.
393. Draft your RFC.
40    * Follow the [RFC template](https://tinyurl.com/cirq-rfc-template), link the Github issue in your RFC.
41    * Make sure to share your doc with cirq-dev@googlegroups.com for comments.
42    * Link the RFC in your issue.
434. Recruiting a sponsor:
44    * A sponsor must be a maintainer of the project or the product manager (currently Alan Ho).
45    * Write a comment in your Github issue that calls out that you are "Looking for a sponsor". A maintainer will mark the issue with a label: "rfc/needs-sponsor".
46    * While it might take some time to get a maintainer to sponsor your RFC, it is essential, as the sponsor will facilitate the process for reviewing your design.
47    * Tips to recruit a sponsor: 1) keep commenting on the issue weekly 2) attend Cirq Cynq and push for a sponsor.
485. Agree with your sponsor on a Cirq Cync meeting to present the RFC so that other contributors and maintainers can become more familiar with your design.
496. The meeting may approve the RFC, reject it, or require changes before it can be considered again. \
50It is likely that multiple iterations of comments and meetings with your sponsor will be required before approval.
51
52
53## RFC participants
54
55Many people are involved in the RFC process:
56
57*   **RFC author** — one or more community members who write an RFC and are committed to championing it through the process
58*   **RFC sponsor** — a maintainer or product manager who sponsors the RFC and will shepherd it through the RFC review process
59*   **review committee** — a group of maintainers who have the responsibility of recommending the adoption of the RFC.  This group can be emailed by emailing cirq-maintainers@googlegroups.com. This is typically the attendees at the Cirq Cync meeting.
60*   Any **community member** may help by providing feedback on whether the RFC will meet their needs.
61
62### RFC sponsors
63
64A sponsor is a project maintainer responsible for ensuring the best possible outcome of the RFC process. This includes:
65
66*   Advocating for the proposed design.
67*   Guiding the review committee to come to a productive consensus.
68*   If the RFC moves to implementation:
69    *   Ensuring proposed implementation adheres to the design.
70    *   Coordinate with appropriate parties to successfully land implementation.
71
72
73### RFC review committees
74
75The review committee decides on a consensus basis whether to approve, reject, or request changes. They are responsible for:
76
77*   Ensuring that substantive items of public feedback have been accounted for.
78*   Adding their meeting notes as comments to the PR.
79*   Providing reasons for their decisions.
80
81The constitution of a review committee may change according to the particular governance style and leadership of each project.
82
83## Implementing new features
84
85Once an RFC has been approved, implementation can begin.
86
87If you are working on new code to implement an RFC:
88
89*   Make sure you understand the feature and the design approved in the RFC. Ask questions and discuss the approach before beginning work.
90*   New features must include new unit tests that verify the feature works as expected.
91*   Add or update relevant API documentation. Reference the RFC in the new documentation.
92*   Follow any other guidelines laid out in the [CONTRIBUTING.md](https://github.com/quantumlib/Cirq/blob/master/CONTRIBUTING.md) file in the project repo you're contributing to.
93*   Run unit tests before submitting your code.
94*   Work with the RFC sponsor to successfully land the new code. This could include PR / marketing of the new feature as well.
95*   Follow the Cirq process of deprecating code. Please refer to [\_compat.py](https://github.com/quantumlib/Cirq/blob/master/cirq/_compat.py) as an example.
96
97
98## Keeping the bar high
99
100While we encourage and celebrate every contributor, the bar for RFC acceptance is kept intentionally high. A new feature may be rejected or need significant revision at any one of these stages:
101
102*   Initial design conversations on the relevant mailing list.
103*   Failure to recruit a sponsor.
104*   Critical objections during the feedback phase.
105*   Failure to achieve consensus during the design review.
106*   Concerns raised during implementation (for example: inability to achieve backwards compatibility, concerns about maintenance).
107
108If this process is functioning well, RFCs are expected to fail in the earlier, rather than later stages.
109An approved RFC is not a commitment to implementation on any sort of timeline. The prioritization of features depends on user interest and willingness of contributors to implement them.
110