Closed Akarys42 closed 1 year ago
Team leads are already properly defined as part of RFC 6. Not giving RFC power to individual developers make sense here.
There can absolutely be more than one team lead
FCP starting today, ending on June 5th
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?
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.
Allow FCPs to be used to force the discussion to end
Wouldn't that defeat the purpose of a final comment period?
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.
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.
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?
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.
Ah, okay. I think I understand that change now