| 1 |
On Thu, Jan 30, 2014 at 9:48 PM, Peter Stuge <peter@×××××.se> wrote: |
| 2 |
|
| 3 |
> Chris Reffett wrote: |
| 4 |
> > - -The QA team policymaking workflow will look like the following: |
| 5 |
> .. |
| 6 |
> > If we think a developer's actions are causing problems, we may ask |
| 7 |
> > them to stop/undo pending discussion by the QA team at the next meeting. |
| 8 |
> |
| 9 |
> plus |
| 10 |
> |
| 11 |
> > - -Rules for the QA team editing peoples' packages: |
| 12 |
> .. |
| 13 |
> > *For trivial fixes, such as repoman errors, we fix the issue and send |
| 14 |
> > the developer a friendly reminder |
| 15 |
> > *For large but non-critical fixes, we open a bug, wait 2 weeks, and if |
| 16 |
> > it is not fixed within that time frame we make the change. |
| 17 |
> |
| 18 |
> sounds to me like QA is giving itself carte blanche to make any "fix" |
| 19 |
> they want as per "we think a developer's actions are causing problems" |
| 20 |
> hmm? |
| 21 |
> |
| 22 |
|
| 23 |
To be fair, I had a long discussion with this regarding when QA has the |
| 24 |
authority to temporarily ban a developer. This discussion came about |
| 25 |
because on occasion, a developer and the QA team will have a disagreement |
| 26 |
regarding a package, and QA will attempt to assert their authority. My |
| 27 |
interpretation is that the authority of the QA team nominally comes from |
| 28 |
the idea that we want a certain level of quality in the tree, and that we |
| 29 |
have policies in place to facilitate that quality level. |
| 30 |
|
| 31 |
So in a case where a developer is clearly violating an existing documented |
| 32 |
policy, then QA does have the authority to modify their package after a |
| 33 |
short discussion about it. In the case where policy is missing, QA does not |
| 34 |
have a clear case of authority there. It becomes a more murky area. I've |
| 35 |
tried to very much encourage QA to both publish the policies they want to |
| 36 |
enforce, and automate enforcement with better tooling (repoman or |
| 37 |
otherwise). Being transparent and consistent in enforcement of policy goes |
| 38 |
a long way for getting developers on your side. |
| 39 |
|
| 40 |
So in short, while one could read that passage as you did, I don't think |
| 41 |
that is their intention. When developers 'cause problems' it should be |
| 42 |
obvious to everyone how and why that is, and not simply obvious to |
| 43 |
say...the QA lead. |
| 44 |
|
| 45 |
-A |
| 46 |
|
| 47 |
|
| 48 |
> |
| 49 |
> |
| 50 |
> //Peter |
| 51 |
> |
| 52 |
> |
Archives