Re: infrastructure team rules
On Tue, 16 Oct 2007, Josip Rodin wrote:
> > 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 :)
Yeah, but replacing one by 0.5 doesn't look like good in the long term. :)
Of course, there are other criterai like the 2 additions every 2 years...
there must be a way to simplify the mathematics. :-)
> > 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).
State so explicitely then, otherwise it looks like all member
additions/removals have to go through this process.
> > 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.
Yeah, I agree but I also like to follow the evolution of teams and I'd
like to be informed of candidacies and additions/rejections. (I already
see every addition through the script that maps Debian groups into Alioth
:)).
There doesn't need to be a flamewar every time just because we publish
such information. People could get used to it.
Anyway, I don't consider this to be required in such a text but it would
still be nice.
>
> > > * 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
I think the count of latent member and conversion into vacated seat is more
work than handling lower and upper bounds of the number of active members.
> 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.
"nobody becomes a candidate" is not really under control... :) and "nobody
perceives this as a problem" is difficult to estimate.
> 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.)
And if they persist and don't improve their skills? :-)
(note that skills judgment are often fairly inaccurate and based on few
former experience)
> 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! :)
Sure, still I'm uneasy about voting something conceptually flawed at this
level. At least the document should somehow recognize this shortcoming and
explain how we're supposed to deal with it if it ever happen. :)
Also, many of your rules depend on the count of active/latent members. Who
is in charge of this count? Where is it published?
> > 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 :)
I can but I'm also uneasy with this. Latent members can be removed from
the team, I don't expect any trouble to add them back if they ever desire
to work again in the team... and letting accounts with unused rights
doesn't sount right. In particular when we speak of DSA and full root
rights on all machines.
18 months is quite a lot. Maybe we should simply let this point open
explaining that each team can have a different policy with latent members
depending on the case and the associated rights.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: