TOC: Candidate Eligibility: Non-code contributions

[bkrannich]

https://github.com/cloudfoundry/community/blob/main/TOC.md#candidate-eligibility
Similar to #58, TOC members, WG Leads, and Approvers seems to favour code contributions over non-code contributions. I'd like to ask the question if this is the intention when it comes to TOC candidates?

[loewenstein]

This came up already when we were talking about the bootstrapping of the TOC, as there are currently no eligible candidates at all.

[chipchilders]

Ability to ask for an exception for TOC eligibility criteria should be added to both TOC and MIGRATION

[bkrannich]

@chipchilders: When you write "ask for an exception" it sound like "usually" we do favour code contributions over other contributions for TOC candidates. Not sure if this is the intent, thus I opened this Github issue.

[chipchilders]

@loewenstein says that @bkrannich is happy now and that we can close it

[bkrannich]

@chipchilders, @loewenstein: Confirming my happiness 😄 - thanks!

[bkrannich]

Hi @chipchilders,

Looking at the latest version in the repo together with @loewenstein, I am not sure my initial intent for opening this issue is still represented in the current wording when it comes to non-code contributions.

I understood from @loewenstein that https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md#scope-of-technical-contributions is a disclaimer that is trying to include non-contributions for the remainder of the document but I am not sure people reading the document would intuitively understand this intent.

Let's make a couple of examples:

• Would the authors of a document like https://docs.google.com/document/d/1rG814raI5UfGUsF_Ycrr8hKQMo1RH9TRMxuvkgHSdLg/edit?usp=sharing be Approvers according to https://github.com/cloudfoundry/community/blob/main/toc/ROLES.md#role-summary ? Would we want them to be Approvers so that they are eligible for the TOC?
• See New CF RBAC space-scoped granular roles cfar-proposals#22 - it links https://docs.google.com/document/d/1isfsSWvF8xDU0G69k4MqB3o5c2vB0P3Vbi79W0yvqFQ/edit ; would we want the authors of that document to be eligible? The document doesn't mention it's authors, would it be sufficient to list them inside the document and would that be a suggestion for similar documents moving forward?
• Another one is https://docs.google.com/document/d/17zIHB-L6tLEJPdbB4JYUEb4ii8w2YIUL5TQU7fV9jlM/edit - same questions as with the previous bullet.
• Would the person organizing the CAB call be viewed as an Approver even though they don't need to be officially part of a working group? Or would CAB need to turn into an official working group to allow for an Approver role?
• I frequently refer back to @emalm 's https://docs.google.com/document/d/1uPLab3F0LwbpV4ryGtaERfxdOx0Q4BCvbS8J-dVG29g/edit document - would we want the creator of such a document to be an Approver according to the definition?

I think the above examples are less clear than the ability to merge code into an official repo. However, I believe the intention is for the above examples to allow these types of contributions to fall under the Approver role. This is why I liked your suggestion in #59 (comment) to define an exception process but I learned from @loewenstein that the exception process has been removed meanwhile.

I guess my ask would either be to make it more clear in the wording of the documents how the above examples would be viewed or to reconsider an exception process for them.

Thanks in advance.

[chipchilders]

The community should discuss during the Friday meeting. If you can make it, that would be helpful!

[chipchilders]

@bkrannich hopefully the discussion last week helped clarify the working group's prior deliberations that led to the current approach. I believe, based on that conversation, that you were OK with (1) that voter eligibility was clear enough and (2) that TOC eligibility should absolutely require demonstrated support for the project in an official technical community leadership role. The only question was about the role definitions, to be sure that they clearly indicated the types of technical community work that qualified "non-code" contributors for leadership roles. You took the action to review with that context in mind. Can you let the governance working group know if you are OK, or if you have any suggested changes, via either this issue or a PR into the appropriate files?

[bkrannich]

@chipchilders Yes, I am fine with your summary. In terms of the actual text, Valentina is about to prepare some suggestions to make the wording more clear (without changing what you wrote in your previous comment, I'd say) and will send that to you as input by EOB today.

[chipchilders]

Reviewed and approved by GB. We can continue to iterate on the ROLES.md as the new TOC leads the community through the necessary changes.