Closed Bug 1456221 Opened 3 years ago Closed 3 years ago
[Shield] Opt-out Study: New Bookmark Sync
We believe that new bookmark sync (also called structured bookmark application, two-phase application, and bookmark buffering) will reduce bookmark corruption rates for Sync users, leading to increased user satisfaction with Sync. The pref flipping experiment will roll out a new bookmarks engine that reduces or eliminates bookmark corruption caused by Sync. The new engine stages synced bookmarks in a separate database, produces a complete and consistent merged tree, and updates the local store and the server to match the new tree. We'll use bookmark validation dashboards to monitor these corruption rates, and roll back if corruption rates or failed syncs spike. Please see https://docs.google.com/document/d/1pTHmgHty_vDqxg4eCeC48pweqTpOfq0YMA1jTQTvafc/edit?usp=sharing for the PHD.
Kanchan, you mentioned QA doesn't provide pre-Beta sign-off for features that are pref'd off, but do we have your sign-off to flip the pref on for Nightly users as part of this study?
Science review R+
QA assessment: Most of the high priority logged bugs have been fixed. A bug 1442805, which is an edge case, has been prioritized for future. Considering all critical bug fixes, I sign-off on this feature to be pref’d on for Nightly users as part of this study. Kit, please let me know if sign-off on this bug would be sufficient or you want me to send a sign-off to release management as well. Thanks for the great work on bug fixes!
We're live, small sample for now. Bumping the sample rate daily.
(In reply to Kanchan Kumari QA from comment #3) > Kit, please let me know if sign-off on this bug would be sufficient or you > want me to send a sign-off to release management as well. Thanks, Kanchan! Sounds like this is sufficient for now. :-)
I think we're ready to move forward with the next phase! > We're requesting approval to add two more prefs to the New Bookmark Sync study, and roll the experiment out to 50% of Nightly users. > > * `services.sync.engine.bookmarks.validation.percentageChance` should be set to 100 for 100% of Nightly users. > * `services.sync.engine.bookmarks.validation.maxRecords` should be set to 5000 for 100% of Nightly users. > * `services.sync.engine.bookmarks.buffer = true` should be set to 50% of Nightly users. > > The `bookmarks.validation` prefs are used for data collection, and will let us directly compare corruption rates for users with the old and new engines. We're not requesting additional QA as part of this rollout.
Unfortunately pref-flip recipes can only affect one pref at a time. We may be able to achieve the desired conditions with multiple recipes, though. If you're ready to set the two new prefs for 100% of the population, do I presume correctly that it's uncontroversial for it to become the default in mozilla-central? If so we could do rollouts for them and keep the existing 50/50 boolean flip recipe intact. If not, it will be more difficult but I don't think impossible.
Lina should weigh in to confirm, but I think the idea here is to change the validation prefs to 100% just for a few weeks. Validation generates the telemetry data we need but it only runs pseudo-randomly for each user. To ensure that we have the telemetry data to evaluate the experiment we need to force the validation to run more frequently/always. However, because validation is moderately resource-intensive, we probably want to scale it back to the original rates once we have the data. We want to maintain the 50/50 split on `services.sync.engine.bookmarks.buffer = true`, assuming that's what its currently set to.
Nevermind - added two extra recipes to flip the .validation prefs for 100% of Nightly, one per pref. slugs are (respectively): pref-flip-new-bookmark-sync-61-1456221-vpC pref-flip-new-bookmark-sync-61-1456221-vmR This action was taken following discussion in #shield where @lina verified it was okay to flip those prefs for everyone in the Nightly population, not just the 10% targeted by the initial pref-flip.
Disabled all 3 recipes.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.