| 1 |
On Sun, Jan 19, 2014 at 5:15 AM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> |
| 3 |
> I think that the current version is just fine. QA should take care of |
| 4 |
> the tree, and any developer issues should be handled by Comrel. |
| 5 |
> |
| 6 |
|
| 7 |
Tend to agree. Are there situations where the current policy has been |
| 8 |
inadequate? I am fine with giving QA teeth, but if they effectively |
| 9 |
have them already it isn't so much of a problem. |
| 10 |
|
| 11 |
If we do make a change I suggest changing: |
| 12 |
+* Any QA team lead decision can be revoked by major opposing vote |
| 13 |
from all current QA members. Given the nature of this action new |
| 14 |
elections should be held within 1 month to elect a new QA team lead. |
| 15 |
|
| 16 |
I think there are better ways of dealing with an out-of-control QA |
| 17 |
lead. First, Council should just be able to remove them if this is |
| 18 |
the case. Second, Council did confirm the QA lead, and the Council |
| 19 |
didn't confirm any of the other QA members, so in the event of a |
| 20 |
disagreement do we really want to back the others? Third, if the QA |
| 21 |
lead can add/remove members from the team at-will, then they really |
| 22 |
aren't any kind of independent check on authority. I think it is |
| 23 |
healthier if the team works more like a team and less like a |
| 24 |
self-oversight board, and in the truly exceptional case where |
| 25 |
oversight is needed, well, we have the Council already. |
| 26 |
|
| 27 |
Rich |
Archives