User:Gmealer/QA Checklisting Program: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 25: Line 25:
=== Agility ===
=== Agility ===


Specialization enables deeper knowledge--at the cost of bottlenecks. If only one person is capable of a task, they must be free before the task can be performed. We should reduce specialization as much as we can afford without sacrificing knowledge. The ideal is that anybody should be able to perform any task as needed.
Specialization enables deeper knowledge—at the cost of bottlenecks. If only one person is capable of a task, they must be free before the task can be performed. We should reduce specialization as much as we can afford without sacrificing knowledge. The ideal is that anybody should be able to perform any task as needed.


=== Community ===
=== Community ===

Revision as of 22:33, 31 December 2011

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 program involves creating checklists and associated brief documentation for any repeatable processes, especially those that we expect to share with community members or that are of interest outside our team.

Why should we do this?

Reliability

We are the backstop. More than any other engineering team in Mozilla, it's vital that our processes are reviewable and repeatable. We must know exactly what we are doing and that what we are doing is right, and we must do it that way every single time.

Accountability

We take responsibility for the quality within Mozilla, and strive to ensure that every release is a good one. But bad releases will happen. When they do, it is very important that we are able to review exactly what we did so that we can understand what to do better.

Transparency

Other teams need to know what we're doing, especially when it directly affects them. We can give them a quick understanding of our processes and set their expectations appropriately. And we can more easily get useful and salient suggestions from outside as to what we might do better.

Efficiency

The ramp into Mozilla is a tough one. We waste valuable time with new employees just bringing them to minimally effective. Even experienced employees forget processes they don't perform often and need reminders. The cost of not having them is lost time and mistakes.

Agility

Specialization enables deeper knowledge—at the cost of bottlenecks. If only one person is capable of a task, they must be free before the task can be performed. We should reduce specialization as much as we can afford without sacrificing knowledge. The ideal is that anybody should be able to perform any task as needed.

Community

We must be as responsive as possible to the community. Community energy is a precious resource, and we cannot afford to waste it on scouring wikis for correct information, on time lost to training, and on eager contributors left idle for lack of an available task they know how to perform. That which makes us efficient and agile makes the community efficient and agile.

Visibility

We do a lot. We should show everyone how much.