Re: infrastructure team rules
On Tue, 16 Oct 2007, Josip Rodin wrote:
> I pondered a bit about that old subthread about infrastructure teams the
> other day... what follows is what I was intending to post to debian-vote.
> But I'll post it to debian-project first, hoping that people improve it
> before we get to the stage where everyone posts GPG-signed messages :)
Good initiative. You might take some inspiration in the "Team guidelines"
that I drafted earlier this year:
http://wiki.debian.org/Teams/Guidelines
> * The practice of existing members of a team finding people to join in
> and help is the original and natural way of changing team membership.
Yeah, although in practice it's a mix of "people reply to help request"
and "people spontaneously volunteer and ask what they can do to help".
Maybe you can make that clearer.
> * Infrastructure teams have to decide to mark old members who don't
> sufficiently contribute to the team effort as latent.
> * Latent team members count for 50% of an empty seat in the team.
> They can be unmarked as such every four months.
> * Team decisions regarding latent team members have to be communicated to
> the Debian Project Leader or to the developers in general.
The concept of "latent" team member is a somewhat strange. I agree
something like that is needed because one can't be expected to be fully
invested in a team 100% of the time. But your mathematics are strange, why
would a latent member count only for 50% of a "empty seat" ?
> * Developers can nominate themselves for membership in infrastructure
> teams every four months.
> * Candidates for team membership have to demonstrate some minimal existing
> competence in the area.
> * Candidates for team membership have to pledge a minimum 18 months
> availability to the team. Teams can vary this time period by 6 months,
> as determined by their specific circumstances and team consensus.
> * Infrastructure teams can decide to accept any number of candidates
> after a nomination round.
I think teams should be free to coopt new members at any time as usual,
but additionally there would be those nominations rounds so that
candidates have an occasion to get a decision and a rationale (at least
they can know what they were doing wrong and can try to improve) instead
of the usual lack of answer.
> * Team decisions regarding validity of candidates have to be communicated to
> the Debian Project Leader or to the developers in general.
Teams have to communicate their decisions and the associated rationale to
the candidates and to the DPL. The decisions (a simple yes/no/not needed)
have to be communicated to the developers at large (on debian-devel) and
the candidate can follow-up with the rationale he has been given if he
wishes so.
> * Each infrastructure team has to populate every full vacated seat
> (caused by two latent members) every two years.
> * Each infrastructure team has to accept at least two valid candidates
> every two years.
There must be some limit somewhere. I agree new blood is good and needed
but you can't expand the team indefinitely.
Maybe there should be a minimal size for each team and that minimal size
must always be met and comprises only active members. And the upper limit
would be 2.5 × the minimal size (including latent members).
Latent members that have been latent for 18 months have to be removed.
> * New members of teams have to promise to make every reasonable effort
> to work with the existing team.
> * The previous team members reserve the right to promptly remove new members
> who are not willing to work productively in a team or who are otherwise
> a destructive influence in the team.
> * Removed members of teams can not nominate themselves for membership in
> the same team for the period of twelve months since their last removal.
Otherwise it looks sane in general and I like the fact that it doesn't
replace completely the current practice but try to address its
shortcomings only.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: