Media/WebRTC: Difference between revisions
Sescalante (talk | contribs) (removing archived info to seperate page) |
Sescalante (talk | contribs) (formatting) |
||
Line 4: | Line 4: | ||
*[https://wiki.mozilla.org/Platform/Roadmap#WebRTC_.2F_WebAudio Summary of our plans for this year] | *[https://wiki.mozilla.org/Platform/Roadmap#WebRTC_.2F_WebAudio Summary of our plans for this year] | ||
*[https://mozilla.aha.io/published/fc5d6de0471e12abc297b3de748d972e?page=1 More detailed Roadmap], noting that the further out the more lose the targets are] | *[https://mozilla.aha.io/published/fc5d6de0471e12abc297b3de748d972e?page=1 More detailed Roadmap], noting that the further out the more lose the targets are] | ||
==Contacts and Useful Links== | ==Contacts and Useful Links== | ||
*[https://wiki.mozilla.org/Webrtc/contacts Contacts for webRTC] | *[https://wiki.mozilla.org/Webrtc/contacts Contacts for webRTC] | ||
*[https://wiki.mozilla.org/Webrtc/links Useful Links for webRTC] | *[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 | *[https://mozilla.github.io/webrtc-landing/gum_test.html Click here] to test webRTC features in the Firefox browser | ||
==Meetings== | |||
<p> </p> | |||
{| class="wikitable" | |||
|- | |||
! 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] | |||
|- | |||
|} | |||
* 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 [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 Berlin Upcoming Standards Meetings] | |||
==Releases== | ==Releases== | ||
*[https://wiki.mozilla.org/RapidRelease/Calendar Firefox Release Calendar] | *[https://wiki.mozilla.org/RapidRelease/Calendar Firefox Release Schedule Calendar] | ||
===Firefox 40=== | ===Firefox 40=== | ||
Line 124: | Line 135: | ||
* Add Whiteboard tag of [good first bug] for contributors to pick up | * Add Whiteboard tag of [good first bug] for contributors to pick up | ||
== | ==Archived== | ||
===Notes=== | |||
=== Notes === | |||
*[https://wiki.mozilla.org/Media/WebRTC/archived Archived notes] | *[https://wiki.mozilla.org/Media/WebRTC/archived Archived notes] | ||
Revision as of 18:31, 17 April 2015
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.
Project Status
- Summary of our plans for this year
- More detailed Roadmap, noting that the further out the more lose the targets are]
Contacts and Useful Links
- Contacts for webRTC
- Useful Links for webRTC
- Click here to test webRTC features in the Firefox browser
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 | 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.
- 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 Berlin Upcoming Standards Meetings
Releases
Firefox 40
17 Total; 0 Open (0%); 17 Resolved (100%); 0 Verified (0%);
Firefox 39
18 Total; 0 Open (0%); 18 Resolved (100%); 0 Verified (0%);
Firefox 38
13 Total; 0 Open (0%); 13 Resolved (100%); 0 Verified (0%);
Firefox 37
20 Total; 0 Open (0%); 20 Resolved (100%); 0 Verified (0%);
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
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.
Product Backlog
- Bugzilla "webRTC+" tagged bugs
- Add the "Rank" Column to your results and sort on Rank
- The option to "Change columns" is at bottom of search results
- Search is based on "backlog" - "does not contains the string" - "webrtc+"
- Add the "Rank" Column to your results and sort on Rank
- Un-triaged or firefox-backlog- bugs
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.
- P1 Rank options=1-19, default 15
- P2 Rank options=20-29, default 25
- P3 Rank options=30-39, default 35
- P4 Rank options=40-49, default 45
- P5 Rank options=50-59, default 55
- any that we don't think we can get to in the next 6 months should go in "backlog-" area
- 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.
- "+" 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.
- "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
- 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
- Before it can be given a Rank it should:
Blocking FxOS
- Blocking Guidelines relevant for FxOS bugs
- Nominate bugs actually blocking FxOS release will set Project Flag: Blocking-B2G to the "{release number}?"
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
Archived
Notes