CloudServices/Sync/OKRs 2016Q3: Difference between revisions
< CloudServices | Sync
Jump to navigation
Jump to search
(added average) |
(Add evaluation notes.) |
||
| Line 5: | Line 5: | ||
! Description | ! Description | ||
! Rating | ! Rating | ||
! Evaluation | |||
|- | |- | ||
| 1.1 | | 1.1 | ||
| Measure structural integrity defects in users' bookmark trees. | | Measure structural integrity defects in users' bookmark trees. | ||
| 1 | | 1 | ||
| Instrumentation for bookmark defects complete. | |||
|- | |- | ||
| 1.2 | | 1.2 | ||
| Land fixes to the underlying defects related to the disabled, failing bookmark validation tests in TPS and enable these tests in TPS. | | Land fixes to the underlying defects related to the disabled, failing bookmark validation tests in TPS and enable these tests in TPS. | ||
| 0.7 | | 0.7 | ||
| We haven't enabled mobile root validation in TPS, because bug 1302901 is awaiting review. We also landed other work to support this, even though we haven't enabled the tests yet. | |||
|- | |- | ||
| 1.3 | | 1.3 | ||
| Deploy sync server API for batch atomic writes to production and land client integrations on Desktop. (iOS and Android need coordination) | | Deploy sync server API for batch atomic writes to production and land client integrations on Desktop. (iOS and Android need coordination) | ||
| 0.5 | | 0.5 | ||
| Client work is 100% complete, but the server is awaiting a production deployment plan. Nodes are currently replaced only by attrition, and we also don't want to replace all nodes at once with the new code. Outcome from this is a clear separation of responsibilities between Desktop and server teams: the Desktop team doesn't write server code; the server offers an API that we consume. | |||
|- | |- | ||
| 1.4** | | 1.4** | ||
| Land improvements to the sync change tracker to ensure that users' bookmark changes are tracked before Sync has initialized or during a sync. | | Land improvements to the sync change tracker to ensure that users' bookmark changes are tracked before Sync has initialized or during a sync. | ||
| 0.5 | | 0.5 | ||
| We have a plan in place. This objective was appropriately ambitious; turns out it was just hard. | |||
|- | |- | ||
| 1.5* | | 1.5* | ||
| Land repair code that uploads missing bookmarks. | | Land repair code that uploads missing bookmarks. | ||
| 0 | | 0 | ||
| We don't have a plan for this, as there are a lot of issues that came up in the design. Overly ambitious; not as simple as we thought. | |||
|- | |- | ||
| 1.6 | | 1.6 | ||
| Land validators to measure the integrity of 3 other sync data types. Integrate the validators into TPS and report defect rates via telemetry. | | Land validators to measure the integrity of 3 other sync data types. Integrate the validators into TPS and report defect rates via telemetry. | ||
| 0.9 / avg 0.6 | | 0.9 / avg 0.6 | ||
| This isn't enabled yet, since we're not sure of the risk of enabling validation for all users. Enabling is a one-line change. Apart from that, all validator work is complete and in TPS. | |||
|} | |} | ||
<nowiki>*Won't achieve | <nowiki>*Won't achieve | ||
| Line 38: | Line 45: | ||
! Description | ! Description | ||
! Rating | ! Rating | ||
! Evaluation | |||
|- | |- | ||
| 2.1 | | 2.1 | ||
| Add affordance to Desktop context menu to send tab to connected sync devices. | | Add affordance to Desktop context menu to send tab to connected sync devices. | ||
| 1 | | 1 | ||
| Shipped. | |||
|- | |- | ||
| 2.4 | | 2.4 | ||
| Add measurement to the sync ping for send tab usage. | | Add measurement to the sync ping for send tab usage. | ||
| 0.1 | | 0.1 | ||
| This became more ambitious than just measuring clicks on the "Send Tab" button. We have a plan, but it's not at all close to landing. This key result should have been more precise; it's not sufficiently clear to evaluate. | |||
|- | |- | ||
| 2.2** | | 2.2** | ||
| Improve timeliness of sending tabs to devices using push events on Nightly Desktop, Android, and iOS. | | Improve timeliness of sending tabs to devices using push events on Nightly Desktop, Android, and iOS. | ||
| 0.8 | | 0.8 | ||
| Shipped on Desktop and Android, which are big-impact platforms. Not shipped on iOS, but less impact. | |||
|- | |- | ||
| 2.3 | | 2.3 | ||
| Land messaging to inform users of incoming tabs in Desktop (bug 1244597). | | Land messaging to inform users of incoming tabs in Desktop (bug 1244597). | ||
| 1 / avg 0.725 | | 1 / avg 0.725 | ||
| Shipped. UX is working on a second iteration to make this better. | |||
|} | |} | ||
3. Use data to help prioritize new features and fix defects in Sync | 3. Use data to help prioritize new features and fix defects in Sync | ||
| Line 61: | Line 73: | ||
! Description | ! Description | ||
! Rating | ! Rating | ||
! Evaluation | |||
|- | |- | ||
| 3.1** | | 3.1** | ||
| Create a bookmark structural integrity dashboard on https://sql.telemetry.mozilla.org/. Dependent on 1.1 | | Create a bookmark structural integrity dashboard on https://sql.telemetry.mozilla.org/. Dependent on 1.1 | ||
| 0 | | 0 | ||
| Structural integrity data is included in the Sync ping, but needs additional work to show in re:dash. | |||
|- | |- | ||
| 3.2** | | 3.2** | ||
| Create a integrity of 3 sync data types (1.6) dashboard on https://sql.telemetry.mozilla.org/ . Dependent on 1.6 | | Create a integrity of 3 sync data types (1.6) dashboard on https://sql.telemetry.mozilla.org/ . Dependent on 1.6 | ||
| 0 | | 0 | ||
| We've done a lot of work toward getting data in the pipeline. We also don't have an OKR for a general Sync health dashboard, which did land. | |||
|- | |- | ||
| 3.3** | | 3.3** | ||
| Line 77: | Line 92: | ||
| Measure lost data occurrences due to single device password resets, visualize on https://sql.telemetry.mozilla.org/ | | Measure lost data occurrences due to single device password resets, visualize on https://sql.telemetry.mozilla.org/ | ||
| 0.5 / avg 0.125 | | 0.5 / avg 0.125 | ||
| We have an estimate: 6% of people signing in reset their passwords and lose their data. 85% of password resets are for users on a single device. The visualization exists, but we're not confident it's answering the question we want to ask. | |||
|} | |} | ||
<nowiki>**At risk but we believe we can get data in Presto or Redshift in order to make Re:Dash dashboards</nowiki> | <nowiki>**At risk but we believe we can get data in Presto or Redshift in order to make Re:Dash dashboards</nowiki> | ||
| Line 91: | Line 107: | ||
|- | |- | ||
| 4.2 ** | | 4.2 ** | ||
| Instrument the current reset experience as a baseline for future improvements | | Instrument the current reset experience as a baseline for future improvements. | ||
| | | | ||
|- | |- | ||
Latest revision as of 01:42, 30 December 2016
1. Build user trust by improving structural data integrity for bookmarks.
| Description | Rating | Evaluation | |
|---|---|---|---|
| 1.1 | Measure structural integrity defects in users' bookmark trees. | 1 | Instrumentation for bookmark defects complete. |
| 1.2 | Land fixes to the underlying defects related to the disabled, failing bookmark validation tests in TPS and enable these tests in TPS. | 0.7 | We haven't enabled mobile root validation in TPS, because bug 1302901 is awaiting review. We also landed other work to support this, even though we haven't enabled the tests yet. |
| 1.3 | Deploy sync server API for batch atomic writes to production and land client integrations on Desktop. (iOS and Android need coordination) | 0.5 | Client work is 100% complete, but the server is awaiting a production deployment plan. Nodes are currently replaced only by attrition, and we also don't want to replace all nodes at once with the new code. Outcome from this is a clear separation of responsibilities between Desktop and server teams: the Desktop team doesn't write server code; the server offers an API that we consume. |
| 1.4** | Land improvements to the sync change tracker to ensure that users' bookmark changes are tracked before Sync has initialized or during a sync. | 0.5 | We have a plan in place. This objective was appropriately ambitious; turns out it was just hard. |
| 1.5* | Land repair code that uploads missing bookmarks. | 0 | We don't have a plan for this, as there are a lot of issues that came up in the design. Overly ambitious; not as simple as we thought. |
| 1.6 | Land validators to measure the integrity of 3 other sync data types. Integrate the validators into TPS and report defect rates via telemetry. | 0.9 / avg 0.6 | This isn't enabled yet, since we're not sure of the risk of enabling validation for all users. Enabling is a one-line change. Apart from that, all validator work is complete and in TPS. |
*Won't achieve ** At risk
2 Create value by helping users with task continuity between mobile and desktop.
| Description | Rating | Evaluation | |
|---|---|---|---|
| 2.1 | Add affordance to Desktop context menu to send tab to connected sync devices. | 1 | Shipped. |
| 2.4 | Add measurement to the sync ping for send tab usage. | 0.1 | This became more ambitious than just measuring clicks on the "Send Tab" button. We have a plan, but it's not at all close to landing. This key result should have been more precise; it's not sufficiently clear to evaluate. |
| 2.2** | Improve timeliness of sending tabs to devices using push events on Nightly Desktop, Android, and iOS. | 0.8 | Shipped on Desktop and Android, which are big-impact platforms. Not shipped on iOS, but less impact. |
| 2.3 | Land messaging to inform users of incoming tabs in Desktop (bug 1244597). | 1 / avg 0.725 | Shipped. UX is working on a second iteration to make this better. |
3. Use data to help prioritize new features and fix defects in Sync
| Description | Rating | Evaluation | |
|---|---|---|---|
| 3.1** | Create a bookmark structural integrity dashboard on https://sql.telemetry.mozilla.org/. Dependent on 1.1 | 0 | Structural integrity data is included in the Sync ping, but needs additional work to show in re:dash. |
| 3.2** | Create a integrity of 3 sync data types (1.6) dashboard on https://sql.telemetry.mozilla.org/ . Dependent on 1.6 | 0 | We've done a lot of work toward getting data in the pipeline. We also don't have an OKR for a general Sync health dashboard, which did land. |
| 3.3** | Visualize send tab usage from 2.4 on https://sql.telemetry.mozilla.org/. | 0 | |
| 3.4** | Measure lost data occurrences due to single device password resets, visualize on https://sql.telemetry.mozilla.org/ | 0.5 / avg 0.125 | We have an estimate: 6% of people signing in reset their passwords and lose their data. 85% of password resets are for users on a single device. The visualization exists, but we're not confident it's answering the question we want to ask. |
**At risk but we believe we can get data in Presto or Redshift in order to make Re:Dash dashboards
4. Validate an experience that improves user trust by retaining sync data through a password reset
| Description | Rating | |
|---|---|---|
| 4.1 | Validate with users cross-platform alternatives that persists user data through a password reset. | |
| 4.2 ** | Instrument the current reset experience as a baseline for future improvements. | |
| 4.3 ** | Plan measurement of the new experience. |
5. Increase multi-device usage by improving in-context messaging
| Description | Rating | |
|---|---|---|
| 5.1 ** | Document options for creating in-context messages reinforcing value of sync features. | |
| 5.2 ** | Create mocks detailing the user experience through a chosen design. | |
| 5.3 ** | Test and create report of feature viability through testing on small user sample. |