[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: infrastructure team rules

On Tue, Oct 16, 2007 at 04:31:32PM +0200, Raphael Hertzog wrote:
> > > 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.

OK. It's actually in the first section in general, but it should be repeated
in the second one, too, and phrased exactly. I intended to leave alone the
existing practices of adding or removing people; this is meant to be a
fallback procedure for when that fails.

> > 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.

I'd still prefer it left to each team's discretion whether to just tell
the DPL or the public. Inquiring developers can always check with the DPL
and he can share that information (it's not really secret).

You can propose the publishing by default as an amendment.

> > > > * 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.

Possibly, but it's a much clearer criterion. If the team doesn't submit a
summary of how many are active and how many are latent in some reasonable
timeframe, the DPL can easily decide that they are all latent. If they say
they have 5 active team members but nobody ever hears about three of them,
that's fairly easy to dispute. But in cases where the team submits faulty
information about the minimal number of members, then we have to have a
procedure to override them. Or if that number changes over time, but that
single person or two team members go AWOL, then we can't intervene without
extra rules about that.

> > 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.

Well, candidates can also be rejected as invalid if the team members have
a consensus that more new people would not contribute to the effort.
They could technically do that by taking them and then immediately declaring
them a bad influence. :)

I'm thinking of this also as a good method to address burnouts - if there
is a reasonable amount of certainty that new people will be able to come
and contribute in two years time, and eventually a reasonable amount of
redundancy in the teams, people won't feel much pressure to work for the
team and won't burn out as before. In real-world circumstances this
decreased incentive would likely be a bad thing, but in Debian we're all
generally intrinsically motivated.

> > 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)

They can still be either rejected again because of a lack of skill, or
in borderline cases removed after some time by consensus.

> > 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. :)

You have a point. :) Maybe a general point about it being necessary for
teams to to revise their membership roster every, say, four years,
and aim to avoid bloat?

> Also, many of your rules depend on the count of active/latent members. Who
> is in charge of this count? Where is it published?

Like it says, these are reported to the DPL or to the developers in general.
The teams submit them, so, a team representative sends them in, I guess.

> > > 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.

Thinking about that, that is indeed supposed to be done at each team's
discretion, so it should be covered when the first issue above is fixed.

The rules are mainly supposed to help detect latent members, and avoid
members cheating on roll calls, but what the teams do with long-latent
members is their business.

     2. That which causes joy or happiness.

Reply to: