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:
-----
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, 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.
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
availability.
* 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 that has lost two or more members to latency
or retirement, but has not added any new members according to the rule
above, needs to proceed with adding at least one new member as soon
as valid candidates become available.
* 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.
Attachment:
signature.asc
Description: Digital signature