DELPH-IN Organization Admins

[goodmami]

DRAFT (This is based on the email thread from July 2020. Maybe here is a good place to put this information?)

This team is for people administering the delph-in organization on GitHub. This includes those with the "owner" role of the organization and those who assist with administration tasks. Please comment here to request to join the team or to change a role such as getting write/admin privileges for some repository. Note that comments here are visible to all members of the delph-in organization.

While we are a strictly open-source group, we nevertheless need to follow some organizational security practices to avoid account takeovers and other malicious actions.

Policies

• Repositories must be open-source, preferably with a permissive license
  • MIT, BSD, and Apache are good choices for code
  • CC-BY is good for corpora, lexical resources, and documentation
  • Note that not choosing a license means it's not open-source!
• Private repositories in the organization are discouraged but sometimes may be appropriate (e.g., for work under review)
• Members, particularly those with admin privileges, are expected to follow good password hygiene
• Owners must also use 2FA (click here to set it up)
• Avoid granting privileges without a specific reason; see here for permission levels within an organization, and here for repository permissions
  • The group of people with the "owner" role should be small, as it carries full privileges, but there should be at least 2 owners
  • Try to grant the lowest level necessary for the member to accomplish their task
  • Relinquish roles that are no longer needed

[olzama]

After working with the infrastructure for a while, I am starting to think that having both "admins" and "owners" is confusing because it leads to admins trying to do things which they cannot (only owners can). And then it is awkward because e.g. I need to petition to do something to organize the summit, and it is not even clear with whom exactly I am petitioning and why I have to do that :). So I think either owners group should be expanded to include all admins (and admins can be disbanded), or if we want fewer owners and some "admins", then each admin should have a "dedicated" owner with whom they actually work very closely and through whom they do everything, sort of (so, more like an RA--PI relationship, I guess, would be an appropriate analogy, which is to say, the PI should be as invested in the result as the RA :) ).

[olzama]

On reflection, "standing committee" and "owners" being different sets I think may ultimately be confusing (if we also have "admins")... E.g. something organizational, such as whether the wiki should be open for editing to anyone, should generally be raised with the standing committee (I think), but here it is the owners who can actually do anything. And right now there isn't even a guarantee that any of the owners will also be standing committee (right? I know in practice there is overlap but I mean, conceptually, there is no procedure in place that guarantees that?) There is also a noticeable misalignment between SC membership and the level of activity in organizing this set of repos. Maybe we could somehow designate a standing committee member (or two, better yet) who would be responsible for promptly reacting to organizational issues as an owner? So, SC and owners can then be different sets, and perhaps we could have additional "admins", but we should somehow make sure that there is one or two specific SC members who will consider it their job to engage with organizational questions/issues and are also owners, so they can quickly resolve issues. So, if someone like me is one of the summit organizers, I have a to-go SC member who will quickly respond and make a decision/change regarding this GH space, such as in the case with wiki writeability, (or alternatively decide that that warrants a SC vote or whatever). I think previously, it was the case that all or most SC members acted in this exact way, but maybe with the move to GH that changed (understandably).

[olzama]

I think what would in principle solve the current conundrum is if @danflick were owner but I don't know if he wants to be (I'll ask).

[goodmami]

Agree that the roles, teams, permission levels, etc. can be confusing.

• Permissions:
  • repository-level: read, triage, write, maintain, admin
  • organization-level (divided by roles; see below)
• Roles:
  • owner: full privileges (admin on every repository in the org and organizational-level permissions)
  • member: no privileges unless granted through various means
  • billing manager (not used by us)
• Teams: manage permissions for groups of people for certain repositories and provide a discussion space (roles like "owner" do not have a discussion space)

Owners don't have any extra repository permissions beyond what an "admin" has. As mentioned above, there should be a small number of owners. Probably the most important privilege (for us) an owner has is to invite new members to the organization (an admin can invite people to a repository, but not to an organization).

This "admins" team is mainly for the discussion space and for giving other members admin privileges to organization-wide repositories like docs, although this latter function could be accomplished via other means. I'm not certain what purpose the standing committee team has on GitHub. While it would seem to make sense that the owners would be the (actual) standing committee because those people would generally be longer-term participants who recruit students to DELPH-IN, the overlap is imperfect because some standing committee members do not use GitHub much and some non-standing committee, namely Guy and me and formerly Ned, are owners because we initially set it up and are very familiar with GitHub. I'm not generally in favor of giving more people the owner role, purely for security reasons, but I think there's an argument for adding you or Dan to better manage the current summit. I'll reply in the other thread about that.

[olzama]

Yeah. I think what I am saying also is that the industry(?)-oriented structure suggested above, while maybe necessary for larger organizations, perhaps is not perfect for what I've come to know as DELPH-IN spirit :). I am not sure how much security/hierarchy of this sort we need in our community? At least what I am experiencing feels more like unnecessary hurdles, so far.

[olzama]

Probably the most important privilege (for us) an owner has is to invite new members to the organization (an admin can invite people to a repository, but not to an organization).

So, first an owner (e.g. you) can add a GH user to the org, and then an admin (e.g. I) can add them to the docs? I am still confused though because I am supposedly an admin but I don't seem to be able to add people to Participants? Maybe "admin" and "admins" are different?

[goodmami]

I am not sure how much security/hierarchy of this sort we need in our community?

To be clear, it's not personal and it's not about creating power hierarchies or unnecessary hurdles. Owners are all-powerful in the organization and therefore have the ability to remove the owner role from others. So if a current owner's account gets hacked, the malicious actor could boot everyone else out, delete everything, and start hosting whatever they like using our name. This is why I require 2FA for owners (only verbally, the toggle to actually require it would immediately kick all members (not just owners) who don't have 2FA out of the organization, so we haven't taken that step yet).

I am still confused though because I am supposedly an admin but I don't seem to be able to add people to Participants?

admin privileges are for repositories, not for the organization. Through the "admins" team you have admin privileges on the delph-in/docs repository, so you can do anything an owner can for that repo. Through the matrix-devs team you have "maintain" privileges on the delph-in/matrix repository. You'll either need to be an owner to invite people to the organization (including into teams like Participants), or rely on someone who is. I suspect that when we created the admins team we were hopeful it would do more for us than it does... we're all learning the limits of the system :)

[arademaker]

The community is not too big. Maybe we can draft a initial concrete proposal for groups and accounts and give people sometime to revise and then apply in the org. Does it work?

[goodmami]

Maybe we can draft a initial concrete proposal for groups and accounts and give people sometime to revise and then apply in the org. Does it work?

The head post of this discussion is an attempt at that draft :) While it is nominally about the "admins" team it's really about how to administer the organization. I welcome feedback, additions, and alternatives!

Until yesterday there was no feedback so I've just been trying to apply the security policies: 2FA and principle of least privilege (thanks to Ned for putting a name to it).

[arademaker]

Sorry, what I was trying to say is to create a spreadsheet with groups and accounts and let people revise before applying it. So far, if I understood right, we are proposing the groups:

1. Admins
2. SC
3. Participants

is it right?

[goodmami]

Ah, sorry. Yes, that's a good idea.

And yes, those are the 3 teams we have (that aren't for specific repositories). Olga said she found the overlap between 'admins' and 'standing committee' (and maybe those with the 'owner' role) to be confusing, whereas I don't see much reason to have the 'standing committee' team. I think we all agree that Participants is a good idea.

[guyemerson]

I think the "admins" and "standing committee" teams have a use case in terms of notifying different sets of people.

I agree that the difference between teams, permissions, and roles is confusing. However, that complexity is there regardless of what we do -- there are hurdles in simply learning how GitHub security works. I agree with @goodmami 's draft proposal above, and I agree with @arademaker that we should clarify who should be in those three teams. It seems clear who should be in the "standing committee" and "participants" teams (the standing committee, and everyone), so we just need to decide if we want to modify the "admins" team. Separately from these teams, we also need to decide if we want to modify the set of people with the "owner" role.

[olzama]

However, that complexity is there regardless of what we do -- there are hurdles in simply learning how GitHub security works.

I don't want to put the org in any danger of course, but I wonder if worrying about security too much is a sort of "danger" in itself. In theory, maybe something could happen to this set of repositories, but I don't know that it is super likely? (And many of us would have them backed up twice, I am pretty sure!) While In practice, we are creating a complicated administrative hierarchy here which does not clearly map to the social hierarchy (that would be impossible because social hierarchies are live and much more interesting than sets of privileges), and then make any move in this org dependent on it. This used to not be the case in the past because all projects (e.g. Matrix, Jacy, etc.) were independent of each other, led by their respective PI. Now we've created something new, an org which indeed unites all of these projects, but the administrative aspects of it aren't fully clear. I agree that we can discuss all of this during the summit :).

[guyemerson]

I don't think we're creating a complicated hierarchy. We can't avoid having to decide who has the owner role. For each repository, we can't avoid having to decide who has permissions (and at what level). This is the complexity that we can't avoid. Teams make it easier to manage permissions, not harder, because it's always possible to assign permissions directly to individual people, rather than to teams.

Having said that, you're raising a valid point about how permissions should be managed, since Delph-in projects are not centralised. Every repo should have someone with admin permissions, but this can be anyone -- this isn't connected to owners or to teams.

One place where we might want to tweak things is the "member privileges" (https://github.com/organizations/delph-in/settings/member_privileges), i.e. controlling how many things require the "owner" role. I don't believe we've discussed all the options here, and perhaps setting these correctly would alleviate your concerns.

[olzama]

We can't avoid having to decide who has the owner role.

Agreed; I think I am mostly finding myself wishing that there was a better/clearer procedure for making those decisions though, in particular regarding who this "we" is. (And I'd personally suggest it should be up to SC; I think delegating this particular authority results in odd/inconvenient situations, for a number of reasons).

[olzama]

Every repo should have someone with admin permissions, but this can be anyone -- this isn't connected to owners or to teams.

I guess that's right; I suppose I found myself in a particularly odd position because of summit organization (which is centralized). But that's not a common situation.

[goodmami]

maybe something could happen to this set of repositories, but I don't know that it is super likely?

Not likely, but potentially devastating. It's not about losing the work because, as you say, we'll probably have local clones of the repos. It's about losing access to the organization, and having our published URLs resolve to something we can't control. I think we can contact GitHub support to recover a hacked account, but I'd like to avoid that headache.

One place where we might want to tweak things is the "member privileges"

Except for the ability to create teams, those privileges are for repository access and wouldn't address the current issue, namely adding new members to the org. I don't think we'd want to give all members admin or even write access to all organization repositories, public or private. Granting read access to all members does nothing at the moment, as all organization repositories are public already.

in particular regarding who this "we" is.

Ok how about, as you suggested, everyone in the 'admins' team gets the owner role, and other members can ask the team for admin action (including requesting to become an admin), either through this discussion space or by @-mentioning the team?

[olzama]

I guess, my specific issues have been resolved for now because I was finally able to add everyone to Participants and then Dan was able to make the wiki announcement which was overdue, and now the summit organization can proceed. That's great. I was a bit frustrated about having to negotiate that for several days :). After the summit, perhaps I don't need the owner privileges; that's a separate matter. Maybe let's discuss this at the summit? I have some thoughts about why the issues arose in the first place (specifically, looks like there's several owners but only one of them typically acts in practice, and that can lock things down), but perhaps no need to discuss that online! The pressing issue for me was the summit organizing.