I updated https://wiki.mozilla.org/B2G/QA/Triage#Summary_of_Keywords_and_Flags 
to include more information on what was called out in the below email. The 
decision on these rules was made internally within the QA team. I realize now 
that this wasn't well communicated publicly when we determined these rules, 
which is probably why there's confusion here.

----- Original Message -----
> From: "Tim Chien" <[email protected]>
> To: "Jason Smith" <[email protected]>
> Cc: "dev-b2g" <[email protected]>, "dev-gaia" 
> <[email protected]>
> Sent: Wednesday, September 10, 2014 11:58:20 PM
> Subject: Re: QA Keywords - Focusing on Using One Keyword to Focus on the 
> Immediate Need
> 
> Jason,
> 
> Thank for sending out the note here.
> 
> -- Should the rule here be document somewhere on the wiki instead of
> burying in the mailing list?
> -- AFAIK many of the rules was being enforced months before this note.
> Who made the decision on these rules and why developers wasn't
> properly communicated (and consulted) beforehand?
> 
> I am not saying the rules doesn't make sense -- they make a lot of
> sense given out QA resource constraints -- I just want to make sure we
> don't have frustration coming out of hidden rules in the future.
> 
> 
> On Sat, Sep 6, 2014 at 7:43 AM, Jason  Smith <[email protected]> wrote:
> > Hi Everyone,
> >
> > I've received feedback from our test team that some people are adding
> > multiple QA keywords onto a bug, instead of adding a single keyword for
> > the immediate need, which is causing confusion to the test team on what
> > the immediate need of the QA request. The process is documented here -
> > https://wiki.mozilla.org/B2G/QA/Triage#Summary_of_Keywords_and_Flags, but
> > in summary:
> >
> > * Only one keyword should be used to focus on the immediate QA need.
> > ** Example: We aim to get branch checks first before we do a window, as
> > branch checks helps us confirm an issue is truly a regression before we
> > start to bisect this. In this case, we start with qawanted here to do
> > branch checks. After branch checks are complete, the tester will add
> > regressionwindow-wanted to work on getting a window for a particular bug
> > if it's a blocking issue.
> > ** Exception is for qaurgent - that's used in conjunction with a QA keyword
> > to bump the priority of the QA request. It should only be used for bugs
> > with critical impact at a bare bones level (e.g. smoketest, all automation
> > is down due to X bug).
> > * We only focus on doing regression windows on blocker bugs only due to
> > resource cost requirements needed to do a window. If you would like to
> > have a window for a particular bug, then make sure to figure out if the
> > issue is a blocker first. If it is a blocking issue, then feel free to add
> > the regressionwindow-wanted keyword.
> >
> > Feel free to reach out to Tony and I on any questions you have.
> >
> > Sincerely,
> > Jason Smith
> > _______________________________________________
> > dev-gaia mailing list
> > [email protected]
> > https://lists.mozilla.org/listinfo/dev-gaia
> 
> 
> 
> --
> Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
> OS, Mozilla Corp. (Taiwan)
> 
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to