RFC Process

[hone]

• rendered

Summary

The "RFC" (request for comments) process provide a consistent and controlled path for new features to enter the spec, libraries, or tools, so that all stakeholders can be confident about the direction Cloud Native Buildpacks is evolving in.

[jkutner]

Can we mark some of the sections or other bits as optional? Maybe Prior Art? I think that will help make the template more approachable.

[hone]

@jkutner yeah, all of it is open change. It's common on other RFC forms which is why I put it there. It seems like a lot of the ones I ran across are derived from the Rust RFC. Ideally we hit a happy balance of people putting enough effort and it not being a burden to make one.

[nebhale]

• Other classes of changes that should be in scope?
• Changes to the target users?
• Is this too much process?

I think the cumulative answers to these three questions are the biggest risk here. I'm slightly worried that we're a bit too broad in what is currently scoped as part of an RFC, but maybe I'm thinking about it in the wrong way (so please tell me if so). As an example of this, I would have expected some change to the flags of pack to not require an RFC. I'd expect robust discussion in a GitHub issue, but having a multi-week period with external documentation in a different repository feels a bit heavy. On the other hand, I could see a different change of flags to pack require an RFC. I don't have a good heuristic today, so maybe being conservative to start and using our future experience to decide is sufficient.

• How long should the Final Comment Period be?

If we're going to funnel a lot of stuff through the RFCs, I think the period should be shorter (3 days). However, if it turns out that RFCs are rarer and only for large changes longer is appropriate (7 days). Especially since there is an assigned team member who is responsible for shepherding each one through it's through final phase, I think that being at the lower end of each range (and expecting nagging) is acceptable.

[nebhale]

I'm not sure if it should be defined here, but I was thinking about voting and the idea of a super-majority. What form should voting take?

• Affirmative Only
• Affirmative and Negative
• Affirmative, Negative, and Abstinence

[nebhale]

Can we mark some of the sections or other bits as optional? Maybe Prior Art? I think that will help make the template more approachable.

@jkutner Is optional required or could a user put in an N/A where appropriate? And if someone put in N/A in a place we didn't feel comfortable with (I'm as lazy as the next person), we'd kick it back as part of discussion?

[hone]

@nebhale as part of the multiweek FPC, I think it definitely is long, but just defaulted to 10 since I didn't know what number to pick. I'm fine with 3-7 days I'd think. The balance is giving everyone time to finalize comments if they haven't done so. Maybe the right answer here is to have it shorter now since we're still moving rapidly and as things stabilize more and the team gets bigger it'll make sense to slow down.

[jkutner]

I would have expected some change to the flags of pack to not require an RFC. I'd expect robust discussion in a GitHub issue... On the other hand, I could see a different change of flags to pack require an RFC. I don't have a good heuristic today...

@nebhale is the heuristic whether or not it's backwards compatible? Maybe not the only criteria, but it seems like something additive would be fine to discuss in GH issues. While something breaking (and its migration strategy) would require an RFC.

[hone]

@jkutner @nebhale I'd argue that it'd be better to hopefully make the RFC light enough. Anything need would benefit as well from understanding context + motivation for adding another flag IMO as we saw today in our WG meeting.

[sclevine]

Thoughts:

• Strongly agree that the template should be a suggested format rather that a strict format.
• Process wise, I think we could start by giving every committer the discretion to use the RFC process or not before making a change. We can tighten this up to require folks who aren't maintainers to submit RFCs in the future. When we get to that point, we can define the criteria that makes an RFC necessary on a subteam-by-subteam (or repo-by-repo) basis.
• I'd suggest that we use affirmative-only voting and only require an FCP when requested by the RFC author, maintainer, or core team member. This will speed up suggestions that everyone agrees on. We can change this process once we move out of beta.
• Who votes on RFCs? If the RFC is only applicable to one subteam, do only maintainers and core team members in the team have binding votes? Or are all RFCs project-wide with core team votes only (i.e., same rules as the spec)?
• I'm not sure if we need to start with a dedicated team member for each RFC. It may be enough to review each RFC at weekly WG meetings for now. Also, I think the RFC opener could be responsible for formatting their RFC appropriately before it is merged.
• Requiring each RFC to start as a PR seems heavy-weight. A PR could be required before it's accepted, but I think starting the RFC as a github issue might be sufficient.

[nebhale]

I concur on the following points:

• suggested format
• committer discretion to start, and see how that works
• affirmative only voting
• No dedicated team member now (maybe add them in the future?)

Points of disagreement or clarification:

• I think FCPs should apply at all times, but if all binding votes are cast (not just the super-majority), can be closed early. I'd like to leave the window open for "official" disagreement.
• RFCs should be Core Team + Project Maintainers (taking into account that some RFCs might not be project-specific). That group has binding votes and needs a super-majority.
• I'm open to non-binding votes but if we want to exclude them I'm OK with that too.
• No dedicated team member now, but maybe add them in the future?
• I'm really attracted to the idea of starting as a GH issue, but concerned that we lose history

[hone]

@nebhale @sclevine I'm curious when you think you/someone would want to deviate from the template? I think Ben's point about putting N/A for any section that doesn't seem necessary is a good one.

Process wise, I think we could start by giving every committer the discretion to use the RFC process or not before making a change.

I like @nebhale's suggestion: Affirmative, Negative, and Abstinence

Process wise, I think we could start by giving every committer the discretion to use the RFC process or not before making a change.

I disagree with this point. I'd much rather figure out a better scope of what should require a RFC where committers can make changes where needed and not open RFCs. Part of the point of the RFC is anything "substantial" should require a RFC from anyone. I also understand that this is going to be an evolving window. Ideally any of the high level features we talked about on Thursday would benefit from having a RFC written for them.

I think FCPs should apply at all times, but if all binding votes are cast (not just the super-majority), can be closed early. I'd like to leave the window open for "official" disagreement.

I think this is a good one until we move into GA to revisit if we want to change. What do we think about 7 days, but a clause to close early?

Who votes on RFCs?
RFCs should be Core Team + Project Maintainers (taking into account that some RFCs might not be project-specific).

I think @nebhale's suggestion is good. I would imagine when we get bigger the Core Team will probably vote a lot less so subteams can have more autonomy?

I'm not sure if we need to start with a dedicated team member for each RFC. It may be enough to review each RFC at weekly WG meetings for now.

I'm also fine with this. The dedicated member is probably premature, but it's mostly to ensure things don't become stale.

Requiring each RFC to start as a PR seems heavy-weight. A PR could be required before it's accepted, but I think starting the RFC as a github issue might be sufficient.

I struggled with this too. I wanted to balance lightweight vs too much process. After seeing #2, I feel like it's probably ok to require it. It's just nice to have all the discussion in one place and inline comments. RFCs are substantial features and therefore should require some more work put behind it.

I'll update this PR with suggestions from this thread.

[ekcasey]

What is our threshold for a "super majority"? Do we just mean "majority"?

[nebhale]

I believe that we'd aimed for super majority to mean 2/3 or greater and no single company can have more than 50% of countable votes. This latter requirement might mean that a voter might be required to recuse themselves when they otherwise have an opinion.