Add review checklist for Infrastructure Platforms readiness assessment

Hossein Pursultanirequested to merge
docs-feature-readiness-checklist into master

⚠️ This MR is moved https://gitlab.com/gitlab-org/architecture/readiness/-/merge_requests/1 ⚠️

What does this MR do?

This MR introduces a standardized checklist as a critical component of the GitLab Infrastructure Platform Review Process. The checklist serves as a comprehensive assessment tool for determining feature readiness across all GitLab platforms (SaaS, Dedicated, and Self Managed).

This standardized approach will help reduce context switching and rework, decrease production incidents by catching issues earlier, improve velocity through standardized processes, and create predictable, documented paths to production that all team members can quickly understand.

Key aspects

  • Process integration: The checklist will be fully integrated into the Infrastructure Platform Review Process, providing a structured approach to evaluate feature delivery readiness.
  • Structured assessment: Framed as an issue template, the checklist presents questions categorized by infrastructure areas of concern and cross-cutting considerations, making it easy to identify and address potential delivery challenges.
  • Cross-team communication: The checklist acts as both a review mechanism and a communication bridge between product teams (who develop features) and infrastructure teams (who deliver features to various platforms), ensuring alignment on requirements and expectations.
  • Tracable evidence and documentation: By implementing the checklist as an issue template, teams can leverage GitLab's native functionality to link supporting evidence (other issues and MRs) directly to their answers, creating a traceable record of compliance and readiness.

Initial scope

This initial version of this checklist focuses primarily on the concerns and requirements of the groupSelf Managed. The checklist addresses considerations of groupSelf Managed that product teams need to account for when developing features intended for deployment across all GitLab platforms (not limited to Self Managed platform).

NB: groupSelf Managed not be confused with "Self Managed platform".

Contributions are welcome

This checklist is designed to evolve as a collaborative tool across all infrastructure teams. We invite and encourage other infrastructure groups to contribute by:

  • Adding sections specific to your team's platform concerns
  • Formulating relevant assessment questions
  • Organizing questions in a way that makes sense for your review process

The structure and format established by the groupSelf Managed team can serve as a template for other teams to follow. As more teams contribute, we will identify and extract shared concerns and questions that apply across multiple platforms, helping to create a more unified and comprehensive review process.

Please fill free to either make suggestions or directly commit to this branch.

By building this checklist collaboratively, we can ensure that product teams have a clear understanding of requirements across all platforms, reducing delivery friction and improving the overall quality of feature deployments.

Related issues

Related to &17136 (closed)

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.
Edited by Hossein Pursultani

Merge request reports