[tc] Assuming control of GitHub organizations

Graham Hayes gr at ham.ie
Thu Jun 27 12:23:36 UTC 2019

On 27/06/2019 09:55, Thierry Carrez wrote:
> Jim Rollenhagen wrote:
>> The opendev team reached out to me about handing off administrative
>> access of
>> the "openstack" and related organizations on GitHub. They think it
>> would be
>> best if the TC took control of that, or at least took control of
>> delegating
>> that access. In general, the goal here is to support OpenStack's
>> presence and visibility on GitHub.
>> [...]
>> Do TC members want to manage this, or should we delegate?

I think we should manage it, but possibly allow the foundation to manage
parts of it (pinning, descriptions, etc).

For setting up syncing / creation of projects we should look at keeping
that under the TC (that could be the TC or other group of people that
step up)

> I have been considering our GitHub presence as a downstream "code
> marketing" property, a sort of front-end or entry point into the
> OpenStack universe for outsiders. As such, I'd consider it much closer
> to openstack.org/software than to opendev.org/openstack.
> So one way to do this would be to ask Foundation staff to maintain this
> code marketing property, taking care of aligning message with the
> content at openstack.org/software (which is driven from the
> osf/openstack-map repository).
> If we handle it at TC-level my fear is that we would duplicate work
> around things like project descriptions and what is pinned, and end up
> with slightly different messages.

I am not as concerned about this, the TC should be setting out our
viewpoint for the project, and if this is in conflict with the message
from the foundation, we have plenty of avenues to raise it.

>> One thing to figure out is how to grant that access. The opendev team
>> uses a
>> shared account with two-factor authentication provided by a shared shell
>> account. This mitigates accidental pushes or settings changes when an
>> admin is
>> using their usual GitHub account. The TC (or its delegates) probably
>> doesn't
>> have a shared shell account to do this with. Some options:
>> * each admin creates a second GitHub account for this purpose use a
>> shared
>> * account without 2FA use a shared account with 2FA, share the one
>> time secret
>> * with everyone to configure their own token generator use personal
>> accounts
>> * but be very careful
>> Thoughts on these options?
> I'd do a limited number of personal accounts, all with 2FA.

I would do it with personal accounts, but require 2FA, and explicit
opt-in from TC / SIG / $group managing it.

We should look at automating as much as possible of course, and have it
ran by shared account that can be held in trust* as a break glass
account if the needs arise in the future, but that is a longer term

* trustee tbc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190627/a0d1b784/attachment-0001.sig>

More information about the openstack-discuss mailing list