Stream: t-compiler/wg-meta

Topic: github perms


Pietro Albini (Feb 21 2019 at 19:46, on Zulip):

ok @simulacrum you need to have read access to the repo, not write access

Pietro Albini (Feb 21 2019 at 19:46, on Zulip):

but the team needs to have read access explicitly

Pietro Albini (Feb 21 2019 at 19:46, on Zulip):

it's not enough to be on the org

Santiago Pastorino (Feb 21 2019 at 19:52, on Zulip):

people with read access are not able to change labels?

Pietro Albini (Feb 21 2019 at 19:57, on Zulip):

that's not possible

Santiago Pastorino (Feb 21 2019 at 19:59, on Zulip):

ok, asking Github people

Santiago Pastorino (Feb 21 2019 at 19:59, on Zulip):

changing something on the repo is writing

Santiago Pastorino (Feb 21 2019 at 20:00, on Zulip):

I guess they might want to have a set of things the organization allow to each member

Santiago Pastorino (Feb 21 2019 at 20:00, on Zulip):

and then you might be able to add people and allow only changing labels

Santiago Pastorino (Feb 21 2019 at 20:00, on Zulip):

unsure if that's something they want to build or what, but gonna ask

nikomatsakis (Feb 21 2019 at 21:03, on Zulip):

ok @simulacrum you need to have read access to the repo, not write access

@Pietro Albini by this you mean, in order to be assigned to an issue?

Pietro Albini (Feb 21 2019 at 21:04, on Zulip):

yep

Pietro Albini (Feb 21 2019 at 21:04, on Zulip):

not to assign yourself or other people (that requires write access), but to let others assign you

nikomatsakis (Feb 22 2019 at 18:31, on Zulip):

@Pietro Albini to clarify, triagebot is active now?

Pietro Albini (Feb 22 2019 at 18:31, on Zulip):

afaik no, but it should be soon

Pietro Albini (Feb 22 2019 at 18:31, on Zulip):

ask @simulacrum about it, they're working on it

nikomatsakis (Feb 22 2019 at 18:31, on Zulip):

oh, ok

oli (May 09 2019 at 10:01, on Zulip):

Our docs for working group membership mention adding working group members to the github team. The problem is that one can only add org members to teams. While there's work happening around creating some sort of "assign non-org-members to issues" scheme, the main advantage of team membership that I see is being able to ping groups. We could add a similar workaround where pinging a team will also cause a bot to ping the non-org members directly. All in all I believe this is solvable, but I'm wondering if we should update the docs to reflect this policy.

davidtwco (May 09 2019 at 10:16, on Zulip):

We'd thrown around the idea of having a "subscribe me to this working group" function on a bot that would add you to the org and to the working group. But I think there were also concerns that we wanted to avoid adding all-the-people to the org if we didn't need to. In the end, I think it was left as something to resolve later. Like you said, there are plenty of ways to go about fixing this. For now, updating our documentation to reflect that it's only-kind-of-possible to add people to GitHub groups is probably a good idea.

nikomatsakis (May 09 2019 at 12:21, on Zulip):

Yeah, I think we were coming to the view that people should not be added to the org lightly -- though I think this is a "lightly held" opinion for me. I agree it would be nice to have a way to add people to some alias that can be notified readily.

nikomatsakis (May 09 2019 at 12:22, on Zulip):

In general, the manner of "working group membership" remains a bit tricky I feel like. See also this question on the website of how to present working groups.

nikomatsakis (Sep 12 2019 at 14:59, on Zulip):

Speaking of github permissions. I'd like to make it possible for @Albin Stjerna to land PRs on polonius, publish new versions, etc.

Is the best way to do this to create a wg-polonius github team (we seem to be missing an entry from the team repo!) so I can give that permissions...?

Seems like yes?

The alternative might be to add @Albin Stjerna to the "compiler contributors" team and give perms to that.

This comes back to that question of WG membership, I guess. I've been sort of shifting my opinions there.

nikomatsakis (Sep 12 2019 at 14:59, on Zulip):

Also related to @Santiago Pastorino's questions about learning WG

nikomatsakis (Sep 12 2019 at 15:07, on Zulip):

Created https://github.com/rust-lang/team/pull/114

Santiago Pastorino (Sep 12 2019 at 15:38, on Zulip):

@nikomatsakis my main question is in the case of the learning wg, what kind of access would you give?

Santiago Pastorino (Sep 12 2019 at 15:39, on Zulip):

I guess what @Pietro Albini have said on the learning-wg thread makes sense

nikomatsakis (Sep 12 2019 at 15:46, on Zulip):

Yeah so I think membership should be reserved for the same level of interaction as would be expeced for compiler contributors

nikomatsakis (Sep 12 2019 at 15:46, on Zulip):

But basically it does't seem to make sense to me to add everybody to compiler contribs..? I guess it's not bad either

Pietro Albini (Sep 12 2019 at 15:49, on Zulip):

doesn't compiler-contributors give r+?

Pietro Albini (Sep 12 2019 at 15:49, on Zulip):

yeah it does

Santiago Pastorino (Sep 12 2019 at 16:07, on Zulip):

Yeah so I think membership should be reserved for the same level of interaction as would be expeced for compiler contributors

just in case, because I don't know I got right what you meant, Pietro suggested to allow the learning wg write access on rustc-guide only

Santiago Pastorino (Sep 12 2019 at 16:07, on Zulip):

and the repo could be branch protected

Santiago Pastorino (Sep 12 2019 at 16:07, on Zulip):

by doing that, people can have control on the issue tracker, project, be able to merge things and stuff like that

Santiago Pastorino (Sep 12 2019 at 16:07, on Zulip):

I think it's fine to do that

Santiago Pastorino (Sep 12 2019 at 16:07, on Zulip):

but there's also the possibility of just giving access to the issue tracker

Santiago Pastorino (Sep 12 2019 at 16:08, on Zulip):

access to rustc-guide I'd say is low risk in general

nikomatsakis (Sep 12 2019 at 16:56, on Zulip):

by doing that, people can have control on the issue tracker, project, be able to merge things and stuff like that

yes, this

nikomatsakis (Sep 12 2019 at 16:56, on Zulip):

so I basically think there are two axes:

nikomatsakis (Sep 12 2019 at 16:56, on Zulip):

it seems like having just compiler contributors means we can judge the first, but it feels a bit ... too flat

nikomatsakis (Sep 12 2019 at 16:57, on Zulip):

for projects with separate repos, it feels like it makes sense to hvae an add'l group (e.g., wg-polonius, wg-learning) that also has access to that repo and we can add people to that

nikomatsakis (Sep 12 2019 at 16:57, on Zulip):

not because I'm paranoid per se

nikomatsakis (Sep 12 2019 at 16:57, on Zulip):

but because, I don't know, it just seems more...descriptive :)

Last update: Nov 18 2019 at 01:55UTC