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

[Rich Freeman <rich0@gentoo.org>]

On Mon, Apr 7, 2014 at 7:36 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> This is also already present in GLEP 48[1]:
>
>     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.
>
> We know what to do; however, we can't do it if we're not addressed.

So, I already sent this suggestion to qa@ last week, but:

I would recommend that QA consider some questions that at least seem
to be poorly understood (perhaps the process should be on the wiki):
1.  When should a QA member seek action regarding something in the tree?
2.  Does a QA member need to seek approval for their actions, and when?
3.  When seeking approval, how should a QA member do so?  How long do
they need to wait for a reply before taking action?
4.  How should the sought action be clearly communicated to those
whose approval is sought, and how should approval or disapproval be
communicated?

From what I've gathered about this case from IRC/etc there was a lot
of informal but probably well-intended communication going on and some
of it ended up being ambiguous.  This is hardly new to teams in Gentoo
- I've read some Council logs in the past and had trouble
understanding what was actually decided.  A good practice is to
clearly state a motion/proposal/etc, and then have everybody clearly
say they approve or do not approve it.  Bugzilla is a great place to
document such things if everybody isn't in IRC at the same time, and
it produces a log.  But, it is up to QA to define its processes.

What is in the GLEP is really just a basic policy - you need to come
up with a way of "operationalizing" it.  It is great that in the event
of a disagreement that majority approval is needed within QA, but in
this case not everybody in QA was consulted before the mask, and the
discussion wasn't formalized so it isn't obvious that disapproval
was/wasn't given.  There are no written policies, so I can't really
say zero_chaos broke any rules (nothing says you have to ask before
doing, or that when asking you need to explicitly get approval vs not
explicitly getting disapproval).

What we also don't want is a situation where one person in QA does
something.  Then somebody else objects and undoes it pending a vote.
Then the vote comes in and it gets reverted again.  Then the impacted
developer appeals to council or the problem gets fixed and then the
mask/etc gets dropped.  At that point all our users ragequit because
they just had a package upgraded three times and downgrated twice.

QA needs to provide guidance around when (in general) their members
should apply masks, and what steps if any they should take before
doing so.  If there is objection to what they come up with, we can
deal with it, but it would be beneficial to at least come up with
something.

That said, the Council/Trustees could probably afford to do the same.
:)  I think we've been following fairly good practices around making
clear decisions this year, but it isn't like it is written down
anywhere.  It has been a problem in the past.

Rich