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