176140 - Make [e-mail] the QA for: Layout, Block & Inline, Floats, Fonts and Text, and R & A Pos components

Status: VERIFIED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[timeless]

split from bug 160347 comment 43.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

pasting relevant part from cited comment here, to make this report more useful.
-------------------------------------------------------------------------------
The proposed QA contacts are not (with the exception of madhur) very active in
the Mozilla layout community, and shouldn't in my opinion be made QA contacts
without first demonstrating that they understand CSS layout. I hereby volunteer
for QA of the Layout, Layout: Block & Inline, Layout: Floats, Layout: Fonts and
Text, Layout: HTML Frames, and Layout: R & A Pos components, since I believe I
currently do more work in those areas of Mozilla QA than the currently assigned
QA contacts.

Comment 2

[lchiang]

QA contacts are also signed up to:
1.  verify bugs on branch(es) and trunk
2.  execute all testcases in a structured manner for regression/functional
testing as agreed upon with development on all supported platforms (tier 1)
3.  help development with triaging incoming bugs in an area and prioritize them,
as necessary
4.  create automation as necessary for testing
5.  cover for others in all above areas to meet deadlines in case the main qa
contact is out
There may be more, but I'm meeting with Asa (when he returns from vacation) to
clarify the role of QA contact and the assumed responsibilities for that role.

Regards,
Lisa

Comment 3

[Hixie (not reading bugmail)]

Branches are the responsability of the branch owners, QA contact duties should
IMHO only extend as far as the trunk. That is to say: while QA contacts are
welcome to also verify bugs on branches, the trunk is what matters.

Regular testing and testcase development is not a part of the duties of QA
contacts, it is the part of the work of the people filing bugs. Naturally,
someone who is a QA contact should also be developing test cases and filing
bugs, but that is not part of the wark of being a QA contact.

The work of a QA contact is primarily triaging. In Layout components we get a
huge number of invalid and duplicate bugs, and thus the main work of a QA
contact is to confirm or invalidate new bugs. Triaging can also include
minimising test cases.

Naturally, there is nothing stopping other people from helping with QA, indeed
many people do this on a regular basis. I would highly recommend anyone thinking
of volunteering to be a mozilla.org QA contact to spend several weeks helping in
the area that they wish to work in.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I agree with some of Ian's comments here, in particular, that understanding the
requirements of a component well is necessary in order to test it (see my
comments in bug 172191 comment 16 for why).  However, I think some of his
comments are not true in general, but are true for Layout.  In particular,
triaging being a major part of the QA contact's responsibilites is true only in
areas that receive, as many but *not all* parts of Layout do, large numbers of
external bugs.  I also think the role of a QA contact should be broader than
either the description in comment 2 or the description in comment 3, as I
described in bug 172191 comment 16 (although I didn't mention triaging there,
perhaps partly since it's not true in general, but more importantly since I forgot).

Comment 5

[lchiang]

Asa - go ahead and do as you want on this bug (request).  I don't have the
bandwidth to comment further on this.

Comment 6

[Asa Dotzler [:asa]]

Everyone involved in this seems to have a slightly different take on what's the
most important task(s) for a QA contact to perform. 

While I think that writing and running testcases and reporting bugs is extremely
important I don't see how being the QA contact helps or hinders that effort
significantly. So let's take that out of the problem for a minute here.

That leaves verifications and triage. I'm sure that everyone interested is
capable of doing both but I'm assuming that Hixie favors triage and Netscape
needs verifications to happen on a particular schedule that it's assumed Hixid
wouldn't meet. 

Being the QA contact would help in verifications because changing a bugs status
has always belonged to the Assignee and QA contact (and the reporter in some
cases). But that's not set in stone and it's not unreasonable to assume a second
QA contact that handles this part of a bug's lifecycle. Being the QA contact
also helps if you're the one doing the majority of the triage in a particular
area because of the bugmail notifications, although watching and/or queries
mitigate the disadvantage of not being QA contact for triage somewhat. 

I tend to think that verifications are a bit less important than triage. From my
 experience shipping the last 20+ Mozilla releases I can say that I've slapped
my head and said "Doh!" more times because we shipped with a bug we had reported
but didn't get the proper triage than shipping with a bug we thought we had
fixed but didn't. So if my options were having the best possible triager or the
best possible verifyer occupying that default spot I think I'd go with triage.

But surely there's some convenient way that we can get the triage expertise that
Hixie brings and also make it easy for Netscape QA to verify bugs on a schedule
that meets Netscape's needs. It seems silly to waste either of these
contributions because somewhere we got the idea that we couldn't have different
people doing different tasks. 

Comment 7

[Hixie (not reading bugmail)]

I would be very happy for anyone to verify bugs that I am QA contact for. That
requires nothing more than doing a query regularly and verifying the bugs in
question. Triage, on the other hand, requires immediate notification of the new
bugs, which only bugmail (or query equivalent, since if I used bugmail I would
get overwhelmed in a matter of minutes) can produce.

So I don't see how making me QA contact for said components would stop
Netscape's QA team from doing their job, but I do see how the current situation
hampers my getting to know about new layout bugs.

Note: as David pointed out, by comments above were specifically related to these
layout components, and not networking or UI components.

Comment 8

[Hixie (not reading bugmail)]

->me

Comment 9

[Hixie (not reading bugmail)]

Done.

Comment 10

[timeless]

vrfy fixed

Comment 11

[gerardok]

Fine, Ian, you can be the default QA contact for these components.  Kevin,
please let me know if there is any problem with triaging, or bug verifications.