[ZF] A couple of github issues
Matthew Wilkes
matthew at matthewwilkes.co.uk
Fri Feb 8 15:37:22 UTC 2013
Hi Jim, all,
> Can't admin users also add users to the team, including users who
> weren't already associated with the organization?
That's currently the case and would be true with the method I'm
proposing, yes.
> - There are two teams, an admin team and a dev team. The former
> having Pull, Push and Admin rights, and the later having Push and
> Pull rights.
No, there are three teams. Two are manually managed, these are the two
you mention. There is also what I've been calling a 'stub team' which
nominally has admin rights, but over no repositories. It's a bit counter
intuitive, as GitHub uses bad names for its roles.
Being in the 'Owners' team gives you push, pull and admin on all
repositories, but it ALSO gives you permission to administer teams and
the organisation as a whole.
Being in a team that grants push, pull and admin, however, only grants
you the ability to administer (i.e. delete, move, or add contributors
to) individual named repositories. This is where our trick will happen.
> - The admin team is smaller than the dev team.
The Owners team will stay how it is now, that's right. It will be the
people in charge of processing contributor agreements, for example.
> - The admin team is responsible for creating repos, which they them
> move to the dev team.
Any members of the stub team will be able to create repositories. I'm
suggesting that all the developers are in this stub team as well as the
normal developers team. The script I've written will take care of
managing the stub team, so we never have to touch it.
> - The dev can't delete repositories
That's right. Repositories that developers create automatically get
assigned to the stub team, i.e. giving all those members access to
administer them. However, every time the script runs (it takes a minute
or so) it reassigns the new repository to the developers team, meaning
only the Owners team can delete repositories more than a couple of
minutes after creation.
> - The admin team can't delete repositories they've transfered to the
> dev team.
Nope, they can.
> You seem to be especially concerned about deleting repositories. I
> have to admit that I haven't been as concerned as I probably should
> be. I've gotten a bit spoiled by subversion, which makes it
> impossible to truly delete anything.
The reason for that is that the closest I could get in the GitHub UI was
what we want plus the ability for developers to delete arbitrary
repositories. The idea of this script is to stop that happening.
> In general, the property of subversion that makes it impossible to
> delete data (other than by deleting the repo, which isn't possible by
> committers) has allowed us to be pretty liberal about accepting
> committers.
I think we should both try and prevent deleting of repositories (as this
kills issue trackers and so on too) as well as do backups, as git does
allow contributors to damage the history of a repo.
Just to try and make it clearer, here's the workflow that we'd do for
adding a new contributor and a contributor creating a repo:
New contributor
===============
1. A member of the owners team, such as Tres or Andreas goes to github
2. They go to the repository settings page
3. Then the teams tab
4. They select the developer team
5. They add the new contributor
6. The mr.sisyphus script automatically adds the new contributor to the
CanAdd team
New repo
========
1. A member has been added to the developer team
2. Therefore they're also in the CanAdd team
3. They can select the new repo button on github then choose zope-foundation
4. They create a new repo which GitHub associates with the CanAdd team
5. All developers gain have push, pull and administration rights on that
repo by virtue of being in CanAdd
6. The mr.sisyphus script automatically disassociates that repo with the
CanAdd team and associates it with the developer team
7. The push, pull, admin granted by CanAdd is removed, but all
developers retain push and pull by virtue of being in the developer team.
Matt
More information about the foundation
mailing list