On Sat, Jan 29, 2011 at 5:07 AM, Fabian Groffen <grob...@gentoo.org> wrote: > 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
This is currently up for debate on the internet ;) http://desktoppub.about.com/cs/typespacing/a/onetwospaces.htm > >> 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 > >
