Media/WebRTC: Difference between revisions

Jump to navigation Jump to search

Media/WebRTC (view source)

Revision as of 16:48, 30 September 2017

467 bytes removed ,  30 September 2017
Updated triage guidelines
(Adding links to the testing and logging pages)
(Updated triage guidelines)
Line 18: Line 18:
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/53 Firefox 53 WebRTC & Web Audio Release Notes]
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/53 Firefox 53 WebRTC & Web Audio Release Notes]
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/54 Firefox 54 WebRTC & Web Audio Release Notes]
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/54 Firefox 54 WebRTC & Web Audio Release Notes]
 
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes/55 Firefox 55 WebRTC & Web Audio Release Notes]
==Product Backlog==
Go to [https://wiki.mozilla.org/Media/Bugs#WebRTC_Bugzilla_Queries WebRTC bugs] to search for all open WebRTC bugs (including untriaged and unconfirmed bugs).


===Triage Guidelines===
===Triage Guidelines===
The Product Backlog is continually maintained to ensure relative priorities are understood.  Individual priority may vary based circumstance.
The Product Backlog is continually maintained to ensure relative priorities are understood.  Individual priority may vary based circumstance.
* Priorities follow the Firefox Desktop Standard:
* Priorities follow the Firefox Desktop Standard:
** Priority 1 - Blocker, must-fix before shipping.  
** Priority 1 - Blocker, must-fix before shipping. Almost by definition of P1, the "affected" flags and "tracking" flags for the bug should be set when it's triaged. 
** Priority 2 - Major impact,  considering severity × probability. Not a blocker for shipping.
** Priority 2 - High priority backlog (bugs we are currently working on or will be working on next)
** Priority 3 - Average Bug.  definitely a problem, but doesn't stop someone from using the product.
** Priority 3 - Lower priority backlog
** Priority 4 - Minor or polish bugs that are real issues (especially in aggregate) and annoying.
** Priority 4 - Bugs we will accept patches for
** Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability.
** Priority 5 - Parking lot (Bugs we do not plan to spend any time on)


*RANK: As priority buckets start to have a large amount of bugs in them, the Rank field can be used to call attention to higher or lower rank and provide a way to sort easily in bugzilla.  To have some rhyme/reason to the order - Rank should relate to Priority.  The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - default to mid-range value.
*RANK: The Rank field lets us prioritize bugs within a priority bucket (P2, P3, etc) in bugzilla.  To have some rhyme/reason to the order - Rank should relate to Priority.  The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - the triager will default to mid-range value.
** P1  Rank options=1-19, default 15
** P1  Rank options=0-9, default 5
** P2  Rank options=20-29, default 25
** P2  Rank options=10-19, default 15
** P3  Rank options=30-39, default 35
** P3  Rank options=20-29, default 25
** P4  Rank options=40-49, default 45
** P4  Rank options=30-39, default 35
** P5  Rank options=50-59, default 55
** P5  Rank options=40-49, default 45
** any valid bugs that we don't believe we'll ever put resources on, but would accept patches for, go in "parking-lot" area
*** Note: P5 and "parking-lot"-labelled bugs are treated identically.  We no longer use "parking-lot"; it is a legacy classification.


<p> </p>
<p> </p>
*The Blocking-Flag called "Backlog" track bugs that are approved or not for the Backlog ("webRTC+", "parking lot")
*QE-Verify is a flag that developers should be setting. QE uses to filter which bugs they check.
*QE-Verify is a flag that developers should be setting. QE uses to filter which bugs they check.
**"+" means that QE should look at the bug and it can be verified with human eyes
**"+" means that QE should look at the bug and it can be verified with human eyes
**"-" means QE should not look at
**"-" means QE should not look at
***Typically QE-verify"-" goes with "in-testsuite" being set to "+", to show testing via another method.
***Typically QE-verify"-" goes with "in-testsuite" being set to "+", to show testing via another method.
*"Points" should be set when known (if nothing set - assumed a "1" or very small).  Most relevant if taking a bigger bug so we know when bugs are large bits of work.


===Filing a bug===
===Filing a bug===
Mreavy
Confirmed users
654

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1181487"

Navigation menu