Firefox/searchandaddon
Firefox Search
problem statement or why we do this project and the scope of work focused on - intro for someone brand new.
Meetings & Communications
| Meeting | Day of week | Pacific Time | Eastern Time | Central European Time | Vidyo Room | Notes |
|---|---|---|---|---|---|---|
| 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 | 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 | Bugzilla queries, etherpad |
Key Bugzilla Queries
- 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.
- Untriaged Bugs:Bugs under Firefox::Search without [fxsearch] in whiteboard
Development
Schedule
- Firefox main release schedule is the master location for the dates when each Firefox version goes to Aurora, Beta, & Release.
Firefox 41 Release
- Iteration 41.2: Tuesday May 26 - Monday June 8
- Iteration 41.3: Tuesday June 9 - Monday June 29
- Note: IT 41.3 is a 3-week iteration.
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
Themes
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 - 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
Things we want to do - but not starting until higher priorities are done:
- TBD - add as things come up
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.
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.
Current
Iteration - 41.3, through June 29
Theme 958204 Search Suggestions
| Suggestions: Allow user to select a query from search suggestions in Awesome Bar | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
4 Total; 0 Open (0%); 4 Resolved (100%); 0 Verified (0%); |
| Suggestions: Search Suggestions in the AwesomeBar should be clearly identified as such |
|---|
No results. 0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%); |
| Partner Engine: Support server-driven setting of search defaults |
|---|
No results. 0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%); |
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)
- 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
Collection of priority work the team has committed to complete on in a two-week iteration.
| ID | Summary | Status | Assigned to | Whiteboard | Fx points |
|---|---|---|---|---|---|
| 959594 | Retrieving the results from the default search provider | RESOLVED | Drew Willcoxon :adw | [suggestions][fxsearch] | --- |
| 1162142 | [User Story] Search Suggestions in the AwesomeBar should be clearly identified as such | RESOLVED | Drew Willcoxon :adw | [suggestions][UX][fxsearch] | --- |
| 1162144 | Add link to search settings to AwesomeBar | VERIFIED | Dave Townsend [:mossop] | [suggestions][fxsearch] | --- |
| 1176205 | Set browser.urlbar.suggest.searches to false on aurora | VERIFIED | Dave Townsend [:mossop] | [fxsearch][searchsuggestions][Bugday-20150701] | --- |
4 Total; 0 Open (0%); 2 Resolved (50%); 2 Verified (50%);
Past
Iteration - 41.2, through June 8
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 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
| ID | Summary | Status | Assigned to | Whiteboard | Fx points |
|---|---|---|---|---|---|
| 1107883 | The awesomebar shows a search as first suggestion for typed IPv6 URLs | VERIFIED | Mark Hammond [:markh] [:mhammond] | [unifiedautocomplete][fxsearch] | 5 |
1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%);
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 top 3 users stories for search suggestions
- Unified Autocomplete bugs that are blocking Search Suggestions are under 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
9 Total; 0 Open (0%); 7 Resolved (77.78%); 2 Verified (22.22%);
Iteration - 40.3 through May 11
- Focus on folks 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 User Story document
- Kev filing User Story bugs under bug 958204
- Unified Autocomplete bugs that are blocking Search Suggestions are under bug 1157952
- Live view into bugzilla of bugs marked [fxsearch] and Iteration 40.3:
- Iteration Bug Selection: View Status Board
- Other Key Bugzilla Queries are here
10 Total; 0 Open (0%); 7 Resolved (70%); 3 Verified (30%);
Iteration - 40.2 April 27
- Normally there would be a summary of features worked on / progress / blockers
- Normally list of bugs closed like this one
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)
Triage Guidelines
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:
- 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 Firefox-backlog flag is used to track bugs that are approved for the Backlog "+" (or Backlog - to not be looked at for a while)
- 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 QE should not look at
- Typically goes with in-testsuite set to "+", to show testing via another method.
- Points should be set when known.
- Iteration should be updated when a bug is being worked on during a particular Iteration.
Filing a bug
- Open a bug under Product:"___" || Component: "___" or "_____"
- 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"+ 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:
- 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 feature requests or enhancements, it means that there's a clear problem statement or suggestion
- Before it can be given a Rank it should:
Project Health
- (get central location for graphics from Erin)
Include clear, executive level summary that will be included at the [mana page overall view level:
- 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).
Project Introduction
- Team Mailing list: if applicable
- Team IRC Channel: where does this team "hang-out"
- 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 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 Links wiki page is the central location for current focus, Roadmap, Metrics, UX, Marketing, tech-architecture, and more.
Roles and Responsibilities
The Contacts Page has the Roles and Responsibilities for Firefox teams, partner teams, and external partners.
