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

Re: Proposal - Project infrastructure team procedures



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.
> 
> > * Ad hoc intervention by Debian Project Leaders is not a practical solution
> >   to resolve issues with infrastructure teams. The process of delegation
> >   and undelegation has not historically proven itself as an effective
> >   mechanism for improving infrastructure teams. There has also been
> >   ambiguity on the constitutional position of infrastructure teams as such,
> >   particularly those that predate it.
> > * To avoid issues with teams which are not proactive with regard to adding
> >   or removing members, and to address aforementioned inadequacies and
> >   ambiguities, it is necessary to define a modicum of procedure for how
> >   developers can join the infrastructure teams. It is also necessary to
> >   properly engage the Debian Project Leader with the functioning of
> >   the infrastructure teams.
> 
> those two points are removed.
> 
> 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)

I'm not sure if you phrased that last sentence correctly... what does
the 'without taking the necessary actions' part mean?

Did you mean to say s/without/by not/?

Anyway, I'd agree to stripping down the detailed procedure, but you still
shouldn't strip these two ideas:
* the definition of infrastructure teams - add one clause saying that
  the DPL decides which they are, so that we preclude any discussion
  of the lack of applicability
* the mention of communication - add one clause saying that relevant
  membership decisions have to be promptly and properly communicated
  between the DPL and the teams, so that we don't have a lack of
  transparency. I'd also charge the DPL to eventually inform the developer
  body about the gist of all such matters.

-- 
     2. That which causes joy or happiness.


Reply to: