MozillaWiki

Firefox/searchandaddon: Difference between revisions

Page Discussion

Firefox/searchandaddon (view source)

Revision as of 18:52, 17 May 2016

7,349 bytes added ,  17 May 2016
m
→‎Key Bugzilla Queries: fixed query
m (first draft)
 
(84 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=Search and Add-ons=
=Firefox Search=
 
problem statement or why we do this project and the scope of work focused on - intro for someone brand new.
problem statement or why we do this project for someone brand new.
 
==Project Introduction==
* '''Team Mailing list:''' if applicable
* '''Team IRC Channel:''' where does this team "hang-out"
*[https://wiki.mozilla.org/Firefox/IterativeDevelopment Summary of our plans for this year]
**links back to main Firefox page - need to create a section on main page for team summaries.  provides high-level plans for the year for Desktop management.
*[https://mozilla.aha.io/published/fc5d6de0471e12abc297b3de748d972e?page=1 More detailed Roadmap], noting that the further out the more lose the targets are
* '''Dependencies:''' feature, partner, resource, etc. that impact this projects ability to succeed - put links to other project pages.
 
==Links to Current info==
The [https://wiki.mozilla.org/Firefox/searchandaddon/links Links wiki page] is the central location for current focus, Roadmap, Metrics, UX, Marketing, tech-architecture, and more.
 
==Roles and Responsibilities==
The [https://wiki.mozilla.org/Firefox/Contacts Contacts Page] has the Roles and Responsibilities for this team, partner teams, and external partners involved in this project.


==Meetings & Communications==
==Meetings & Communications==
Line 23: Line 8:
! 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
|-
|-
| "Stand-up" Meetings || Monday, Tuesday, Wednesday, Thursday || 8:00AM - 8:30AM || 11:00AM - 11:30PM || 5:00PM - 5:30PM || webRTC-Apps || [https://etherpad.mozilla.org/haeLwWEkZV etherpad]
| '''Planning''' || bi-weekly at the start of the iteration on Tuesday|| 9:00AM - 10:00AM || 0:00AM - 0:30PM || 0:00PM - 0:30PM || team vidyo room || [https://etherpad.mozilla.org/searchplanning etherpad]
|-
|-
| "Pull Meetings" || bi-weekly at the start of the iteration on ___ || 8:00AM - 8:30AM || 11:00AM - 11:30PM || 5:00PM - 5:30PM || webRTC-Apps || [https://etherpad.mozilla.org/haeLwWEkZV etherpad]
| '''Stand-up''' & '''Triage''' || TBD - 1 hour off week (first 1/2 stand-up, second half optional triage) || 0:00AM - 0:30AM || 0:00AM - 0:30PM || 0:00PM - 0:30PM || Team vidyo room || [https://wiki.mozilla.org/Firefox/searchandaddon#Key_Bugzilla_Queries Bugzilla queries], [https://etherpad.mozilla.org/searchplanning etherpad]
|-
|-
| "Retrospective" || Friday || 8:00AM - 9:00AM || 11:00AM - 12:00PM || 5:00PM - 6:00PM || webRTC-Apps || [https://etherpad.mozilla.org/loop-retrospectives etherpad]
|}
|}
*Links to mailing list or all communication channels
 
<p> </p>
 
==Key Bugzilla Queries==
* '''[http://mzl.la/1TGrUtG Team Product Backlog]:''' 
** Add '''fxsearch''' to triaged bugs and set Priority
**Optional
***Add a '''short descriptive area tag''' in the whiteboard when possible, to visually group bugs quickly in a list. ex: "[visual refresh] fxsearch"
**'''Importance''' will be left at default, "normal", unless a bug is on the line of being one Priority higher and lower - and then will be marked "Major" or "Minor" accordingly.
* '''Priorities''' follow this Standard:
** Priority 1 - Blocker, must-fix before shipping or a priority feature we are including in this release.
** Priority 2 - Major impact,  considering severity × probability. Not a blocker for shipping.  For Features we'd really like it, but wouldn't hold shipping for it.
** 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.
<p> </p>
 
<p> </p>
*'''[http://mzl.la/1LqCwiy Untriaged Bugs]:'''Bugs under Firefox::Search without [fxsearch] in whiteboard
<p> </p>
<p> </p>


Line 35: Line 37:
<p> </p>
<p> </p>
==Schedule==
==Schedule==
'''Release timing'''
*[https://wiki.mozilla.org/Release_Management/TeamWiki Firefox main release schedule] is the master location for the dates when each Firefox version goes to Aurora, Beta, & Release.
*[https://wiki.mozilla.org/Release_Management/TeamWiki Firefox main release schedule] is the master location for the dates when each Firefox version goes to Aurora, Beta, & Release.
'''Sprints''' (if team is using 2 week sprints)
'''Firefox 41 Release'''
*[https://wiki.mozilla.org/Firefox/IterativeDevelopment#Upcoming_Iterations schedule for 2 week increments (3 Sprints per Fx Release)]
* '''Iteration 41.2:'''  Tuesday May 26 - Monday June 8
**There is a field in Bugzilla there is a field for "Iteration" that has the iteration number and the last day in that sprint:
* '''Iteration 41.3:'''  Tuesday June 9 - Monday June 29
***<FxRelease#>.1 - <last day before uplift>
** ''Note:  IT 41.3 is a 3-week iteration.''
***<FxRelease#>.2 - <last day before uplift>
<p> </p>
***<Fxrelease#>.3 - <last day before uplift>
'''Firefox 42 Release'''
* '''Iteration 42.1:'''  Tuesday June 30 - Monday July 13
* '''Iteration 42.2:'''  Tuesday July 14 - Monday July 27
* '''Iteration 42.3:'''  Tuesday July 28 - Monday August 10
<p> </p>
==Themes==
As we plan what's coming next, [https://docs.google.com/a/mozilla.com/document/d/1de2o8Osl_z98BBfkt243i-dHdcKmQB15xJ9rShkwk3Q/edit?usp=sharing these are areas being discussed].  This is not a commitment to the next projects - just our scratch area, but it is in order of relative priority - including the work we've pulled for the sprints.
*'''Partner Engine:''' issues relating to the integration of our partner's search engines
*'''Search Suggestions:''' Adding search suggestions to the awesomebar
*'''Search Hijacking:''' Keep users on the search engine that they want
**'''Add-on Signing'''
 
*'''Search UI:''' basically how our search access points work/look
 
<p></p>
Things we want to do - but not starting until higher priorities are done:
*TBD - add as things come up
<p></p>
Other common Themes that will be mixed in the backlog as they come up:
*'''UX:''' this tag is less a theme - more a marker so UX knows we need something from them on that bug- it often lives with other Themes and the UX comes off when we get the info.  Unless it's a unique UX bug - then UX stays.
*'''error:''' bug we've seen come in that we prioritize along side Theme work - often not Theme specific.
*'''tech-debt:''' work to make development smoother (test harness, dev tools, documentation, etc.)
*'''metrics:''' work specific to improving visibility into the product - but not required for a feature
*'''investigation''' or '''watch:''' needs investigation or just watching to see if it's reproducible and get an idea of the impact / cause.
<p></p>
At this point we are wrapping up other project work, risk is that it will carry over beyond 40.3.  Need to clarify/set expectations for Search Suggestion timelines/features.
<p> </p>
 
==Current==
===Iteration - 41.3, through June 29===
[https://bugzilla.mozilla.org/show_bug.cgi?id=958204 Theme 958204] '''Search Suggestions'''
<p> </p>
{| class="wikitable collapsible collapsed" style="width: 100%"
! Suggestions: Allow user to select a query from search suggestions in Awesome Bar
 
|-
|
* '''ID:'''  [https://bugzilla.mozilla.org/show_bug.cgi?id=1162140 Bug 1162140]
** Suggestions was turned on in Nightly to find bugs
** Disabled now until we land "opt-in/opt-out" user choice control.
 
<p> </p>
<bugzilla>
{
"f1":"blocked",
"o1":"equals",
"v1":"1162140",
"include_fields":"id, summary, status, assigned_to, cf_fx_points"
}
</bugzilla>
|}
<p> </p>
 
<p> </p>
{| class="wikitable collapsible collapsed" style="width: 100%"
! Suggestions: Search Suggestions in the AwesomeBar should be clearly identified as such
 
|-
|
* '''ID:'''  [https://bugzilla.mozilla.org/show_bug.cgi?id=1162142 Bug 1162142]
* UX done - hoping work will be done as well - dependent on bugs from landing first part of search and auto complete bugs
<p> </p>
<bugzilla>
{
"f1":"blocked",
"o1":"equals",
"v1":"1162142",
"include_fields":"id, summary, status, assigned_to, cf_fx_points"
}
</bugzilla>
|}
<p> </p>
 
{| class="wikitable collapsible collapsed" style="width: 100%"
! Partner Engine: Support server-driven setting of search defaults
 
|-
|
* '''ID:'''  [https://bugzilla.mozilla.org/show_bug.cgi?id=1169280 Bug 1169280]
* Asked for status on server side work - checking on other potentially required bugs.
<p> </p>
<bugzilla>
{
"f1":"blocked",
"o1":"equals",
"v1":"1169280",
"include_fields":"id, summary, status, assigned_to, cf_fx_points"
}
</bugzilla>
|}
<p> </p>
 
 
'''Details'''
* Biz dev project has taken priority.  Florian is 100% devoted to that work
* UX design for opt-in/opt-out is a priority (as Search Suggestions is disabled until this lands)
** [https://bugzilla.mozilla.org/show_bug.cgi?id=1169280 Bug 959567[User Story] Implement search suggestions opt-in/out UI] is candidate for Aurora uplift if we don't get implemented in 41.3
*'''Unified Autocomplete''' bugs are being resolved (large project / several bugs)
**Will enable in Nightly in this iteration
<p> </p>
Collection of priority work the team has committed to complete on in a two-week iteration.
<p> </p>
*[https://wiki.mozilla.org/Firefox/searchandaddon#Key_Bugzilla_Queries view in Bugzilla]
 
<p> </p>
<bugzilla>
{
        "assigned_to": "dtownsend@mozilla.com, dao@mozilla.com, mak77@bonardo.net, mjaritz@mozilla.com, shorlander@mozilla.com, adw@mozilla.com, markh@mozilla.com, florian@queze.net",
        "include_fields":"id, summary, status, assigned_to, whiteboard, cf_fx_points",
        "cf_fx_iteration":"41.3 - Jun 29"
 
}
</bugzilla>
 
<p> </p>
 


==Themes==
<p> </p>
As we plan what's coming next, these are areas being discussed.  This is not a commitment to the next projects - just our scratch area, but it is in order of relative priority.  (after the work we've pulled for the sprints).
*finishing Theme 1 (large change)
*Theme 2: any time constraints/dependencies
*Theme 3: quick why
Things we want to do - but parking lot until higher priorities are done:
*Process Improvement: Theme
*Other platform Investigation
*Tech-debt: any time constraints/dependencies
*Theme 4
*Quality: description of areas
*Theme 5
'''Risks'''
*Risk 1 : ex: Roadmap goals for the release in November are too high for ____(dev, UX, PM?) resources by x amount (bugs? points? UX resources).  likely will not make any features beyond x, y, z.
*Risk 2 : ex: Dependency on a service that is not established/planned for from another team.  Need help prioritizing if we should delay the feature in this project or raise the priority in the other team based on their existing backlog
==Status Reports==
[https://wiki.mozilla.org/Mobile/Firefox_for_iOS/Status_Report/21-Apr-2015 example from Jenn's]


==Current (queries)==
*Many options for how teams want to present this information. 
*[https://wiki.mozilla.org/Program_Management/ProjectPlanTemplate/Queries Sample queries to visualize the bugs] in bugzilla
*Some examples of teams using [https://wiki.mozilla.org/Firefox/Iterative_Hello_Development#Current Iteration], by [https://wiki.mozilla.org/Media/Webrtc#Releases Release], by tracking bug
==Past==
==Past==
*Pipeline of work that has been completed and moving through Aurora and Beta to release.
===Iteration - 41.2, through June 8===
*Ideally these aren't just queries, but human readable so folks know what is coming in x release.
User Story this iteration: "As a user, when I enter text in the location bar, I will be presented with suggested search queries from the search default in the AwesomeBar dropdown that update as I continue to enter text to provide me with common queries related to the text I have entered."
 
No selection actions, no queries, just suggests being fetched from the provider and displayed in the AwesomeBar dropdown. We know that Unified Complete is a blocker, and as such wasn't positioned as a story, but some parts are required to complete the work to address the first story.
 
'''Details'''
* Still figuring out who is on which teams based on work load, so some flux.  will update before Stand-up.
* Folks finishing up work from existing projects in this iteration still, as developers free up moving onto highest priority work.
* UX for User Stories was taken and first User stories for '''Suggestions''' related to [https://docs.google.com/document/d/1de2o8Osl_z98BBfkt243i-dHdcKmQB15xJ9rShkwk3Q/edit top 3 users stories for search '''suggestions''']
**'''Unified Autocomplete''' bugs completing (large project) - bug to enable in Nightly in this iteration
* Live view into bugzilla for all contributors on Partner Search and tagged for Iteration 41.1
**Other [https://wiki.mozilla.org/Firefox/searchandaddon#Key_Bugzilla_Queries Key Bugzilla Queries are here]
 
<p> </p>
<bugzilla>
{
        "assigned_to": "dtownsend@mozilla.com, dao@mozilla.com, mak77@bonardo.net, mjaritz@mozilla.com, shorlander@mozilla.com, adw@mozilla.com, markh@mozilla.com, florian@queze.net",
        "include_fields":"id, summary, status, assigned_to, whiteboard, cf_fx_points",
        "cf_fx_iteration":"41.2 - Jun 8"
 
}
</bugzilla>
 
<p> </p>
 
 
<p> </p>
 
===Iteration - 41.1, through May 25===
User Story this iteration: "As a user, when I enter text in the location bar, I will be presented with suggested search queries from the search default in the AwesomeBar dropdown that update as I continue to enter text to provide me with common queries related to the text I have entered."
 
No selection actions, no queries, just suggests being fetched from the provider and displayed in the AwesomeBar dropdown. We know that Unified Complete is a blocker, and as such wasn't positioned as a story, but some parts are required to complete the work to address the first story.
 
'''Details'''
* Folks finishing up work from existing projects in this iteration still, as developers free up moving onto highest priority work.
* Started bugs related to [https://docs.google.com/document/d/1de2o8Osl_z98BBfkt243i-dHdcKmQB15xJ9rShkwk3Q/edit top 3 users stories for search '''suggestions''']
**'''Unified Autocomplete''' bugs that are blocking Search Suggestions are under [https://bugzilla.mozilla.org/show_bug.cgi?id=1157952 bug 1157952] for this iteration
*Search hijacking is work that wasn't a newly started Theme, but was under progress and bugs are being taken from that area.
* Live view into bugzilla for all contributors on Partner Search and tagged for Iteration 41.1
**Other [https://wiki.mozilla.org/Firefox/searchandaddon#Key_Bugzilla_Queries Key Bugzilla Queries are here]
 
<p> </p>
<bugzilla>
{
        "assigned_to": "dtownsend@mozilla.com, dao@mozilla.com, mak77@bonardo.net, mjaritz@mozilla.com, shorlander@mozilla.com, adw@mozilla.com, markh@mozilla.com, florian@queze.net",
        "include_fields":"id, summary, status, assigned_to, whiteboard, cf_fx_points",
        "cf_fx_iteration":"41.1 - May 25"
 
}
</bugzilla>
 
<p> </p>
 
 
<p> </p>
 
 
===Iteration - 40.3 through May 11===
* Focus on folks [http://tinyurl.com/m7kz29w wrapping up bugs carried over from previous projects in addition to taking on new work as free up].
* '''Search Suggestions''' will be the first feature focus for this team
**As a team we reviewed the working [https://docs.google.com/document/d/1de2o8Osl_z98BBfkt243i-dHdcKmQB15xJ9rShkwk3Q/edit User Story document]
**Kev filing User Story bugs under [https://bugzilla.mozilla.org/show_bug.cgi?id=958204 bug 958204]
**'''Unified Autocomplete''' bugs that are blocking Search Suggestions are under [https://bugzilla.mozilla.org/show_bug.cgi?id=1157952 bug 1157952]
* Live view into bugzilla of bugs marked [fxsearch] and Iteration 40.3:
** Iteration Bug Selection:  [https://docs.google.com/a/mozilla.com/spreadsheets/d/1hD85MNJt-0BeAwfJ9SNwXdr8-oZjVruK_othgq3Bxdc/edit?usp=sharing View Status Board]
**Other [https://wiki.mozilla.org/Firefox/searchandaddon#Key_Bugzilla_Queries Key Bugzilla Queries are here]
 
<p> </p>
<bugzilla>
{
        "assigned_to": "dtownsend@mozilla.com, dao@mozilla.com, mak77@bonardo.net, mjaritz@mozilla.com, shorlander@mozilla.com, adw@mozilla.com, markh@mozilla.com",
        "include_fields":"id, summary, status, assigned_to, cf_fx_points",
        "cf_fx_iteration":"40.3 - 11 May"
 
}
</bugzilla>


=Product Backlog=
==Key Bugzilla Queries==
*put key queries here so folks can find simply
<p> </p>
<p> </p>
All work related to the ongoing development and maintenance of the Firefox Desktop Product 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>
==Bugzilla Agile fields==
Several Fields have been added this year into bugzilla for Agile tracking that you may want to leverage:
*'''Iteration''': right now this has the 3 previous and future 2 week sprints for Firefox release schedule - shows iteration (40.1) and uplift date.
*'''Points''': Fibonacci series 1,2,3,5,8,13]
*'''Rank''': see Rank use description under [https://wiki.mozilla.org/Program_Management/ProjectPlanTemplate/Firefoxdesktop#Triage_Guidelines Triage Guidelines]
**Rank will not show under your Product::Component unless you request it by filing a bug with "bugzilla.mozilla.org :: Administration".  You need to give a list of acceptable editors (usually the folks that can triage).
<p> </p>
<p> </p>


===Iteration - 40.2 April 27===
*Normally there would be a summary of features worked on / progress / blockers
*Normally [https://wiki.mozilla.org/Firefox/Iterative_Hello_Development#Past list of bugs closed like this one]
<p> </p>
<p> </p>
'''Product Backlog''' 
*There needs to be a way to mark the bugs you have triaged versus not.  Firefox uses the flag for "firefox-backlog". 
*If you are not strictly desktop, there's also an option to add you team to the blocking-flag "backlog". 
**ex: the webRTC team uses webRTC+ for bugs they are accepting and "parking lot" for ones they are not.  The queries are based on product/component - so multiple teams can use "parkinglot" and just request a new tag <team name>+ tag by filing a bug under "bugzilla.mozilla.org :: Administration"
*ex: [http://mzl.la/18g6hk2 Bugzilla Ranked "Firefox-backlog+" list]
**Add the "Rank" Column to your results and sort on Rank to view order of work.
***The option to "Change columns" is at bottom of search results
**Search is based on "Flags" - "contains the string" - firefox-backlog+
*[http://mzl.la/18Xoxhm Un-triaged bugs]
**Search is based on not having the Firefox-backlog+ or Firefox-backlog-


=Product Backlog=
All work related to the ongoing development and maintenance of the Firefox Desktop Product are collected and prioritized in the Product Backlog.  The goals of the Product Backlog are to:
* Improve work prioritization, so the team is always working on the most important features.
* Simplify continual planning, so the plan matches reality.
* Improve visibility so that the stakeholders make the best decisions about the direction of the product (call out risks early, relative priorities, trade-offs)
<p> </p>
<p> </p>
<p> </p>


==Triage Guidelines==
==Triage Guidelines==
The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting.
The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting.
* Priorities follow this Standard:
* '''Priorities''' follow this Standard:
** Priority 1 - Blocker, must-fix before shipping.  
** Priority 1 - Blocker, must-fix before shipping.  
** Priority 2 - Major impact,  considering severity × probability. Not a blocker for shipping.
** Priority 2 - Major impact,  considering severity × probability. Not a blocker for shipping.
Line 108: Line 267:
** Priority 4 - Minor or polish bugs that are real issues (especially in aggregate) and annoying.
** 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.
** Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability.
 
<p> </p>
*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''': 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
** P1  Rank options=1-19, default 15
** P2  Rank options=20-29, default 25
** P2  Rank options=20-29, default 25
Line 116: Line 275:
** P5  Rank options=50-59, default 55
** 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
** any that we don't think we can get to in the next 6 months should go in "backlog-" area
<p> </p>
<p> </p>
*The Firefox-backlog flag is used to track bugs that are approved for the Backlog "+"  
*The '''Firefox-backlog''' flag is used to track bugs that are approved for the Backlog "+" (or Backlog - to not be looked at for a while)
*QE-Verify is a flag that developers should be setting on bugs they are working on. This is used for QE to filter which bugs they check
*Add '''whiteboard''' tag to bugs [fxsearch] as bugs for this team may span Product:: Component areas.
*'''QE-Verify''' is a flag that developers should be setting on bugs they are working on. This is used for QE 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 goes with in-testsuite set to "+", to show testing via another method.
***Typically goes with in-testsuite 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.
*'''Points''' should be set when known.
*"Iteration" should be updated when a bug is being worked on during a particular Sprint.  
*'''Iteration''' should be updated when a bug is being worked on during a particular Iteration.  
<p> </p>


==Filing a bug==
==Filing a bug==
** Open a bug under Product:"Loop" || Component: "General" or "Client"
** Open a bug under Product:"___" || Component: "___" or "_____"
** Hello team reviews for inclusion into a release backlog every 2 weeks, and will mark "firefox-blocking" accordingly
** Team reviews for inclusion in Backlog every 2 weeks
*If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+
*If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+ and set a Priority with a reason.  This makes it simplest to triage those bugs quickly.
**Before it can be given a Rank it should:
**Before it can be given a Rank it should:
*** be in an actionable state
*** be in an actionable state (for the team taking it)
*** for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
*** 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
*** 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
<p> </p>
<p> </p>
=Project Health=
=Project Health=
[[File:IOS,Desktop Yellow Risk.png|frameless]]<br>
[[File:IOS,Desktop Yellow Risk.png|frameless]]<br>
Line 142: Line 302:
*for company goal x, we are in _____ state because ______.  Please consider ______(propose fix or adjustment of goal).
*for company goal x, we are in _____ state because ______.  Please consider ______(propose fix or adjustment of goal).
*for release goal for ______ ,  we are in _____ state because ______.  Please consider ______(propose fix or adjustment of goal).
*for release goal for ______ ,  we are in _____ state because ______.  Please consider ______(propose fix or adjustment of goal).
==Project Introduction==
* '''Team Mailing list:''' if applicable
* '''Team IRC Channel:''' where does this team "hang-out"
*[https://wiki.mozilla.org/Firefox/IterativeDevelopment Summary of our plans for this year]
**links back to main Firefox page - Marco to create a section on main page for team summaries. 
**Quick high-level plans for the year for Desktop management and contributors. Likely completed by Kev/Dave with EPM help as needed.
***Here's an example of the overview from [https://wiki.mozilla.org/Platform/Roadmap#WebRTC_.2F_WebAudio Platform team for webRTC]
* '''Dependencies:''' feature, partner, resource, etc. that impact this projects ability to succeed - put links to other project pages.
==Links to Current info==
The [https://wiki.mozilla.org/Firefox/searchandaddon/links Links wiki page] is the central location for current focus, Roadmap, Metrics, UX, Marketing, tech-architecture, and more.
==Roles and Responsibilities==
The [https://wiki.mozilla.org/Firefox/Contacts Contacts Page] has the Roles and Responsibilities for Firefox teams, partner teams, and external partners.
Sescalante
Confirmed users
1,094

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1070331...1133043"