Media/WebRTC

WebRTC is a free, open project that will bring peer-to-peer real-time audio, video and data to the web without plugins, using open web standards. Checkout the WebRTC project page set up by Google for interesting links and details.

Releases & Notes

• Firefox Release Schedule Calendar
• Firefox WebRTC & Web Audio Release Notes

Triage Guidelines

The Product Backlog is continually maintained to ensure relative priorities are understood.

• Priorities follow the Firefox Desktop Standard:

Go to WebRTC bugs to search for all open WebRTC bugs (including untriaged and unconfirmed bugs).

• • 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 - High priority backlog (bugs we are currently working on or will be working on next)
  • Priority 3 - Lower priority backlog
  • Priority 4 - Bugs we will accept patches for
  • Priority 5 - Parking lot (Bugs we do not plan to spend any time on)

• 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=0-9, default 5
  • P2 Rank options=10-19, default 15
  • P3 Rank options=20-29, default 25
  • P4 Rank options=30-39, default 35
  • P5 Rank options=40-49, default 45
    • Note: P5 and "parking-lot"-labelled bugs are treated identically. We no longer use "parking-lot"; it is a legacy classification.

• 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 QE should not look at
    • Typically QE-verify"-" goes with "in-testsuite" being set to "+", to show testing via another method.

Filing a bug

• Open a bug under Product:"Core" || Component: "WebRTC, WebRTC:Audio, WebRTC:Network or WebRTC:Signaling"
  • After triage, bugs will be marked "firefox-blocking", with a Priority, and a Rank
• If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+
  • Before it can be given a Rank it should:
    • be in an actionable state
    • for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
    • for feature requests or enhancements, it means that there's a clear problem statement or suggestion
    • has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months

Contributor Engagement

• Add Whiteboard tag of [well filed] to the well filed bugs to acknowledge that we appreciate the effort and thoroughness
• Add Whiteboard tag of [good first bug] for contributors to pick up

Project Status

• Detailed Roadmap, noting that the further out the more lose the targets are]

Contacts and Useful Links

• Click here to try WebRTC features in the Firefox browser
• Contacts for WebRTC
• Useful Links for WebRTC
• Running tests for WebRTC in Firefox
• Getting WebRTC logs in Firefox

Meetings

Meeting	Day of week	Pacific Time	Eastern Time	Central European Time	Vidyo Room	Notes
"Weekly Stand-up"	Wednesday	6:00AM - 6:30AM & 1:30 - 2:00 PM	9:00AM - 9:30PM & 4:30 - 5:00 PM	3:00PM - 3:30PM & - 10:30PM-11:00PM	webRTC-Apps	etherpad

• Stand-up = 2 minutes on what have you been working on, planning to work on, and are you blocked. Bring-up topics for longer Discussion at end if needed.
  • Developers and active contributors only need to attend one of the two sessions each week. We have 2 sessions due to the number of very different time zones throughout the team.
  • please update the Stand-up Notes etherpad if you cannot make the meeting (even if it's just to say you're on PTO)
• IETF Standards Meetings

Archived

Notes

• Archived notes

---