• Resources for reviewers
• Review process
  • Roles and process
    • The merge request author should
    • The Product Intelligence reviewer should
• Review workload distribution

Service Ping review guidelines

This page includes introductory material for a Product Intelligence review, and is specific to Service Ping related reviews. For broader advice and general best practices for code reviews, refer to our code review guide.

Resources for reviewers

• Service Ping Guide
• Metrics Dictionary

Review process

We recommend a Product Intelligence review when a merge request (MR) touches any of the following Service Ping files:

• usage_data* files.
• The Metrics Dictionary, including files in:
  • config/metrics.
  • ee/config/metrics.
  • schema.json.
• Product Intelligence tooling. For example, Gitlab::UsageMetricDefinitionGenerator

Roles and process

The merge request author should

• Decide whether a Product Intelligence review is needed. You can skip the Product Intelligence review and remove the labels if the changes are not related to the Product Intelligence domain and are regular backend changes.
• If a Product Intelligence review is needed, add the labels ~product intelligence and ~product intelligence::review pending.
• For merge requests authored by Product Intelligence team members:
  • Assign both the ~backend and ~product intelligence reviews to another Product Intelligence team member.
  • Assign the maintainer review to someone outside of the Product Intelligence group.
• Assign an engineer from the Product Intelligence team for a review.
• Set the correct attributes in the metric’s YAML definition:
  • product_section, product_stage, product_group, product_category
  • Provide a clear description of the metric.
• Add a changelog according to guidelines.

The Product Intelligence reviewer should

• Perform a first-pass review on the merge request and suggest improvements to the author.
• Check the metrics location in the Service Ping JSON payload.
• Suggest that the author checks the naming suggestion while generating the metric’s YAML definition.
• Add the ~database label and ask for a database review for metrics that are based on Database.
• Add ~Data Warehouse::Impact Check for any database metric that has a query change. Changes in queries can affect data operations.
• For tracking using Redis HLL (HyperLogLog):
  • Check the Redis slot.
  • Check if a feature flag is needed.
• For a metric’s YAML definition:
  • Check the metric’s description.
  • Check the metric’s key_path.
  • Check the product_section, product_stage, product_group, and product_category fields. Read the stages file.
  • Check the file location. Consider the time frame, and if the file should be under ee.
  • Check the tiers.
• If a metric was changed or removed: Make sure the MR author notified the Customer Success Ops team (@csops-team), Analytics Engineers (@gitlab-data/analytics-engineers), and Product Analysts (@gitlab-data/product-analysts) by @ mentioning those groups in a comment on the MR.
• Metrics instrumentations
  • Recommend using metrics instrumentation for new metrics, if possible.
• Approve the MR, and relabel the MR with ~"product intelligence::approved".

Review workload distribution

Danger bot adds the list of changed Product Intelligence files and pings the @gitlab-org/analytics-section/product-intelligence/engineers group for merge requests that are not drafts.

Any of the Product Intelligence engineers can be assigned for the Product Intelligence review.