RFC: Sub Team Maintainer (formerly author) Creates Repo Issues

[dfreilich]

Readable

Signed-off-by: David Freilich dfreilich@vmware.com

[hone]

I think this makes a lot of sense if the RFC comes from a contributor/core team member, but I've noticed in the prior art that none of the other RFC processes follow this practice. I wonder if it this instead should fall upon the subteam to manage/create issues when they're finalized maybe in the subteam/maintainers meeting once a week to go over finalized RFCs. This requires a lot more onus on the RFC author especially if they are a non-contributor.

[dfreilich]

@hone I definitely hear that. A suggestion that came up in conversation (I believe from @natalieparellano) was to add a section like

# Suggested Issues

to the RFC template, where the author of the PR would write what repos/issues they would create, which could then get approval from the reviewers, as well as additional suggestions.

To lower the barrier of entry, I would add that while we welcome well-fleshed out issues, even placeholder ones that link to the RFC are a better start than no issues.

[ekcasey]

Given that some sub-teams have multiple maintainers, there may still be some potential for ambiguity around who will handle a particular RFC. I propose that when we move RFCs into FCP we should assign a sub-team maintainer to the PR and they will be responsible for creating the issues.

[hone]

@ekcasey my thought is that this would happen during the weekly subteam meetings, but I don't feel strongly about it.

[dfreilich]

@ekcasey I don't know whether we need that level of process at this point. I agree with @hone that I had felt it could be done during the subteam meetings, as one of the repeating action items. Should I clarify that?

[jromero]

There are some RFCs that require multiple sub-teams to create issues from a single RFC. For the sake of minimizing coordination could we maybe change this to be a label per subteam.

For example:

• issues-created/platform
• issues-created/implementation

If no issues need to be created for a given subteam they can add that label for brevity sake. We can further automate this process by checking that these labels are present.

[dfreilich]

I incorporated @jromero's feedback. LMK what you think.

[dfreilich]

@nebhale and @jkutner I made some changes since you last checked it over. Just want to make sure you're still ok with the contents.

[hone]

Once this RFC is merged in that means someone from the core team will need to create the issue on this repo. :)

[ekcasey]

Final Comment Period with merge disposition, closing on 30 September, 2020.