-
Notifications
You must be signed in to change notification settings - Fork 812
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Launchpad: [WIP] Use site goal selection to determine which checklist is shown in launchpad #41944
base: trunk
Are you sure you want to change the base?
Conversation
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available. Follow this PR Review Process:
Still unsure? Reach out in #jetpack-developers for guidance! |
Code Coverage SummaryCoverage changed in 1 file.
1 file is newly checked for coverage.
Add label
I don't care about code coverage for this PR
|
Related to Automattic/wp-calypso#99960
Proposed changes:
Add
?use_goals
param to launchpad API, which opts in to using the new goal-based logic. I think the client would set this after checking whether the user was in the cumulative cohortAdd
?enable_features_for_goals
param to launchpad API, which works in a similar way to the same option in 173946-ghe-Automattic/wpcom. Basically the client is telling the backend which feature flags are enabled.When the client opts in with
?use_goals
then we use the same checklist slugs and definitions that we've always used. Back in pet6gk-1Xe-p2 I had thought we might dynamically generate the checklist based on the selected goals. But until we have greater clarity on how product designers want this to work, we should stick with hard coding specific goal selections to specific checklists (pet6gk-1Xe-p2#comment-1653).Since we're going with hard coding anyway ... then how about we just stick with the hardcoded definitions in
wpcom_launchpad_get_task_list_definitions()
for now 🤷.Currently the checklist slugs from
wpcom_launchpad_get_task_list_definitions()
map one-to-one with intents. This PR implies that we can hand craft a bunch of checklist slugs that don't correspond to any intent. If the user chooses just goals A and B then we can have a special checklist just for that. If the user chooses goal A and any two of goal B, D, and F, then we can even give that a custom checklist.Currently
get_checklist_slug_by_goals()
re-implements a bunch of the logic fromgoalsToIntent()
in Calypso.https://github.com/Automattic/wp-calypso/blob/eb10fb401a19def56b58d2d2fd8df5182d642448/packages/data-stores/src/onboard/utils.ts#L8
Since
?use_goals
will probably be set for all cumulative users, we need to reimplement a bit of that logic so that all of the goal selections keep working as before.The reason I think it's worth moving the logic from the client to Jetpack (i.e. why is worth deprecating
goalsToIntent()
) is because even though all the checklists are hard coded right now; IMO in a future world we probably should have dynamically generated checklists. Rather than creating a checklist for every single permutation of goals, over time as the data team is able to say which tasks give the user the most success, we probably should transition to a dynamic system for generating checklists like I first described in pet6gk-1Xe-p2.Other information:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions: