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
--
Ubuntu-qa mailing list
Ubuntu-qa@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa
