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

Re: Proposal - Project infrastructure team procedures



On 30/04/08 at 00:53 +0200, Josip Rodin wrote:
> On Sat, Apr 19, 2008 at 08:24:25PM +0200, Lucas Nussbaum wrote:
> > > Debian developers acknowledge the following:
> > > 
> > > * The Debian Project infrastructure is run by people who volunteer their
> > >   time and knowledge in a good-faith effort to help the Debian Project.
> > > * The practice of existing members of a team having people join in and help,
> > >   and new people volunteering without a particularly formal procedure, is
> > >   the original and natural way of changing team membership.
> > > * Training of and otherwise working with new team members requires
> > >   additional effort from existing team members, so care should be taken
> > >   to avoid having too much team effort spent on unnecessary new members
> > >   or new members who would not reciprocate the effort.
> > > * Infrastructure teams have to be stable, but they don't have to calcify.
> > 
> > everything stays the same so far.
> > 
> > Debian developers resolve the following:
> > 
> > * Infrastructure teams are encouraged to adapt their sizes to their workloads,
> >   to ensure that they don't block or slow down the work of other Debian
> >   contributors.
> > 
> > * Existing team members who don't sufficiently contribute to the team
> >   effort should be removed from the team.
> > 
> > * When an infrastructure team slows down or blocks the work of other Debian
> >   contributors without taking the necessary actions, the Debian Project Leader
> >   is empowered to add or remove members to/from the team using delegations.
> >   When possible, this should be done by consulting the team first.
> > -----
> > 
> > (suggestions of improvements are welcomed for the draft)
> 
> Do you think that this will get a modicum of seconds?

I haven't asked for seconds, but several people contacted me, saying
they would second it. So yes.

> If so, do you think
> that that will happen primarily because the text is shorter, or primarily
> because it it's simple (it straightforwardly legitimizes delegations),
> or something else?

My personal state of mind is:
- yes, we have a problem with infrastructure teams, and we need to
  address it.
- I fear that your proposal is too complicated, and that, if we have the
  choice between your proposal and FD, your proposal might lose. This
  could then be interpreted as either:
  (A) people thought that we have a problem, but your proposal wasn't the
      best way to address it
  (B) people thought that we don't have a problem
  The main goal of my proposal is to allow people to choose between (A)
  and (B) explicitely.

> Maybe my timing was bad, but no seconds, no objections, and one reply -
> that sounds like we have a showstopper problem with motivating people to
> do *anything* about this, and I'm thinking that we need to understand
> that before we think about more wording :)
> 
> Hmm. In the last few weeks, we've seen a few DPL decisions go completely
> uncontested. Three people replied positively to Sam's decision on -devel,
> and nothing else. Is that indicative enough?

I'm not sure. OK, everybody seem to agree that the DPL is already
empowered to add people to infrastructure teams. And the new members are
clearly delegates. But it is still unclear whether the previous members
are also delegates, and could be undelegated.

On one hand, the recent delegations made this matter less urgent, so we
don't need to vote on that now. On the other hand, the fact that there's
no urgent situation might mean that it's the best time to discuss (and
vote) on this.
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |


Reply to: