Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08

[Tom Wijsman <TomWij@gentoo.org>]

On Mon, 7 Apr 2014 09:30:44 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> "how we already operate" isn't a documented practice.  I wouldn't
> bring it up if there wasn't apparent confusion.

It can be deduced from how we already operate, there isn't confusion
about that as months have passed; but yes, that could possible be
useful for new members that would join. Added another QA agenda item.

> > 1.  As stated in "[...] look out for the best interests of all
> > developers, as well as our users. [...] ensure developers have the
> > information they need, and that packages are maintained. [...]
> > ensure tree policies are respected [...]".
> 
> So, if any individual in QA on their own feels that taking an action
> in the name of QA furthers these goals, they may do so?

A definitive answer to this is hard to give, it depends on the action.
It boils down to communicating about it as well as common sense; and
that's why there is the GLEP answer to question (2), which gives some
room for QA members to do something and not have these actions wait.

> > 2. No, "In the case of disagreement among QA members the majority of
> > established QA members must agree with the action. [...]".
> 
> My question is whether they need to seek approval, and when. 
>
> I can read the GLEP just fine.  I'm not sure what you mean by, "No."
> Are you saying they don't need to seek approval before taking action?

As per GLEP 48, when there is disagreement (or doubt that there is). If
they're sure about their thoughts, why do they need to seek approval?

If this isn't the way we are expected to operate, then the GLEP should
be updated about this; but I don't think this is a resolution to this.

(And yes; as earlier in this thread, this is about expectations again)

> Honestly, this kind of ambiguity is exactly what I want us to avoid
> when we get into the operations of QA.  It is better to say, "no,
> pre-approval of individual QA actions is not needed because..." or
> "no, pre-approval of individual actions IS needed because..." Short
> answers to complex questions lead to interpretation.

This makes extra policy where there is none; and thus, the lack of there
being a policy is the answer here. The policy in answer (2) limits that.

> I think it is an important thing to clarify.  Are you suggesting a
> workflow where any individual in QA can take an action they feel is
> necessary, and then the rest of QA only comes into it if somebody
> notices and disagrees, at which point the action gets undone?  Or is
> the workflow that when somebody wants to take an action they first run
> it past the team?

There is no suggestion from me, what is and isn't in GLEP 48 works fine.
 
> Well, clearly nobody waited for a vote on this one. At least, I can
> find no record of a vote approving the mask on the new virtuals.

For there to be a vote the team needs to be aware; and as nobody that
disagreed send a mail out to them, nothing happened.

> If this is only done after a QA action is taken if there is
> disagreement, then we should clarify what happens in the meantime
> (does the mask/etc stay in place for a few weeks?).

As deputy lead, soon after, I've requested the mask to temporarily
stay until the team comes together to discuss it and/or decide if it
can stay or gets unmasked; as a lead, the day after, creffett decided to
take away the mask and asked Zero_Chaos to get approval from the team.

The mask, per GLEP 48, stays unless QA team or a lead decides otherwise.

> I think the importance of clarifying when individuals should act on
> their own becomes more important if any team discussion only comes
> after the fact.  If team discussion happens before actions are taken
> then there is less risk of inconsistent actions, but of course more
> latency before action can be taken.

I don't see how we would have ever been able to predict this case.

> The Trustees do this sort of thing all the time.  Log a bug, document
> a proposal, and individuals leave their votes in comments.  Generally
> it is done for things that are more routine and don't require
> discussion.  It has been suggested for the Council but so far the need
> hasn't arisen.

Neither has it for QA team; if someone feels so, he / she will do that. 

> I think it is important to have a way to deal with issues outside of
> meetings for a team like QA which is much closer to the daily
> operations of Gentoo.

Mail to the alias or filing a bug works; in this case, neither happened.

> The thing that bothers me about this particular case is that I've
> heard several on QA mention that they intended to express disagreement
> with zero_chaos's actions, but that their intent was never clearly
> stated as outright disapproval and was interpreted as just "be careful
> / think twice / etc" advice. 
>
> It wasn't clear that their approval was needed before taking action,

There is no policy that indicates approval is needed.

> and their disapproval wasn't explicit either.

Disapprovals were clearly put out to the QA leads; the first one was
retracted as a change in mind happened at that point, I wasn't around
when the second happened but it resulted in the removal of the mask.

It should be more explicit and send out to the whole QA team, not
just leads; this again brings us back to escalate in small steps, which
is something that applies to whole Gentoo and not just to the QA team.

> I don't want to suggest that if QA spots a rootkit in a package that
> they need to wait for a monthly meeting to do something about it.

And that's why a definitive answer to your question is hard to give.

> Common sense needs to prevail.  However, when the house isn't on fire
> it wouldn't hurt to have a somewhat orderly way to go about
> interventions.

That can happen in the form of stepwise escalations.

> I don't think you need a perfect set of rules either.  Any guideline
> is going to be subject to interpretation, and I'm not into crucifying
> people over that.  The goal though is to push back the grey areas
> reasonably far, and then rely on good attitudes and common sense to
> get us through the rest.
> 
> I really don't want to beat up on QA here.  I think you guys are
> generally doing great work.  I just think that there is probably a
> little room for improvement/transparency.

+1 Agreed; as stated on the ComRel bug, this is a case where we _all_
can learn from. Just by this case happening and thinking it through;
there are already a lot of preventative measures that come up in mind,
next time it happens people will be taken apart, their viewpoints will
be listened to in detail, helped further to properly escalate it, ...

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