rfcs
rfcs copied to clipboard
rust-lang
rust-lang org GitHub access policy
I think that working groups with their own orgs that are outside the rust-lang org should continue to manage their own affairs.
Permissions should only be given to teams within the Rust-Lang organization, not to individuals.
This statement is a little confusing to me, can you clarify it? On its own, I read it that permissions would only be granted to an entire team, but then later it implies that permissions can be doled out to individuals in a team. Is it trying to say that permissions shouldn't be given to anyone not in any team? Can I give access to random people from other teams? Does everyone on every team become a member of the rust-lang organization? If not, how does org membership work?
It's also not clear if this is assuming there is some correlation between a repo and a team. Many repos have nebulous or non-existent relationships. rust-lang/rust itself isn't owned by any one team, and it's not really clear which teams are responsible for it. Which teams would get "write" access? I am much more productive with write access. Under these rules, how would I get that?
There are repos like rust-lang/mdbook or rust-lang/rust-enhanced which I manage, but don't have any teams associated with them. Would every repo spawn a new team? How would that work with the teams website? There are 133 repos, and many are not associated with a team.
Thank you for the feedback, @ehuss! I will add clarity around those points today.
Hello again @ehuss!
I've added in some clarification that when I say permissions should be administered through teams I mean the GitHub notion of teams, not the Rust notion of teams. A GitHub team can have access to either one GitHub repo or multiple GitHub repos. Additionally, there can be multiple GitHub teams with access to one or more repos. Some Rust teams - like the Infrastructure team - have multiple GitHub teams associated with them (i.e. Infra and Infra Admins) with different levels of GitHub permissions.
Does that help?
Ah, thanks for the clarification. I'm still a bit uncertain. Will this mean new GitHub teams will need to be created for all the repositories that currently use individual permissions? Will these GitHub teams be driven by rust-lang/team, or is it ad-hoc in the GitHub UI? If a big repo like rust-lang/rust wants to give write access to various people from different teams, would there be a "rust-writers" GitHub team (or would they all go to rust-push with write access? I can't see the permissions for most of these things.). I guess I'm still a bit confused by the phrase "must be administered through GitHub teams" when often the permissions need to be adjusted per-individual. It seems like that would be an explosion of hundreds of GitHub teams to create subsets of rust-lang teams.
Another thing that is not clear to me, is the intent here to manage all permissions via rust-lang/team? Or will there still be ad-hoc permissions managed in the GitHub UI? The RFC says "Rust-Lang GitHub teams are administered through the Team repository.", but AFAIK that is only partially true today (only some GitHub teams are managed that way).
Would it be possible for this RFC to include the moderation team in it? AFAIK, our permissions are currently given on a very ad hoc basis. We are somewhat limited (AIUI) by GitHub's inflexible permission model, but it would still be good to address it here if we're trying to clean up our processes.
Would it be possible for this RFC to include the moderation team in it? AFAIK, our permissions are currently given on a very ad hoc basis. We are somewhat limited (AIUI) by GitHub's inflexible permission model, but it would still be good to address it here if we're trying to clean up our processes.
I don't see a way to make the moderation team work with GitHub permissions. A more feasible approach is probably to create a "moderation platform" where (for example) you copy the link to a comment and a bot will delete it.
Hi @ehuss!
Following up on your questions.
The intent is for all permissions to be managed via rust-lang/team. This makes it much easier to understand who has what permissions and, should someone depart from a team, to remove permissions that are no longer needed or desired. Having this be done in one place would make managing the permissions much more straightforward.
It is true that there are teams managing permissions ad-hoc via the GitHub UI. Should this RFC be adopted, they should move (which may take some time) to managing permissions via rustlang/team.
For repos that currently grant permissions to individuals, rather than teams, they would need to move to managing permissions through teams only. Again, this may take a little bit of time to do and that is ok. My advice to them would be to evaluate the existing teams currently in rust-lang/teams and see if there are any that meet their needs. If there is not an existing team that would work for them, they could choose to create a new team. It is not required that every repo have a dedicated team solely for that repo. If they need one team with certain permissions and another team with different permissions, they would need to create both those teams. This may result in several new teams being administered through rustlang/team - but I still believe this is an improvement over the current ad hoc way we manage permissions now.
Should this RFC be accepted as it is right now, then all repos that are currently tuning permissions in the GitHub UI should switch to using
I don't see a way to make the moderation team work with GitHub permissions.
I think the RFC should address it in some way. In particular, there is a trade off being made here. Moderation could work with GitHub permissions, but it would sacrifice some other property that we care about. I think those kinds of things should be made explicit so that we can be clear on what our shared values are here.
@BurntSushi Would you be able to clarify the moderation team's situation with GitHub for those of us unaware?
Ah sure. Basically, the moderation team is charged with moderating official Rust spaces. That generally includes everything in the rust-lang organization on GitHub. In recent times, the number of repositories in this organization has grown quite a bit. Every so often, the moderators get a report of something happening that could use our attention in one of these repositories. In some of those cases, the moderators do not have access to close/lock/delete issues or issue comments. This means we either can't respond, need someone else to respond on our behalf or need to request ad hoc permission to that repository in order to take action.
Moderation is already an emotionally difficult task, and adding more barriers to doing it kind of sucks. If the bot approach mentioned by @pietroalbini above is easy and it works, then I don't think I'd have many complaints there. But it would definitely need the ability to lock issues, for examples.
Now, thankfully, we don't get such reports very often. At this point in time, they are quite rare. Which is why I'm not particularly keen on pushing strongly for a "fix" to this necessarily at this point in time. For the most part, all I'd really like is to see the moderation team represented in some fashion in this RFC to at least indicate that we've put thought into it. For example, I think one of the reasons why the GitHub permission model doesn't work well here is that there is no way to assign granular permissions to mods, such that giving them the ability to delete/lock issues ends up giving them too much power. Documenting this sort of thing as something that we've given thought to, and the things we are giving up, seems like a good idea to me. Giving a bit more space to future possible solutions to this problem would also be great.
That's understandable. How much of that problem do you think would be solved by having selected trusted moderation team members with sufficient permissions? Like infra-admins except for the mod team. At least then someone on the team is able to handle it.
How much of that problem do you think would be solved by having selected trusted moderation team members with sufficient permissions? Like infra-admins except for the mod team. At least then someone on the team is able to handle it.
I think that's probably the crux of the matter. I actually don't understand all of the technical details here, so maybe @pietroalbini could elaborate a bit more. But I definitely get the high order bit here: we would ideally lock down permissions on repositories as much as possible. Having some trusted members above that is a knock against that strategy.
FWIW, there are only four people on the moderation team right now. So a "subset" might actually be the "whole set" at this point in time. :-) But yes, in principle, I don't have any objections to a subset model from the moderation side.
Unfortunately the permission levels GitHub offers are not really suited for us, and the moderation team would need write or admin access to every repository in the organization to properly do their work (without the need to ping an organization owner).
Giving those permissions across the org would grant access to private repositories containing sensitive information (such as security stuff) and allow to push to any repository that doesn't have branch protection configured (some of them also automatically deploy stuff to production).
It's probably fine to give the moderation team write access to the most active repositories (like rust-lang/rust and rust-lang/rfcs) for now, as those repositories contain only public information and have security measures such as protected branches in place. That would allow them to do most of their work without the need to bring an org owner in the loop, reducing the amount of times they need to ping someone.
Thinking more long-term, if we decide it's worth having the moderation team with write access to every public repositories we'd have to implement automation to manage that, otherwise some sort of moderation platform they can authenticate to would be the best choice.
By the way, here is the privileges needed to do common moderation actions, extracted from the docs:
- Write, Maintainer or Admin required:
- Editing or deleting comments
- Hiding comments
- Locking conversations
- Maintainer or Admin required:
- Limiting interactions in a repository
- Admin required:
- Deleting issues
Thank you for the feedback, everyone, I have updated the RFC based on this feedback and added clarification where needed.
@nellshamrell What are your thoughts on incorporating moderation into this RFC somehow? I left a few comments above, but happy to clarify things further!
@BurntSushi
Thanks for the comment. I believe the best course of action for the moderators team would be to form a GitHub team (managed through the teams repo) that has write access to all of the major repos (there are some private repos - usually security related - that they would not have access to). This seems to fit in well with the guidelines around teams and permissions in the RFC as it is, I'm not sure I see the need to specifically call out the moderation team in the text of the RFC.
Actually...I just re-read all the previous comments and saw the notes about including text about the moderation team to show that we considered it. I'll add in some text right now :)
@nellshamrell Sounds good! Appreciate it! Although it sounds like that is not entirely consistent with @pietroalbini's stance here? Or maybe I'm misunderstanding?
@BurntSushi @nellshamrell well, the current snippet is not wrong, but it doesn't touch much on the last two paragraphs of my comment.
Thank you @pietroalbini!
Responding to the last two paragraphs in your comment:
It's probably fine to give the moderation team write access to the most active repositories (like rust-lang/rust and rust-lang/rfcs) for now, as those repositories contain only public information and have security measures such as protected branches in place. That would allow them to do most of their work without the need to bring an org owner in the loop, reducing the amount of times they need to ping someone.
I feel we can do this through the GitHub teams repo - set up a moderators team and grant it write access to the most active repositories including (but not limited to) rust-lang/rust and rust-lang/rfcs. Is there more I should address re: this in this RFC?
Thinking more long-term, if we decide it's worth having the moderation team with write access to every public repositories we'd have to implement automation to manage that, otherwise some sort of moderation platform they can authenticate to would be the best choice.
I agree on this - but I feel addressing it may be out of scope for this particular RFC. Could this be something that is addressed in a future RFC?
@nellshamrell I'd explain a bit that we can't give access to all repositories to a team, as there are sensitive private repos in the org, and that if a team needs access to everything tooling can be developed to selectively give them the level of access they need.
@pietroalbini @BurntSushi - added in more clarification around the moderation team and GitHub permissions.
Anything blocking this RFC? Or has it been superseded by something else? At a glance I don't see open concerns (but also unsure if there were other discussions elsewhere)
@rust-lang/leadership-council, I have made some significant edits to this RFC to try to bring it up-to-date and ready to merge. A significant change is to drop the requirement that org admins use separate accounts after consultation with the infra team. If you have a chance, I would appreciate if you could review this new revision. I would like to move this towards FCP within a few weeks if there isn't any significant feedback.
We are currently in the process of migrating repository permissions to the team database. Most repositories have some team or group that is obviously associated with them. There are a few outliers, and we are working towards resolving them, by either creating a new team or archiving or moving the repository. rust-lang/rust is going to be one of the most difficult ones to resolve, but I think it is doable. (Some tracking information is here and in open team PRs).
cc @Kobzol Just FYI, I'm not sure if you have seen this, since you have been doing a lot of the work to clean this up.