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

infrastructure team procedures (fifth edit)


This is take five - Stephen Gran sent me several suggestions for rewording
and stating things explicitly in private mail. I've spelled a few more
things out, and reordered some of the text so that it's clearer what's going
on. I've also moved some paragraphs from the acknowledgement section to
the resolution section so that it's clear that they carry more weight than
a mere introduction.

I'm no longer 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.
* 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.
* 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, 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.

Debian developers resolve the following:

* The primary goals of this additional set of procedures are:
  * to improve the infrastructure teams
  * to maintain fairness towards both the teams and the developer body
  * to improve the relationship between the Debian Project Leader
    and the infrastructure teams
* Should there be any ambiguity with a procedure, the people interpreting
  them are tasked with making sure that the general spirit of this
  resolution takes precedence over the exact letter of the rules,
  in the absence of a new resolution clarifying the ambiguity.
* The set of procedures laid out below is not meant to be completely
  inclusive, both because we want to fix what is broken and keep everything
  else as it is, and because this is the first resolution on the matter.

* 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.
* Whether a team in Debian constitutes an infrastructure team is
  decided by the Debian Project Leader.
* 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.
* 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.
* 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.

* 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. These qualities have
    to be determined by 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.
* These decisions and communications have to be done before the end of
  the nomination round (i.e. within four months).

* 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:
  * Infrastructure teams need to have enough active members to carry out
    their responsibilities.
  * Each infrastructure team has to accept at least two valid candidates
    every two years.
  * Each infrastructure team has not added any new members according to
    the rule above, but has had to mark at least two members as latent
    in the same period, has to accept at least one new valid candidate.

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

* The Debian Project Leader has to evaluate team decisions on which
  members are latent, which members are added, and which members are
  removed, all according to the procedures described above.
* The Leader can require the team to reconsider these decisions and require
  additional explanations, particularly in the cases where the appropriate
  time constraints aren't respected.

* If the team fails to make any additions or removals according to the
  procedures described above, the Debian Project Leader can make
  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, in particular the procedures on how to handle bug reports, how
  to record changes, how to participate in mailing list discussions, and in
  general how to collaborate with other developers.


     2. That which causes joy or happiness.

Reply to: