Re: [gentoo-project] 4 Lists, 2 Requests and a matrix.

[Tom Wijsman]

On Mon, 12 May 2014 12:03:52 -0700
Seemant Kulleen <seemantk@×××××.com> wrote:

>    - The QA team is an entirely brand new team.

For completeness, we replace an old team; the QA project is nothing new.

>    - The team-members were put in place by the collective assent of
> the Gentoo developer community.

Indirectly, yes, as the community has chosen the Council; directly, it
has been put in place by the Council (and 2 extra members by QA lead).

>       - No prior team was in place to spoonfeed them any
> information.  No batons to pass, no knowledge to transfer.
> Processes, guidelines, and frameworks, rules of engagement, rules of
> the road, etc. -- none of these existed for the QA team to orient
> themselves into their new roles.

Yes, there is a lack of knowledge codification; however, a small set of
content can be found if you spend the time digging Council meeting
logs and gentoo-qa ML material which is tedious to do.

Given that, I'm under the impression that it went lost under the
collective memory of the previous QA team; we've pinged them once or
twice before, but haven't received a reply.

At the moment I think we're past the hard part and have formed an idea;
however, you can state such thing at any point in time so it has yet to
be seen if that's really the case.

>       - The QA team members share a motivation.
>       -  To constantly improve the Gentoo experience.

Besides what I stated above, there is GLEP 48 which is a very valuable
document; we try to hold ourselves to it as much as we can, as that is
effectively written with what the Council directly wants from us (and
in extension, what the community indirectly wants from us).

> From this standpoint I'm seeing a ton of missed expectations. For
> example (stated and implied by words, if not intention) within Gentoo:
>
>    - *The QA team will fix everything.  Right now.  I meant,
> yesterday, sorry.*

s/will/might/ or s/will/should/; while some people on the QA team could
be seen as bug fixing monkeys, we don't have the resources (mostly time)
available to fix everything. Thus we can only fix and help where we can.

>    - *I am correct.  The other party is wrong.  It's so *obvious*. Why
>    isn't the QA team just addressing this already??*

It's obvious to both parties and they both want their own solution.

>    - *Why does QA get cc'd all over the place on bugzilla?*

QA team writes a Wiki entry for QA workflow, requested by the Council;
among other things, it is meant to help with knowing how to contact QA
and how QA works internally. As to avoid misunderstandings.

CC-ing the QA team works better if there is a non controversial action
to be taken.

CC-ing the QA team works worse if there is a controversial action
expected, or when there is looked for an action that could be
controversial and hasn't ever been previous discussed by the community. 

It is to be noted that due to the controversial nature, this is often
something that affects a larger share of the community. We thus want to
hear and consider the community's view on it as well; and yes, that's
what the earlier form of a pointer to gentoo-dev ML is all about.

>    - *Most of the things QA gets cc'd on have nothing to do with us.*

Sometimes we get CC-ed on bugs that are in the maintainer's scope, on
bugs that are personal and thus ComRel's scope, on bugs for which a
clear policy exists and the maintainer already respects that policy, ...

... which means that we have no action or decision to make there.

>    - *QA's job is to be the technical equivalent of ComRel.*

It works in a similar way in terms of escalation (discuss with your
peers and community first, then come to us), as well as working out
discussions (acting as the third reader); only taking a technical
action or decision when necessary, which is like ComRel not that common.

>    - *I'm not sure what the rest of the QA team thinks QA's job is?*

That what is stated in GLEP 48.

>    - *I just want to do this part of QA.*

That's entirely possible, nobody is forced to do certain parts.

>    - *Go raise this on the mailing lists, then council, then QA, if
> you don't like it.*

This should be clear given the above response to getting CC'ed.

>    - *QA is afraid of the community and wants to pacify everyone,
> which makes them ineffective.*

Where is this pacification? Is it that what is written in GLEP 48?

> According to the Principle of
> Humanity<https://en.wikipedia.org/wiki/Principle_of_humanity>,
> I must ascribe the best possible intention to someone else's actions
> and words.  (Allow that others are driven by the same pure
> motivations that drive me.)
>
> Which is related to my final observation: Gentoo developers, as a
> whole and as individuals, share the intention *to improve the Gentoo
> experience.*

+1

> Finally, my request:
>
>   1. QA Team: please unite as a team, and figure out:
>     1. Your ABI:
>       1. What should people expect from you as a team and you as
>          individual members and doers on that team.

GLEP 48 and the QA project page covers this, too much to summarize.

>       2. Your API:
>         1. How do people interact with you?  When is it
> appropriate?  What is the chain of conversation to get to you?

A Wiki that documents inquiries is being worked out by the QA team.

>       3. Your customers:
>         1. Your fellow developers.
>         2. Us users.

GLEP 48 covers this; indeed that, all developers and users.

>    2. Gentoo Developer Team at Large:
>      1. Please engage with the team that you guys have voiced into
> place: 1. What responsibilities are appropriate for their shoulders?
>        2. What authority is appropriate for them to be effective?

That is what GLEP 48 is all about; I suggest people to read it again,
suggesting corrections to the Gentoo Council if something in that
document or what the QA team does is considered as inappropriate.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

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