Squeak VM vouching scheme
Last updated at 5:16 pm UTC on 16 January 2006
This is all moot since we moved from SourceForge to our own SubVersion repository. Do we want to provide a similar setup there?
We use a vouching model to control who gets commit rights on SF.
- The primary port maintainers all have commit rights by default.
- All others get vouches from them directly or indirectly from someone that already has such a vouch.
- When one of the Squeak VM developers gives a vouch to someone new two things must be done:
- One of the SF admins must make the necessary modifications at SF.
- The page Squeak VM developers should be updated.
Further explanation of the vouch model
Since we can't know every last person we have to put our trust in the
persons we do know and trust enough to have write access. This vouch implies a certain indirect responsibility - in other words, if the person who you vouched for misbehaves you are responsible for:
- Making sure he or she behaves according to the policies.
- Cleaning up for this person's mess in case he or she doesn't.
You can remove your vouch if you no longer trust this person's ability to handle things properly. A developer without a vouch will be automatically removed from the list. So will any "disconnected" networks of vouches. In even other words, the vouches represent "pointers to developers" and anyone who isn't pointed to will be garbage collected ;-) The roots of that system are the primary developers for each port.
Ok, so what do I do then to get access?
For anyone who wants to join the Squeak VM developers he or she needs a vouch by an existing developer. The existing developer is responsible for explaining the policies and rules. The existing developer can also ask one of the people having vouched for him to give the new developer write access.
Once you're at the roots of that system you will end up with a project admin who will be able to make the necessary modifications at SF.
It also means that people who have been vouched for by project admins have a "shorter path" to getting new people in than developers who are only connected through "three indirect links" (of course, if you can get a project admin to vouch for you directly, that's the easiest way).
This models the trust level which weakens with any new indirection. It also means that any developer shoud try to get a vouch from the roots, e.g., proove to one the primary maintainers that he or she is a worthwhile addition to the Squeak VMDev community.
This is the original post by Andreas Raab proposing the model:
Since it seems that we're really making some progress with the VM stuff at source forge I'd like to raise one additional issue. It's the
question who should be a developer (e.g., have commit rights) and how
some person could become one. Looking at the list we have 18 developers
some of which I don't even know. This will be an ongoing problem and I'd
like to make a small proposal here:
Since we can't know every last person we have to put our trust in the
persons we do know and trust enough to have write access. I'd like to
see a "vouching" scheme where any developer in the Squeak project needs
a vouch by at least one other developer. This vouch implies a certain
indirect responsibility - in other words, if the person who you vouched
for misbehaves you are responsible for a) making sure he or she behaves
according to the policies and b) cleaning up for this person's mess in
case he or she doesn't. You can remove your vouch if you no longer trust
this person's ability to handle things properly. A developer without a
vouch will be automatically removed from the list. So will any
"disconnected" networks of vouches. In even other words, the vouches
represent "pointers to developers" and anyone who isn't pointed to will
be garbage collected ;-) The roots of that system are the primary
developers for each port.
For anyone who wants to join the developers he or she needs a vouch by
an existing developer. The existing developer is responsible for
explaining the policies and rules on VMDev. The existing developer can
also ask one of the people having vouched for him to give the new
developer write access. Once you're at the roots of that system you will
end up with a project admin who will be able to make the necessary
modifications. It also means that people who have been vouched for by
project admins have a "shorter path" to getting new people in than
developers who are only connected through "three indirect links" (of
course, if you can get a project admin to vouch for you directly, that's
the easiest way). This models the trust level which weakens with any new
indirection. It also means that any developer shoud try to get a vouch
from the roots, e.g., proove to one the primary maintainers that he or
she is a worthwhile addition to the Squeak VMDev community.
Here are the people on the developers list I can vouch for:
* Bert Freudenberg
* Cees de Groot
* G�ran Hultgren
* Ian Piumarta
* John McIntosh
* Lex Spoon
* Michael R�ger
* Tim Rowledge
Rob Withers
[Note that I have included the primary developers (roots) to indicate
that my trust in their abilities].
What do you think?
