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

Review process

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

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.
  • Update the Metrics Dictionary if needed.
  • 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.
  • For tracking using Redis HLL (HyperLogLog):
  • 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.
  • Metrics instrumentations
    • Recommend to use metrics instrumentation for new metrics addded to service with limitations
  • 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/growth/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.