1 files changed, 8 insertions, 5 deletions
diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md
index 04c942ab532..339da40b29d 100644
--- a/doc/topics/gitlab_flow.md
+++ b/doc/topics/gitlab_flow.md
@@ -1,4 +1,7 @@
 ---
+stage: Create
+group: Source Code
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers"
 disqus_identifier: 'https://docs.gitlab.com/ee/workflow/gitlab_flow.html'
 ---
 
@@ -266,11 +269,11 @@ One option is to use continuous integration (CI) to merge in `master` at the sta
 Another option is to only merge in from well-defined points in time, for example, a tagged release.
 You could also use [feature toggles](https://martinfowler.com/bliki/FeatureToggle.html) to hide incomplete features so you can still merge back into `master` every day.
 
-> **Note:** Don't confuse automatic branch testing with continuous integration.
-> Martin Fowler makes this distinction in [his article about feature branches](https://martinfowler.com/bliki/FeatureBranch.html):
->
-> "I've heard people say they are doing CI because they are running builds, perhaps using a CI server, on every branch with every commit.
-> That's continuous building, and a Good Thing, but there's no *integration*, so it's not CI."
+NOTE: **Note:**
+Don't confuse automatic branch testing with continuous integration.
+Martin Fowler makes this distinction in [his article about feature branches](https://martinfowler.com/bliki/FeatureBranch.html):
+"I've heard people say they are doing CI because they are running builds, perhaps using a CI server, on every branch with every commit.
+That's continuous building, and a Good Thing, but there's no *integration*, so it's not CI."
 
 In conclusion, you should try to prevent merge commits, but not eliminate them.
 Your codebase should be clean, but your history should represent what actually happened.