[gentoo-dev] rfc: formally allow qa to suspend commit rights

[gentoo-dev] rfc: formally allow qa to suspend commit rights

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 888 bytes --]

All,

I would like to bring back for discussion an old patch to glep 48 [1]
which was suggested by Jorge [2].

That patch evolved into this one [3], and in the council meeting back
then [4], parts of it made their way into glep 48, but the rest seemed to
be forgotten.

Attached you will find an updated version of this patch taking into
account the current version of glep 48.

This is nothing new; the qa team has requested that commit rights be
suspended before. I am just proposing that we actually add the parts of
the old patch to the glep that spell out when and how this can happen.

Thoughts?

William

[1] http://wiki.gentoo.org/wiki/GLEP:48
[2] http://archives.gentoo.org/gentoo-project/msg_ac161677a6e06a8647e16420eeae8d47.xml
[3] http://www.mail-archive.com/gentoo-qa@lists.gentoo.org/msg00144.html
[4] http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt

[-- Attachment #1.2: suspend.patch --]
[-- Type: text/x-diff, Size: 4973 bytes --]

diff --git a/GLEP:48.mw b/GLEP:48.mw
index 1012011..a1633d7 100644
--- a/GLEP:48.mw
+++ b/GLEP:48.mw
@@ -24,13 +24,15 @@ The QA team should be given certain abilities to look out for the best interests
 * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action.
 * The QA team is directed by a lead, chosen yearly by private or public election  among the members of the team, and confirmed by the council. The QA team lead can choose one member as a deputy. The deputy has all of his powers directly delegated from the QA team lead and thus his actions and decisions should be considered equal to those of the QA team lead. The deputy is directly responsible only to the QA team lead.
 * The QA team lead must approve developers who would like to join the project. The applicant must demonstrate a thorough understanding of the duties he would like to perform. By accepting the applicant the QA team lead will accept the responsibility to direct them as part of the team and will be held responsible for any action the team member takes on behalf of the QA team.
+* Any QA team lead decision can be revoked by major opposing vote from all current QA members. Given the nature of this action new elections should be held within 1 month to elect a new QA team lead.
 * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem.  The QA team does not want to override the maintainer's wishes by default, but only wish to do so when the team finds it is in the best interest of users and fellow developers to have the issue addressed as soon as possible.
 * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations.  Coding style issues fall under this category, and while they are not severe, they can make automated checks of the tree more difficult.
 * There will be cases when our tools are incapable of handling a certain situation and policy must be broken in order to get something working completely.  This will hopefully not occur very often, but each time it does occur, the QA team and the maintainer will come to some agreement on an interim solution and it is expected that a bug will be opened with the appropriate team to work towards a correct solution.
 * In the case of disagreement among QA members the majority of established QA members must agree with the action.  Some examples of disagreements are whether the perceived problem violates the policy or whether the solution makes the situation worse.
 * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council.
 * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation.
-* If a particular developer persistently causes breakage, the QA team may request that Comrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to Comrel.
+* In case a particular developer persistently causes breakage, the QA lead may request commit rights of that developer to be suspended by the Infra team. Comrel should then proceed to evaluate the situation, by finding a compromise or pernamently revoking those rights.
+* Should a situation arise where a developer causes breakage to the point that it cannot be ascribed to an honest mistake, either the QA lead or two members of the QA team can require the Infra team to temporarily suspend commit access for the developer, pending analysis of the causes and resolution to be provided by the QA team within 14 days of said suspension.  Resolution for these kinds of issues is completely in the hands of the QA team, and only the Gentoo Council can revisit the case.
 * The QA team will maintain a list of current "QA Standards" with explanations as to why they are problems, and how to fix the problem.  The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered.  The QA team will also do their best to ensure all developer tools are in line with the current QA standards.
 * The QA team will work with Recruiters to keep related documentation and quizzes up to date, so that up and coming developers will have access to all of the necessary information to avoid past problems.
 * QA will take an active role in cleaning up and removing from the tree unmaintained packages as they are found to be broken.  It is also encouraged of members of the QA team to assist in mentoring new developers that wish to take over unmaintained packages/herds.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]

All,

I  put this on the wrong list, so please disregard this here and reply
on -project instead; I forwarded this msg over there.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: rfc: formally allow qa to suspend commit rights

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Sat, Jan 18, 2014 at 11:02:24PM -0600, William Hubbs wrote:
> +* In case a particular developer persistently causes breakage, the QA lead may request commit rights of that developer to be suspended by the Infra team. Comrel should then proceed to evaluate the situation, by finding a compromise or pernamently revoking those rights.

s/pernamently/permanently/

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[hasufell]

> either the QA lead or two members of the QA team can require the Infra team to temporarily suspend commit access for the developer

-1 to that part

That sounds like you are able to make non-trivial decisions without the
approval of the lead.

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Sun, 19 Jan 2014 13:46:01 +0100
hasufell <hasufell@gentoo.org> wrote:

> > either the QA lead or two members of the QA team can require the
> > Infra team to temporarily suspend commit access for the developer
> 
> -1 to that part
> 
> That sounds like you are able to make non-trivial decisions without
> the approval of the lead.

For non-trivial decisions, two members is indeed a bit low; it is
probably made in the time of a smaller team, as increasing the amount
would beat its purpose (for in case lead is absent) it sounds like "or
two members of the QA team" should just be removed.

(For trivial decisions, this is in place to deal with extreme breakage.)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Denis Dupeyron]

On Sat, Jan 18, 2014 at 10:02 PM, William Hubbs <williamh@gentoo.org> wrote:
> This is nothing new; the qa team has requested that commit rights be
> suspended before. I am just proposing that we actually add the parts of
> the old patch to the glep that spell out when and how this can happen.
>
> Thoughts?

Yes, thoughts, absolutely. Asking for QA to be at the same time judge,
party and executioner. Need I say more?

Denis.

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

On Sun, 19 Jan 2014 13:22:07 -0700
Denis Dupeyron <calchan@gentoo.org> wrote:

> On Sat, Jan 18, 2014 at 10:02 PM, William Hubbs <williamh@gentoo.org>
> wrote:
> > This is nothing new; the qa team has requested that commit rights be
> > suspended before. I am just proposing that we actually add the
> > parts of the old patch to the glep that spell out when and how this
> > can happen.
> >
> > Thoughts?
> 
> Yes, thoughts, absolutely. Asking for QA to be at the same time judge,
> party and executioner. Need I say more?

That is under the assumption that such suspension is permanent as well
as that QA is the only judge. However, most mentioned suspensions
there are temporary and QA needs to bring forward reasoning as to why
QA has requested the temporary suspension; the final judge here is the
Gentoo Council just like with ComRel's suspensions.

QA really is just a party here and has nearly no final power when it
comes to judging or execution; the goal here is to deal with
the rather unusual bigger breakages, but if this doesn't go through QA
can just forward the request to ComRel and have them consider and do it.

This patch just came up by a hypothetical discussion where QA was given
the impression that QA has the power to request this; some of the
Council meetings back in history seem to approve this patch, others do
not. It's a rather odd history, and hence we set things straight here.

It is more of a "Do we want QA to delegate this through ComRel or not?".

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Denis Dupeyron]

On Sun, Jan 19, 2014 at 6:01 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> It is more of a "Do we want QA to delegate this through ComRel or not?".

Actually, no. What it is is a "Subject was thoroughly discussed in the
past, and a decision was made." More than once, in fact. What basis do
you have that would warrant more bilkeshedding on this subject?

It may sound crazy, but it isn't entirely impossible that decisions
made in the past were not made lightly. It's also not entirely
impossible that one of the reasons such decisions are made is so that
people can stop rehashing the same topics over and over again and
focus on more useful and fun topics.

Denis.

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3405 bytes --]

On Sun, 19 Jan 2014 18:22:39 -0700
Denis Dupeyron <calchan@gentoo.org> wrote:

> On Sun, Jan 19, 2014 at 6:01 PM, Tom Wijsman <TomWij@gentoo.org>
> wrote:
> > It is more of a "Do we want QA to delegate this through ComRel or
> > not?".
> 
> Actually, no. What it is is a "Subject was thoroughly discussed in the
> past, and a decision was made." More than once, in fact. What basis do
> you have that would warrant more bilkeshedding on this subject?

The basis that it has once been accepted as well as another time invited
more discussion, clearly indicates that it needs further bikeshedding:

http://www.gentoo.org/proj/en/council/meeting-logs/20110308-summary.txt

    * GLEP 48 (QA)
    After a long discussion and a review of the final proposal text, the
    result is the following:
    - vote:
	in favor: scarabeus, ferringb, wired, jmbsvicetto
	didn't state (abstain): betelgeuse, patrick, a3li
->  Given the result, the GLEP update is accepted and can proceed,
    albeit Peteri raised a question how Devrel is going to work out the
    resolution after the process is handled over from QA. It was agreed
    that the part of the text (last sentence of the diff) will be
    updated with string based on what those two teams agree with
    without more council involvment (unless required otherwise)..

http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt

    * GLEP48 review

    Jorge submitted a proposal to the ml to update GLEP48[4].
    After some initial debate over the power granted to the QA team,
    the timeline in case of an escalation to DevRel, the relation with
    DevRel and whether QA should only enforce policies or also take
    part in creating policies, after the request by Patrick, Jorge
->  suggested pushing this back to the mls. Petteri then asked the
    council to at least vote to commit the non suspension related parts
    of the proposal. The diff[5] was approved with 6 yes votes. Alec
    during this discussion presented some thoughts about the QA team[6].

    [4] -
    http://archives.gentoo.org/gentoo-project/msg_ac161677a6e06a8647e16420eeae8d47.xml
    [5] -
    http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/glep/glep-0048.txt?r1=1.3&r2=1.4
    [6] - http://pastebin.com/C1jGF1DJ

> It may sound crazy, but it isn't entirely impossible that decisions
> made in the past were not made lightly.

This assumes that the decisions have voted against the matter; however,
they voted for this matter on the basis of a small change to be made to
it (20110308-summary.txt) but that never happened and seems forgotten.

Some developers even refer to Diego having used this power in the past.

> It's also not entirely impossible that one of the reasons such
> decisions are made is so that people can stop rehashing the same
> topics over and over again and focus on more useful and fun topics.

This assumes the topic to be useless or boring; however, that's personal
opinion and there is an useful need for this from the QA, Council and
ComRel perspective. Sometimes we need to deal with a more serious topic.

This is one of those days.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Jeroen Roovers]

On Sun, 19 Jan 2014 13:22:07 -0700
Denis Dupeyron <calchan@gentoo.org> wrote:

> Yes, thoughts, absolutely. Asking for QA to be at the same time judge,
> party and executioner. Need I say more?

Actually, infra would be the executioner. Also, as already pointed
out, this practice was established a very long time ago, long before
GLEP 48 was established.


Regards,
     jer

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

On Sat, Jan 18, 2014 at 9:02 PM, William Hubbs <williamh@gentoo.org> wrote:

> All,
>
> I would like to bring back for discussion an old patch to glep 48 [1]
> which was suggested by Jorge [2].
>
> That patch evolved into this one [3], and in the council meeting back
> then [4], parts of it made their way into glep 48, but the rest seemed to
> be forgotten.
>
> Attached you will find an updated version of this patch taking into
> account the current version of glep 48.
>
> This is nothing new; the qa team has requested that commit rights be
> suspended before. I am just proposing that we actually add the parts of
> the old patch to the glep that spell out when and how this can happen.
>
> Thoughts?
>

We almost never suspend commit rights. I'm not really finding a situation
where this is necessary. Certainly not in the streamlined fashion proposed
here.

-A



>
> William
>
> [1] http://wiki.gentoo.org/wiki/GLEP:48
> [2]
> http://archives.gentoo.org/gentoo-project/msg_ac161677a6e06a8647e16420eeae8d47.xml
> [3] http://www.mail-archive.com/gentoo-qa@lists.gentoo.org/msg00144.html
> [4]
> http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt
>

[-- Attachment #2: Type: text/html, Size: 2116 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

On Sun, 19 Jan 2014 17:24:30 -0800
Alec Warner <antarus@gentoo.org> wrote:

> We almost never suspend commit rights. I'm not really finding a
> situation where this is necessary. Certainly not in the streamlined
> fashion proposed here.

Well, the QA team has been inactive for a while; so, I guess this
might have been a while back.

We for example have:

    #gentoo-qa | * WilliamH has seen flameeys ask infra to lock people
    out for a time before 

But also:

    #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend
    people

Whether this has actually happened is something that is questionable;
but yes, one would have to agree that this was definitely streamlined.
The idea was on people's minds, probably because that patch was accepted
in one of the Council meetings; but streamlining of it never happened.

Hence the topic is brought up again here to make a decision final.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Rich Freeman]

On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>     #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend
>     people
>
> Whether this has actually happened is something that is questionable;

Not that this necessarily needs to make it into the GLEP, and I'm
still on the fence regarding whether we really need to make this
change at all, but things like access suspensions and other
administrative/disciplinary procedures should be documented.  I think
whether this is a matter of public record or not is open to debate,
but I don't like the fact that we can really say for sure when/if this
has actually happened.

Rich

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Alan McKinnon]

On 01/20/14 15:59, Rich Freeman wrote:
> On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>     #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend
>>     people
>>
>> Whether this has actually happened is something that is questionable;
> 
> Not that this necessarily needs to make it into the GLEP, and I'm
> still on the fence regarding whether we really need to make this
> change at all, but things like access suspensions and other
> administrative/disciplinary procedures should be documented.  I think
> whether this is a matter of public record or not is open to debate,
> but I don't like the fact that we can really say for sure when/if this
> has actually happened.


Speaking as someone who had this power in his day job, for QA to be able
to suspend accounts is a very bad idea indeed. It always ends badly. I
suspended 20+ accounts in my current job over the years and the number
of cases where it was the right thing to do is precisely 0.

It was always a case of ill-advised action taken out of frustration, or
bypass the training step, or don't try hard enough to reach the
"infringer" and communicate like grown adults. Yup, I did all three.

Suspending an account is a very serious thing to undertake, the effects
on the suspended person are vast and this power should never lie with
the person who is feeling the pain. Instead, there are well established
channels to the body who can make the decision. If QA has a problem with
a dev for any reason whatsoever, then QA should make a well-thought out
case to that other body for decision. Anything else is madness and open
invitation for it to all go south.


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Patrick Lauer]

On 01/20/2014 10:09 PM, Alan McKinnon wrote:
> On 01/20/14 15:59, Rich Freeman wrote:
>> On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>>     #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to suspend
>>>     people
>>>
>>> Whether this has actually happened is something that is questionable;
>>
>> Not that this necessarily needs to make it into the GLEP, and I'm
>> still on the fence regarding whether we really need to make this
>> change at all, but things like access suspensions and other
>> administrative/disciplinary procedures should be documented.  I think
>> whether this is a matter of public record or not is open to debate,
>> but I don't like the fact that we can really say for sure when/if this
>> has actually happened.
> 
> 
> Speaking as someone who had this power in his day job, for QA to be able
> to suspend accounts is a very bad idea indeed. It always ends badly. I
> suspended 20+ accounts in my current job over the years and the number
> of cases where it was the right thing to do is precisely 0.

I've been in positions where such powers were not granted, it's worse.

All you can do is send strongly-worded letters and undo, then wait for
the same thing to be tried again, while telling damagement that this
situation is not good.

> 
> It was always a case of ill-advised action taken out of frustration, or
> bypass the training step, or don't try hard enough to reach the
> "infringer" and communicate like grown adults. Yup, I did all three.

Some people need more direct clues, and since violence in the workplace
is usually disallowed ...

> Suspending an account is a very serious thing to undertake, the effects
> on the suspended person are vast and this power should never lie with
> the person who is feeling the pain. Instead, there are well established
> channels to the body who can make the decision. If QA has a problem with
> a dev for any reason whatsoever, then QA should make a well-thought out
> case to that other body for decision. Anything else is madness and open
> invitation for it to all go south.
> 
It's a serious thing, so it should have some consequences.

I'm mildly amused how everyone wants strong QA, but as soon as QA tries
to actually *do* something it's bad, and overstepping their boundaries,
and NIMBY.

Yey, we're allowed to sometimes do revert games, if we're asking nicely
... and the only way to stop the revert game is for QA to stand down.
We're allowed to send strongly-worded emails, but getting things baked
into policy is too radical.

And the biggest "flamewar" so far was about cosmetic issues.
Y'know, if I get around to it I'll try to work towards making most of
these warnings fatal, then you can't accidentally add such things.
(And people not using repoman will have some extra fun!)

Have fun,

Patrick

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Rich Freeman]

On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer <patrick@gentoo.org> wrote:
>
> Yey, we're allowed to sometimes do revert games, if we're asking nicely
> ... and the only way to stop the revert game is for QA to stand down.
> We're allowed to send strongly-worded emails, but getting things baked
> into policy is too radical.

So, here is how I reconcile this.  There are basically two kinds of
problems - technical problems, and people problems.  We need to deal
with both.  I see QA as being primarily responsible for technical
problems, and it should be staffed to deal with them.  I'm fully
supportive of it being a policy-creating body, with the Council being
the place to vet any policies that seem controversial.

If an ebuild has a deficiency, that's a technical problem - QA should
step in.  QA should also educate the maintainer so that they
understand how to avoid the problem in the future.

Suppose the maintainer refuses to take the problem seriously (whether
they're just lazy, incompetent, or malicious).  Now, that is a people
problem, and really shouldn't be QA's responsibility to deal with
beyond pointing it out to Comrel.

Comrel should deal with people problems, and they should be staffed
accordingly.  They need the manpower so that they can deal with them
efficiently.  When QA says that a developer is not following a
technical policy, Comrel should defer to them as this is their area of
expertise.  If either QA or Comrel gets out of hand there is always
the appeal to Council, so neither body needs to be walking on
eggshells or taking 18 months to decide to do something about a
problem.  If QA feels like Comrel isn't taking their complaints
seriously, there is the Council - Comrel should be taking their
concerns seriously.  However, QA needs to recognize that people
problems aren't always best solved with the use of command-line
utilities.

In then end we'll only get where we need to be if we work together,
and avoid the passive-aggressive nonsense.  If somebody feels that QA
is out of line by all means put it on the Council agenda.  Otherwise,
devs need to do what they can to make the job of QA easier, and not
harder.

About the only time I really see need for "emergency suspension
powers" is in the situation of some kind of hacking attempt.  I'm not
aware of any attack like this ever being mounted, but if it were the
necessary action would involve a lot more than just suspending
somebody's commit rights.  Probably the best first action would be to
disable all rsync/etc distribution, lock down cvs entirely, and then
begin cleanup.

If there is some kind of general standing problem of Comrel ignoring
QA by all means let the Council know (assuming you can't just work it
out with them).  However, Comrel announced not all that long ago a
general desire to enforce CoC with short bans/etc, and that they were
interested in having a vital QA organization so that they have some
kind of authority to rely on for technical questions.  That certainly
sounds like a good direction to me, so I don't want to dwell too much
on the past.

Bottom line - don't be afraid to do your job, and when something gets
in the way speak up about it!

Rich

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3484 bytes --]

On Mon, Jan 20, 2014 at 4:46 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> >
> > Yey, we're allowed to sometimes do revert games, if we're asking nicely
> > ... and the only way to stop the revert game is for QA to stand down.
> > We're allowed to send strongly-worded emails, but getting things baked
> > into policy is too radical.
>
> So, here is how I reconcile this.  There are basically two kinds of
> problems - technical problems, and people problems.  We need to deal
> with both.  I see QA as being primarily responsible for technical
> problems, and it should be staffed to deal with them.  I'm fully
> supportive of it being a policy-creating body, with the Council being
> the place to vet any policies that seem controversial.
>
> If an ebuild has a deficiency, that's a technical problem - QA should
> step in.  QA should also educate the maintainer so that they
> understand how to avoid the problem in the future.
>
> Suppose the maintainer refuses to take the problem seriously (whether
> they're just lazy, incompetent, or malicious).  Now, that is a people
> problem, and really shouldn't be QA's responsibility to deal with
> beyond pointing it out to Comrel.
>
> Comrel should deal with people problems, and they should be staffed
> accordingly.  They need the manpower so that they can deal with them
> efficiently.  When QA says that a developer is not following a
> technical policy, Comrel should defer to them as this is their area of
> expertise.  If either QA or Comrel gets out of hand there is always
> the appeal to Council, so neither body needs to be walking on
> eggshells or taking 18 months to decide to do something about a
> problem.  If QA feels like Comrel isn't taking their complaints
> seriously, there is the Council - Comrel should be taking their
> concerns seriously.  However, QA needs to recognize that people
> problems aren't always best solved with the use of command-line
> utilities.
>
> In then end we'll only get where we need to be if we work together,
> and avoid the passive-aggressive nonsense.  If somebody feels that QA
> is out of line by all means put it on the Council agenda.  Otherwise,
> devs need to do what they can to make the job of QA easier, and not
> harder.
>
> About the only time I really see need for "emergency suspension
> powers" is in the situation of some kind of hacking attempt.  I'm not
> aware of any attack like this ever being mounted, but if it were the
> necessary action would involve a lot more than just suspending
> somebody's commit rights.  Probably the best first action would be to
> disable all rsync/etc distribution, lock down cvs entirely, and then
> begin cleanup.
>
>
I can only think of one incident, and once we learned of the incident that
developer was let go.



> If there is some kind of general standing problem of Comrel ignoring
> QA by all means let the Council know (assuming you can't just work it
> out with them).  However, Comrel announced not all that long ago a
> general desire to enforce CoC with short bans/etc, and that they were
> interested in having a vital QA organization so that they have some
> kind of authority to rely on for technical questions.  That certainly
> sounds like a good direction to me, so I don't want to dwell too much
> on the past.
>
> Bottom line - don't be afraid to do your job, and when something gets
> in the way speak up about it!
>
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 4373 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3565 bytes --]

On Mon, Jan 20, 2014 at 4:22 PM, Patrick Lauer <patrick@gentoo.org> wrote:

> On 01/20/2014 10:09 PM, Alan McKinnon wrote:
> > On 01/20/14 15:59, Rich Freeman wrote:
> >> On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
> >>>     #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to
> suspend
> >>>     people
> >>>
> >>> Whether this has actually happened is something that is questionable;
> >>
> >> Not that this necessarily needs to make it into the GLEP, and I'm
> >> still on the fence regarding whether we really need to make this
> >> change at all, but things like access suspensions and other
> >> administrative/disciplinary procedures should be documented.  I think
> >> whether this is a matter of public record or not is open to debate,
> >> but I don't like the fact that we can really say for sure when/if this
> >> has actually happened.
> >
> >
> > Speaking as someone who had this power in his day job, for QA to be able
> > to suspend accounts is a very bad idea indeed. It always ends badly. I
> > suspended 20+ accounts in my current job over the years and the number
> > of cases where it was the right thing to do is precisely 0.
>
> I've been in positions where such powers were not granted, it's worse.
>
> All you can do is send strongly-worded letters and undo, then wait for
> the same thing to be tried again, while telling damagement that this
> situation is not good.
>
> >
> > It was always a case of ill-advised action taken out of frustration, or
> > bypass the training step, or don't try hard enough to reach the
> > "infringer" and communicate like grown adults. Yup, I did all three.
>
> Some people need more direct clues, and since violence in the workplace
> is usually disallowed ...
>
> > Suspending an account is a very serious thing to undertake, the effects
> > on the suspended person are vast and this power should never lie with
> > the person who is feeling the pain. Instead, there are well established
> > channels to the body who can make the decision. If QA has a problem with
> > a dev for any reason whatsoever, then QA should make a well-thought out
> > case to that other body for decision. Anything else is madness and open
> > invitation for it to all go south.
> >
> It's a serious thing, so it should have some consequences.
>
> I'm mildly amused how everyone wants strong QA, but as soon as QA tries
> to actually *do* something it's bad, and overstepping their boundaries,
> and NIMBY.
>
> Yey, we're allowed to sometimes do revert games, if we're asking nicely
> ... and the only way to stop the revert game is for QA to stand down.
> We're allowed to send strongly-worded emails, but getting things baked
> into policy is too radical.
>

I think you are framing the argument incorrectly. I'm not suggesting that
QA team not have any powers, but that the powers you are asking for are
perhaps, not so great.

If someone is making tree changes, and they are breaking the tree, and you
fix it (using your QA powers to fix it.) Then they revert it. I don't think
the proper solution is for QA and a dev to get into a revert war until QA
exercises their power to revoke the devs commit access.

Simply file a bug and have the developer reprimanded for violating policy.



>
> And the biggest "flamewar" so far was about cosmetic issues.
> Y'know, if I get around to it I'll try to work towards making most of
> these warnings fatal, then you can't accidentally add such things.
> (And people not using repoman will have some extra fun!)
>
> Have fun,
>
> Patrick
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4763 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On Tue, 21 Jan 2014 08:22:23 +0800
Patrick Lauer <patrick@gentoo.org> wrote:
> And the biggest "flamewar" so far was about cosmetic issues.
> Y'know, if I get around to it I'll try to work towards making most of
> these warnings fatal, then you can't accidentally add such things.
> (And people not using repoman will have some extra fun!)

Well couldn't QA start focusing on non-cosmetic issues? I can provide a
list if you need it.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 747 bytes --]

Am Mittwoch, 22. Januar 2014, 18:54:00 schrieb Ciaran McCreesh:
> On Tue, 21 Jan 2014 08:22:23 +0800
> 
> Patrick Lauer <patrick@gentoo.org> wrote:
> > And the biggest "flamewar" so far was about cosmetic issues.
> > Y'know, if I get around to it I'll try to work towards making most of
> > these warnings fatal, then you can't accidentally add such things.
> > (And people not using repoman will have some extra fun!)
> 
> Well couldn't QA start focusing on non-cosmetic issues? I can provide a
> list if you need it.

Actually, from what I gathered on IRC, suggestions would be appreciated!
(but better in separate threads! :)

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On Wed, 22 Jan 2014 17:54:00 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 21 Jan 2014 08:22:23 +0800
> Patrick Lauer <patrick@gentoo.org> wrote:
> > And the biggest "flamewar" so far was about cosmetic issues.
> > Y'know, if I get around to it I'll try to work towards making most
> > of these warnings fatal, then you can't accidentally add such
> > things. (And people not using repoman will have some extra fun!)
> 
> Well couldn't QA start focusing on non-cosmetic issues? I can provide
> a list if you need it.
> 

Yes, we already do; fixing reverse dependencies that break on a bump,
migrating ebuilds away from deprecated EAPIs, working on QA bugs, ...

... but a list with more ideas is very welcome.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 4853 bytes --]

On Mon, 20 Jan 2014 16:09:46 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> Speaking as someone who had this power in his day job, for QA to be
> able to suspend accounts is a very bad idea indeed. It always ends
> badly. I suspended 20+ accounts in my current job over the years and
> the number of cases where it was the right thing to do is precisely 0.

The relation between "using power" and "having power is a bad idea" is
non-existing; it is rather how that power is used that determines
whether it is a good idea than whether one is able to use that power.

> It was always a case of ill-advised action taken out of frustration,
> or bypass the training step, or don't try hard enough to reach the
> "infringer" and communicate like grown adults. Yup, I did all three.

The prior experience demonstrated here shows how frustration or lack of
proper communication are really good symptoms to investigate and learn
from; however, these symptoms seem non-existing with our QA lead.

> Suspending an account is a very serious thing to undertake, the
> effects on the suspended person are vast and this power should never
> lie with the person who is feeling the pain.

This is the core symptom of the way you do QA, if you are the person
that is feeling pain then you need to reconsider your QA position; the
thing feeling the pain here is the Portage tree, and the QA team is
just ensuring its quality and thus should not get emotional or
personally affected by the developers' changes to some bits 'n bytes.

Of course one could see QA as defending the Portage tree with our heart;
but not that literally, at least not up to the point that one gets
painfully hurt or even just frustrated...

> Instead, there are well established channels to the body who can make
> the decision. If QA has a problem with a dev for any reason
> whatsoever, then QA should make a well-thought out case to that other
> body for decision.

Adding extra bodies adds more delay; furthermore, these bodies have
less time, understanding and more about the technical QA issue at hand.

If a developer does an unannounced mass action that breaks the tree
severely or is heavily prohibited by policy, is unreachable while he
continues to commit this; then it would be handy to "temporarily" be
able to withdraw the commit access to bring it to that developer's
attention. This is under the assumption that we have tried to contact
the person multiple time and after a reasonable amount of time the
person has not responded; if we still then need to wait for another
team to notice, investigate and finally take action whereas we have
already took the decision, ...

This is rather to note that we need have a talk to coordinate that mass
action and unbreak the tree, than it is to punish that developer by
hitting with a ruler on his/her hand; in a sense of "let's fix the
damage to the tree and proceed".

There even can happen worse things; like misusing 'pkgmove', the
@system set or similar that can cause some real havoc. It is in this
occasion where a developer hasn't discussed or talked to anyone earlier
before proceeding with a change he knows he shouldn't do, as well as
ignoring us afterwards; that we simply temporarily cannot allow further
commits, simply because the developer seems "technically unable to
follow the policy and its enforcement".

This is similar to how you have Gentoo support ops in #gentoo, Gentoo
chat ops in #gentoo-chat and individual ops in individual IRC channels;
if they had to rely on another body which would be the group contacts or
FreeNode, you would have to wait a long for them to kick, ban or mute.

If the non-technical ComRel lead has this power, then why doesn't the
technical QA lead have this power? After all, the technical lead assures
the quality of what the developer has access to; like I stated above,
the technical lead has more time, understanding and knows the issue.

You can see this as ComRel improving the QA of the community relations,
whereas QA is improving the QA of the Portage tree and its commits; to
some extent it even becomes questionable why ComRel can suspend access
to the Portage tree, but I guess for revert wars between developers.

> Anything else is madness and open invitation for it to all go south.

This is a too broad generalization on the basis of one use case.

See power as an useful temporary tool for when it is absolute necessary,
don't see it as a permanent tool for whenever something goes wrong; the
former usefulness leads to success, the latter madness leads to sadness.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Rich Freeman]

On Tue, Jan 21, 2014 at 9:56 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> If a developer does an unannounced mass action that breaks the tree
> severely or is heavily prohibited by policy, is unreachable while he
> continues to commit this; then it would be handy to "temporarily" be
> able to withdraw the commit access to bring it to that developer's
> attention.

Hadn't really thought about it in this light.  In this situation
restricting commit access is being used as a technical solution to a
technical problem - not unlike killing a runaway process.

I have no issues at all with QA taking action in a manner like this,
though unless that mass-update is really slow I doubt we'd ever react
in time.

What I don't like is the idea of QA taking what amounts to punitive
measures.  I think that this is a role best held by Comrel.  I do
appreciate Markos's comments regarding Comrel not being the right
solution to a technical problem.  I do not see Comrel has having a
role in mediating a dispute between QA and a developer over the
correctness of policy or its enforcement (personal conflicts are a
different matter as Markos acknowledges).  What I do see Comrel has
having a role in is a developer who simply refuses to follow policy -
whether that is CoC, technical policy, or whatever.  In the case of
CoC Cevrel is judge, jury, and executive (that is, they determine
whether it was violated in addition to dealing with the fact that it
was).  In the case of a QA issue QA is the jury (they determine if the
policy was violated), and Comrel is the judge and executive (they
determine how to get the dev to go along with policy or get rid of
them).

If Comrel really objects to this I'm not entirely opposed to letting
QA have the reins (certainly we can't just let policy go unenforced
entirely).  However, I would encourage the teams to give some thought
as to whether it makes sense to work together to separate the human vs
technical factors here.

This discussion has been helpful...

Rich

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

On Tue, Jan 21, 2014 at 10:47:50AM -0500, Rich Freeman wrote:
> If Comrel really objects to this I'm not entirely opposed to letting
> QA have the reins (certainly we can't just let policy go unenforced
> entirely).  However, I would encourage the teams to give some thought
> as to whether it makes sense to work together to separate the human vs
> technical factors here.

Well, I guess that's the big question isn't it -- what is personal vs
technical?

I think we can all agree that if qa changes an ebuild and a dev comes back
with "You stupid *** leave my *** ebuild alone." and reverts qa's
change, that is personal and goes straight to Comrel because it is now a
CoC violation as well.

What about the scenario where qa makes a change, then the dev, in a
civil manor, explains to qa why he prefers his original method and
reverts QA's change without the agreement of QA and without presenting
his case to the council? Now you have another qa violation since GLEP
48 states that QA's changes must stand until the council says otherwise.
However, assuming the exchanges between qa and the dev are still
respectful, I'm not sure there is a personal issue.

wrt the commit rights issue: QA is asking for the ability to *suspend*
not *revoke* commit rights. This was explained well by Tom; it is a
temporary measure to get a dev's attention if nothing else works.

I agree that it is strong. However, if qa gets out of hand with it,
the council can always step in and take care of the matter.

Thoughts?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Rich Freeman]

On Tue, Jan 21, 2014 at 12:26 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Tue, Jan 21, 2014 at 10:47:50AM -0500, Rich Freeman wrote:
>> If Comrel really objects to this I'm not entirely opposed to letting
>> QA have the reins (certainly we can't just let policy go unenforced
>> entirely).  However, I would encourage the teams to give some thought
>> as to whether it makes sense to work together to separate the human vs
>> technical factors here.
>
> What about the scenario where qa makes a change, then the dev, in a
> civil manor, explains to qa why he prefers his original method and
> reverts QA's change without the agreement of QA and without presenting
> his case to the council? Now you have another qa violation since GLEP
> 48 states that QA's changes must stand until the council says otherwise.
> However, assuming the exchanges between qa and the dev are still
> respectful, I'm not sure there is a personal issue.

It isn't a personal issue, but it is a personnel / human-factors issue.

A developer is refusing to follow policy.  The CofC is but one policy
- all the GLEPs are policy, as is the Devmanual.  A developer who
refuses to follow policy is subject to action by Comrel.  At least,
that is how I see the roles of the groups (but I'm open to
counter-argument).

The other way to do things is to make both groups responsible for what
amounts to HR, but then we need to make sure we staff QA accordingly.
QA can't then just solve the technical problems and deal with people
like you might deal with code, otherwise the Council and/or Comrel
really will end up having to deal with a bunch of personal problems.

QA stepping in with temporary bans as a band-aid solution to a more
serious problem is fine.  However, dealing with the inter-personal
issues requires a different sort of skillset.  A developer who doesn't
follow policy is either unable to do so or unwilling to do so.  Either
problem might be correctable, or perhaps we'll just have to go our
separate ways.  I think Comrel should be the body that is staffed with
the right skills to make that determination.

Rich

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

Tom Wijsman wrote:
> Of course one could see QA as defending the Portage tree with our heart;
> but not that literally, at least not up to the point that one gets
> painfully hurt or even just frustrated...

Anyone who cares about quality will be frustrated by others who do not.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

On Tue, 21 Jan 2014 18:56:57 +0100
Peter Stuge <peter@stuge.se> wrote:

> Anyone who cares about quality will be frustrated by others who do
> not.

We have policies to enforce quality, thus frustration is optional. :)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

Tom Wijsman wrote:
> > Anyone who cares about quality will be frustrated by others who do not.
> 
> We have policies to enforce quality, thus frustration is optional. :)

Policies don't enforce quality, people enforce quality.
And doing that is quickly frustrating.

If enforcing quality would be a purely mechanical task there wouldn't
be the same need for people, which would be ideal. But I think we're
some ways away from that still.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

On Tue, 21 Jan 2014 19:16:54 +0100
Peter Stuge <peter@stuge.se> wrote:

> Tom Wijsman wrote:
> > > Anyone who cares about quality will be frustrated by others who
> > > do not.
> > 
> > We have policies to enforce quality, thus frustration is
> > optional. :)
> 
> Policies don't enforce quality, people enforce quality.

Well, we have policy [1] stating that QA can enforce quality until
overridden by a decision by the Council; so, to be fair, there are
even more parties involved than just the policy. Which doesn't change
the point; we can enforce quality, thus frustration is optional. :)

> And doing that is quickly frustrating.

There seems to be a lack of frustration in my experience as a QA
member; I care about quality by helping people fix breakage, this gives
me a feeling of accomplishment instead of a feeling of frustration.

> If enforcing quality would be a purely mechanical task there wouldn't
> be the same need for people, which would be ideal. But I think we're
> some ways away from that still.

We have (Auto)RepoMan and it improves as we speak; we are rather quite
close to it, making RepoMan warnings fatal is just a step away. Given
there is a lack of frustration, why should we do that? It could cause
more frustration than what it is trying to fix. Interesting thought...

Could we return back to the original subject of this thread?

 [1]: https://wiki.gentoo.org/wiki/GLEP:48

      "In the event that a developer still insists that a package does
      not break QA standards, an appeal can be made at the next council
      meeting. The package should be dealt with per QA's request until
      such a time that a decision is made by the council."

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

Tom Wijsman schrieb:
> 
>  [1]: https://wiki.gentoo.org/wiki/GLEP:48
> 
>       "In the event that a developer still insists that a package does
>       not break QA standards, an appeal can be made at the next council
>       meeting. The package should be dealt with per QA's request until
>       such a time that a decision is made by the council."
> 


Thanks for this pointer, i guess this makes the existing situation
pretty clear:

If QA does a commit and a dev does disagree, he can discuss it with QA
or ask for council decision, but should never revert this QA change on
his own.

So if the dev then does ignore this rule, he does not follow our written
rules (problem with the behaviour) and as a result this becomes a case
for comrel.

Now if comrel cannot convince the dev to accept the QA change (at least
until council decision), it means comrel would have to take disciplinary
action (e.g. commit access removal).



With this in mind, i currently dont see any case where QA would need the
ability to remove the commit access of a dev, so i dont see a need for
this glep update.

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]

On Tue, 21 Jan 2014 22:03:22 +0100
Thomas Sachau <tommy@gentoo.org> wrote:

> With this in mind, i currently dont see any case where QA would need
> the ability to remove the commit access of a dev, so i dont see a
> need for this glep update.

The case you have enumerated is just one possible case, this is a case
where policy is in place; it is however not always the case that there
is policy, or perhaps even that policy is unclear. In these other cases
the QA team has to take an actual decision instead of "it is policy"; in
such cases, the reasoning behind this becomes technical and you get the
whole idea we have been discussing here.

Besides that, you also have the possibility for bigger breakages to
happen; regardless of whether or not they are written down in policy.

In some of these cases the roles of QA and ComRel become questionable;
cfr. the whole discussion on #gentoo-qa, where I also asked the reverse
question as to why QA has the power to suspend people in a technical
area like the Portage tree when it is not part of their terrains.

And just to make it clear one more time; it is the ability to
"temporarily" "suspend" the commit access, as a means to get the
developer to contact us where the developer was otherwise unavailable
or intended to not communicate or listen to us. It is no way an actual
removal or permanent decision; or well, it might be if this is about
repeated behavior, but that's a whole different story...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

On Tue, Jan 21, 2014 at 11:56:14PM +0100, Tom Wijsman wrote:
> On Tue, 21 Jan 2014 22:03:22 +0100
> Thomas Sachau <tommy@gentoo.org> wrote:
> 
> > With this in mind, i currently dont see any case where QA would need
> > the ability to remove the commit access of a dev, so i dont see a
> > need for this glep update.

All, can we please stop this thread on  -dev and move it to -project? I
specifically asked that after I posted here, but then others, and I
guess myself too, did not pay attention to that.

Please move to -project to continue the discussion; this really belongs
there.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Alan McKinnon]

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.

Do you realise the message that is sent by denying someone access? You
are saying that person is not good enough to work on Gentoo. Do you
really want to send that message?

Vast wholescale breakage is very rare and not something you can base
policy on.

Rich's most recent reply is the most sane proposal I've seen so far.
Revoking access is a human problem and is solved with human solutions.

Do beware the law of unintended side-effects.




On 01/21/14 16:56, Tom Wijsman wrote:
> On Mon, 20 Jan 2014 16:09:46 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
>> Speaking as someone who had this power in his day job, for QA to be
>> able to suspend accounts is a very bad idea indeed. It always ends
>> badly. I suspended 20+ accounts in my current job over the years and
>> the number of cases where it was the right thing to do is precisely 0.
> 
> The relation between "using power" and "having power is a bad idea" is
> non-existing; it is rather how that power is used that determines
> whether it is a good idea than whether one is able to use that power.
> 
>> It was always a case of ill-advised action taken out of frustration,
>> or bypass the training step, or don't try hard enough to reach the
>> "infringer" and communicate like grown adults. Yup, I did all three.
> 
> The prior experience demonstrated here shows how frustration or lack of
> proper communication are really good symptoms to investigate and learn
> from; however, these symptoms seem non-existing with our QA lead.
> 
>> Suspending an account is a very serious thing to undertake, the
>> effects on the suspended person are vast and this power should never
>> lie with the person who is feeling the pain.
> 
> This is the core symptom of the way you do QA, if you are the person
> that is feeling pain then you need to reconsider your QA position; the
> thing feeling the pain here is the Portage tree, and the QA team is
> just ensuring its quality and thus should not get emotional or
> personally affected by the developers' changes to some bits 'n bytes.
> 
> Of course one could see QA as defending the Portage tree with our heart;
> but not that literally, at least not up to the point that one gets
> painfully hurt or even just frustrated...
> 
>> Instead, there are well established channels to the body who can make
>> the decision. If QA has a problem with a dev for any reason
>> whatsoever, then QA should make a well-thought out case to that other
>> body for decision.
> 
> Adding extra bodies adds more delay; furthermore, these bodies have
> less time, understanding and more about the technical QA issue at hand.
> 
> If a developer does an unannounced mass action that breaks the tree
> severely or is heavily prohibited by policy, is unreachable while he
> continues to commit this; then it would be handy to "temporarily" be
> able to withdraw the commit access to bring it to that developer's
> attention. This is under the assumption that we have tried to contact
> the person multiple time and after a reasonable amount of time the
> person has not responded; if we still then need to wait for another
> team to notice, investigate and finally take action whereas we have
> already took the decision, ...
> 
> This is rather to note that we need have a talk to coordinate that mass
> action and unbreak the tree, than it is to punish that developer by
> hitting with a ruler on his/her hand; in a sense of "let's fix the
> damage to the tree and proceed".
> 
> There even can happen worse things; like misusing 'pkgmove', the
> @system set or similar that can cause some real havoc. It is in this
> occasion where a developer hasn't discussed or talked to anyone earlier
> before proceeding with a change he knows he shouldn't do, as well as
> ignoring us afterwards; that we simply temporarily cannot allow further
> commits, simply because the developer seems "technically unable to
> follow the policy and its enforcement".
> 
> This is similar to how you have Gentoo support ops in #gentoo, Gentoo
> chat ops in #gentoo-chat and individual ops in individual IRC channels;
> if they had to rely on another body which would be the group contacts or
> FreeNode, you would have to wait a long for them to kick, ban or mute.
> 
> If the non-technical ComRel lead has this power, then why doesn't the
> technical QA lead have this power? After all, the technical lead assures
> the quality of what the developer has access to; like I stated above,
> the technical lead has more time, understanding and knows the issue.
> 
> You can see this as ComRel improving the QA of the community relations,
> whereas QA is improving the QA of the Portage tree and its commits; to
> some extent it even becomes questionable why ComRel can suspend access
> to the Portage tree, but I guess for revert wars between developers.
> 
>> Anything else is madness and open invitation for it to all go south.
> 
> This is a too broad generalization on the basis of one use case.
> 
> See power as an useful temporary tool for when it is absolute necessary,
> don't see it as a permanent tool for whenever something goes wrong; the
> former usefulness leads to success, the latter madness leads to sadness.
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/22/2014 08:00 AM, Alan McKinnon wrote:


People already do that without revoking commit access, e.g. when the
recruitment project tells you they don't want to process your recruit
or when project leads don't respond to membership applications at all
or when the ComRel lead is not interested in a private discussion.

And then they seem surprised when you get pissed. And they even seem
clueless about why the working atmosphere in the gentoo-dev community
is pretty bad. It is not, because someone has a strong opinion.
Everyone has, at times. It's about that attitude of telling people
that you are not good enough for their time.

So this is already happening. The proposal here is just a "logical"
consequence to this situation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS358gAAoJEFpvPKfnPDWzIzkH/j/jmHuAIVIy/d+pOya4x4iF
5o/jmqZQ2uYakfRbaISegMb4JtWtlEfjHIyPj2jaIyfBSqfYavfvwZg7pL8st4Kj
dB9vGD6P7h0YtK1g8m66XezWwJUD/ym+zgAx3q3M36JfRzKH1rohBlkSQJDivsK3
ogc4bHi9zBXRb1Lpk1OTHdJGTdvUBgqcTEZvTKkAmYZQiNqboCtE3D0euy3u/Osp
NYoeDgSdTrAEj3HkAnhujuLZTa/vimDKvde9mRElQVxadrtxxicQ+09Ct8obvC07
zGyQ2BBgINAVMxdNuND7tq0ryT+HnNObkowv2V1My3zhg4tT5CE/7xSOB8CZdak=
=H/Gc
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[hasufell]

On 01/22/2014 11:36 AM, hasufell wrote:
> 
> 
> People already do that without revoking commit access, e.g. when the
> recruitment project tells you they don't want to process your recruit
> or when project leads don't respond to membership applications at all
> or when the ComRel lead is not interested in a private discussion.
> 
> And then they seem surprised when you get pissed. And they even seem
> clueless about why the working atmosphere in the gentoo-dev community
> is pretty bad. It is not, because someone has a strong opinion.
> Everyone has, at times. It's about that attitude of telling people
> that you are not good enough for their time.
> 
> So this is already happening. The proposal here is just a "logical"
> consequence to this situation.
> 

sorry for messing up that mail, it was a reply to

On 01/22/2014 08:00 AM, Alan McKinnon wrote:> I don't want to appear
rude, but when reading this entire mail all I see
>
> Do you realise the message that is sent by denying someone access? You
> are saying that person is not good enough to work on Gentoo. Do you
> really want to send that message?

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 6723 bytes --]

On Tue, Jan 21, 2014 at 11:00 PM, Alan McKinnon <alan.mckinnon@gmail.com>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.


> Do you realise the message that is sent by denying someone access? You
> are saying that person is not good enough to work on Gentoo. Do you
> really want to send that message?
>

Of course it is. We want to send the message that if a person's
contributions are not up to par, their access to commit to the project will
be revoked, until they can prove that they can contribute at a level that
is not detrimental to users or other developers. A large portion of the QA
team's role in Gentoo is to define what 'par' means and at some level, get
the community to agree with them.

Developer mentorship, for example, generally requires that a prospective
developer submits changes to their mentor and the mentor reviews them. Part
of that process is to determine that prospective developers can contribute
at the expected level and we have quizzes to try and verify that developers
understand key facets of ebuild development. Certainly if a prospective
developer routinely submits faulty ebuilds and doesn't show improvement, we
are unlikely to grant them commit access.


>
> Vast wholescale breakage is very rare and not something you can base
> policy on.


> Rich's most recent reply is the most sane proposal I've seen so far.
> Revoking access is a human problem and is solved with human solutions.
>
> Do beware the law of unintended side-effects.
>
>
>
>
> On 01/21/14 16:56, Tom Wijsman wrote:
> > On Mon, 20 Jan 2014 16:09:46 +0200
> > Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> >
> >> Speaking as someone who had this power in his day job, for QA to be
> >> able to suspend accounts is a very bad idea indeed. It always ends
> >> badly. I suspended 20+ accounts in my current job over the years and
> >> the number of cases where it was the right thing to do is precisely 0.
> >
> > The relation between "using power" and "having power is a bad idea" is
> > non-existing; it is rather how that power is used that determines
> > whether it is a good idea than whether one is able to use that power.
> >
> >> It was always a case of ill-advised action taken out of frustration,
> >> or bypass the training step, or don't try hard enough to reach the
> >> "infringer" and communicate like grown adults. Yup, I did all three.
> >
> > The prior experience demonstrated here shows how frustration or lack of
> > proper communication are really good symptoms to investigate and learn
> > from; however, these symptoms seem non-existing with our QA lead.
> >
> >> Suspending an account is a very serious thing to undertake, the
> >> effects on the suspended person are vast and this power should never
> >> lie with the person who is feeling the pain.
> >
> > This is the core symptom of the way you do QA, if you are the person
> > that is feeling pain then you need to reconsider your QA position; the
> > thing feeling the pain here is the Portage tree, and the QA team is
> > just ensuring its quality and thus should not get emotional or
> > personally affected by the developers' changes to some bits 'n bytes.
> >
> > Of course one could see QA as defending the Portage tree with our heart;
> > but not that literally, at least not up to the point that one gets
> > painfully hurt or even just frustrated...
> >
> >> Instead, there are well established channels to the body who can make
> >> the decision. If QA has a problem with a dev for any reason
> >> whatsoever, then QA should make a well-thought out case to that other
> >> body for decision.
> >
> > Adding extra bodies adds more delay; furthermore, these bodies have
> > less time, understanding and more about the technical QA issue at hand.
> >
> > If a developer does an unannounced mass action that breaks the tree
> > severely or is heavily prohibited by policy, is unreachable while he
> > continues to commit this; then it would be handy to "temporarily" be
> > able to withdraw the commit access to bring it to that developer's
> > attention. This is under the assumption that we have tried to contact
> > the person multiple time and after a reasonable amount of time the
> > person has not responded; if we still then need to wait for another
> > team to notice, investigate and finally take action whereas we have
> > already took the decision, ...
> >
> > This is rather to note that we need have a talk to coordinate that mass
> > action and unbreak the tree, than it is to punish that developer by
> > hitting with a ruler on his/her hand; in a sense of "let's fix the
> > damage to the tree and proceed".
> >
> > There even can happen worse things; like misusing 'pkgmove', the
> > @system set or similar that can cause some real havoc. It is in this
> > occasion where a developer hasn't discussed or talked to anyone earlier
> > before proceeding with a change he knows he shouldn't do, as well as
> > ignoring us afterwards; that we simply temporarily cannot allow further
> > commits, simply because the developer seems "technically unable to
> > follow the policy and its enforcement".
> >
> > This is similar to how you have Gentoo support ops in #gentoo, Gentoo
> > chat ops in #gentoo-chat and individual ops in individual IRC channels;
> > if they had to rely on another body which would be the group contacts or
> > FreeNode, you would have to wait a long for them to kick, ban or mute.
> >
> > If the non-technical ComRel lead has this power, then why doesn't the
> > technical QA lead have this power? After all, the technical lead assures
> > the quality of what the developer has access to; like I stated above,
> > the technical lead has more time, understanding and knows the issue.
> >
> > You can see this as ComRel improving the QA of the community relations,
> > whereas QA is improving the QA of the Portage tree and its commits; to
> > some extent it even becomes questionable why ComRel can suspend access
> > to the Portage tree, but I guess for revert wars between developers.
> >
> >> Anything else is madness and open invitation for it to all go south.
> >
> > This is a too broad generalization on the basis of one use case.
> >
> > See power as an useful temporary tool for when it is absolute necessary,
> > don't see it as a permanent tool for whenever something goes wrong; the
> > former usefulness leads to success, the latter madness leads to sadness.
> >
>
>
> --
> Alan McKinnon
> alan.mckinnon@gmail.com
>
>
>

[-- Attachment #2: Type: text/html, Size: 8431 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

On Wed, 22 Jan 2014 02:58:45 -0800
Alec Warner <antarus@gentoo.org> wrote:

> Of course it is. We want to send the message that if a person's
> contributions are not up to par, their access to commit to the
> project will be revoked, until they can prove that they can
> contribute at a level that is not detrimental to users or other
> developers. A large portion of the QA team's role in Gentoo is to
> define what 'par' means and at some level, get the community to agree
> with them.
> 
> Developer mentorship, for example, generally requires that a
> prospective developer submits changes to their mentor and the mentor
> reviews them. Part of that process is to determine that prospective
> developers can contribute at the expected level and we have quizzes
> to try and verify that developers understand key facets of ebuild
> development. Certainly if a prospective developer routinely submits
> faulty ebuilds and doesn't show improvement, we are unlikely to grant
> them commit access.

True; becoming a developer goes further than obtaining access, it also
involves keeping that access. And everyone knows well enough that it
takes more than a single breakage to permanently lose that access; to
determine where the limits are, one can remember the case with
python-exec where you see that the developer is still around.

Permanently losing it thus takes quite a big effort; in comparison, a
temporary suspension is something rather helpful ("Oh, were I breaking
the tree? Thanks for preventing me from making further damage; sorry, I
forgot to check IRC and/or e-mails. What can we do to fix it?"),
temporary suspensions do not have to be worried about. 

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Patrick Lauer]

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?

Every workplace environment and most opensource projects have some
mechanism to enforce sanity in such situations, so why not have it
explicitly stated so that there's no one surprised when it triggers?
> 
> Do you realise the message that is sent by denying someone access? You
> are saying that person is not good enough to work on Gentoo. Do you
> really want to send that message?
Yes. And I have no problem being the Evil Guy who pulls the trigger,
err, presses the enter key.

You are saying that *any* contribution should be accepted just to not
hurt someones feelings.
Bad news: I don't care about feelings. I care about facts, and results.

The *chance* that this happens is luckily small enough, but it does make
sense to have an established protocol for such cases. Otherwise any
action will be considered "overstepping the boundaries" and/or "breaking
the rules", and then there's a huge (social) fallout that could have
easily been avoided. Like the discussion we're having now, only
amplified a lot.

> 
> Vast wholescale breakage is very rare and not something you can base
> policy on.

Black swan events are more common than optimists pray for

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Rich Freeman]

On Wed, Jan 22, 2014 at 7:34 AM, Patrick Lauer <patrick@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

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Wed, 22 Jan 2014 14:42:14 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> 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.

Looking at the rest of your mail besides this; I think that what needs
to be discussed further is which cases would be a ComRel matter and
which cases would not be.

There are some loosely defined borders we know of ("technical",
"personal", "CoC violation", "breakage", ...) but when it comes to
matters that lie on the borders of the above or there are combinations
possible, I think we have some situations where both solutions may be
possible, maybe we should try to work these out a bit further. 

As when we would wait till it happens and then start to discuss whose
matter this is, it would form a problem as well as a delay.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Alan McKinnon]

On 01/22/14 14:34, Patrick Lauer wrote:
>> Do you realise the message that is sent by denying someone access? You
>> > are saying that person is not good enough to work on Gentoo. Do you
>> > really want to send that message?
> Yes. And I have no problem being the Evil Guy who pulls the trigger,
> err, presses the enter key.
> 
> You are saying that *any* contribution should be accepted just to not
> hurt someones feelings.


No, I'm not even remotely saying that. Please go back and read gain what
I did say.

I never mentioned anything about "any contribution". What I did say
comes after the qualifier "by denying someone access", which is a very
far cry indeed from "any contribution".

I also have no problem being the Evil Guy, because I am that
sonofabitch. I really know what happens when you suspend/nuke/delete
access because I have done it. And every single time it was the wrong
thing to do.

The only time it was acceptable is for a runaway script or similar, or
an honest mistake where I can fix the fallout far faster than the user
can. As the sysadmin and root, I know more about the systems than the
users do, similarly in Gentoo land it's a fair assumption that the
average QA person is more knowledgeable about the tree and policies than
the average dev. So when QA takes action in a spirit of help and with
communication in place, all is good and things usually work out well.

When it swings the other way and suspension is done as a means of
punishment (to whatever degree) then QA has stepped beyond the bounds of
what QA is about and into something else.

I still don't see any suggestions in this thread on how to limit the
scope of what QA wants. No-one will seriously try prevent a good QA guy
from limiting damage, but what happens when QA itself abuses the policy?
And it will happen, we both know this. How does QA propose to curb that
downside?


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

On Wed, 22 Jan 2014 09:00:14 +0200
Alan McKinnon <alan.mckinnon@gmail.com> 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.

Can you avoid top posting? Had to scroll down to see who you reply to.

> 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.

We take a positive approach instead, access is "temporarily suspended".

> Do you realise the message that is sent by denying someone access? You
> are saying that person is not good enough to work on Gentoo. Do you
> really want to send that message?

That is an assumption and depends on the actual message you send to that
person; "temporarily suspending" someone goes with a reason. If that
reason is to talk with the person as to fixing up the breakage, where
afterwards the access gets restored; we're sending a different message.

> Vast wholescale breakage is very rare and not something you can base
> policy on.

Policy is there to prevent wholescale breakage; imagine Gentoo without
a policy present, that would be very rare. What do you then base on?

> Rich's most recent reply is the most sane proposal I've seen so far.
> Revoking access is a human problem and is solved with human solutions.

Which message? Why is it the most sane?

> Do beware the law of unintended side-effects.

Or unexpected benefits?

Yes, a law exists; but what are the benefits compared to the cost?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/20/2014 03:09 PM, Alan McKinnon wrote:
> On 01/20/14 15:59, Rich Freeman wrote:
>> On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman <TomWij@gentoo.org>
>> wrote:
>>> #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to
>>> suspend people
>>> 
>>> Whether this has actually happened is something that is
>>> questionable;
>> 
>> Not that this necessarily needs to make it into the GLEP, and
>> I'm still on the fence regarding whether we really need to make
>> this change at all, but things like access suspensions and other 
>> administrative/disciplinary procedures should be documented.  I
>> think whether this is a matter of public record or not is open to
>> debate, but I don't like the fact that we can really say for sure
>> when/if this has actually happened.
> 
> 
> Speaking as someone who had this power in his day job, for QA to be
> able to suspend accounts is a very bad idea indeed. It always ends
> badly. I suspended 20+ accounts in my current job over the years
> and the number of cases where it was the right thing to do is
> precisely 0.
> 
> It was always a case of ill-advised action taken out of
> frustration, or bypass the training step, or don't try hard enough
> to reach the "infringer" and communicate like grown adults. Yup, I
> did all three.
> 
> Suspending an account is a very serious thing to undertake, the
> effects on the suspended person are vast and this power should
> never lie with the person who is feeling the pain. Instead, there
> are well established channels to the body who can make the
> decision. If QA has a problem with a dev for any reason whatsoever,
> then QA should make a well-thought out case to that other body for
> decision. Anything else is madness and open invitation for it to
> all go south.
> 
> 

Yep. This proposal is actually another workaround that emerges,
because people do not communicate and ignore each other. This is a
common habit in the gentoo dev community and it seems we have accepted
that fact.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS3wDWAAoJEFpvPKfnPDWzPYYH/A87fN34q1ShBhPvIh2uqP1K
UogA7se08pol0abNpDenYM2qDcTxYWXRPgYS7xXcrjh1bbhDmI+/0zuW7vd8/AWh
V20TffIkMHr1hMWyFKysFD6VKZC8DYr8fCGkgEfTRAjv1mdGFvfX+k1cqUZ+VtKB
bNPiH5Op7EOqpBp/5oz/CmGNFB8nPPEsDRrUbkE/hBPO3JfufBVHdDnmgJg9s0Og
Yd5dS55wQTTX7mbLDL4LePDF5pEtM9LnGc2uLgvDrepyX0Z2rio8aNnn/UI0IrY2
p7gkpMK9aA8vSixuvz3qpQbDs0julAswv5ZjTNgu237nukp1yiJGcAwjCDrCRl0=
=HdSb
-----END PGP SIGNATURE-----