Media/WebRTC: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Replaced individual release notes with a link to the release notes collection page)
(Seems like we should link to these - activity ongoing, e.g. Lots of Bug 1544770 activity. Documentation, etc needed re. privacy - incl. competitive advantage.)
Line 1: Line 1:
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 [http://www.webrtc.org/ WebRTC project page] set up by Google for interesting links and details.   
WebRTC is a free, open project that brings peer-to-peer real-time audio, video and data to the web without plugins, using open web [[standards]].  Checkout the [http://www.webrtc.org/ WebRTC project page] set up by Google for interesting links and details.   


==Releases & Notes==
==Releases & Notes==
Line 55: Line 55:
*[https://wiki.mozilla.org/Media/WebRTC/Tests Running tests for WebRTC in Firefox]
*[https://wiki.mozilla.org/Media/WebRTC/Tests Running tests for WebRTC in Firefox]
*[https://wiki.mozilla.org/Media/WebRTC/Logging Getting WebRTC logs in Firefox]
*[https://wiki.mozilla.org/Media/WebRTC/Logging Getting WebRTC logs in Firefox]
*[https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04 IETF Draft: "Using Multicast DNS to protect '''privacy''' when exposing ICE candidates"] (AKA mDNS; Interactive Connectivity
      Establishment (ICE) [RFC5245] protocol)
*[[Media/WebRTC/Privacy]]
*[[Media/WebRTC/Architecture]]
*[https://wiki.mozilla.org/index.php?search=Media%2FWebRTC%2F&title=Special%3ASearch&fulltext=1 etc.]


==Meetings==
==Meetings==

Revision as of 22:58, 3 January 2020

WebRTC is a free, open project that brings 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

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

Contacts and Useful Links

     Establishment (ICE) [RFC5245] protocol)


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