infrastructure team procedures (fourth edit)
Hi,
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
http://lists.debian.org/debian-project/2007/06/msg00020.html
http://lists.debian.org/debian-project/2007/10/msg00064.html
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
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 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: