Admin access

[glennawatson]

The DNF has been insisting on having admin access to repositories and nuget ownership for the purposes of project continuity

For projects like ReactiveUI we have multiple sub-owners who can take over in the case of emergency so wouldn't be needed but a lot of smaller projects might like to take advantage. Can it be opt in or opt out?

Also from a practicality point of view there are security implications of having an additional admin on your account.

[dansiegel]

Personally I do not see a reason why it's ultimately needed. I think one of the first things that we need to do is collectively ask, "What reason(s) does the .NET Foundation for having such access?" My understanding is there are at least 2 concerns from the Foundation perspective (perhaps there are more & I'd love to hear them)

• the dnfadmin user provides a service account to allow the Foundation to help with tasks that a maintainer may need help with
• the dnfadmin user provides security if the maintainers walked away or were otherwise incapable of continuing to maintain the project

As I see these 2 issues...

• First rather than keeping an admin user on the org it makes more sense to look @robmen's suggestion of a Buddy System where if needed the individual who needs access to help can get temporary access. This also helps with accountability as it's not just some service account where really anyone could have logged in.
• The second issue I would say conceptually we should be able to accomplish the same goal by having a legal addendum that treats it similar to a Trust so that if the maintainers all disappeared the Foundation would have the legal backing to work with the GitHub team to be able to assign new maintainers.

Edit: As it has been pointed out that GitHub has an existing system for dealing with Successors I would say that should be the primary preference for dealing with that issue. Any issues not listed here should continue to be discussed to determine if it is something that has no better work around.

[JimBobSquarePants]

It simply should not be a requirement. There’s existing tooling in place for appointing successors.

[CumpsD]

Successors only deals with death, no? Not abandonment or abuse

[Pilchard123]

It occurs to me that one of the membership eligibility criteria is "The project's code is easily discoverable and publicly accessible (preferably on GitHub)" (emphasis mine).

How does requiring admin access work for projects that are not on GitHub? Similar questions can be asked about being moved into GitHub Enterprise, though there seems to be a plan in the works to move away from requiring that, and for projects that do not produce NuGet packages.

[Perksey]

For the record, I do support the .NET Foundation [optionally] having admin access over project resources.

Having been on a previous project where the primary maintainer went radio silent (without telling anyone, still very much alive & active in the tech industry to this day) we really struggled to get access to the project resources after additional maintainers kept leaving. The .NET Foundation is supposed to be a mark of maturity and stability, so I think it should ensure that either party has access to all resources should that access need to be redistributed. GitHub has a built in Successors mechanism wherein if a maintainer were to unfortunately pass away access can be gained to their projects, but this only applies in that circumstance and not for simple AWOL.

I think in cases like ReactiveUI, ImageSharp, WiX, and others where they have a backing corporation of their own that they should be empowered to hold access and redistribute if needed provided the Foundation has contacts, but in any case my point is project continuity is a big concern and is a valid reason for having admin access provided this access is only used in that event.

[SeanKilleen]

Cross-posting this here per @glennawatson's suggestion.

---

I'll offer an additional idea to support your aims here, in case it's useful--

Since one of the problems of usage of dnfadmin is that folks aren't aware of what it was doing, one step toward transparency might be to list all the times it is used (going forward; historically may he impractical) and their purposes. If a public log of this exists, others can weigh in if the usage goes into a gray area, and there will likely be a sense that communication should happen before it's used. It could be a useful check on the overall usage of the account (which does I think still have its benefits from a management perspective).

If we have a list of usages after the fact, this can be used to shift things to the left -- instead of "we did x" with the account, it can become "we're thinking about doing x with the account" as a request for comment.

[JeremySkinner]

I'm in a slightly different position to @glennawatson as I'm the sole maintainer of my project, and I don't have anyone else who can take over ownership in an emergency, so I would actually like the DNF to have access for this purpose (in fact, it was my main reason for bringing FluentValidation into the foundation).

That being said, I'd like to see a couple of things clarified:

• Does the dnfadmin account need day to day admin access, or can we just make use of the github successors feature and delegate dnfadmin as successor
• Is admin access actually needed for the CLA bot to work, or was that only needed to do the initial setup?

So essentially for my project, I'd like the following if possible:

• No day to day admin access for dnfadmin
• Delegate DNF as the project successor
• CLA bot still works

[dansiegel]

Personally I'm not a fan of the service account. I'd rather see individuals granted access as needed. That keeps audit logs easy to figure out... instead of trying to somehow figure out who used the service account it becomes "oh @rprouse did X" (and to clarify for anyone who comes along... this is just an example not an accusation)

[jmiddour]

I can see where the .NET Foundation having a constant admin account may not be acceptable for some projects. Likewise I can see where relying on someone being around to grant individuals access is not ideal for the .NET Foundation's continuity goals.

The GitHub successor public description requires a death certificate or obituary, so that is obviously meant for a worst case scenario and I think it would work well in that scenario. For project abandonment, perhaps a compromise would be additional succession options along the lines of an emergency or trusted contact scenario.

A designated successor requests access to an account with a reason. The maintainer gets notification and is able to immediately resolve (yes or no). If the maintainer does not reply within n days (21?) then the emergency contact is granted access.

The 3 scenarios could play out like this:
If the maintainer says no, then obviously more communication needs to take place.
If the maintainer says yes, then the maintainer would retain ownership and keep the option of revoking access at any point.
If the request times out, the successor is allowed to assume ownership as the project would be considered abandoned.

I think this feature would also be valuable to GitHub users outside of the .NET Foundation context, so making it part of the succession feature set of GitHub makes sense.

If there are concerns regarding who the successor is, perhaps a requirement that a successor be either a foundation account or a current foundation member would be reasonable.

Just an idea.

[Pilchard123]

I don't want to toot my own horn, but I had a similar idea to @jmiddour over here. I'll link back over here from there too.

[jmiddour]

@Pilchard123 From my standpoint, please feel free to toot away. I am quite confident that I am not the first nor the only one to come up with this idea.

I am neither a member of the .NET Foundation nor a project maintainer; I am just a developer that benefits greatly from both. My aim was to provide the public discussion a concise, specific, and (hopefully) acceptable neutral starting point for how to accomplish the aims of both groups.

Edit to add: After reading your post, they are very similar and I think some version of it would solve both aspects of this issue. And I am quite happy to say that you beat me to it! 😁

[Pilchard123]

It's all good, I'm not trying to make any claims of it being my novel idea either. I'm in the same boat as you - not a member and not a maintainer, just trying to help.

[SeanKilleen]

As a tangential thought to this -- I know that one of the problems with communicating upcoming changes is communicating the changes to a large group of repositories.

I had actually started on some management tooling for this at a former employer for exactly this purpose. It was early stages of functional but one of the things that worked was messaging some or all repositories in an organization by creating a GitHub issue with a label.

The project is open source. It's been dormant but I could try to dust it off if it could be beneficial.

Automating management activities can help ensure their communication is automated as well.

[rprouse]

Agreed. We need to figure out one consistent way to communicate with project leaders. Right now it is a mix of Twitter, email, Slack, GitHub discussions, issues, etc. 🤷🏻‍♂️