On 28-01-2011 22:11:30 +0100, Tomáš Chvátal wrote: > So draft we would like to have implemented as Glep update is this diff: > http://dev.gentoo.org/~scarabeus/glep-0048.diff > > Please comment and help us improve the "english" of the whole document > so it gets accepted :)
(:Nread http://dev.gentoo.org/~scarabeus/glep-0048.diff) > --- glep-0048.txt 2006-09-05 22:45:04.000000000 +0200 > +++ glep-0048.new.txt 2011-01-25 13:49:38.525343000 +0100 > @@ -34,6 +34,20 @@ > * The QA team's purpose is to provide cross-team assistance in keeping the > tree in a good state. This is done primarily by finding and pointing out > issues to maintainers and, where necessary, taking direct action. > +* The QA team is directed by a lead, chosen yearly by private or > + public election among the members of the team. The QA team lead can > + choose one member as a deputy. The deputy has all of his powers directly > + delegated from the QA team lead and thus his actions and decisions should > + be considered equal to those of the QA team lead. The deputy is directly > + responsible only to the QA team lead. Since QA is getting lots of powers these days, I strongly object to this, see also my comment on becoming a QA member. I suggest the following: The QA lead is yearly elected by the whole dev-community (active developers), same procedure as being used for a council voting. The nomination is also done by developers, but they can only chose from the current QA-members. > +* The QA team lead must approve developers who would like to join the > project. The > + applicant must demonstrate a thorough understanding of the duties he would > like > + to perform. By accepting the applicant the QA team lead will accept > + the responsibility to direct them as part of the team and will be held > + responsible for any action the team member takes on behalf of the QA team. Again, I strongly object to this plan. Instead: To become a QA member, one must be a current developer, for at least 6 months, and one must go through a quiz. The quiz is then evaluated by the QA lead or a replacing member from the QA team, in the same way as recruiters evaluate new developers. The outcome of the evaluation is signed by the QA lead. In case of decline of a new member after the evalation, the QA lead must be able to provide a written argumentation of this decline, which can be requested by said member or by devrel. If providing such argumentation is impossible within a week after evaluation, QA must accept said member to the QA team. > +* Any QA team lead decision can be revoked by a major opposing vote from > + all current QA members. Given the nature of this action new elections > + should be held within 1 month to elect a new QA team lead. > * In case of emergency, or if package maintainers refuse to cooperate, > the QA team may take action themselves to fix the problem. The QA team > does not want to override the maintainer's wishes by default, but only > @@ -50,7 +64,7 @@ > an interim solution and it is expected that a bug will be opened with the > appropriate team to work towards a correct solution. > * In the case of disagreement among QA members the majority of established > - QA members must agree with the action. Some examples of disagreements are: > + QA members must agree with the action. Some examples of disagreements are: sentences are separated by double spaces, nevertheless, this doesn't belong in this patch > whether the percieved problem violates the policy or whether the solution > makes the situation worse. > * In the event that a developer still insists that a package does not break > @@ -59,17 +73,23 @@ > made by the council. > * Just because a particular QA violation has yet to cause an issue does not > change the fact that it is still a QA violation. > -* If a particular developer persistently causes breakage, the QA team > - may request that devrel re-evaluates that developer's commit rights. > - Evidence of past breakages will be presented with this request to devrel. > +* In case a particular developer persistently causes breakage, the QA > + lead may request commit rights of given developer to be suspended by > + the Infra team. Devrel should then proceed to evaluate the situation, by > + finding a compromise or permanently revoking those rights. > +* Should a situation arise where a developer causes breakage to the point > + that it cannot be ascribed to bona-fide mistake, either the QA lead or two > + members of the QA team can require the Infra team to temporarily suspend > + access to said developer, pending analysis of the causes and resolution > + to be provided by the QA team within 14 days of said suspension. > + Resolution for this kind of issue is completely in hands of the QA team > + and only the Gentoo Council can revisit the case. It seems I feel the same as Rich here. I object against this policy, instead: After QA suspension, resolution must go through devrel with QA lead as the party that sets up the argumentation/evidence for said actions, and suggested resolution. However, devrel will evaluate and perform the final statement/actions here. > * The QA team will maintain a list of current "QA Standards" with > explanations > as to why they are problems, and how to fix the problem. The list is not > meant by any means to be a comprehensive document, but rather a dynamic > document that will be updated as new problems are discovered. The QA team > will also do their best to ensure all developer tools are in line with the > current QA standards. > -* In order to join the QA team, you must be a developer for at least 4 months > - and must ask the current lead for approval. > * The QA team will work with Recruiters to keep related documentation and > quizzes up to date, so that up and coming developers will have access to > all > of the necessary information to avoid past problems. -- Fabian Groffen Gentoo on a different level
