1 |
On Thu, 2006-03-02 at 09:01 +0000, Stuart Herbert wrote: |
2 |
[snip] |
3 |
> * There's nothing in this policy about end users. If this QA team is |
4 |
> not *focused* on delivering benefit to end users, then (as has |
5 |
> happened this week) it becomes a self-serving team, focused instead on |
6 |
> what can only be described as a destructive path. No-one benefits |
7 |
> from that, no-one at all. |
8 |
> |
9 |
> * The QA team is asking for more than it needs to perform its role. |
10 |
> The UNIX principle is that of "least privilege". Donnie's already |
11 |
> pointed out that FreeBSD is able to conduct effective QA without the |
12 |
> extra power that the QA team is continuing to ask for. |
13 |
So I see two scenarios for that: |
14 |
- A QA team with a purely advisory function, helping with communication. |
15 |
pro: no big policy changes etc. |
16 |
con: teethless QA may get ignored |
17 |
|
18 |
- A QA team with limited executive power, fixing bugs as they are found |
19 |
pro: fast turnaround times on bugs |
20 |
con: resistance from developers |
21 |
|
22 |
The second approach needs to be carefully implemented, people need to |
23 |
have trust in the QA team to empower them. |
24 |
|
25 |
> * There is no proposal for a process to formulate, and gain wide |
26 |
> approval for new QA standards. This week, there's been an example of |
27 |
> the QA team documenting a QA standard *after* a bug was raised about a |
28 |
> QA violation ... and then that document being used as if that |
29 |
> particular QA standard had always been in the document. |
30 |
Communications issue. This thread should help fix the policies for that I hope. |
31 |
|
32 |
> Mistakes will always be made by all developers, and good QA is |
33 |
> essential to Gentoo's future. We need a good QA team for Gentoo. Not |
34 |
> having a QA team is, in my eyes, not an option at all. |
35 |
Fully agreed. |
36 |
> But, as this week has shown, QA members are also developers (and |
37 |
> human), and are just as capable of making mistakes as anyone else. |
38 |
Obviously :-) |
39 |
> We need a quality assurance team that conducts all its activities in a |
40 |
> quality manner. I'm not just talking about personal behaviour, or of |
41 |
> any one individual. The way *everything* is done must be in a quality |
42 |
> manner. That should mean a high quality process for creating QA |
43 |
> standards, having them approved, and making sure developers know what |
44 |
> changes are coming and when. That should mean high quality automated |
45 |
> tools that cope with the real world, not some ivory tower that has no |
46 |
> real pay-off for users. It should mean an interpretation and |
47 |
> application of QA standards that is focused on how it improves matters |
48 |
> for real users - and not a "tick in a box" QA approach. It should |
49 |
> mean a team of educators, not a team out to bully with the mandate to |
50 |
> do so. |
51 |
That sounds like a mission statement and should be part of QA policy |
52 |
|
53 |
> In twelve years of being a professional software engineer, I've never |
54 |
> seen a successful QA team that didn't match that description above. |
55 |
> |
56 |
> Mark, in the discussions about the QA policy, your fallback |
57 |
> justification always seems to be "Trust us". I think this week's |
58 |
> events have put a big dent in the credibility of that argument, if not |
59 |
> holed it below the water line. If the QA team followed processes |
60 |
> similar to what I've described above, I believe that this week's |
61 |
> events wouldn't have happened. What started off as a worthy piece of |
62 |
> QA work, which I'm sure has fixed many real problems for users, |
63 |
> degenerated into something altogether unpleasant and unnecessary for |
64 |
> all involved. We've all gotten a week older and a week greyer out of |
65 |
> this. Have we fixed any real problems that stop our users installing |
66 |
> and running Gentoo? No, we haven't. I hope we can all (and I include |
67 |
> myself in that) learn something from this to prevent a repeat. |
68 |
> |
69 |
> I call for Mark's proposed policy to be rejected as it stands. |
70 |
I'd like to see it extended with the ideas shown in this thread. Also |
71 |
the QA team should consider ways of getting higher acceptance - I |
72 |
suggest that a general vote should be done, that's about as democratic |
73 |
as we can get and noone can weasel put after that (although I'm open for |
74 |
other processes to give the QA team support) |
75 |
|
76 |
Patrick |
77 |
-- |
78 |
Stand still, and let the rest of the universe move |