Skip to content
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

Open
wants to merge 2 commits into
base: trunk
Choose a base branch
from

Conversation

p-jackson
Copy link
Member

@p-jackson p-jackson commented Feb 21, 2025

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 cohort

Add ?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 from goalsToIntent() 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:

  • Have you written new tests for your changes, if applicable?
  • Have you checked the E2E test CI results, and verified that your changes do not break them?
  • Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

  • Go to '..'

Copy link
Contributor

github-actions bot commented Feb 21, 2025

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

  • To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (WordPress.com Site Helper), and enable the add/logic-for-goal-based-checklists branch.
  • To test on Simple, run the following command on your sandbox:
bin/jetpack-downloader test jetpack-mu-wpcom-plugin add/logic-for-goal-based-checklists

Interested in more tips and information?

  • In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
  • Read more about our development workflow here: PCYsg-eg0-p2
  • Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

Copy link
Contributor

github-actions bot commented Feb 21, 2025

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

  • ✅ Include a description of your PR changes.
  • ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  • ✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  • ✅ Add testing instructions.
  • ✅ Specify whether this PR includes any changes to data or privacy.
  • ✅ Add changelog entries to affected projects

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:

  1. Ensure all required checks appearing at the bottom of this PR are passing.
  2. Choose a review path based on your changes:
    • A. Team Review: add the "[Status] Needs Team Review" label
      • For most changes, including minor cross-team impacts.
      • Example: Updating a team-specific component or a small change to a shared library.
    • B. Crew Review: add the "[Status] Needs Review" label
      • For significant changes to core functionality.
      • Example: Major updates to a shared library or complex features.
    • C. Both: Start with Team, then request Crew
      • For complex changes or when you need extra confidence.
      • Example: Refactor affecting multiple systems.
  3. Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

@github-actions github-actions bot added the [Status] Needs Author Reply We need more details from you. This label will be auto-added until the PR meets all requirements. label Feb 21, 2025
Copy link

Code Coverage Summary

Coverage changed in 1 file.

File Coverage Δ% Δ Uncovered
projects/packages/jetpack-mu-wpcom/src/features/wpcom-endpoints/class-wpcom-rest-api-v2-endpoint-launchpad.php 141/153 (92.16%) -2.58% 5 💔

1 file is newly checked for coverage.

File Coverage
projects/packages/jetpack-mu-wpcom/src/features/launchpad/goal-launchpad-task-lists.php 0/31 (0.00%) 💔

Full summary · PHP report

Add label I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage. to override the failing coverage check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[mu wpcom Feature] Launchpad [mu wpcom Feature] Wpcom Endpoints [Package] Jetpack mu wpcom WordPress.com Features [Status] In Progress [Status] Needs Author Reply We need more details from you. This label will be auto-added until the PR meets all requirements. [Type] Task
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant