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

Re: Proposal - Project infrastructure team procedures

On 17/04/08 at 21:34 +0200, Josip Rodin wrote:
> Hi,
> This originates from the debian-project mailing list discussions at
> http://lists.debian.org/debian-project/2007/06/msg00020.html
> http://lists.debian.org/debian-project/2007/10/msg00064.html
> http://lists.debian.org/debian-project/2007/10/msg00142.html
> http://lists.debian.org/debian-project/2008/04/msg00042.html
> I've cleared up the remaining few issues reported against the fifth edit,
> and I am now looking for seconds at debian-vote to the following proposal:


I'm still not convinced that we need all that bureaucracy. Here is a
draft amemdment. If we vote on both your proposal and this admendment,
could you tell me why I should rank your proposal higher than the

Draft amendment - Project infrastructure team procedures

> 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

* 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)
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Reply to: