Future of Ubuntu QA team in Launchpad

[Sense Hofstede]

2010/1/21 Dave Morley <davmor2 at davmor2.co.uk>:
> On Wed, 2010-01-20 at 22:56 -0500, Stéphane Graber wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Shane Fagan wrote:
>> > On Wed, 2010-01-20 at 15:53 +0100, Ara Pulido wrote:
>> >> Hello,
>> >>
>> >> During last Ubuntu QA meeting we discussed the future of the Ubuntu QA
>> >> team in Launchpad [1].
>> >>
>> >> Right now is a moderated team with a high entry barrier, which turned
>> >> out to be a bit useless: no one is really moderating it and it just
>> >> confuses people.
>> >>
>> >> We discussed some possibilities for the team, but we wanted to drop them
>> >> here in the list for discussion. Feel free to vote for any of them, or
>> >> add your own suggestion. The options would be:
>> >>
>> >> a) Keep it as it right now (moderated team, people have to apply).
>> >> b) Open the team to anyone who is interested in QA activities, and then
>> >> redirect them to the Bugsquad or Testing team depending on their
>> >> knowledge and preferences.
>> >>
>> >> During the conversation, we inclined toward B, but we want them to share
>> >> it with the rest before taking any actions.
>> >>
>> >> Thanks,
>> >> Ara.
>> >>
>> >> [1] https://launchpad.net/~ubuntu-qa
>> >>
>> > Im against this idea because its good to have a structure in place. Id
>> > like for the QA team on launchpad to handle the code for the SRU tools
>> > and Checkbox as well as any other QA related projects which shouldnt
>> > have open access privileges. So for bzr access to change certain QA
>> > tools they would need to ask for access (joining the QA team). So then
>> > it can be a controlled team and control the entire umbrella.
>> > The bug squad and the testing team both have open access anyway there is
>> > no reason to open the QA team.
>> >
>> > Shane
>>
>> I agree with both Shane and Sense, the idea behind the Ubuntu QA team
>> (as in, the Launchpad team) was to more clearly represent these who made
>> major contributions to one of the sub-teams (testing, bugsquad,
>> bugcontrol), helps managing that community (ISO testing, bug triaging,
>> automation, ...) and is often present on IRC, ML and during the meetings
>> to discuss QA issues.
>>
>> I still think that this role is important and that it helps people know
>> who to contact when they want to help and who's actively promoting QA in
>> Ubuntu. Making it non-moderated will likely end up with all of bugsquad
>> + bugcontrol + testing joining it, making the list grow to a few
>> hundreds and having the team completely loose its goal with the likely
>> ending of it not being used.
>>
>> That's just my opinion, I wasn't at the meeting today (clash with my
>> Lunch time, sorry) and can easily understand that some will have
>> completely different opinions.
>
> Shane I think you're wrong.
>
> The idea it this is the ground below the bottom of a 2 sided ladder one
> side testing the other side bugs.
>
> This is the team where people come and ask question to find out how they
> can help and then move on to one of the other teams.
>
> This therefore should have no access to any tools, as the majority of
> work for them is already handled by the different teams above this
> level.  As a tester I don't want bug commit tools and visa versa.
>
> If anything have this as the no entry requirements then sign with gpg or
> require recognition to say you will test or triage bugs as you are then
> becoming more serious about one field.
>
> Also it would be interesting to be able to have the testing members get
> the ability to have a test-masters level.  So that both testing and bug
> teams have a similar structure.
>
> So:
> 1. qa-team general sign up and enquires no tools (mails for bugs and
> testing)
> 2. Testing branch off qa-team, with ubuntu-testing the sign up to say
> you'll do it (first level of involvement) then testing-masters above
> that where you are invited to join (gpg signed second level of
> involvement with more access to stuff and commit rights for tools)
> 3. Bug branch off qa-team, with bug-squad the sign up to say you'll do
> it (first level as is) and bug-masters as an invite (gpg signed second
> layer of involvement as is)
I'm not so sure if it would be a good idea to open the floodgates for
QA team membership and make it a team like the Bug Squad. That would
allow anyone to join without having to show any commitment and without
having to do anything for the team. It would allow people to just
collect team icons for their Launchpad profile without contributing
actively to making the QA team a great and active team.

Furthermore, limiting the two other branches of the QA team would deny
the existence of the other (smaller) tasks of the QA team.

The idea of giving the QA team a kind of promotional role doesn't
sound too bad, though. We could make the team guide newcomers and
explain them our ways and point them to a possible QA subteam they
might like. This would also take some burden from the shoulders of the
subteams, especially of the smaller subteams.

Two different teams -- a moderation and a non-moderated team -- could
be useful if the role of the QA team would be bigger. However, I don't
foresee a large team with 20 to 50 people enthusiastically working
very hard to be admitted to the moderated team; simply because I
wouldn't know what they could do. We need a lot of people in the Bug
Squad and the Testing team can use any volunteer they can get as well.
However, making the coordinating team a very large and open team would
only achieve the need for an extra coordination layer to coordinate
this team of coordinators. That would be inefficient and bureaucratic.

Opening a team to anyone doesn't mean suddenly there will be loads of
people all fighting for the honour to do the tedious administrative
work that apparently is a bit forgotten sometimes. We should try to
revitalise the current QA team. Being more welcoming towards
(potential) new contributors could be a part of it, but an endless
stream of newcomers won't solve our problems.

Regards,
-- 
Sense Hofstede
[ˈsɛn.sə ˈɦɔf.steːdə]