Add RFC for role change process

[Gerg]

I'm not particularly attached to the criteria I specified. Feel free to suggest major modifications. I'm just trying to spark conversation around this process.

[stephanme]

Overlaps to a good extend https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0002-github-members.md

[Gerg]

I view this as an extension of that RFC. I'm primarily interested in the process through which the promotion is reviewed and accepted.

That said, maybe there is more I can do to integrate the two RFCs.

[Gerg]

For instance, I think this RFC currently conflicts with this paragraph:

As removing a member from the cloudfoundry GitHub org may have unintended consequences across the organization, the TOC is the body required to approve those removals.
Proposals to remove a member should also be submitted via PR, and the submitter should tag the PR with toc and should mention @cloudfoundry/toc to make the TOC aware of the request.
The TOC will then consult any working groups that may be affected by the removal of this member and use its usual decision process to approve or reject the removal.

[stephanme]

I don't remember the exact reason why removing a member from the cloudfoundry org might have unintended consequences. Can't really imaging for a contributor and I agree that TOC should not be required here.

Maybe this discussion is caused by using a low level technical document (cloudfoundry.yml) for maintaining a higher level concept (contributor role). Could be solved by having a separate contributor document that gets (eventually automated) translated into cloudfoundry.yml similar to the WG charters. Allows e.g. to ensure that all approvers are members of the cloudfoundry org and makes it easier for new contributors to file a PR: cloudfoundry.yml has currently 7k lines and ~650 org members.

[dsboulder]

Is this ready for the approval period at this point?

[Gerg]

@dsboulder I've made all the changes I intend to make, so should be ready to go.

[emalm]

Sounds like @Gerg is moving to start the Final Comment Period on this proposed RFC. @cloudfoundry/toc, please vote (👍 / 👎 ) on this comment, or otherwise comment on this conversation!

[stephanme]

I'm fine with the basic workflow and the rules.

What I still don't like is manual editing of cloudfoundry.yml. This huge file contains manually maintained data (contributors = cloudfoundry org members) and generated content (projects, teams = approvers, wg leads = content from the WG charters).
In my opinion, a separate contributor.yml file would make the automation easier (less conflicts, less errors, eventually a fully automated generation of cloudfoundry.yml).

@rkoster : What is your opinion? If you say "no problem" I give up my concerns.

[rkoster]

org/cloudfoundry.yml should be an implementation detail. I would also vote for a separate contributor.yml file.

[stephanme]

As discussed in the last TOC meeting: I amended the PR and introduce a dedicated contributors.yml (initialized with the org members copied from cloudfoundry.yml).

An automation could look like this:

• cloudfoundry.yml keeps the static content that is not generated (org config, projects but not anymore org members and eventually no teams)
• org members are generated from contributors.yml + all users mentioned in the WG charters and TOC.md
• teams can be generated from WG charters and TOC.md
• cloudfoundry.yml, org members and teams are merged into one file that is the input for Peribolos

[stephanme]

After the changes I guess we should start a new Final Comment Period on this proposed RFC. https://github.com/orgs/cloudfoundry/teams/toc, please vote (👍 / 👎 ) on this comment, or otherwise comment on this conversation!