Re: infrastructure team rules
[will check the wiki page, but I deleted the quote by mistake :)]
On Tue, Oct 16, 2007 at 09:13:38AM +0200, Raphael Hertzog wrote:
> > * 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" ?
That's simply for later calculation of how much they have to repopulate :)
> 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.
Yes, that's the point. This would define this procedure, but nothing
prevents teams from acting otherwise (in good faith).
> > * 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.
Oh, yes, to the candidates too, I missed that.
But I don't think we want to force everything to be published to the public
list. If someone wants to complain about their rejection, they should start
in the same venue and work their way upwards - with the team, with the
leader, then the developer body (via the -private list for example), and
only if all of these fail, the general public. We don't want instant
flamewars for every rejection.
> > * 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).
I actually thought about it, but decided not to do so because it leads to
too much micromanagement :) The point of having an ever-growing policy is
to address the ever-growing amount of work that makes people go latent
more and more. But it's also slowly ever-growing, mind.
If everyone in an old team stays active, and there appear two valid
candidacies every two years, they have to accept those two people.
That's not a lot.
If an old team loses two members to inactivity, they have to replace
those two with one new one, and also accept another valid candidate
in the same time period. That's not a lot - perhaps even too little
given the loss.
If an old team is already large (say, 8 to 10 people), and gets two
latent members, but nobody perceives this as a problem, nobody becomes
a candidate and no addition is made.
If the same team from the last example has a couple of annoying wannabes
who want to take advantage of rules, they can be rejected as invalid
candidates (because of lack of expertise or lack of good faith), or
they go away before two years lapse, and there is no problem.
(If they persist after two years, and improve their skills, then they
should be given a chance. They can still be thrown out post res, if
they continue to piss everyone off.)
If a team continues to be very active for a period of ten years, and they
have an abundance of valid candidates to choose from, they get to expand in
size by ten - but a) I'd like to see that team! :) b) if they get unwieldy,
they can always branch out, such as have a team with tiers, and have the DPL
unmark some of the tiers as infrastructure teams, so that the problematic
rules don't apply (but general stance still does). Or we revise the rules
in five years. That's a lot of time in our universe! :)
> Latent members that have been latent for 18 months have to be removed.
I don't agree with that - they don't hurt, they should stay, maybe they
reactivate at some point. Or just do a thing or two every year. Or just
act as a backup in case everyone else suddenly goes inactive. I trust you
can see my point here :)
> 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.
Exactly. The current system by and large actually works out in the end, in
most cases. We just have to file off the rough edges and prevent more rough
edges from appearing.
--
2. That which causes joy or happiness.
Reply to: