All,

I took minutes during the TB QA meeting at MozCamp.

Minutes can be found here starting on line 18:

https://etherpad.mozilla.org/tb-qa

Here's a summary:

Summary

• The rapid release has really changed the way we do testing. Community involvement has dropped off.

• Ludo has no chance of watching all of Bugzilla, and sometimes somebody comes in with a patch, and we don't see it because they don't set the right flags, and then it gets bitrotted and we lose a potential contributor.

One of the more recent bmo changes allowed more people to access whines... if we can construct a query for all new patches without reviewers (given Bugzilla, this might not be possible), it should be simple enough just to have someone get whined for this sort of stuff.

Action items

1. Get a list of people watching each TB component, and make sure we've got somebody with eyes on each one.
2. We're going to tackle the Papercuts list (10 bugs) to prove that we can deal with a list.
3. rkent(?) is going to send out a weekly status report on the Papercuts list, and what needs fixing, on what got fixed.

I was under the impression that the weekly status report on The List was going to be managed by QA / Support. It's also not clear who will be receiving the status report on The List.

1. When the list is empty, or close to being empty, QA is going to develop a process for creating the list (which includes the facility for devs to indicate that a bug is too difficult).
2. We need to come up with some critiera for choosing bugs like the ones on Papercuts. Then QA / Support will build the list.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor