Adding to Participants (e.g. for the summit)

[olzama]

For the summit, we will need a Participants group (which will just have to double the entire organization, I think). That group will need to have writing privileges in the docs repository.
I think we will also need multiple people with the privilege to add to Participants, e.g. this admin group. Is that possible to set up?

[olzama]

Btw, that means Participants must have push-access, I think. At least right now the Docs repo is restricted for editing only by "teams with push access". But looks like the only other option is that anybody with a GitHub account could edit.

[goodmami]

@arademaker created a Participants team 6 days ago. We can give that team push access to docs. It's probably not so bad to just open up the wiki, too.

[olzama]

Yes I know he created it but we need to add to it. Right now I don't know who can add; I certainly can't (and I am one of the people registering others for the summit). I suspect that Dan (the other such person) cannot either.

[olzama]

It's probably not so bad to just open up the wiki, too.

To anyone with a GitHub account?

That would be different from what we did before? Not that I mind (we will all have backups of the wiki, probably, in case of something malicious; plus something malicious is probably unlikely). But still seems like a relatively big decision to make (for the @delph-in/standing-committee ?) -- and @danflick and I need to start registering people for the summit fairly soon. And @arademaker and I need to announce the wiki even sooner :).

In general, I think there should be someone who is both serving on the standing committee and is active in developing the github organization. Otherwise it becomes a bit inconvenient :).

[emilymbender]

In the previous set up, it was my job to keep the ParticipantsGroup and the participants mailing list aligned. I'm happy to keep doing that, so long as it's possible to create something analogous to ParticipantsGroup on GitHub and someone can show me how to manipulate it.

I'd rather not have the DELPH-IN wiki be world writable ...

[olzama]

There is already a Participants "team", right now only @arademaker (who created it) is there.

Here's what needs to be done:

1. All current members of the organization need to be added there (so, 19 of us)
2. Anyone who joins the delph-in org in the future should be added there
3. The group should be given push privileges

Unfortunately I cannot demo any of that because my level of privileges doesn't allow me to see/perform any of those actions. So maybe @goodmami (I think he is owner? I am confused as to who the owners are, and there isn't an obvious way to see, not that I can find.)

[olzama]

Update: looks like the owners (apart from @emilymbender ) are @arademaker , @fcbond, @oepen , @goodmami , and @guyemerson . So, maybe one of them can demo (or sign up for doing (1)--(3) above).

[emilymbender]

So it sounds like we also need to get DELPH-IN participants to join the delph-in github org, too, right?

[olzama]

Yes, for sure. Dan is going to send out an announcement soon urging people to do so (and I will also send a similar announcement, regarding the wiki).

[goodmami]

Emily, if you're happy to keep managing participants then I don't think Olga needs an owner role. That said, I don't have a problem with granting it to her or Dan, except for a general wariness of having too many accounts with full privileges, if it helps them manage the summit. If that's the case, they would need to enable 2FA first. @olzama, if Emily manages invites, is there another owner privilege you still require?

I'd rather not have the DELPH-IN wiki be world writable ...

That's fair, and closer to what we had previously. I've had the Xigt wiki (GitHub-)world-writable for years without any issue, which I attributed to GitHub itself keeping out malicious actors and bots. But it could also just be that Xigt is less prominent than DELPH-IN :) I have now given write permissions to the delph-in/docs repository on the Participants team, so anyone in that team can edit the wiki (or push anything else to the main git repository).

and someone can show me how to manipulate it.

1. Go to https://github.com/orgs/delph-in/teams/participants/members
2. Click "Add a member" and enter their GitHub username
   • email works too, but I'm not sure if it works if it's not the same email address as they use for GitHub
   • this step adds them to both the organization and the team

For more info, see GitHub's documentation: Inviting Users to Join Your Organization

So for step (2) to be most effective, perhaps Dan should solicit people's GitHub usernames?

[guyemerson]

Just to check -- is there no way to automatically grant access to the docs repo to everyone in the delph-in organisation? It seems redundant to set up a team that includes everyone in the organisation. But I also can't see a way round this in the GitHub settings.

[goodmami]

Unfortunately not, I don't think. It does seem like it would be a useful feature, though. What we can do is:

1. Make the wiki editable by anyone with a GitHub account
2. Give all members a base role that allows for writing to any repository (not just docs)
3. Manually add everyone directly to the docs repository with write access
4. Manually add everyone to a team like Participants and give the team write access

(1) and (2) are too open, and (3) only solves the immediate problem. With (4) we can reuse that membership for any future repositories that we wish to open to the whole group. It's a bit annoying to add people one at a time, but it only needs to be done once per person.

[arademaker]

We can give that team push access to docs. It's probably not so bad to just open up the wiki, too.

I would like to be able to grant access to the wiki only , not to push to the docs repo. But this seems not possible. That is the limitation that I found and would like to confirm with @goodmami

[arademaker]

But we can at least protect the main branch I think …

[arademaker]

Manually add everyone to a team like Participants and give the team write access

Yes, I vote option 4 :-)

[olzama]

I would like to be able to grant access to the wiki only , not to push to the docs repo

Right, that's not possible as far as I know. But is it really a problem that all members will have push access to the docs? There is nothing else in the docs, really, just the wiki?

[oepen]

dear all:

Manually add everyone to a team like Participants and give the team write access

this sounds like just the right solution to me, and it is wholly parallel to how we used to manage wiki edit privileges in the MoinMoin universe: the ParticipantsGroup was a kind of membership roster, which primarily emily kept up-to-date; any WikiUser listed on that page had default edit rights to the entire DELPH-IN wiki. on a governance note, i would suggest we copy much of this communication to the standing committee. in my view, we could look at the limited group of admin users for the DELPH-IN organization as the implementation of the infrastructure task force that we discussed during and after the summit last year. these are the people actually doing useful community work these days. as i understand the current division of labor, it would seem natural to me that alexandre and olga are part of that group. i would personally not be primarily concerned about GitHub security, but i believe it makes sense to restrict the infrastructure task force in size also to maintain a certain level of cohesion and uniformity, e.g. have a forum to discuss design and naming decisions before they are implemented. in my view, the standing commitee (which currently overlaps with the infrastructure task force, if interpreted as the above, in francis and me, i believe; maybe also emily) should have a chance to keep itself informed about non-trivial design decisions, but i would find it important that the task force has the privileges and autonomy required to continue to develop our new emerging community infrastructure. i will try to follow this process in cases where we need to synchronize with the remaining infrastructure hosted in the 'delph-in.net' domain (SVN, mailing lists, archival download links, the MoinMoin archive). for example, i imagine it might now be tempting to redirect the outward-facing DELPH-IN web page (www.delph-in.net) to the home page of the new wiki, rather than to the FrontPage in the read-only MoinMoin instance. in my view, such a move would not strongly require approval by the standing commitee. alternatively, if somewhere felt inspired to generate a new front page with fancier layout via GitHub pages, i could designate a name for that in the 'delph-in.net' domain (and then redirect there); that name could, however, not be 'www.delph-in.net', because there is a relatively large number of legacy download URLs behind that prefix. conceptually, i think the standing committee should have a chance to comment on a re-design decision of this scale. best wishes, oe

[olzama]

Stephan @oepen , I was just talking privately with @goodmami and saying that ideally, there would be some direct communication with the SC on any issues which sound important. Of course we could maintain separate email communication with the SC in addition to discussions that we might have here, but that sounds perhaps not ideal? What we seem to be lacking is a GH setup which would directly bridge administration with the SC. For example, this admins group doesn't include all of the SC members (even the SC group doesn't include all of the SC members!).

Could we somehow set up a robust channel of communication with the SC through here?

[olzama]

Could we somehow set up a robust channel of communication with the SC through here?

I suggest:

1. All SC members should actually be added to the SC team :). One of the owners should do it. Right now a couple of members are missing from that team, making the situation awkward.

2. Once we add everyone to Participants, we can start having all discussions in the docs/ repo (Alexandre and I enabled the special "Discussions" tab there, which is supposed to be convenient). Notifications of discussions should then reach all members via email, and we will be able to tag @delph-in/standing-committee to draw their attention to something specifically.

3. I am not sure we should use this admins group for future discussions (though we may need the team itself for the ease of assigning admins to repositories). As for discussions, I think we can just discuss everything in the docs/. I don't see much value in excluding some members from these discussions? The organization is small enough. But in case we want to continue discussing things here, then we should at a minimum add the entire SC here so that they always have a chance to react.

[arademaker]

There is nothing else in the docs, really, just the wiki?

in the future, maybe… but we can protect the main branch.

[goodmami]

i would suggest we copy much of this communication to the standing committee

Now that this organization is more or less the home of DELPH-IN's infrastructure, that seems like a good idea. We should probably have some session during the summit to announce/decide how we'll move forward.

as i understand the current division of labor, it would seem natural to me that alexandre and olga are part of that group.

I agree and I see that @olzama has enabled 2FA so I've made her an owner. Alexandre already was for his initial efforts at moving the wiki.

I also think we should bring up these privileges at the summit. I thought of the owner role more as an IT admin status but it seems like some may view it as mirroring the social power hierarchy in DELPH-IN. In that case, I'd be happy to give up the owner role since I'm not in the SC, assuming someone wants to take over the administrative duties I've been performing.

All SC members should actually be added to the SC team :).

It wasn't always the case that they all had GitHub accounts (that I was aware of), and also the SC has shrunk a bit. I now see that the remaining two are members of this org so I've invited them to the SC team. (Actually, I clicked "invite" but it seems to have just added them; apologies if this was not desired by them!).

In any case, I'm not sure all participants in DELPH-IN have GitHub accounts, and I don't really like the idea of requiring an account for participation in DELPH-IN, but if we're moving everything here I guess it's practical.

in the future, maybe… but we can protect the main branch.

I think this is a good solution to this problem. I have not yet experimented with setting up branch protection rules on GH. I'm happy to try but if anyone has experience and wants to step up, that'd be great.

[anncopestake]

Hi All, I just wanted to say that I'm skimming these conversations and am very happy with the direction of travel.   Realistically, if you need comments on an issue from members of the SC who aren't specifically involved, that requires a brief summary - but I take the view that the SC has agreed to delegate this, so doesn't need to be involved very frequently. I think it is reasonable to say that everyone should have a github account for full participation. All best, Ann

[guyemerson]

I am not sure we should use this admins group for future discussions (though we may need the team itself for the ease of assigning admins to repositories). As for discussions, I think we can just discuss everything in the docs/. I don't see much value in excluding some members from these discussions?

The discussions are visible to everyone in the organisation, not just the team. Everyone in the team automatically gets a notification, but anyone in the organisation can opt in to notifications (by clicking on the team and then clicking on the "watch" button).

[olzama]

The discussions are visible to everyone in the organisation

Ah, I see. That's good. And I am assuming not only visible, but any member can also comment?

[olzama]

I take the view that the
SC has agreed to delegate this, so doesn't need to be involved very
frequently.

Maybe not very frequently but I think it is important that SC is present here, and in particular any decisions that aren't obvious, for example, or on which there is no clear consensus, I think could be made easier that way. Unless SC wants to delegate specifically the decision-making authority to any particular member(s), in which case that in turn should be made clearer---or maybe those members should be on SC at that point.

[olzama]

I'd be happy to give up the owner role

I sincerely hope you won't, @goodmami! I am of the opinion that we need more active, engaged owners, not fewer, though sure, perhaps not too many (for the security reasons which you indicated).

Just a matter of a balanced distribution of privileges with levels of activity, mainly because I think it is crucial that decisions can be enacted by more than one person. This is both because sometimes decisions are important enough to warrant discussion and because sometimes things need to happen quickly and if there is only one available/responsive person with enough privileges, it becomes inconvenient (especially so if there happens to be something like 12 hours time difference in between...).

[goodmami]

And I am assuming not only visible, but any member can also comment?

I think any member can post to any team's discussion space. Team members can post messages that only the team can view, but those with the owner role can see everything in all teams. This is why the 'standing committee' team isn't a good place for their internal discussions. I guess I see value in the SC team as a way for other members on GitHub to address the SC or to request a response.

I sincerely hope you won't, @goodmami! I am of the opinion that we need more active, engaged owners...

I wasn't offering to stop being an active member, just to give up some power if I'm not using it :) I could request the role again if I needed those privileges for something in the future.