Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process for moving projects to ocaml-community #11

Open
Drup opened this issue Aug 17, 2018 · 8 comments
Open

Process for moving projects to ocaml-community #11

Drup opened this issue Aug 17, 2018 · 8 comments

Comments

@Drup
Copy link
Member

Drup commented Aug 17, 2018

The current process seems to be to give rights to anyone who wants to move a project over, and since you need admin rights to transfer a project, that's what they get.

Needless to say that this is not going to fly for long. :)

I propose to distinguish various group of people:

  1. Admins that can do anything,
  2. People that want to maintain/contribute to specific packages, but are not (yet!) people you would trust with life&death power over the entire org. This would be for people who are frequent community member and maintain several packages
  3. Maintainer of a single package, such as newly migrated packages. Those don't have to be org members and can simply be given rights to that package.

When migrating a repository, the person who wants to migrate would transfer the repository to one of the admins, who would then move it to the organization. That person would then be given rights to the specific packages, or added as org member in group 2., as deemed appropriate.

Thoughts ?

@pmetzger
Copy link
Member

This seems like an entirely reasonable segregation of duties. So far I haven't been averse to giving organization membership to people requesting to move things because everyone involved has been someone well known in the community, but that will inevitably change. Some set of rules seems necessary, and your proposal feels like a good one.

I'd like to hear what other people think, but presuming there is consensus, I think we should go with this general idea.

One modification I would note is we need a category 0. for the organization owners, which is a role GitHub requires. There need to be several, for redundancy, and such people need to be well trusted. I gave @bluddy an owner tag temporarily so that someone could recover things in case I got hit by a bus, but we should figure out more permanently which three people have the "master keys".

@pmetzger
Copy link
Member

FYI, we probably need to figure out how to map 1, 2, and 3 to various github settings to implement them.

@Drup
Copy link
Member Author

Drup commented Aug 17, 2018

The mapping is trivial. It already correspond to fairly obvious github roles.

@pmetzger
Copy link
Member

Well, so there are only two roles that the system provides, "owner" and "member", plus it allows us to set outside collaborators for particular repositories. It doesn't seem to allow assignment of differing levels of ability to members except by assigning them to teams.

@Drup
Copy link
Member Author

Drup commented Sep 21, 2018

Small brush up of the roles. Adminstrators should now be able to fully migrate a repository from start to finish, and should be able to add other adminstrators and external contributors.

@pmetzger
Copy link
Member

So how should we change the language in the README etc?

@c-cube
Copy link
Member

c-cube commented Sep 11, 2019

is there a setting to allow people to transfer to the organization directly, and then have someone here (and admin, or maybe just a member) approve the transfer request? It seems weird that to transfer to individual accounts you don't need any right, but that for organization it's so complicated.

@Drup
Copy link
Member Author

Drup commented Sep 12, 2019

As far as I know, there is no such thing, no :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants