@@ -20,23 +20,24 @@ process (e.g. a big refactoring of the code, or a
20
20
amounts to a small feature) but is still too controversial or
21
21
big to get by with a single r+, you can start a pFCP (or, if you
22
22
don't have r+ rights, ask someone who has them to start one - and
23
- unless they have a concern themselves, they should).
23
+ unless they have a concern themselves, they should). pFCP stands for
24
+ "proposed final comment period".
24
25
25
26
Again, the pFCP process is only needed if you need consensus - if you
26
27
don't think anyone would have a problem with your change, it's ok to
27
28
get by with only an r+. For example, it is OK to add or modify
28
- unstable command-line flags or attributes without an pFCP for
29
+ unstable command-line flags or attributes without a pFCP for
29
30
compiler development or standard library use, as long as you don't
30
31
expect them to be in wide use in the nightly ecosystem.
31
32
32
33
You don't need to have the implementation fully ready for r+ to ask
33
34
for a pFCP, but it is generally a good idea to have at least a proof
34
35
of concept so that people can see what you are talking about.
35
36
36
- That starts a "proposed final comment period" (pFCP), which requires
37
- all members of the team to sign off the FCP. After they all do so,
38
- there's a 10 day long "final comment period" where everybody can comment ,
39
- and if no new concerns are raised, the PR/issue gets FCP approval.
37
+ When a pFCP is started, it requires all members of the team to sign off
38
+ the FCP. After they all do so, there's a 10 day long "final comment
39
+ period" where everybody can comment, and if no new concerns are raised ,
40
+ the PR/issue gets FCP approval.
40
41
41
42
## The logistics of writing features
42
43
0 commit comments