An idea on the structure of QA

[Jiří Kovalský]

Hello Nicholas,

    I am quite new to this mailing list so I apologize if my post will 
sound ignorant. :) Actually, I admit that my intention was to learn how 
community QA is organized at Ubuntu to get some inspiration and improve 
our own processes [1] at NetBeans.

[1] http://wiki.netbeans.org/NetCAT

    The new structure proposal is well written and clear to me. The 
Goals section though seems like you created it after the solution was 
found and not vice-versa as it should normally be in my opinion. Also I 
didn't understand the purpose of Use Cases section. Did you want to 
assign Mark, Jim, Kathy and Michelle to some team later in the document 
or these were only mentioned to keep the four basic types of 
contributors in mind?

    Finally, I might have overlooked it in the text, but would it be 
possible to participate in some Infrastructure team and in another 
Testing team at the same time? If so, is this what you really want? And 
out of curiosity, would there be a membership renewal process? Our 
8-years experience from cooperation with the NetBeans community is that 
although well known and seasoned testers are very useful, its typically 
brand new participants who excel.

I hope this feedback is at least somehow helpful.

Best regards,
--
Jiří Kovalský
NetBeans Community Manager
http://www.netbeans.org

On 14.3.2012 21:03, Nicholas Skaggs wrote:

> Hello everyone,
> Today during the weekly QA community meeting, I shared my idea for
> organizing the QA community to be more effective at communication and
> working efficiently with each other, in addition to helping recruit and
> retain new members and grow. I'd like to also share this idea with the
> mailing list and the community at large. I'll just repeat a little bit
> of what was spoken about on IRC for reference. The full log is available
> here:
>
> https://wiki.ubuntu.com/QATeam/Meetings/QA/20120314
>
> The background on this proposal stems from my own attempts at learning
> about QA in ubuntu. I went on a misson to list and catalog everyone
> doing QA work in ubuntu (although I'm sure I missed some people, and if
> so, I apologize!). I posted the results of this on my blog the other day.
>
> http://www.theorangenotebook.com/2012/03/whos-who-on-quality-in-ubuntu.html
>
> Once I had the list of teams, it became apparent that communicating and
> understanding everything that was going on was going to be hard. In the
> weeks following me creating my list, I learned about more teams, more
> interesting work being done, etc. It seemed like when I would hear about
> a new tool I would find out someone else in ubuntu had used/was using
> that tool and here was there work, etc. Given these experiences, I
> started writing some thoughts about a proposal to organize the QA
> community to meet 3 specific goals that I thought would be hard to meet
> under the current structure:
>
> Ease of Communication
> Ability to recruit and retain community members
> Ability to scale with growth potential
>
> These are also in the proposal, which you can read here:
> https://wiki.ubuntu.com/QATeam/ProposedTeamStructure
>
> I'd like everyone to remember that of course this is just an idea. I am
> hoping to spark some discussion about solving the problems that I have
> brought up. Namely, how can we better communicate as a diverse group of
> teams?; how can we work more effectively?; how can we grow our
> community? Ideas and input on the proposal, as well as the
> problems/solutions are very welcome. I want us to rally around solving
> these issues, and come to the best solution as a community for us to pursue.
>
> Lastly I wanted to bring up an important piece about the proposal. It is
> purposefully sparse on implementation details. I gave a proposed
> structure, but I did not directly assign teams into that structure. This
> was intentional. I want us as a community to talk about specific teams
> and the changes would happen to them as part of drafting a blueprint to
> implement this plan. To this end, the plan is focused more upon the work
> items we value and hold as part of the QA community and the people and
> roles they can fill to accomplish that work. The specifics on the teams
> those people belong to, I see as a part of the next steps in writing and
> executing an implementation plan.
>
> The timeline of next steps is to gather feedback and discussion on this
> proposal, decide to move forward with a proposal (this proposal, a
> modified version of it, or perhaps a different proposal entirely),
> create a workplan and finally execute the plan.
>
> Thanks,
>
> Nicholas