| 1 |
On 11/13/13 6:47 AM, Rich Freeman wrote: |
| 2 |
> I would like to propose some changes to GLEP-48 as discussed in the |
| 3 |
> most recent Council meeting. |
| 4 |
|
| 5 |
Thank you for working on this. |
| 6 |
|
| 7 |
> Here is my personal sense of the problems I've seen: |
| 8 |
> 1. Complaints that QA is overbearing by devs in general. |
| 9 |
|
| 10 |
My personal experience doesn't confirm this, but I do acknowledge that |
| 11 |
this may be the case and that sometimes there is an impression of that |
| 12 |
or more. |
| 13 |
|
| 14 |
> 2. Complaints that QA is ignored. |
| 15 |
|
| 16 |
+1 |
| 17 |
|
| 18 |
> 3. Complaints that QA has not been backed up by the Council, being |
| 19 |
> reversed on appeal excessively. |
| 20 |
|
| 21 |
I'm not aware of almost any reversals - still, I do agree that sounds |
| 22 |
like a problem. |
| 23 |
|
| 24 |
> 4. Complaints that QA is too closed. |
| 25 |
|
| 26 |
+1 |
| 27 |
|
| 28 |
> I think the solution is therefore to give QA a mandate. The council |
| 29 |
> has a mandate because it is elected by the developer community and is |
| 30 |
> accountable to them annually. As such the council can confirm the |
| 31 |
> lead of QA and confer their mandate upon them. In doing so the |
| 32 |
> council and QA will be structurally aligned, and the council can be |
| 33 |
> held accountable for failing to properly support the lead that they |
| 34 |
> themselves confirmed. That said, the team should be self-governing to |
| 35 |
> the greatest extent possible so the team will be given the opportunity |
| 36 |
> of recommending a lead to the council. |
| 37 |
|
| 38 |
I'm in favor of giving this a try. |
| 39 |
|
| 40 |
Note, applies to all drafts: what if the council doesn't want to confirm |
| 41 |
the elected lead? Another election? Council appoints their own guy? |
| 42 |
|
| 43 |
Are there any protections about being simultaneously a Council member |
| 44 |
and QA team lead/deputy? |
| 45 |
|
| 46 |
If there is a conflict between a developer and QA that gets escalated to |
| 47 |
Comrel and the developer appeals to Council, this appeal process will |
| 48 |
still work - right? |
| 49 |
|
| 50 |
> Some discussion came up in the council meeting regarding activities |
| 51 |
> like running the tinderbox, filing bugs, etc. I think the |
| 52 |
> policy/enforcement side of QA needs to have a mandate as it exercises |
| 53 |
> power over all developers. However, the more "informational/advisory" |
| 54 |
> side of QA does not need one. I see things like running a tinderbox |
| 55 |
> as being a more traditional Gentoo project which does not need so much |
| 56 |
> oversight - it might be a QA subproject but I think anybody who wants |
| 57 |
> to provide helpful information to developers should be encouraged to |
| 58 |
> do so. Any bugs they log would only have authority insofar as they |
| 59 |
> align with the policy/enforcement side of QA (however, even when not |
| 60 |
> required by policy developers are always encouraged to do what they |
| 61 |
> can to fix bugs). |
| 62 |
|
| 63 |
+1 we could have more tinderboxes and tinderbox more things. |
| 64 |
|
| 65 |
Paweł |
Archives