From a4fe964e883ebb04cf2a6c3cb359c8e08064a1c3 Mon Sep 17 00:00:00 2001
From: Robert Marshall <rmarshall@gitlab.com>
Date: Wed, 11 May 2022 13:41:09 +0000
Subject: [PATCH] Add observability to definition of done

Per discussion during CTO office hours on Thursday, May 5 2022, we
want to include observability in our definition of done to increase our
ability to diagnose issues reactively and proactively.

Signed-off-by: Robert Marshall <rmarshall@gitlab.com>
---
 doc/development/code_review.md                         | 6 +++++-
 doc/development/contributing/merge_request_workflow.md | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index a296717151e8..afb8eb5d25a0 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -154,7 +154,7 @@ with [domain expertise](#domain-experts).
 
 #### Acceptance checklist
 
-This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for high-impact risks to quality, performance, reliability, security, and maintainability.
+This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for high-impact risks to quality, performance, reliability, security, observability, and maintainability.
 
 Using checklists improves quality in software engineering. This checklist is a straightforward tool to support and bolster the skills of contributors to the GitLab codebase.
 
@@ -182,6 +182,10 @@ See the [test engineering process](https://about.gitlab.com/handbook/engineering
 1. I have considered the scalability risk based on future predicted growth.
 1. I have considered the performance, reliability, and availability impacts of this change on large customers who may have significantly more data than the average customer.
 
+##### Observability instrumentation
+
+1. I have included enough instrumentation to facilitate debugging and proactive performance improvements through observability.
+
 ##### Documentation
 
 1. I have included changelog trailers, or I have decided that they are not needed.
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 5ed0885eed99..6fe15e51ba80 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -81,6 +81,7 @@ request is as follows:
 1. If your MR touches code that executes shell commands, reads or opens files, or
    handles paths to files on disk, make sure it adheres to the
    [shell command guidelines](../shell_commands.md)
+1. [Code changes should include observability instrumentation](../code_review.md#observability-instrumentation).
 1. If your code needs to handle file storage, see the [uploads documentation](../uploads/index.md).
 1. If your merge request adds one or more migrations, make sure to execute all
    migrations on a fresh database before the MR is reviewed. If the review leads
-- 
GitLab