canmove, Confirmed users
2,041
edits
User:Gmealer/QA Checklisting Program: Difference between revisions
User:Gmealer/QA Checklisting Program (view source)
Revision as of 00:01, 1 January 2012
, 1 January 2012→How do we get started?
| (22 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
= The QA Checklisting Program = | |||
== What is this? == | == What is this? == | ||
The QA Checklisting Program is an ongoing effort to document our processes in a way that will make us more effective as a team and more accessible to the Mozilla Community. | The QA Checklisting Program is an ongoing effort to document our processes in a way that will make us more effective as a team and more accessible to the Mozilla Community. | ||
The program involves creating checklists and associated | The program involves creating checklists and associated concise documentation for repeated processes, especially those that we expect to share with community members or that are of interest outside our team. | ||
== Why should we do this? == | == Why should we do this? == | ||
| Line 13: | Line 15: | ||
=== Transparency === | === Transparency === | ||
Other teams need to understand our processes, especially ones that directly affect them. Through documentation, other teams will know what and how much we're contributing. And we | Other teams need to understand our processes, especially ones that directly affect them. Through documentation, other teams will know what and how much we're contributing. And we can more easily get useful feedback as to whether we're doing the right things. | ||
=== Accountability === | === Accountability === | ||
| Line 29: | Line 31: | ||
=== Community === | === Community === | ||
Community energy is a precious resource, and we cannot afford to waste it. That which makes us efficient and agile makes the community efficient and agile as well. We are the community. | Community energy is a precious resource, and we cannot afford to waste it. That which makes us effective, efficient and agile makes the community effective, efficient and agile as well. We are the community. | ||
== How do we get started? == | |||
#'''Brainstorm Processes'''<br><br>Brainstorm at the whole-QA level as well as the subteam level. Identify all processes that are performed on a regular basis. Don't attempt to figure out if they should be checklisted yet, just get everything on the table.<br><br> | |||
#'''Identify Trackers'''<br><br>Create or find a way to track the list of processes so that they can be easily rearranged. It doesn't matter if the tracker is a wiki, Pivotal, spreadsheet, whatever. Use what works. Create a whole-QA tracker and a tracker for each subteam.<br><br> | |||
#'''Identify Indexes'''<br><br>Create placeholders to index completed checklists on wiki for QA and for each subteam. Don't concentrate too much on initial organization; a flat list for each placeholder is fine. As processes get added, organization will become more obvious.<br><br> | |||
#'''Prioritize Checklists'''<br><br>Add all processes to the tracker. Arrange the list of processes in the order that they should be checklisted. Guidelines for priority are:<br><br> | |||
#* Processes that can be performed by outside community should be higher. | |||
#* Processes that directly involve external teams or the community should be higher. | |||
#* Processes that should be performed as quickly as possible should be higher. | |||
#* Processes with a low margin of error should be higher. | |||
#* Processes performed very frequently should be higher. | |||
#* Processes performed very infrequently should be higher. | |||
#* Processes that are complex or have a lot of steps should be higher.<br><br> | |||
#'''Schedule Urgent Checklists'''<br><br>Some processes are either vital to the team, or so time-sensitive that they should be documented immediately. These are urgent checklists, and will likely already be at the top of the prioritized list. Move them to the top if necessary, and schedule resources now to create these.<br><br> | |||
#'''Create Checklists'''<br><br>Create urgent checklists first. Other checklists can be created opportunistically the next time the process is performed, or scheduled off the list in priority order when resources are available.<br><br> | |||
#'''Add to Indexes'''<br><br>As each checklist is created, it should be added to the appropriate index. If a checklist is shared between subteams but not across QA as a whole, add it to each subteam index that applies.<br><br> | |||
== What does a checklist look like? == | |||
General template as well as example TBA. | |||
== Should we checklist everything? == | |||
Discretion should be used as to what's important enough to checklist, and what level of detail of supporting documentation should be created. | |||
Documentation requires maintenance, and the more complete the documentation the more maintenance it will cost. Incorrect documentation is worse than no documentation, so do not document more than can be afforded. | |||
However, any processes with the specific high-priority qualities mentioned under "Prioritize Checklists" in [[#How_do_we_get_started.3F|How do we get started?]] should have a reasonably detailed checklist. | |||