| 1 |
* Diego Elio Pettenò <flameeyes@×××××.com>: |
| 2 |
|
| 3 |
The current "QA team's role and purpose" (GLEP 48) always talks about |
| 4 |
the QA TEAM -- and I think this is good: QA needs a leader who can build |
| 5 |
a team IMHO. |
| 6 |
(Only once the lead is mentioned: New team members have to be approved |
| 7 |
by the lead.) |
| 8 |
|
| 9 |
> +* The QA team is directed by a lead, chosen yearly by private or |
| 10 |
> + public election among the members of the team. The QA team lead can |
| 11 |
> + choose one member as deputy, whose decisions should be considered as |
| 12 |
> + they were made by the lead in case he (or she) is not available. |
| 13 |
|
| 14 |
"[Projects] may have one or many leads, and the leads are selected by |
| 15 |
the members of the project. This selection must occur at least once |
| 16 |
every 12 months, and may occur at any time." [GLEP 39] |
| 17 |
|
| 18 |
Why did you drop the "any time" rule? |
| 19 |
"not available" -- within two hours, two days or two weeks, or devaway |
| 20 |
or until the end of the fixed one-year-term (instead of running a new |
| 21 |
election)? Or: How can the other teams know that the deputy takes the |
| 22 |
lead role? |
| 23 |
|
| 24 |
> +* The QA team lead approves applicant developers as team members. By |
| 25 |
> + doing this he (or she) will accept to direct them as part of the team |
| 26 |
> + and will be held responsible for their actions, as taken on behalf |
| 27 |
> + of the QA team. |
| 28 |
|
| 29 |
Here you wanted to drop the developer-for-four-months requirement. Ok. |
| 30 |
|
| 31 |
"the lead will be held responsible for their actions" |
| 32 |
I think this can be dropped: the team is responsible for its actions anyway |
| 33 |
(whatever that means) and the lead will be replaced soon too. |
| 34 |
|
| 35 |
> -* If a particular developer persistently causes breakage, the QA team |
| 36 |
> - may request that devrel re-evaluates that developer's commit rights. |
| 37 |
> - Evidence of past breakages will be presented with this request to devrel. |
| 38 |
> +* In case a particular developer persistently causes breakage, the QA |
| 39 |
> + lead may request his (or her) commit rights to be suspended. Devrel |
| 40 |
> + should then proceed to evalute the situation, by finding a |
| 41 |
> + compromise or definitely revoking those rights. |
| 42 |
|
| 43 |
What do you mean by "Devrel should then proceed to evalute the |
| 44 |
situation, by finding a compromise or definitely revoking those |
| 45 |
rights"? |
| 46 |
Two points: |
| 47 |
- QA specifies how Devrel is supposed to work in this case? |
| 48 |
- Compromise between the particular developer and QA? |
| 49 |
So if the QA team doesn't want to find a compromise, the developer |
| 50 |
will have his commit bit definitely revoked? |
| 51 |
|
| 52 |
> +* Should a situation arise where a developer causes breakage to the |
| 53 |
> + point it cannot be ascribed to bona-fide mistake, either the lead or |
| 54 |
|
| 55 |
"be ascribed to bona-fide mistake" -- |
| 56 |
how can we evaluate this? |
| 57 |
|
| 58 |
Do you think this rule would have been used in the past? |
| 59 |
|
| 60 |
> + two members of the QA team can require the Infra team to temporarily |
| 61 |
> + suspend access to said developer, pending analysis of the causes and |
| 62 |
> + resolution to be provided within a week of said suspension. |
| 63 |
|
| 64 |
And then? Appeal to the council? Will unjustified decisions by the QA |
| 65 |
team lead or the two members be investigated too? |
| 66 |
-- |
| 67 |
Regards Torsten |
Archives