Add missing entries to the Registration Features list

Andrew Dunnrequested to merge
docs/registration-features-list into master

What does this MR do?

The Available features list under Registration Features Program names 24 features. FEATURES_WITH_USAGE_PING in ee/app/models/gitlab_subscriptions/features.rb:365 grants 27, concatenated from STARTER_FEATURES_WITH_USAGE_PING (10, :322), PREMIUM_FEATURES_WITH_USAGE_PING (13, :336) and ULTIMATE_FEATURES_WITH_USAGE_PING (4, :353).

Three of those keys had no entry: repository_mirrors, devops_adoption and instance_level_devops_adoption. The last two both control the instance-level DevOps adoption report in the Admin area, so one entry covers both.

  • devops_adoption decides whether that page renders its adoption tabs. ::License.feature_available?(:devops_adoption) at ee/app/controllers/ee/admin/dev_ops_report_controller.rb:19 backs the show_adoption? helper, read at app/views/admin/dev_ops_report/show.html.haml:5.
  • instance_level_devops_adoption permits the data those tabs read. ee/app/policies/ee/global_policy.rb:32 feeds the rule at :189, which enables view_instance_devops_adoption, enforced in ee/app/graphql/resolvers/analytics/devops_adoption/enabled_namespaces_resolver.rb:40.

group_level_devops_adoption was already covered. The existing DevOps Adoption entry links the group page, which is what that key gates (ee/app/policies/ee/group_policy.rb:71), so the key was documented but the entry was not named for its scope.

The list therefore goes to 26 entries, covering all 27 keys:

  • Repository mirroring, new, for repository_mirrors.
  • DevOps adoption by instance, new, for the two instance keys above.
  • DevOps Adoption renamed to DevOps adoption by group.

Both DevOps adoption surfaces render the same UI label, DevOps adoption (ee/lib/sidebars/groups/menus/analytics_menu.rb:106 and lib/sidebars/admin/menus/analytics_menu.rb:34), so the scope words come from the two pages' own titles. Every other entry on the list is written from its page title the same way.

The list is not alphabetical, grouped by tier, or in source order, so the instance entry sits beside its group counterpart and repository mirroring is appended.

This is written as completing the list against FEATURES_WITH_USAGE_PING, not as a defect report. Blame over :66-89 returns one commit for all 24 lines, so I could not tell from the repository whether any of the three omissions was deliberate. If one of them was, say so and I will drop that entry.

Related issues

None. Found by reading the page against FEATURES_WITH_USAGE_PING.

Author's checklist

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

  • ~"frontend"
  • ~"backend"
  • ~"type::bug"
  • ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

  • If the content requires it, ensure the information is reviewed by a subject matter expert.
  • Technical writer review items:
    • Ensure docs metadata is present and up-to-date.
    • Ensure the appropriate labels are added to this MR.
    • Ensure a release milestone is set.
    • If relevant to this MR, ensure content topic type principles are in use, including:
      • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
      • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
      • Any task steps should be written as a numbered list.
      • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
  • Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

AI-Generated Content Disclosure: This MR was prepared with assistance from Claude Code. The output has been reviewed for correctness, verified against source per the verification table in the MR, and validated against the documentation style guide.

Merge request reports