QA Community Action Plan

[Anthony Hughes]

Good Evening Everyone,

I'm writing here to start a discussion about goals for the QA Community (both long-term and short-term). Identifying the tent-poles of our community, the long-term goals, and the short-term wins are all critical to developing and executing a successful action plan.

After some internal discussion, we've come up with a good set of ideas to begin with.

1) Events
* Leverage Mozilla and non-Mozilla events as much as possible
* Leverage Mozilla Reps and Stewards in Geographic areas
* Have QA gear to pass out at all events
* Develop a QA events calendar that tracks events we are participating in
* Commit resources to make the MozCamps successful
* QA presenters in attendance, as well as a QA specific "track"

2) Enable QA community members to become involved in Ownership
* Bugzilla
* Testdays
* Features
* Events
* Code reviewer/committer
* Empower core contributors to become amabassadors, enable them to build satellite communities

3) Make QMO active rather than passive
* Clearly defined entry paths to contributing on all teams/projects
* Bucket large tasks into smaller chunks so it's easier for the community to choose
* Update the QA video with Marcia's video talking about why people get involved with QA contribution
* Job descriptions for contributor roles
* Clearer steps to get involved on Nightly first run page, link to QMO

4) Mozillians.org
* Use as an entry point for new QA contributors
* Membership drive to get known contributors into Phonebook

5) Education
* Apply the working relationships with schools like Seneca and Waterloo to other schools
* Create a self-paced learning program so contributors can teach themselves when we are not available

6) Infrastructure
* need to have a management system in place to handle scale of newcomers > active contributors > core contributors
* need a way to gather metrics, visualize trends, react timely to community needs (ie. dashboard)

7) Community Giving Program
* provide tablets, hardware, etc to core contributors (ex. Seth's Community Giving program) -- requires funding commitment
* create a program to reward contributors based on earning points and/or badges

I encourage everyone to engage us in discussion. Feel free to add your own ideas, give feedback on these ideas, and ask questions. It's important that this action plan be of the community.

Thank you very much,

Anthony Hughes
Quality Engineer
Mozilla Corporation

[Anthony Hughes]

One thing I saw Tony Chung mention tonight via email which I don't want to get lost is a point about us needing to update our wiki documentation. I'd actually like to take that one step further in suggesting that we remove (archive) documentation that is completely deprecated, migrate static/frozen/unchanging documentation to QMO, and ensure wiki documentation is accurate and discoverable.

In fact, I think a "wiki cleanup" project is something which can be executed with community support.

Side-bar:
Wiki is best suited for ever changing documents with multiple authors/contributors (ie. project pages, test plans, planning of meetings/events, etc ). QMO is best suited for documents which are fairly static (won't change much over time) and few authors, but many consumers. Things like user guides, team pages, archive of old test plans, events, and meeting notes, etc.

Anthony

_______________________________________________
dev-quality mailing list
dev-q...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-quality

[Geo Mealer]

----- Original Message -----
> From: "Anthony Hughes" <ahu...@mozilla.com>

> suggesting that we remove (archive) documentation that is completely
> deprecated, migrate static/frozen/unchanging documentation to QMO,
> and ensure wiki documentation is accurate and discoverable.

100% agreed.

>
> In fact, I think a "wiki cleanup" project is something which can be
> executed with community support.

Also agreed, though I think the indexing of "what needs done" probably needs to start with us. But we can generate a task list from that and then farm it out.

> Side-bar:
> Wiki is best suited for ever changing documents with multiple
> authors/contributors (ie. project pages, test plans, planning of
> meetings/events, etc ). QMO is best suited for documents which are
> fairly static (won't change much over time) and few authors, but
> many consumers. Things like user guides, team pages, archive of old
> test plans, events, and meeting notes, etc.

Mostly agreed. I don't think it's straightforward to archive something that started on wiki to QMO. So, I'd suggest an archive section for wiki that we move stuff too that we want to keep (and that we only keep things we need to).

User guides...possibly. WordPress is such a PITA to update vs. wiki that I'm really only in favor of keeping landing pages on QMO in its current form, and having almost all actual information on wiki.

That'll be particularly true as we bring in more community members. I don't think they should all have QMO editor access; the revision control isn't good enough to make that OK. So anything any community member might edit (which is almost everything) should be on Wiki IMO. Anything that we want limited edit access to should be on QMO.

Geo

[Anthony Hughes]

Great points, Geo.

Thanks!

[Archaeopteryx]

Hi.

> 1) Events
Consider spreading the date range in which QA runs (maybe with someone
at the first day present). Having it always on the same day causes some
people always being unable to attend.

> * Bucket large tasks into smaller chunks so it's easier for the community to choose roles
This can maybe not over-emphasized so people who just want to contribute
few time or try contributing have a good chance to do so.

> * Clearer steps to get involved on Nightly first run page, link
> to QMO

Please get rid of the video. The tab is pretty resource hungry

> 4) Mozillians.org
> * Use as an entry point for new QA contributors

Don't have to high expectations on existing community members coming to
QA, I don't know of any members being idle and not knowing what to do to
help Mozilla. As far as I know, Mozillians has showing contributions on
its roadmap which QA could have an advantage from its implementation.

> * create a program to reward contributors based on earning points and/or badges

Just my experiences with this:
From testdays years ago (with one person rewarded, eligible once per
year if I remember correct): The people who participated did much work,
but the work of some was void or had to be checked by someone else (they
skipped working steps to get more points). The people who participated
in those days and are still active now were already involved somewhere
else in Mozilla.
I don't know about what kind of rewards you are talking, on
addons.mozilla.org we ran last year a review competition for add-on
reviews to decrease the review backlog and the review count was the only
metric. This year, it stretches again over two months, and along to the
review count, security and adherence to review policies have an impact.
These contests shift behaviour of the editors who review the add-ons: A
trend is towards easy to review add-ons which don't need much time,
locking add-ons pending review by having multiple review tabs open etc.
Also keep in mind different motivations dependent on the conditions of
the member (like pay/hour in his home country) or motivations by lack of
resources like time compared to other team members or being active in an
area lacking appropriate metrics.
For myself, after addons.mozilla.org getting paid editors, I think I
shifted priorities away from it because I know someone will care about
the work there.

Archaeopteryx

[Anthony Hughes]

Great feedback, Arch. You've given me at least a couple of good ideas.

Thank you.

----- Original Message -----
From: "Archaeopteryx" <archae...@coole-files.de>
To: dev-q...@lists.mozilla.org
Sent: Thursday, January 26, 2012 2:27:21 PM
Subject: Re: QA Community Action Plan