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.
Description: Digital signature