RFC 0001: Modernize the RFC process

[Akarys42]

• Make the lifecycle a lead responsibility
• Shorten the FCP length to 3 to 7 days
• Allow FCPs to be used to force the discussion to end
• Allow minor FCPs to skip the process
• Clarify the Administrative Board as responsible for the RFCs without any team
• Remove dispositions
• Remove the need for universal approval

[Akarys42]

Team leads are already properly defined as part of RFC 6. Not giving RFC power to individual developers make sense here.

[Akarys42]

There can absolutely be more than one team lead

[Akarys42]

FCP starting today, ending on June 5th

[lukebemish]

Hmm, perhaps I'm missing it, but with the removal of the disposition thing how is it determined whether or not ab RFC is accepted? I'm a bit confused on some of the details of that process. Is it just a vote by the relevant team?

[ghost]

Hmm, perhaps I'm missing it, but with the removal of the disposition thing how is it determined whether or not ab RFC is accepted? I'm a bit confused on some of the details of that process. Is it just a vote by the relevant team?

I believe the removal of disposition means that the team leader will not need to tell you what action they intend on taking when the FCP starts, e.g. if they want to reject it, defer, or want to accept it, however when the period end they will give you their verdict then.

[Oliver-makes-code]

Allow FCPs to be used to force the discussion to end

Wouldn't that defeat the purpose of a final comment period?

[lukebemish]

I believe the removal of disposition means that the team leader will not need to tell you what action they intend on taking when the FCP starts, e.g. if they want to reject it, defer, or want to accept it, however when the period end they will give you their verdict then.

Hmm. I'm a bit confused about some of the changes here then, I think - knowing whether or not your comments are relevant during an FCP would seem to require knowing what the likely result of that FCP is, right? And sometimes that's very hard to tell if there's not much discussion yet. Though I may have missed the point here. I'm also a bit confused about the whole "using FCP to force discussions to end" thing. I think I get what it's trying to do, but some more clarification should probably be added, especially with the whole bit about FCPs no longer having a disposition attached - is the discussion being forced to end because a likely decision won't be changed by further discussion, or because there's enough discussion that it won't be accepted at present? Maybe this isn't necessary, but I've seen a few RFCs lately with comments just saying basically "This RFC is now in FCP" which I'm never quite sure how to read.

[Akarys42]

Basically, this aims at changing the way FCP works to better match what we're already doing right now.

Instead of saying "this is what we'll do" and having a 10 days buffer for anyone to disagree, we can instead say "this PR will be merged in 5 days or more, so get your feedback in right now". This reduces a lot of the burden of FCP processes, and allow PRs without any feedback to continue moving forward.

[lukebemish]

Hmm. Okay, so, if I understand this right: when an FCP period is declared the intent is that the PR will be merged after it, assuming nothing comes up? That makes a lot of sense and does match what's going on now so I think I understand it better now. My one question is: how are PRs rejected under this system?

[Akarys42]

Nah, after the FCP the PR is either merged, closed, or delayed. It is up to the team lead to do any of those three based on the discussions in the PR before and during the FCP.

[lukebemish]

Ah, okay. I think I understand that change now

[Akarys42]

Also i believe that RFC amendments, such as this one, should be their own RFCs, not unlike IETF RFCs for example RFC7405 amending RFC5234 by including "Obsoletes: 5234" in RFC7405 and "Updated by: 7405" in RFC5234

We use the Git history for that, in order to keep RFCs somewhat readable