Future of Ubuntu QA team in Launchpad

Thu Jan 21 15:09:01 UTC 2010

As a person interested in doing more testing (and new to this discussion), I
think there would be a benefit from a few testing leaders. Maybe organizing
the groups into the particular versions (1 desktop, 1 server, 1 netbook, 1
upgrade etc.)? This is sort of done through the sign up for updates, but a
more formal structure would be beneficial. I know that would help out in
focusing the reporting structure.

Best,

Scott

On Thu, Jan 21, 2010 at 9:58 AM, Sense Hofstede <sense at qense.nl> wrote:

> 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<https://launchpad.net/%7Eubuntu-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ə]
>
> --
> Ubuntu-qa mailing list
> Ubuntu-qa at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20100121/26ab67f8/attachment.html>