RFC: add status field #177

aemengo · 2021-07-14T17:17:34Z

natalieparellano · 2021-07-14T18:39:48Z

text/0000-add-state-field.md

+# Unresolved Questions
+[unresolved-questions]: #unresolved-questions
+
+- Should **"Implemented"** be one of the accepted values?


Also (perhaps) "Superseded" "Retracted"

Are there currently RFCs that we'd like to apply "Superseded" or "Retracted" to? I'd like to defer adding new values till when the need arises.

I think there are a handful of superseded RFCs. For example the Supersedes section of RFC 0044 implies that some part of RFC 0022 is superseded. Although, tbh it's not clear at a glance which parts (I suspect the entire RFC is not superseded). This might be another case where notes would help!

Make sense to me!

text/0000-add-state-field.md

yaelharel · 2021-07-21T19:25:40Z

text/0000-add-state-field.md

+# Motivation
+[motivation]: #motivation
+
+This RFC formally introduces the **"On Hold"** state for an RFC, in a way that's clear to the community.


I think it's worth adding an explanation of why this field is needed.

I'm partial to Stephen's thoughts here, saying:

I suggest we require individual RFCs to specify why they might be in the On Hold state, and not define a reason for On Hold in this RFC.

#177 (comment)

When deemed "ready", a team member will propose a "motion for final comment period (FCP)" along with a disposition of the outcome (merge, close, or postpone).

Also, there's a postpone disposition today that we don't take advantage of. I wonder if that's something we can use here?

@aemengo, my comment is on the motivation section:
This RFC formally introduces the **"On Hold"** status for an RFC, in a way that's clear to the community.
What do you mean by "in a way that's clear to the community"?
I think it's worth adding an explanation on why do we want this RFC.
Maybe giving an example or two may help?

@yaelharel

What do you mean by "in a way that's clear to the community"?

I suppose I meant, in a way that is clear to anyone reading the RFC. As opposed to, through word-of-mouth.

Maybe giving an example or two may help?

I don't think adding a Status: to RFCs is a novel idea. We can see them as part of other RFC templates, for instance Tekton.

aemengo · 2021-07-22T16:04:48Z

Addressing comments from Working Group (07/22/2021):

I have a slight preference for Status: over State:

Fixed in latest commit.

Having the full list of acceptable values, demarcated by a |, could get a bit long.

~~I'd prefer not to pre-optimize here. So far, we've only expressed need for the "On Hold" status. When we start adding more, we can reconsider the format.~~

edit: Fixed in latest commit.

Perhaps we can have the template say Status: Draft and then replace it when "Approved".

~~Similar to above, I prefer seeing the list of acceptable values. Just so things can't get out sync. Thus we can remove the values that are implied.~~

~~Since this appears to be a not-strong, weakly-held opinion, we can defer to the OP's preference here. Moreover, this isn't hard to change if it doesn't work out.~~

edit: Fixed in latest commit.

0000-template.md

ekcasey · 2021-07-28T16:25:22Z

text/0000-add-status-field.md

+```
+- Status: On Hold
+```
+


Suggested change

Pull requests that change the status of a previously accepted RFC to "On Hold", should add a Section titled `Notes` to the top of the RFC containing an explanation for the change of status.

Example:

\```

# Notes

## On Hold

Since the approval of this RFC additional concerns X, Y, and Z have been raised. Solving problem Foo is still a priority for the project but the core team has decided to place this RFC on hold pending further discussion of alternative solutions. If you are interested in problem Foo place participate in the discussion on RFC #XXXX.

\```

If at a later date the core team or responsible sub team wishes to move the RFC from "On Hold" back to "Approved", this should be done via PR and another note should be added, describing the resolution of the discussion and the rationale for proceeding with the original RFC.

I feel if we want to move a RFC back off of hold there should have a superseding RFC (in most cases).

ekcasey · 2021-07-28T16:27:34Z

text/0000-add-status-field.md

+    - Perhaps, but then what's the process of keeping the _Implemented_ status in sync?
+
+- How do we retroactively add a **Status:** field to prior RFCs?
+    - Manually?


Yeah, I think manually is fine.

ekcasey · 2021-07-28T16:32:48Z

text/0000-add-status-field.md

+- Name: Add Status to RFC Metadata
+- Start Date: 2021-07-14
+- Author(s): @aemengo, @ekcasey
+- Status: Draft <!-- Acceptable values: Approved, On Hold, Draft -->


Should we add "Superseded" to the list of statuses? An RFC PR that includes RFCs in the "Supersedes" section should also changed the status of all referenced RFCs to "Superseded".

Suggested change

- Status: Draft 

- Status: Draft 

(I also alphabetized the statuses in this suggestion b/c I couldn't see the logic in the original ordering)

Is there value of having a "Draft" status? We don't have reject here.

Is there value of having a "Draft" status?

If someone links you to a readable version of a not-yet-merged RFC, you can see that it is still a draft.

Should we include closed/postponed as well then? Is there a distinction between "status" and "disposition"?

I originally called this out as an anti-goal; trying to show all the status that could be inferred by the PR process. Don't know how you still feel about closed/postponed

Should we include closed/postponed as well then?

Practically speaking, I don't think this would be actionable. We don't have the power to update the status field in someone's fork when an RFC is closed or postponed, and nagging people to update it doesn't feel worth it from a cost/benefit perspective.

@hone I wanted Draft because it seemed like an informative default for in progress RFCs. But I assumed it would be uncontroversial. I am happy to leave status blank until we merge an RFC if you feel strongly about it.

hone · 2021-07-28T17:22:20Z

text/0000-add-status-field.md

+[unresolved-questions]: #unresolved-questions
+
+- Should **"Implemented"** be one of the accepted values?
+    - Perhaps, but then what's the process of keeping the _Implemented_ status in sync?


What's the goal we're trying to solve with the "Status" field? I think answering this would help answer this question.

Based on the motivation of this RFC, it seems as though it's to clearly portray the status of any given RFC. If that's the case I would argue that knowing whether something is "Implemented" or "Implementable" is a helpful distinction.

As a prior art: Tekton TEPs use these statuses: https://github.com/tektoncd/community/tree/main/teps#teps

hone · 2021-07-28T17:22:54Z

text/0000-add-status-field.md

+    - Manually?
+
+- How do we validate the [#meta](#meta) section of prior RFCs?
+    - Perhaps we make a [../validate-rfcs.sh](../validate-rfcs.sh) script that lints the **#meta** section of all rfcs?


maybe we can leverage Javier's automation.

jromero · 2021-07-28T18:39:37Z

text/0000-add-status-field.md

+- Name: Add Status to RFC Metadata
+- Start Date: 2021-07-14
+- Author(s): @aemengo, @ekcasey
+- Status: Draft <!-- Acceptable values: Approved, On Hold, Draft -->


Suggested change

- Status: Draft 

- Status: Draft 

We've discussed using Implementable and Implemented in other conversations.

@ekcasey @natalieparellano @hone

I'm sorry for not being present when these values were posited. Can I please just confirm that the following acceptable values are what's preferred?

Draft, Implementable, Implemented, On Hold, Superseded

I like the idea in general of indicating to users whether an RFC has been implemented, but I anticipate amibiguity regarding the definition of "implemented" as a status field. For example, image a change that adds a feature to the platform API is it implemented when the spec is released? when the lifecycle is released? when pack exposes it to users?

Given the ambiguity I suspect we would want something more detailed than a binary implementable/implemented distinction, like an implementation history section (example https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/970-kubeadm-config#implementation-history)?

If this is contentious or complicated though I think we could break this out into a different RFC and go ahead with a simple Approved status for now.

@ekcasey, I agree. I can see that we'd want to define Implemented. For the sake of not ballooning this RFC, I'm more that okay with only moving forward with Approved.

Does that mean that we agree on a total of:

Draft, Approved, On Hold, Superseded

Well, I agree.

0000-template.md

merge-rfc.sh

hone · 2021-09-08T18:41:02Z

Moving to FCP to close on Sep 15.

buildpack-bot · 2021-09-08T18:41:17Z

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

⬜️ e91988 - buildpacks/rfcs "Back fill status fields"

Signed-off-by: Anthony Emengo <aemengo@vmware.com>

Co-authored-by: Stephen Levine <stephen.levine@gmail.com> Signed-off-by: Anthony Emengo <aemengo@vmware.com>

Signed-off-by: Anthony Emengo <aemengo@vmware.com>

Co-authored-by: Sambhav Kothari <sambhavs.email@gmail.com> Signed-off-by: Anthony Emengo <aemengo@vmware.com>

Signed-off-by: Anthony Emengo <aemengo@vmware.com>

hone · 2021-09-22T14:40:24Z

/queue-issue buildpacks/rfcs "Back fill status fields"

hone · 2021-09-22T16:31:29Z

Not sure why this didn't autoclose, but was merged as RFC 0094!

natalieparellano reviewed Jul 14, 2021

View reviewed changes

aemengo force-pushed the add-state-field branch from 767bbfd to e59fd3b Compare July 20, 2021 11:48

aemengo marked this pull request as ready for review July 20, 2021 11:50

aemengo requested a review from a team as a code owner July 20, 2021 11:50

sclevine requested changes Jul 20, 2021

View reviewed changes

text/0000-add-state-field.md Outdated Show resolved Hide resolved

aemengo force-pushed the add-state-field branch from 7f43cc2 to 8a50caa Compare July 21, 2021 14:47

nebhale requested review from nebhale, jkutner, hone and sclevine July 21, 2021 18:32

nebhale approved these changes Jul 21, 2021

View reviewed changes

yaelharel reviewed Jul 21, 2021

View reviewed changes

sclevine approved these changes Jul 22, 2021

View reviewed changes

samj1912 reviewed Jul 22, 2021

View reviewed changes

0000-template.md Outdated Show resolved Hide resolved

samj1912 reviewed Jul 22, 2021

View reviewed changes

0000-template.md Outdated Show resolved Hide resolved

aemengo force-pushed the add-state-field branch 2 times, most recently from 8d09f74 to 0f50d69 Compare July 22, 2021 21:15

aemengo changed the title ~~RFC: add state field~~ RFC: add status field Jul 22, 2021

aemengo force-pushed the add-state-field branch 2 times, most recently from 6cdda67 to e4e9633 Compare July 22, 2021 21:23

ekcasey reviewed Jul 28, 2021

View reviewed changes

hone reviewed Jul 28, 2021

View reviewed changes

ekcasey added audience/cnb-contributors scope/project labels Jul 28, 2021

jromero requested changes Jul 28, 2021

View reviewed changes

github-actions bot assigned hone Jul 28, 2021

jromero reviewed Jul 28, 2021

View reviewed changes

0000-template.md Outdated Show resolved Hide resolved

jromero reviewed Jul 28, 2021

View reviewed changes

merge-rfc.sh Outdated Show resolved Hide resolved

aemengo force-pushed the add-state-field branch 2 times, most recently from 2bd662b to 688c2ed Compare August 20, 2021 15:48

ekcasey approved these changes Aug 25, 2021

View reviewed changes

jromero approved these changes Aug 25, 2021

View reviewed changes

jkutner approved these changes Sep 2, 2021

View reviewed changes

hone approved these changes Sep 8, 2021

View reviewed changes

hone added the Final Comment Period label Sep 8, 2021

natalieparellano approved these changes Sep 13, 2021

View reviewed changes

Anthony Emengo and others added 5 commits September 13, 2021 22:47

Add RFC for adding state field

b226548

Signed-off-by: Anthony Emengo <aemengo@vmware.com>

Update text/0000-add-state-field.md

56c2fb8

Co-authored-by: Stephen Levine <stephen.levine@gmail.com> Signed-off-by: Anthony Emengo <aemengo@vmware.com>

State: -> Status:

3b327da

Signed-off-by: Anthony Emengo <aemengo@vmware.com>

Update 0000-template.md

3fadd73

Co-authored-by: Sambhav Kothari <sambhavs.email@gmail.com> Signed-off-by: Anthony Emengo <aemengo@vmware.com>

Fixes based on addition of acceptable-values

06c1c46

Signed-off-by: Anthony Emengo <aemengo@vmware.com>

aemengo force-pushed the add-state-field branch from 688c2ed to 06c1c46 Compare September 14, 2021 02:49

hone closed this Sep 22, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: add status field #177

RFC: add status field #177

aemengo commented Jul 14, 2021 •

edited

natalieparellano Jul 14, 2021

aemengo Jul 20, 2021

ekcasey Jul 28, 2021 •

edited

aemengo Aug 20, 2021

yaelharel Jul 21, 2021

aemengo Jul 21, 2021

hone Jul 28, 2021

yaelharel Aug 20, 2021

aemengo Aug 20, 2021

aemengo commented Jul 22, 2021 •

edited

ekcasey Jul 28, 2021

hone Jul 28, 2021

ekcasey Jul 28, 2021

ekcasey Jul 28, 2021

hone Jul 28, 2021

ekcasey Jul 28, 2021

hone Jul 28, 2021

aemengo Aug 20, 2021

ekcasey Aug 25, 2021

hone Jul 28, 2021

jromero Jul 28, 2021

hone Jul 28, 2021

jromero Jul 28, 2021 •

edited

aemengo Aug 16, 2021

ekcasey Aug 20, 2021

jromero Aug 20, 2021

jromero Aug 20, 2021

aemengo Aug 20, 2021

hone commented Sep 8, 2021

buildpack-bot commented Sep 8, 2021 •

edited

hone commented Sep 22, 2021

hone commented Sep 22, 2021

+Pull requests that change the status of a previously accepted RFC to "On Hold", should add a Section titled `Notes` to the top of the RFC containing an explanation for the change of status.
+Example:
+\```
+# Notes
+## On Hold
+Since the approval of this RFC additional concerns X, Y, and Z have been raised. Solving problem Foo is still a priority for the project but the core team has decided to place this RFC on hold pending further discussion of alternative solutions. If you are interested in problem Foo place participate in the discussion on RFC #XXXX.
+\```
+If at a later date the core team or responsible sub team wishes to move the RFC from "On Hold" back to "Approved", this should be done via PR and another note should be added, describing the resolution of the discussion and the rationale for proceeding with the original RFC.

	- Status: Draft <!-- Acceptable values: Approved, On Hold, Draft -->
	- Status: Draft <!-- Acceptable values: Approved, Draft, On Hold, Superseded -->

RFC: add status field #177

RFC: add status field #177

Conversation

aemengo commented Jul 14, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ekcasey Jul 28, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aemengo commented Jul 22, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jromero Jul 28, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hone commented Sep 8, 2021

buildpack-bot commented Sep 8, 2021 • edited

Issues

hone commented Sep 22, 2021

hone commented Sep 22, 2021

aemengo commented Jul 14, 2021 •

edited

ekcasey Jul 28, 2021 •

edited

aemengo commented Jul 22, 2021 •

edited

jromero Jul 28, 2021 •

edited

buildpack-bot commented Sep 8, 2021 •

edited