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

infrastructure team procedures (fourth edit)


Take four, just added the rule explicitly handling the case where DPL and
team disagree on which members are latent.

I'm hoping this is the final one before we go to vote.


This originates from this debian-project mailing list discussions at

Proposed general resolution - 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.
* Infrastructure teams are groups of developers who deal with project
  infrastructure and have access to resources in ways other than
  the standard practice of uploading Debian packages.
* Infrastructure teams have an ongoing responsibility to maintain a level
  of service that is generally acceptable to the developer body.
* It is necessary for infrastructure teams to add new members when
  old members depart from the team or when circumstances prevent
  existing members from contributing to the team effort.
* 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.
* Intervention by Debian Project Leaders is not a practical solution
  to resolve issues with infrastructure teams.
* To avoid issues with teams which are not proactive with regard to adding
  or removing members, it is necessary to define a modicum of procedure
  for how developers can join the infrastructure teams.
* The primary goal of this additional set of procedures is to improve
  the teams and to maintain fairness towards both the teams and
  the developer body.

Debian developers resolve the following:

* Whether a team in Debian constitutes an infrastructure team is
  decided by the Debian Project Leader.
* Infrastructure teams are encouraged to continue adding or removing
  members on their own accord.
* Existing team members who don't sufficiently contribute to the team
  effort have to be marked by the rest of the team as latent.
  The basic requirements for this are:
  * Latent team members can be unmarked as such four months after marking,
    provided they become active again.
  * Team decisions regarding latent team members have to be communicated to
    the Debian Project Leader or to the developer body.
  * The Debian Project Leader can require the team to reconsider decisions
    on which members are latent.
* Developers can nominate themselves for membership in infrastructure
  teams. These nominations are communicated to the whole team and they
  can be made every four months.
* Infrastructure teams have to decide to accept or reject candidates who
  nominated themselves. The basic requirements are:
  * Candidates for team membership have to demonstrate some minimal
    existing competence in the area. It is recommended for candidates
    to have helped the team in some way in the past.
  * Candidates for team membership have to pledge availability to the team.
    It is recommended that candidates pledge no less than twelve months of
  * Candidates for team membership have to promise to make every reasonable
    effort to work with the existing team.
  * Teams can require any number of other qualities from the candidates,
    as determined by their specific circumstances and team consensus.
  * Team decisions regarding validity of candidates have to be communicated
    to the Debian Project Leader or to the developer body.
    Each decision also has to be communicated to the candidate in question.
* If a new member is not willing to work productively in a team,
  or if they are otherwise a destructive influence in the team,
  the previous team members can and should promptly remove them.
* Removed members of teams can't nominate themselves for membership in
  the same team for the period of twelve months since their last removal.
* Infrastructure teams should ensure that they don't have too few members.
  The basic requirements for this are:
  * Whenever the team has had to mark two latent members, and has not
    had any new members added during the period of two years since
    the marking, they have to accept at least one new valid candidate.
  * Each infrastructure team has to accept at least two valid candidates
    every two years.
* Infrastructure teams should ensure that they don't have too many members.
  The basic requirements for this are:
  * Each infrastructure team should review their membership roster
    every four years. During the review, the team is encouraged to remove
    members who have been latent for very long periods of time.
  * If the team has sufficient active members without having fulfilled
    the requirement of adding two new valid candidates every two years,
    and if the Debian Project Leader agrees, they can forgo that rule.
* If the team fails to make any additions or removals as described above,
  the Debian Project Leader is allowed to do the minimum required additions
  instead. The Leader decides the validity of candidates according to
  the procedure described above, adds new team members and communicates
  that decision to the developer body. Such new team members can also be
  rescinded by the Debian Project Leader, unless they get confirmed
  as valid and accepted into the team by team consensus.
* With regard to communication and documentation, infrastructure teams
  should try to work under the guidelines laid out in
  the Debian Developer's Reference.


     2. That which causes joy or happiness.

Reply to: