Merging bugsquad and the community QA team

We could (brainstorming):
- Update our logos to fit Ubuntu Brand Guidelines (http://design.ubuntu.com/brand/pictograms).
- Make a simple plan specially focused for students of computing related studies, and release it to universities; perhaps related with the One Hundred Papercuts project.

Other thoughts:
-

Other Concerns:
- While I fully support merging Bug Squad into the greater QA group, I have a single concern about Bug Control, brought up by a slight miscommunication on the corresponding Mailing List discussions on this proposal. Bug Control is a currently separate group with separate bug permissions and separate application procedures. Based on some discussion I had with C de-Avillez and Nicholas Skaggs, the general consensus was that Bug Control would be left alone during the merger. I would like to confirm this, of course, but the general agreement seems to be to leave Bug Control well enough alone during this merger. (concern added by teward)

bug control is off the table initially, long term bug control should live under the same umbrella

[amjjawad] While I do support this idea, I think we should take it easy and go for it step by step. Why? simply because this is an LTS release and the main focus is to make Ubuntu and other flavours as good as possible, as solid and stable as possible and everything else and in between to go as smooth as possible. It is 'not' about the merge process itself, it is about what could we face 'after' the merge :)
Are we fully ready for that merge?
Are the members of both teams are ready?
How exactly the merge will help?
What are the down sides of the merge?
Do we have a clear plan and goals?
Are we planning to recruit more volunteers?
If yes, then are we ready to guide them, mentor them, teach them, etc?
We need to discuss the things we failed to achieve the previous cycle
We need to discuss the things we successfully completed on the previous cycle
Highlight the successful experience and carry on with that
Avoid the failure we had before and learn from it

merge will help QA team learn how to be better bug reporters and triagers
can we develop more 1 to 1 relationships and mentoring for newcomers?

    g+ hangouts?

    tutorial videos

try to make the bugteam wikipages shorter? for a good TL;DR -example, see: https://wiki.ubuntu.com/Bugs/HowToTriage

You see, there are lots of topics to be discussed to make sure everything will go as smooth as possible. And, the big Q is: Are we ready for a full merge now? is it a good idea to go for a full merge now on this cycle?

Hopefully we could agree on that and come up with a solid plan for this cycle :)

- - - - - - - - -
[Alberto Salvia Novella (es20490446e)]

My experience is this: if you have to do a mess, do as soon as possible; and you will able to polish the hole system sooner, what is indeed the fuel of your project.

This doesn't mean to take risky actions; but rather that, if you're unsure, it's better to test now; so you will get feedback sooner too.

On the other hand, this kind of things have to be taken in a one by one manner; so when you feel the most important thing is polished enough, you take the next one. If you're working in too many things at the same time, then is when you meet the real garbage.

So decide if you can concentrate in this right now.

- - - - - - - - -

[Thomas Ward (teward)]

There was a concern I had about a discussion that came up on #ubuntu-bugs with Brian Murray and C de-Avillez about the process of merging the IRC channels or the mailing lists. My concern was if the channels #ubuntu-bugs and #ubuntu-quality are merged into #ubuntu-quality, that bug questions posed by users in the channel would get lost in the activity that -quality already has. While -quality has only a few hundred lines here in the past day, the activity amounts I've seen can vary closer to releases and when there are ISO testing milestones to reach. While I do not mind if the two are merged, because this means I personally have less IRC channels to join, does anyone else consider there to be a concern about whether what few questions we see in #ubuntu-bugs would get lost in the discussions on #ubuntu-quality at all if the channels merged?

This concern is also quite relevant around release dates, because as release dates for development releases approach, #ubuntu-quality is abuzz with discussions about ISO testing and autotests that still fail around release time and such, and it's definitely during those times I'm almost certain bug questions could get lost in those discussions.

- - - - - - - - -
[Alberto Salvia Novella (es20490446e)]

Yes, I think this is very probable to happen.

- - - - - - - - -
[Thomas Ward (teward)] (comment added on Nov 19 via the pad)

Then I suggest that we do not consider merging the IRC channels at this time. As we get closer and closer to release dates and triaging becomes even more important, it's quite possible things will get lost in #ubuntu-quality, so at least for the short-term (in relation to the merger) we leave the IRC channel #ubuntu-bugs alone.

[balloons] We can redirect #ubuntu-bugs to quality if we wish
[knome] I think it's better to keep them separate to avoid too much information in one channel (-quality is already relatively busy) - we can do #ubuntu-quality-bugs if you want structure ;)
[teward] That was my initial concern, with -quality being as busy as it is, I believe it is better, for now, to keep the bugs-specific items to be kept out of -quality for the sole reason of avoiding too much information in channel or discussion conflicts with the multiple discussions at once. (This is clearly-seen in the standard support channels, as an example of that being #ubuntu and all the conflicting discussions at once there) || #ubuntu-quality-bugs would work, if we want the structure, and if there's no objection from the ones in charge of the current #ubuntu-bugs channel (namely bdmurray)

Implementation details:

Bugsquad Property
Wiki (could probably keep stuff as it is as well)

    reformat some pages, try to make pages shorter

    cross-link to the bugsquad pages

    add QA Team header to bugsquad pages, and add bugsquad wiki links to header

IRC channel

    [balloons] I would propose merging, I don't think too much noise happens in one channel, I like to see activity :-)

    [bdmurray] agrees with having discussions in the same place being a good idea

launchpad teams (do we need to change anything?)

    make bugsquad a subteam?

    make other roles have subteams as well?

    not a priority for now, let's put off for now

mailing list

    benefical to have full view on what's going on

    let's merge them :-)

Knowledge Transfer

    Testers need to learn about bugsquad and bugsuaders might want to learn about testing :-)

    New QA team "roles" for tasks that we inherit from bugsquad

    Pass the knowledge in the regular QA meetings as needed, it'll not be a quick transition anyway

    Making sure bugsquad wikipages are up-to-date helps

Work items:
[knome] Help update the QA team logos to fit the Ubuntu Brand Guidelines: DONE
[nskaggs] create list of "experts" willing to mentor new folks: TODO
[ubuntu-qa] Review bugsquad wiki pages: TODO
[ubuntu-qa] Add QA team header to bugsquad pages, incorporate bugsquad wiki links to header: TODO
[nskaggs] Merge the bugsquad mailing list to -quality: TODO
[nskaggs] make sure tutorial videos happen for bug triage role also: TODO