Media/WebRTC: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(updated)
(Update debugging link)
 
(47 intermediate revisions by 7 users not shown)
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.   


==Project Status ==
==Releases & Notes==
*[https://wiki.mozilla.org/Platform/Roadmap#WebRTC_.2F_WebAudio Summary of our plans for this year]
*[https://wiki.mozilla.org/RapidRelease/Calendar Firefox Release Schedule Calendar]
*[https://mozilla.aha.io/published/fc5d6de0471e12abc297b3de748d972e?page=1 More detailed Roadmap], noting that the further out the more lose the targets are]
*[https://wiki.mozilla.org/Media/WebRTC/ReleaseNotes Firefox WebRTC & Web Audio Release Notes]
*[https://etherpad.mozilla.org/webrtcweekly Weekly stand-up notes]


==Contacts and Useful Links==
===Triage Guidelines===
*[https://wiki.mozilla.org/Webrtc/contacts Contacts for webRTC]
The Product Backlog is continually maintained to ensure relative priorities are understood.
*[https://wiki.mozilla.org/Webrtc/links Useful Links for webRTC]
* [https://mozilla.github.io/webrtc-landing/gum_test.html Click here] to test webRTC features in the Firefox browser


==Releases==
* Priorities follow the Firefox Desktop Standard:
*[https://wiki.mozilla.org/RapidRelease/Calendar Firefox Release Calendar]
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).
 
===Firefox 40===
<p> </p>
<bugzilla>
{
      "component":["WebRTC","WebRTC:%20Networking","WebRTC:%20Signaling","WebRTC:%20Audio/Video"],
        "bug_status":"RESOLVED",
        "include_fields":"id, summary, status, assigned_to",
        "target_milestone":"mozilla40"
}
</bugzilla>
<p> </p>
===Firefox 39===
<p> </p>
<bugzilla>
{
      "component":["WebRTC","WebRTC:%20Networking","WebRTC:%20Signaling","WebRTC:%20Audio/Video"],
        "bug_status":"RESOLVED",
        "include_fields":"id, summary, status, assigned_to",
        "target_milestone":"mozilla39"
}
</bugzilla>
<p> </p>
===Firefox 38===
<p> </p>
<bugzilla>
{
      "component":["WebRTC","WebRTC:%20Networking","WebRTC:%20Signaling","WebRTC:%20Audio/Video"],
        "bug_status":"RESOLVED",
        "include_fields":"id, summary, status, assigned_to",
        "target_milestone":"mozilla38"
}
</bugzilla>
<p> </p>
 
===Firefox 37===
<p> </p>
<bugzilla>
{
      "component":["WebRTC","WebRTC:%20Networking","WebRTC:%20Signaling","WebRTC:%20Audio/Video"],
        "bug_status":"RESOLVED",
        "include_fields":"id, summary, status, assigned_to",
        "target_milestone":"mozilla37"
}
</bugzilla>
<p> </p>
 
==Repository Location ==
All the Platform WebRTC code and the Desktop Loop Client code is in mozilla-central. There are no other active repos.  If you are trying to come up to speed on any of our code, please feel free to come to #media on irc.mozilla.com.  #media is our "virtual hallway".  You can hang out, ask questions, and get answers.
 
==Product Backlog==
<p> </p>
All work related to the ongoing development and maintenance of webRTC are collected and prioritized in the Product Backlog.  The goals of the Product Backlog are to:
* Enable work to be prioritized so that the team is always working on the most important features.
* Support continual planning as the product emerges so the plan matches reality.
* Improve forecasts so that the stakeholders make the best decisions about the direction of the product.
<p> </p>


<p> </p>
** 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. 
'''Product Backlog''' 
** Priority 2 - High priority backlog (bugs we are currently working on or will be working on next)
* [http://mzl.la/1BCZXck Bugzilla "webRTC+" tagged bugs]
** Priority 3 - Lower priority backlog
**Add the "Rank" Column to your results and sort on Rank
** Priority 4 - Bugs we will accept patches for
***The option to "Change columns" is at bottom of search results
** Priority 5 - Parking lot (Bugs we do not plan to spend any time on)
**Search is based on "backlog" - "does not contains the string" - "webrtc+"
* [http://mzl.la/1BD0meY Un-triaged or firefox-backlog- bugs]
 
<p> </p>
===Triage Guidelines===
The Product Backlog is continually maintained to ensure relative priorities are understood.  Individual priority may vary based circumstance.
* Priorities follow the Firefox Desktop Standard:
** Priority 1 - Blocker, must-fix before shipping.  
** Priority 2 - Major impact,  considering severity × probability. Not a blocker for shipping.
** Priority 3 - Average Bug.  definitely a problem, but doesn't stop someone from using the product.
** Priority 4 - Minor or polish bugs that are real issues (especially in aggregate) and annoying.
** Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability.


*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 that we don't think we can get to in the next 6 months should go in "backlog-" 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===
Line 115: Line 41:
*** has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
*** has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
<p> </p>
<p> </p>
'''Blocking FxOS'''
* [https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines%29 Blocking Guidelines relevant for FxOS bugs]
* Nominate bugs actually blocking FxOS release will set Project Flag: Blocking-B2G to the "{release number}?"


'''Contributor Engagement'''
'''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 [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
* Add Whiteboard tag of [good first bug] for contributors to pick up
==libwebrtc Updates==
* One can find documentation on the current libwebrtc fast-forward update process [[Media/WebRTC/libwebrtc_Update_Process|here]].
* The research and history on developing the fast-forward update process is documented [[Media/WebRTC/libwebrtc_Update_Process/automation_plan|here]]
* The 2H2020 transition process is documented [[Media/WebRTC/libwebrtc_Update_Process_Transition_Plan|here]].
* The old libwebrtc update process is documented [[Media/WebRTC/Legacy_Updating_Process|here]].
==Up-streaming Changes==
* One can find instructions for up-streaming changes [[Media/WebRTC/Up_streaming_Changes|here]].
==libsrtp Updates==
Maintained by Cisco, libsrtp needs to be vendored periodically. A description of that process can be found [[Meida/WebRTC/libsrtp_Update_Process|here]].
==Project Status ==
*[https://mozilla.aha.io/published/b40393012432847d857ee68299a8a82f?page=2 Detailed Roadmap], noting that the further out the more lose the targets are]
==Contacts and Useful Links==
*[https://mozilla.github.io/webrtc-landing/gum_test.html Click here] to try WebRTC features in the Firefox browser
*[https://wiki.mozilla.org/Webrtc/contacts Contacts for WebRTC]
*[https://wiki.mozilla.org/Webrtc/links Useful Links for WebRTC]
*[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/WebRTC_Debugging Debugging WebRTC Calls]
*[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) [RFC 5245] 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==
<p> </p>
<p> </p>
{| class="wikitable"
{| class="wikitable"
Line 130: Line 76:
! Meeting !! Day of week !! Pacific Time !! Eastern Time !! Central European Time !! Vidyo Room !! Notes
! 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 || webRTC-Apps || [https://etherpad.mozilla.org/webrtcweekly etherpad]
| "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 || [https://etherpad.mozilla.org/webrtcweekly etherpad]
|-
|-
|}
|}
** 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.
* 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.
** please update the etherpad if you cannot make the meeting (even if it's just to say you're on PTO)
** 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.
* [http://ietf.org/ IETF Berlin Upcoming Standards Meetings]
** please update the [https://etherpad.mozilla.org/webrtcweekly Stand-up Notes etherpad] if you cannot make the meeting (even if it's just to say you're on PTO)
* [http://ietf.org/ IETF Standards Meetings]


=== Notes ===
==Archived==
*[https://etherpad.mozilla.org/webrtcweekly webRTC weekly stand-ups]
===Notes===
*[https://etherpad.mozilla.org/haeLwWEkZV Loop front-end Daily Stand-up Notes]
*[https://wiki.mozilla.org/Media/WebRTC/archived Archived notes]
*[[Media/WebRTC/2014-04-29| Meeting Notes from Tue, Apr 29, 2014]]
*[[Media/WebRTC/2014-04-22| Meeting Notes from Tue, Apr 22, 2014]]
*[[Media/WebRTC/2014-04-15| Meeting Notes from Tue, Apr 15, 2014]]
*[[Media/WebRTC/2014-04-08| Meeting Notes from Tue, Apr  8, 2014]]
*[[Media/WebRTC/2014-04-01| Meeting Notes from Tue, Apr  1, 2014]]
*[[Media/WebRTC/2014-03-25| Meeting Notes from Tue, Mar 25, 2014]]
*[[Media/WebRTC/2014-03-18| Meeting Notes from Tue, Mar 18, 2014]]
*[[Media/WebRTC/2014-03-11| Meeting Notes from Tue, Mar 11, 2014]]
*[[Media/WebRTC/2014-03-04| Meeting Notes from Tue, Mar  4, 2014]]
*[[Media/WebRTC/2014-02-25| Meeting Notes from Tue, Feb 25, 2014]]
*[[Media/WebRTC/2014-02-18| Meeting Notes from Tue, Feb 18, 2014]]
*[[Media/WebRTC/2014-02-04| Meeting Notes from Tue, Feb  4, 2014]]
*[[Media/WebRTC/2014-01-28| Meeting Notes from Tue, Jan 28, 2014]]
*[[Media/WebRTC/2014-01-21| Meeting Notes from Tue, Jan 21, 2014]]
*[[Media/WebRTC/2014-01-14| Meeting Notes from Tue, Jan 14, 2014]]
*[[Media/WebRTC/2014-01-07| Meeting Notes from Tue, Jan  7, 2014]]
*[[Media/WebRTC/2013-12-17| Meeting Notes from Tue, Dec 17, 2013]]
*[[Media/WebRTC/2013-12-10| Meeting Notes from Tue, Dec 10, 2013]]
*[[Media/WebRTC/2013-12-03| Meeting Notes from Tue, Dec  3, 2013]]
*[[Media/WebRTC/2013-11-19| Meeting Notes from Tue, Nov 19, 2013]]
*[[Media/WebRTC/2013-11-14| Meeting Notes from Thu, Nov 14, 2013]]
*[[Media/WebRTC/2013-10-29| Meeting Notes from Tue, Oct 29, 2013]]
*[[Media/WebRTC/2013-10-22| Meeting Notes from Tue, Oct 22, 2013]]
*[[Media/WebRTC/2013-10-15| Meeting Notes from Tue, Oct 15, 2013]]
*[[Media/WebRTC/2013-10-01| Meeting Notes from Tue, Oct  1, 2013]]
*[[Media/WebRTC/2013-09-24| Meeting Notes from Tue, Sep 24, 2013]]
*[[Media/WebRTC/2013-09-17| Meeting Notes from Tue, Sep 17, 2013]]
*[[Media/WebRTC/2013-09-10| Meeting Notes from Tue, Sep 10, 2013]]
*[[Media/WebRTC/2013-09-03| Meeting Notes from Tue, Sep  3, 2013]]
*[[Media/WebRTC/2013-08-27| Meeting Notes from Tue, Aug 27, 2013]]
*[[Media/WebRTC/2013-08-20| Meeting Notes from Tue, Aug 20, 2013]]
*[[Media/WebRTC/2013-08-13| Meeting Notes from Tue, Aug 13, 2013]]
*[[Media/WebRTC/2013-08-06| Meeting Notes from Tue, Aug  6, 2013]]
*[[Media/WebRTC/2013-07-23| Meeting Notes from Tue, Jul 23, 2013]]
*[[Media/WebRTC/2013-07-09| Meeting Notes from Tue, Jul 09, 2013]]
*[[Media/WebRTC/2013-07-02| Meeting Notes from Tue, Jul 02, 2013]]
*[[Media/WebRTC/2013-06-25| Meeting Notes from Tue, Jun 25, 2013]]
*[[Media/WebRTC/2013-06-18| Meeting Notes from Tue, Jun 18, 2013]]
*[[Media/WebRTC/2013-06-04| Meeting Notes from Tue, Jun  4, 2013]]
*[[Media/WebRTC/2013-05-21| Meeting Notes from Tue, May 21, 2013]]
*[[Media/WebRTC/2013-05-14| Meeting Notes from Tue, May 14, 2013]]
*[[Media/WebRTC/2013-05-07| Meeting Notes from Tue, May  7, 2013]]
*[[Media/WebRTC/2013-04-30| Meeting Notes from Tue, Apr 30, 2013]]
*[[Media/WebRTC/2013-04-23| Meeting Notes from Tue, Apr 23, 2013]]
*[[Media/WebRTC/2013-04-16| Meeting Notes from Tue, Apr 16, 2013]]
*[[Media/WebRTC/2013-04-09| Meeting Notes from Tue, Apr  9, 2013]]
*[[Media/WebRTC/2013-04-02| Meeting Notes from Tue, Apr  2, 2013]]
*[[Media/WebRTC/2013-03-26| Meeting Notes from Thu, Mar 26, 2013]]
*[[Media/WebRTC/2013-03-21| Meeting Notes from Thu, Mar 21, 2013]]
*[[Media/WebRTC/2013-03-05| Meeting Notes from Tue, Mar 5, 2013]]
*[[Media/WebRTC/2013-02-26| Meeting Notes from Tue, Feb 26, 2013]]
*[[Media/WebRTC/2013-02-21| Meeting Notes from Thu, Feb 21 and Fri, Feb 22, 2013]]
*[[Media/WebRTC/2013-02-12| Meeting Notes from Tue, Feb 12, 2013]]
*[[Media/WebRTC/2013-01-29| Meeting Notes from Tue, Jan 29, 2013]]
*[[Media/WebRTC/2013-01-22| Meeting Notes from Tue, Jan 22, 2013]]
*[[Media/WebRTC/2013-01-15| Meeting Notes from Tue, Jan 15, 2013]]
*[[Media/WebRTC/2013-01-08| Meeting Notes from Tue, Jan  8, 2013]]
*[[Media/WebRTC/2013-01-03| Meeting Notes from Thu, Jan  3, 2013]]
*[[Media/WebRTC/2012-12-27| Meeting Notes from Thu, Dec 27, 2012]]
*[[Media/WebRTC/2012-12-18| Meeting Notes from Tue, Dec 18, 2012]]
*[[Media/WebRTC/2012-12-11| Meeting Notes from Tue, Dec 11, 2012]]
*[[Media/WebRTC/2012-12-04| Meeting Notes from Tue, Dec  4, 2012]]
*[[Media/WebRTC/2012-11-27| Meeting Notes from Tue, Nov 27, 2012]]
*[[Media/WebRTC/2012-11-20| Meeting Notes from Tue, Nov 20, 2012]]
*[[Media/WebRTC/2012-11-13| Meeting Notes from Tue, Nov 13, 2012]]
*[[Media/WebRTC/2012-10-31| Meeting Notes from Wed, Oct 31, 2012]]
*[[Media/WebRTC/2012-10-23| Meeting Notes from Tue, Oct 23, 2012]]
*[[Media/WebRTC/2012-10-16| Meeting Notes from Tue, Oct 16, 2012]]
*[[Media/WebRTC/2012-10-09| Meeting Notes from Tue, Oct  9, 2012]]
*[[Media/WebRTC/2012-10-02| Meeting Notes from Tue, Oct  2, 2012]]
*[[Media/WebRTC/2012-09-26| Meeting Notes from Wed, Sep  26, 2012]]
*[[Media/WebRTC/2012-09-18| Meeting Notes from Tue, Sep  18, 2012]]
*[[Media/WebRTC/2012-09-11| Meeting Notes from Tue, Sep  11, 2012]]
*[[Media/WebRTC/2012-09-04| Meeting Notes from Tue, Sept  4, 2012]]
*[[Media/WebRTC/2012-08-28| Meeting Notes from Tue,  Aug 28, 2012]]
*[[Media/WebRTC/2012-08-21| Meeting Notes from Tue,  Aug 21, 2012]]
*[[Media/WebRTC/2012-08-14| Meeting Notes from Tue,  Aug 14, 2012]]
*[[Media/WebRTC/2012-08-07| Meeting Notes from Tue,  Aug  7, 2012]]
*[[Media/WebRTC/2012-07-24| Meeting Notes from Tue, July 24, 2012]]
*[[Media/WebRTC/2012-07-17| Meeting Notes from Tue, July 17, 2012]]
*[[Media/WebRTC/2012-07-10| Meeting Notes from Tue, July 10, 2012]]
*[[Media/WebRTC/2012-07-03| Meeting Notes from Tue, July 3,  2012]]
*[[Media/WebRTC/2012-06-26| Meeting Notes from Tue, June 26, 2012]]
*[[Media/WebRTC/2012-06-19| Meeting Notes from Tue, June 19, 2012]]
*[[Media/WebRTC/2012-06-05| Meeting Notes from Tue, June 5,  2012]]
*[[Media/WebRTC/2012-05-31| Meeting Notes from Thu, May 31,  2012]]
*[[Media/WebRTC/2012-05-25| Meeting Notes from Tue, May 25,  2012]]
*[[Media/WebRTC/2012-05-15| Meeting Notes from Tue, May 15,  2012]]
*[[Media/WebRTC/2012-05-08| Meeting Notes from Tue, May  8,  2012]]
*[[Media/WebRTC/2012-05-01| Meeting Notes from Tue, May  1,  2012]]
*[[Media/WebRTC/2012-04-26| Meeting Notes from Thu, Apr 26,  2012]]
*[[Media/WebRTC/2012-04-19| Meeting Notes from Thu, Apr 19,  2012]]


*TRELLO
** [https://trello.com/b/weRHRo0X/loop-33-sprint-2-7-7 Loop Sprint work]




----
----

Latest revision as of 19:04, 10 August 2023

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

libwebrtc Updates

  • One can find documentation on the current libwebrtc fast-forward update process here.
  • The research and history on developing the fast-forward update process is documented here
  • The 2H2020 transition process is documented here.
  • The old libwebrtc update process is documented here.

Up-streaming Changes

  • One can find instructions for up-streaming changes here.

libsrtp Updates

Maintained by Cisco, libsrtp needs to be vendored periodically. A description of that process can be found here.

Project Status

Contacts and Useful Links

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


Retrieved from "https://wiki.mozilla.org/index.php?title=Media/WebRTC&oldid=1247568"