Inactive users to be deleted

[github-actions]

According to the rules for inactivity defined in RFC-0025 following users will be deleted:
@xtreme-nitin-ravindran
@joefitzgerald
@staylor14
@PureMunky
According to the revocation policy in the RFC, users have two weeks to refute this revocation, if they wish.

[joefitzgerald]

I want to refute my revocation. I contributed the go-uaa library (https://github.com/cloudfoundry/go-uaa/graphs/contributors) and still act as a maintainer when product team(s) fail to merge PRs in a timely way. The last time this occurred was: cloudfoundry/go-uaa#66.

cc @beyhan

[xtreme-nitin-ravindran]

Hi, I would like to refute my revocation. I work on compliance aspect of bosh-linux-stemcell-builder <https://github.com/cloudfoundry/bosh-linux-stemcell-builder/tree/be6d676e3ab9b2105bb6bf2539d49d92c126210e> Thanks, Nitin

…

On Sun, Mar 31, 2024 at 8:19 PM github-actions[bot] < ***@***.***> wrote: According to the rules for inactivity defined in RFC-0025 <https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0025-define-criteria-and-removal-process-for-inactive-members.md> following users will be deleted: @xtreme-nitin-ravindran <https://github.com/xtreme-nitin-ravindran> @joefitzgerald <https://github.com/joefitzgerald> @staylor14 <https://github.com/staylor14> @PureMunky <https://github.com/PureMunky> According to the revocation policy in the RFC <https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0025-define-criteria-and-removal-process-for-inactive-members.md#remove-the-membership-to-the-cloud-foundry-github-organization>, users have two weeks to refute this revocation, if they wish. ------------------------------ You can view, comment on, or merge this pull request online at: #801 Commit Summary - bf3140a <bf3140a> Delete inactive users File Changes (1 file <https://github.com/cloudfoundry/community/pull/801/files>) - *M* org/contributors.yml <https://github.com/cloudfoundry/community/pull/801/files#diff-848893d2d3da8db8604783c9b8e8bdbcf4967fda3b970f116265994f66e3aff6> (4) Patch Links: - https://github.com/cloudfoundry/community/pull/801.patch - https://github.com/cloudfoundry/community/pull/801.diff — Reply to this email directly, view it on GitHub <#801>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIT6LIT7AR5BVW3DLHMCPTY3CRXZAVCNFSM6AAAAABFQ2F3W6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYTOMRWGY3DAOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

[beyhan]

Hi @joefitzgerald, hi @xtreme-nitin-ravindran,

at the moment you both have the contributor role which makes you just a member of the cloudfoundry org and gives you read access to all repositories. That means you can't merge any PRs. If you would like to keep this role please make a pr like this when this one is merged and the TOC will make sure to merge it and also the inactive user automation won't suggest your user for removal for the next one year. The other alternative is to apply for a role in the working groups you are active by making a pr like this but this depends to the working group.

[joefitzgerald]

This is a confusing response. I am a contributor, I have contributed a library that is used by many cloud foundry related tools, but I am being removed as a contributor and must make a PR to add myself back as a contributor, and must do this every year.

What is the utility of this policy? The likely result is you will drive the few remaining community contributors out of the project; it's certainly off putting to me and makes me regret moving my library from the cloudfoundry-community org to the cloudfoundry org.

[beyhan]

Hi @joefitzgerald,

Thank you for your honest feedback. I think in your case it makes more sense to become an approver for the go-uaa repository because in the current situation you don't have rights to merge prs as you would wish. Most probably an area split will be required if you are not active in the other repositories where go-uaa belongs at the moment. A similar thing was done in #798 and #784. The automation doesn't touch users with a role because this is a working group responsibility and you don't need to create prs every year. Let me know if you need any help.

What is the utility of this policy? The likely result is you will drive the few remaining community contributors out of the project; it's certainly off putting to me and makes me regret moving my library from the cloudfoundry-community org to the cloudfoundry org.

We don't want to make things more complicated as they should be. We want to keep the contributors list up to date and introduced the inactive user automation because of this issue where we evaluated to use github enterprise. The github enterprise licence type costs are based on github org members count.

[joefitzgerald]

I was not even aware I had lost access to merge PRs in go-uaa or maintain the repo via my admin role on the repo.

I think the most appropriate course of action is transferring the repo back to the cloudfoundry-community org where I am able to retain the permissions necessary to maintain the library, independent of the licensing restrictions you are trying to contend with.

I regret agreeing to transfer it to the cloudfoundry org given the current state of policy regarding permissions.

[beyhan]

Hi @joefitzgerald,

It is unfortunate that you want to go this way but in this situation it is helpful to know that there was an incident with the cloudfoundry-community org. More details are available in this incident document and following discussions #776, #778. That is why some repository owners (#784, #784) decided to move their repositories to the cloudfoundry org recently.

The TOC invested a lot to implement a transparent and fully automated user and repository management for the cloudfoundry org. This is seen as benefit most of the time (at least my impression is such). If you have any concrete feedback about what should improved it is more then welcome. In case you decide otherwise I prepared a draft commit, which implements my suggestion.

[joefitzgerald]

Thanks for that additional context. I see that there is good intention behind the actions thus far. However, if library owners who contribute their library to the cloudfoundry org:

• lose admin access without realizing it
• lose maintainer rights without realizing it
• have to justify their contributions annually or apply to a working group to retain their prior level of access to the repo

... then the process is broken. My expectations are really simple: please restore my admin access to the library so that I can effectively maintain it, or let me move it elsewhere (perhaps I need a new org) where I can restore my admin access.

I also contributed significantly to the go-cfclient library, and at this point I would advise @sneal to exercise extreme caution in moving that library into the cloudfoundry org. Unless a policy change is made, @sneal you will likely lose the ability to administer the repo, particularly if you leave your current employer.

[beyhan]

I can't agree with any of the statements above:

• Approvers get write access to the repositories the area has
• There is an easy process in place to provide admin access like this if required
• Only inactive contributors with no approver or reviewer role has to justify their contributions
• Those roles aren't connected to employing company and if the wish is there to stay an active contributor with the new employer everyone is more then welcome

Were you involved in the discussion to move the go-uaa repo to the cloudfoundry org? It was done with this pr.

[rkoster]

I second @beyhan statement. I believe the only oversight I can see is that as part of #706 some more due diligence could have been performed to figure out if other recent contributors to the go-uaa repo would want to retain their approver roles as part of the move.

This could be a good amendment to our process for moving over repo's (for example get approval from all authors who made a commit to the repo in the prior year before moving a repo over).

[joefitzgerald]

Were you involved in the discussion to move the go-uaa repo to the cloudfoundry org? It was done with #706 pr.

I don't recall this move being discussed with me, and I certainly don't recall being notified that I would lose access (either admin or maintainer access) to the repo I maintain.

I worked over the years to get the UAA team to step up and maintain the repo more. With the organizational changes over the years, there was a lot of transition, so I remained the backstop.

I believe the only oversight I can see is that as part of #706 some more due diligence could have been performed to figure out if other recent contributors to the go-uaa repo would want to retain their approver roles as part of the move.

@rkoster Imagine you had spent lots of time creating and maintaining a repo over the years. Then, someone else moved the repo to another org, didn't discuss it with you, and asked you to justify your maintainer role. I imagine it is easy to empathize with someone upset by this.

This whole conversation almost feels like gaslighting because here I am justifying my rights to the repo that I thought I had rights to in the first place because it was me who created it, as an organization owner! I now realize that the repo transfer to this org caused me to lose my ability to merge PRs, which is why I stopped being able to "contribute," which led to me being included in this PR to remove me as a contributor. This is quite frustrating.

The unwritten contract (other issues notwithstanding) in the cloudfoundry-community org was that people let maintainers maintain their repos. I would have expected a conversation like this:

"Hey <primary contributor of this library>, we would like to move this to another org because we are worried about the permissions on the cloudfoundry-community org. Can we do this for your repo? What level of access will you require to be OK with this?".

Which I think is the intent of your "[...] the only oversight [...]" comment. But it didn't happen. So how are we going to make it right?

• I've asked for my admin rights to the repo, or for it to be transferred back to an org where I have the original permission level.
• @beyhan has said I cannot have permanent admin rights to the repo that I created and did not consent to transfer (breaking the implicit social contract that was in place).
• @beyhan has indicated that if I am made an approver on the repo, I will be exempted from this annual justification process, suggesting that, minimally, this is what needs to happen.
• @beyhan I am fine with having reduced (i.e. maintainer, not admin) access to the repo, provided there is no significant bureaucracy to restore admin access to perform maintenance activities. If I open a PR saying, "I need to maintain the go-uaa repo for for ," is that sufficient to gain approval for the elevated permissions? I consent to not attempting to transfer the repo from this org in such an arrangement.

I am not against the repo being in the cloudfoundry org; I think it's a good place for the library as it is a key dependency of the UAA CLI.

[rkoster]

@joefitzgerald could you create a PR to move the go-uaa library into its own area within the Foundational Infrastructure working group drawing inspiration from this example. I would suggest to at least also include @strehle (UAA maintainer from SAP) as an approver in this working group area.

With regards to Admin permissions there have been cases in the past where people needed admin rights to manage github action secrets, this is actually one of the main drivers behind this whole org clean-up, because we want to reduce only have active contributors in the Cloud Foundry org so that we can switch to an enterprise plan so that we can use custom roles. This would eliminate the need for admin rights on repo's.

[beyhan]

With 2d6b465 I re-added @joefitzgerald because he is active in the go-uaa repository and applied for
an approver status with #810