| 1 |
On Wed, Jan 22, 2014 at 7:34 AM, Patrick Lauer <patrick@g.o> wrote: |
| 2 |
> On 01/22/2014 03:00 PM, Alan McKinnon wrote: |
| 3 |
>> I don't want to appear rude, but when reading this entire mail all I see |
| 4 |
>> is someone who has probably never had to do it for real. |
| 5 |
>> |
| 6 |
>> People are not machines. Volunteers really do not like having their |
| 7 |
>> freely given time nullified and access removed because one person |
| 8 |
>> thought it was deserved. |
| 9 |
> |
| 10 |
> Well ... |
| 11 |
> |
| 12 |
> if these persons actively break things, and endanger others, *and* they |
| 13 |
> don't respond to multiple verbal warnings/threats ... |
| 14 |
> |
| 15 |
> ... what would you do? |
| 16 |
|
| 17 |
So, this was what I was trying to get at in my email. I see a couple |
| 18 |
of different models being thrown around and they really differ on the |
| 19 |
guidelines as to how QA would apply the power to suspend devs. |
| 20 |
|
| 21 |
One scenario that came up is the runaway script. Some dev is doing |
| 22 |
something that is going to create a lot of work to fix and it gets |
| 23 |
noticed. QA can't quickly ping them, so they suspend access to halt |
| 24 |
the damage. Presumably they then fire off an email saying, "hey, I |
| 25 |
noticed your script was doing foo and suspended your access to halt it |
| 26 |
until we talk about it - let me know when you've terminated your |
| 27 |
scripts and I'll get your access reinstated - ping me when you get a |
| 28 |
chance." |
| 29 |
|
| 30 |
That's very different from the scenario you're suggesting, which |
| 31 |
amounts to deliberate ignoring of warnings and thus they require a |
| 32 |
semi-permanent ban that might become permanent. |
| 33 |
|
| 34 |
The first scenario could happen to the best of us. The second |
| 35 |
shouldn't. The first is purely a technical solution to a technical |
| 36 |
problem. The second is a people problem, being mitigated with a |
| 37 |
technical solution. A ban might be inevitable, but what should the |
| 38 |
process be? |
| 39 |
|
| 40 |
Has the QA team discussed this internally and come to some kind of |
| 41 |
consensus about just what they want their role to actually be? I can |
| 42 |
see an argument being made for many different possible roles. What I |
| 43 |
really am most concerned about is understanding just what the role of |
| 44 |
QA is and how the way we do QA accomplishes as much as possible with |
| 45 |
the least burnout for all impacted. I'm all for policy changes in |
| 46 |
support of this, but I'd rather see us hash out how we want to make it |
| 47 |
work and turn it into policy and not create a policy and then figure |
| 48 |
out how to make it work. |
| 49 |
|
| 50 |
Rich |
Archives