QA Community Workflows

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)

[amjjawad] I have some ideas to share:

1- Add two more roles:

(A) Mentors: Those who are ready to take a newcomer to this area under their wings and take good care of them by showing them the right way and make sure they are ready for the dirty job that is waiting for them. NOT anyone can be a mentor. This requires special skills and experience. Mentors need to be helpful, friendly, know how to deal with a newcomer and never talk in a very complicated way, etc. Before recruiting more people to this area, we should be ready first to welcome the newcomers.

(B) Recruiters: Those who are dedicated to recruit more new volunteers to this area and they do need to have special skills and experience. They need to know how to deal with Social Media as it s a good place to recruit from. They should be super friendly. They need to focus on the users more than any other aspects, etc.

2- Having a Team Leader for each group/role and have someone, say vice TL or 2nd person in charge so that one could over the other and back him/her up whenever needed. Team Leaders will be in charge of organizing the teams, make sure to work as a TEAM (which is very important), motivate the members, etc.

That is all for now and I shall update this if I have more ideas.

AGENDA:
-- Roles
https://wiki.ubuntu.com/QATeam/Roles/
We've created roles for each of the main contribution roles -- how are they working?

Ideas for roles
- Outline role definitions and guidelines for each
- Create a workflow for each role
- Document workflows and roles on qa.ubuntu.com
- Communicate oppurtunities and encourage members to adopt a role
- Investigate ideas for buddy and mentorship systems, encouraging interested folks to seek out more senior members of community
- youtube video series for activities in each role?

Ideas for activities of roles
- Continue classroom series and expand their technical content?
- Host hackfests aimed at teaching beginneers in each of the role basic skills for development?
- bug reporting contest for exploratory testing?

From the blueprint:

[amjjawad] I have some ideas to share:
1- Add two more roles:
(A) Mentors: Those who are ready to take a newcomer to this area under their wings and take good care of them by showing them the right way and make sure they are ready for the dirty job that is waiting for them. NOT anyone can be a mentor. This requires special skills and experience. Mentors need to be helpful, friendly, know how to deal with a newcomer and never talk in a very complicated way, etc. Before recruiting more people to this area, we should be ready first to welcome the newcomers.
(B) Recruiters: Those who are dedicated to recruit more new volunteers to this area and they do need to have special skills and experience. They need to know how to deal with Social Media as it s a good place to recruit from. They should be super friendly. They need to focus on the users more than any other aspects, etc.
2- Having a Team Leader for each group/role and have someone, say vice TL or 2nd person in charge so that one could over the other and back him/her up whenever needed. Team Leaders will be in charge of organizing the teams, make sure to work as a TEAM (which is very important), motivate the members, etc.
That is all for now and I shall update this if I have more ideas.

I think this is/will be covered in our merging session :-)
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)

Notes:

Mentorship:
No formal roles, but create enviroment for it
Seek out potential volunteers to informally grab new people and help them along?

Video ideas:
– How to pick a test you want to run
– How to login to the QA tracker (incl. creating a Ubuntu SSO account)
– How to report a bug
– How to send a test report
– How to help debug and triage bugs
– Tools that are used in QA development
– How to set up a development platform
^^ add for each activity in roles, short, simple, good intros

exploratory testing:
hggdh> there is a lot of ad hoc testing by people-at-large, but we do not currently have an easy way for the casual tester to report results
<DanChapman> balloons, it is clear to me. But what about aswell as just saying 'all the time do a weekly call for testing' on the mailing list with an area to 'explore' for that week which will break some newcomers into what areas they should be exploring and an get an idea of how to get involved?
<knome> i think the area which needs clarifying is the priority an proportion of exploratory/general testing
<balloons> knome, I agree.. I want to see this be clarified, easy to understand, and doable
<knome> eg. should one rather get a test done one or twice than do some exploratory testing
<balloons> Well I'd like to see the general tests run, then exploratory testing
<ali1234> exploratory testing happens all the time whenever anyone is doing anything
<balloons> so run the outlined tests at least once :-) but then go wild
<ali1234> half the bugs i find, i find them while investigating (or even attempting to report) another bug
<knome> and possibly write down some examples what exploratory testing can be and specify the goals (eg. report bugs that you wouldn't find with the regular testing)
<knome> balloons, for me, that clarifies it a lot
<balloons> all good stuff.. I hate to cut this off. We'll chat again on this soon
* balloons copies out the conversation bits
<knome> balloons, one last thing is that i think package testing helps a bit with exploratory testing
<knome> they are kind of directed to the same direction, fulfilling the same need

Work items:
[nskaggs] Document workflows and roles on qa.ubuntu.com: TODO
[nskaggs] expand video content -- pref simple, categorized would be helpful. just more! Go slow :-) subtitles help (english). knome can help do effects/intro parts: TODO
[ubuntu-qa] seek out volunteers for informal mentorship roles: TODO
[nskaggs] continue exploratory testing conversation: TODO