How can we give temporary admin permissions to committers?

[fredg02]

In general, we recommend that only project leads get temporary admin permissions. In some cases, it's still easier for projects when tasks are delegated to committers. Such cases require the blessing of a project lead.

There are two approaches:

• Add a committer in the "Settings -> Manage access" menu and give him "admin" access
• Add a committer to the GitHub project lead team and give the team "admin" access

The GitHub sync script does the job of reverting these changes very well. Therefore, temporary admin permissions can only be given between two sync script runs (~2 hours).

We need to find a way to give committers temporary admin permissions for longer periods of time (until they have finished their tasks).

Recent examples, where this was necessary and caused delays and frustration:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=572384
https://bugs.eclipse.org/bugs/show_bug.cgi?id=572917

[fredg02]

@waynebeaton In order to move forward with this, we need your assessment. Are you OK with handing out temporary admin access to committers, with the blessing of a project lead? Or are we sticking to the "only project leads can get admin permissions rule"?

[waynebeaton]

Are you OK with handing out temporary admin access to committers, with the blessing of a project lead?

Yes.

[autumnfound]

Looking into the API binding I use, they expose expires_at which I think could be an important part of this implementation. So we have 2 options for this, one being much looser than the other.

1. We look at the expires_at setting on a project member, and make sure it's less than say a week in the future. If this is so, then we don't remove them. Keep in mind there is no state across runs, so the script won't know if the user has their access extended by a third party with the ability to add users.

2. We add an implementation of the static team manager we use to manage the Eclipse Fdn team on Github to the Gitlab sync. We could set expirations, users, and level of access of the group of users to the list of repos. This would leverage some existing code, but be a little more complex to implement than ignoring users that have an expiration.

Option 1 is much simpler and very lax with access control, while the second would require a commit and a build to update for each new entry (iirc? Its been a while since I've dug around this code), but is much more secure. We could also build another system to ignore users in a list we specify somewhere, but adding more systems is a bit silly. There's also the added bonus that we can start managing external and special groups once we add this in.