Mozilla has lots of QA documentation available: QMO, Main MDN QA landing page, Firefox OS automated testing landing page, and more. We ought to streamline our QA content by weeding out the obsolete stuff, updating the out of date stuff, and turning the different resources into a more cohesive resource.
- Chris Mills: MDN editor
- Marcia Knous: Main QA contact
Join the project
MDN is built by you, the reader! If you'd like to help make this documentation real, we'd like to hear from you. You may contact the writing team by clicking on their names above, or on our mailing list. If you're a new MDN contributor, please have a look at our contributor guide. You can also join the conversation in our IRC channel, #mdn.
Audit our current QA content
- Write a plan for reorganizing it into a more cohesive resource that lives on MDN.
- Migrate the non MDN content over to MDN.
- Update and reorganize the existing material on MDN.
- Make it easier for QA staff and volunteers to help perform QA work.
TBD: This work is not super urgent, but it would be nice to do it soon.
Note: Each milestone bug should block bug 1054344, which is a tracking/meta bug for this project.
- I want to write tests for Mozilla products
- I want to Help perform QA/testing work on Mozilla products
- I want to find out what tools I need to use to do QA work, what workflow I'd use, and how to get started.
- If I want to help with testing of Firefox, Firefox OS, or other Mozilla projects, where do I find out what needs to be tested?
Mainly reference and guide documents. This is mainly TBD. This can be done after the audit of existing docs.
The following items were discussed in a meeting between Chris Mills and the QA staff.
What should be kept where, on MDN?
Should we keep everything under a top level QA node, or should that node just contain generic stuff like introduction, how QA works at Moz, what all the tools are, how to get involved in the community, call to action, etc.? We could then put more applied Firefox / Firefox OS - specific stuff in the relevant zones and link to those from the main QA node. I think this latter idea is better for organization, as people are more like to think product first, then QA, rather than QA first, then product, although both camps do probably exist. This would allow us to cover both.
What should be moved over from QMO?
This is up for discussion. The content (on both MDN and QMO) needs to be audited to work out what stuff should be kept, and what stuff can be dumped due to being out of date or dupe.
There was also the question of whether the community / call to action stuff should remain on QMO, but the actual content should go on MDN, as QMO already has a bit of a following/page rank
I (Chris) personally think everything should just go on MDN, as MDN's page ranking will be higher, and it's good to have everything in one place and not fragmented. Plus if it is on MDN, it is all under the remit of the MDN editors, so we can maintain it.
Should QA be a zone?
I think so. I think QA falls under the zone definition, in that it is a specific function, product or action.
- QA team to audit existing material.
- Chris Mills to work out where to put all the material, and draw up plan for content strategy
This QMO Etherpad for further discussion/raw notes.