Problem/Motivation
Drupal.org will have recipe browsing and a recipe browsing API at some point. For the results to be good, we need to know what recipes are popular.
Right now, we have download numbers for recipes, like https://packagist.org/packages/drupal/events_recurring/stats. Those numbers aren’t necessarily great since it measures when composer is run with the recipe as a dependency. And the key action for a recipe is its application, not download.
It would be better to have an API, similar to update status. So we have metrics for when recipes are applied.
Proposed resolution
The server-side is ready: https://updates.drupal.org/recipe-applied. Our CDN returns a static synthetic response immediately. Like update status, the data will be in query parameters and then we do log analysis to get useful data.
Conditions for sending data:
- Respect opt in/out options
- When the recipe is applied
- Only if the recipe is from Drupal.org, in the
drupal/ namespace on Packagist.org, like https://packagist.org/packages/drupal/events_recurring
- If there is a way to know if GitLab CI is being used, not sending for CI would be ideal
Data to send:
name recipe name, like events_recurringsite_key same arbitrary site key used by update status module- anything else we need?
The final request will be like https://updates.drupal.org/recipe-applied?name=events_recurring&site_key...
Drupal does not need to wait for a response.
Remaining tasks
Decide on any opt in/out options. This is the same privacy policy as update status data. We don’t collect the site URL, don’t share logs, only aggregate, anonymous summaries.
Finalize any other data collected.
Once the final query parameters are set and in core, we can start on the server-side log analysis. The math will be a bit different since recipes are applied once, not installed.
User interface changes
If there is a new opt in/out UI.
Introduced terminology
None
API changes
Not for Drupal as a client.
Data model changes
n/a
Release notes snippet
To be determined