Refactor DevOps stages in direction page

README.md

@@ -131,7 +131,7 @@ Beware that:
   deploy a Review App (hence MRs from contributors). For that case, you should
   have at least Developer access to the `www-gitlab-com` project or
   `gitlab-com` group.
-- The generation of the direction, wishlist and releases pages is omitted
+- The generation of the direction, wishlist, and releases pages is omitted
   in branches and is run only on master. This helps to shave off some time from
   the build process. That means you won't be able to preview these pages with
   Review Apps.

config.rb

@@ -72,10 +72,16 @@ configure :build do
       wishlist = generate_wishlist
       proxy '/direction/index.html', '/direction/template.html', locals: { direction: generate_direction, wishlist: wishlist }, ignore: true
       proxy '/direction/product-vision/index.html', '/direction/product-vision/template.html', locals: { product_vision: generate_product_vision }, ignore: true
-      proxy '/direction/create/index.html', '/direction/create/template.html', locals: { wishlist: generate_wishlist }, ignore: true
+      proxy '/direction/manage/index.html', '/direction/manage/template.html', locals: { wishlist: wishlist }, ignore: true
       proxy '/direction/plan/index.html', '/direction/plan/template.html', locals: { wishlist: wishlist }, ignore: true
-      proxy '/direction/release/index.html', '/direction/release/template.html', locals: { wishlist: wishlist }, ignore: true
+      proxy '/direction/create/index.html', '/direction/create/template.html', locals: { wishlist: wishlist }, ignore: true
       proxy '/direction/verify/index.html', '/direction/verify/template.html', locals: { wishlist: wishlist }, ignore: true
+      proxy '/direction/package/index.html', '/direction/package/template.html', locals: { wishlist: wishlist }, ignore: true
+      proxy '/direction/release/index.html', '/direction/release/template.html', locals: { wishlist: wishlist }, ignore: true
+      proxy '/direction/configure/index.html', '/direction/configure/template.html', locals: { wishlist: wishlist }, ignore: true
+      proxy '/direction/monitor/index.html', '/direction/monitor/template.html', locals: { wishlist: wishlist }, ignore: true
+      proxy '/direction/secure/index.html', '/direction/secure/template.html', locals: { wishlist: wishlist }, ignore: true
+      proxy '/direction/distribution/index.html', '/direction/distribution/template.html', locals: { wishlist: wishlist }, ignore: true
     end
     ## Releases page

generators/direction.rb

@@ -349,44 +349,50 @@ def generate_wishlist
   puts 'Generating wishlist...'
   output = {}
+  # 'boards',
+  # 'burndown charts',
+  # 'capacity planning',
+  # 'chat commands',
+  # 'code review',
+  # 'container registry',
+  # 'deliver',
+  # 'epics',
+  # 'issue boards',
+  # 'issues',
+  # 'jira',
+  # 'labels',
+  # 'milestones',
+  # 'major wins',
+  # 'moderation',
+  # 'notifications',
+  # 'open source',
+  # 'performance',
+  # 'roadmaps',
+  # 'search',
+  # 'Monitoring',
+  # 'search',
+  # 'service desk',
+  # 'todos',
+  # 'usability',
+  # 'vcs for everything',
+  # 'wiki',
+
   [
-    'boards',
-    'burndown charts',
-    'capacity planning',
-    'chat commands',
-    'code review',
-    'container registry',
-    'deliver',
-    'devops:release',
+    'devops:manage',
+    'devops:plan',
+    'devops:create',
     'devops:verify',
-    'elasticsearch',
-    'epics',
-    'issue boards',
-    'issues',
-    'jira',
-    'labels',
-    'milestones',
-    'major wins',
-    'moderation',
-    'moonshots',
-    'notifications',
-    'open source',
-    'performance',
-    'roadmaps',
-    'search',
-    'Monitoring',
-    'search',
-    'service desk',
-    'todos',
-    'usability',
-    'vcs for everything',
-    'wiki',
+    'devops:package',
+    'devops:release',
+    'devops:configure',
+    'devops:monitor',
+    'devops:secure',
     'HA',
     'Cloud Native'
   ].each do |label|
     output[label] = label_list(label)
   end
-  output['build'] = label_list('direction', exclude: ['HA', 'Cloud Native'], editions: Array(edition[2]))
+  output['devops:distribution'] = label_list('direction', exclude: ['HA', 'Cloud Native'], editions: Array(edition[2]))
   ['GitLab Starter', 'GitLab Premium', 'GitLab Ultimate'].each do |tier|
     output[tier] = tier_list(tier)

source/direction/_other.erb

+## Other Interesting Items
+
+There are a number of other issues that we've identified as being interesting
+that we are potentially thinking about, but do not currently have planned by
+setting a milestone for delivery. Some are good ideas we want to do, but don't
+yet know when; some we may never get around to, some may be replaced by another
+idea, and some are just waiting for that right spark of inspiration to turn
+them into something special.
+
+Remember that at GitLab, everyone can contribute! This is one of our
+fundamental values and something we truly believe in, so if you have
+feedback on any of these items you're more than welcome to jump into
+the discussion. Our vision and product are truly something we build
+together!
+
+<%= wishlist["devops:#{stage}"] %>

source/direction/configure/template.html.md.erb

+---
+layout: markdown_page
+title: "Product Vision - Configure"
+---
+
+- TOC
+{:toc}
+
+This is the product vision for Configure in 2019 and beyond.
+
+## Overview
+
+The Configure stage deals with the configuration and operation of applications
+and infrastructure, including Auto DevOps, Kubernetes integration, and ChatOps.
+We aim to make complex tasks (such as standing up new environments) fast and
+easy as well as providing operators all the necessary tools to execute their
+day-to-day actions upon their infrastructure.
+
+## Auto DevOps
+
+Our vision for “[Auto DevOps](https://www.youtube.com/watch?v=KGrJguM361c)” is
+to leverage our [single application](/handbook/product/single-application/) to
+assist users in every phase of the development process, implementing automatic
+tasks that can be customized and refined to get the best fit for their needs.
+e.g. “auto CI” to compile and test software based on best practices for the most
+common languages and frameworks, “auto review” with the help of automatic
+analysis tools like Code Climate, “auto deploy” based on Review Apps and
+incremental rollouts on Kubernetes clusters, and “auto metrics” to collect
+statistical data from all the previous steps in order to guarantee performances
+and optimization of the whole process. Dependencies and artifacts will be
+first-class citizens in this world: everything must be fully reproducible at any
+given time, and fully connected as part of the great GitLab experience.
+
+[Watch the video explaining our vision on Auto DevOps](https://www.youtube.com/watch?v=KGrJguM361c).
+
+## Serverless
+
+Taking full advantage of the power of the cloud computing model and container
+orchestration, cloud native is an innovative way to build and run applications.
+A big part of our cloud native strategy is around serverless. Serverless
+computing provides an easy way to build highly scalable applications and
+services, eliminating the pains of provisioning & maintaining.
+
+- [Serverless](https://gitlab.com/groups/gitlab-org/-/epics/155)
+
+## PaaS
+
+Our Kubernetes integration provides a fast and easy way to standup clusters and
+start deploying your applications, however, we want to go further. Our vision
+for PaaS involves providing the necessary resources for your apps to run with
+**zero configuration** on the user's part. We will take the first steps to reach
+this goal.
+
+- [GitLab PaaS](https://gitlab.com/groups/gitlab-org/-/epics/111)
+
+## ChatOps
+
+The next generation of our ChatOps implementation will allow users to have a
+dedicated interface to configure, invoke, and audit ChatOps actions, doing it in
+a secure way through RBAC.
+
+- [ChatOps](https://gitlab.com/groups/gitlab-org/-/epics/74)
+
+## Runbook Configuration
+
+[Incident Management](https://gitlab.com/groups/gitlab-org/-/epics/349) will
+allow operators to have real-time view into the happenings of their systems.
+Building upon this concept, we envision rendering of runbook inside of GitLab as
+interactive documents for operators which in turn could trigger automation
+defined in `gitlab-ci.yml`.
+
+- [Runbook Configuration](https://gitlab.com/groups/gitlab-org/-/epics/380)
+
+## Chaos Engineering
+
+Chaos engineering in a powerful practice that allows operators to architect
+powerful distributed systems that can withstand turbulent conditions. We want
+operators to be able to run downtime scenarios randomly to test the resilience
+of their architecture. Starting with the minimum units (pods) all the way the
+largest units (regions).
+
+- [Chaos Engineering](https://gitlab.com/groups/gitlab-org/-/epics/381)
+
+## Chat Integration
+
+We want to leverage the latest features from chat platforms right within GitLab.
+
+- [Chat Integration](https://gitlab.com/groups/gitlab-org/-/epics/339)
+
+## Prioritization Process
+
+In general, we follow the same [prioritization guidelines](/handbook/product/#prioritization)
+as the product team at large. Issues will tend to flow from having no milestone,
+to being added to the backlog, to being added to this page and/or a specific
+milestone for delivery.
+
+You can see our entire public backlog for Configure at this
+[link](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Configure);
+filtering by labels or milestones will allow you to explore. If you find
+something you're interested in, you're encouraged to jump into the conversation
+and participate. At GitLab, everyone can contribute!
+
+Issues with the "direction" label have been flagged as being particularly
+interesting, and are listed in the section below.
+
+<%= partial("direction/other", :locals => { :stage => "configure" }) %>

source/direction/create/template.html.md.erb

@@ -8,15 +8,19 @@ title: "Product Vision - Create"
 The Create stage of the DevOps life cycle covers how code is written, reviewed, and merged.
+<!--The Create stage of the DevOps lifecycle covers code creation, which includes
+source code management (Git, Git LFS etc), merge requests, wiki, snippets and
+Web IDE.-->
+
 This is the product vision for Create in 2019 and beyond.
-### Landscape
+## Landscape
 Git's distributed design made new collaborative workflows possible, and has been adopted rapidly over the last decade. Powerful simplifying concepts like forking and merge requests have been embraced in the everyday routines of nearly every developer, yet few significant changes have been made in recent years to embrace the global scale of collaboration between open source and private companies, or improve the way complex real world code is written, reviewed and merged.
 GitLab has made it faster and easier to get ideas into production by creating a single integrated application. This is just the beginning. Greater maturity in the tools we use for creating, collaborating and reviewing will make it easier for everyone to start contributing, engineers to work better together, improve quality and build better application faster. It is still day one.
-### Collaboration
+## Collaboration
 Git's distributed design made new collaborative workflows possible, and forking has made collaboration even easier. Forking is the workflow of choice for open source, and for the same reasons it is also great for private organizations. We want to remove the barriers to collaboration and [inner sourcing](/2016/07/07/trends-version-control-innersourcing/), but also make it easier to collaborate with external open source projects too.
@@ -24,7 +28,7 @@ The distributed capabilities of Git aren't limited to a single server. Open sour
 We'll also be improving simpler forking workflows too with important quality-of-life improvements. To make it easy to see how far behind or diverged your fork is, we will make it possible to [compare branches](https://gitlab.com/gitlab-org/gitlab-ce/issues/19788) across forks and [cherry pick](https://gitlab.com/gitlab-org/gitlab-ce/issues/43568) changes directly from the upstream project into your fork. Forks of private projects will also [inherit permissions](https://gitlab.com/gitlab-org/gitlab-ce/issues/8935) from the upstream project, making it possible for upstream maintainers to rebase stale merge requests and help contributors. This will allow teams to adopt forking workflows without needing to make every project public to the world or to the organization.
-### Code review and approvals
+## Code review and approvals
 Merge requests are key to the workflows that allow teams to iterate rapidly and ship amazing products quickly, by bringing together all the important information in a single place. Critical to this workflow is the code review, and we want GitLab to be the best tool for doing code reviews.
@@ -36,7 +40,7 @@ In the real world, complex features often require large, complex merge requests.
 Complex real-world changes also need good commit messages, but commit messages are too easily neglected. Without good commit messages, debugging a regression, or modifying an important existing function is painful and error prone. To help teams adopt best practice [commit hygiene](/2018/06/07/keeping-git-commit-history-clean/), we will make [commit messages part of code review](https://gitlab.com/groups/gitlab-org/-/epics/286) by allowing comments on commit messages, improving the [visibility of commit messages](https://gitlab.com/gitlab-org/gitlab-ce/issues/49803), and making [squash and merge smarter](https://gitlab.com/gitlab-org/gitlab-ce/issues/47149). GitLab should celebrate great commit messages and amplify their benefits to make it easier for teams to adopt best practices.
-### Web IDE
+## Web IDE
 In 2018 we're building a strong foundation for a cloud development environment with [client side evaluation](https://gitlab.com/gitlab-org/gitlab-ce/issues/47268) and [server side evaluation](https://gitlab.com/gitlab-org/gitlab-ee/issues/4013) powered live previews, and server side evaluation will also enable a [web terminal](https://gitlab.com/gitlab-org/gitlab-ee/issues/5426) to test your changes in real time. IDEs are also very personal and should support customization, to make it easy to move between your local IDE and GitLab IDE. Please share your feedback, and consider contributing – I'd love to see support for [dark syntax themes](https://gitlab.com/gitlab-org/gitlab-ce/issues/46334) and [vim keybindings](https://gitlab.com/gitlab-org/gitlab-ce/issues/47930)!
@@ -50,3 +54,4 @@ The Web IDE makes it easier than ever to resolve code review feedback, reducing
 We are also considering integrating [merge request discussions](https://gitlab.com/groups/gitlab-org/-/epics/72) so that code review comments can be addressed without needing to continually switch between tabs. We don't think the Web IDE should replace the merge request, nor should every feature be duplicated into it, but do think the Web IDE can further simplify the process for resolving code review feedback so teams can iterate faster.
+<%= partial("direction/other", :locals => { :stage => "create" }) %>

source/direction/distribution/template.html.md.erb

+---
+layout: markdown_page
+title: "Product Vision - Distribution"
+---
+
+- TOC
+{:toc}
+
+GitLab is the engine that powers many companies' software businesses so it is
+important to ensure it is as easy as possible to deploy, maintain, and stay up
+to date.
+
+Today we have a mature and easy to use Omnibus based build system, which is the
+foundation for nearly all methods of deploying GitLab. It includes everything a
+customer needs to run GitLab all in a single package, and is great for
+installing on virtual machines or real hardware. We are committed to making our
+package easier to work with, highly available, as well as offering automated
+deployments on cloud providers like AWS.
+
+We also want GitLab to be the best cloud native development tool, and offering a
+great cloud native deployment is a key part of that. We are focused on offering
+a flexible and scalable container based deployment on Kubernetes, by using
+enterprise grade Helm Charts.
+
+## GitLab High Availability
+
+<%= wishlist["HA"] %>
+
+## Cloud Native
+
+<%= wishlist["Cloud Native"] %>
+
+<%= partial("direction/other", :locals => { :stage => "distribution" }) %>

source/direction/manage/index.html.md → source/direction/manage/template.html.md.erb

@@ -13,12 +13,21 @@ This is the product vision for Manage in 2019 and beyond.
 ## Overview
-For administrators and executives, the process of management is always on. It extends to managing people, money, and risk; when the stakes are high, these stakeholders demand an experience and feature set that makes them feel in control. Setting up your processes shouldn’t be a struggle, and administrators shouldn’t have to compromise on security or compliance to make software work for them. 
+For administrators and executives, the process of management is always on. It extends to managing people, money, and risk; when the stakes are high, these stakeholders demand an experience and feature set that makes them feel in control. Setting up your processes shouldn’t be a struggle, and administrators shouldn’t have to compromise on security or compliance to make software work for them.
 Not only do we want to fulfill those fundamental needs, we want to give you the freedom to work in new and powerful ways. We aspire to answer questions managers didn't know they had, and to automate away the mundane.
 Manage's role in GitLab is to **help organizations prosper with configuration and analytics that enables them to work more efficiently**. It’s not enough to give instances the ability to meet their most basic needs; as a single application for the DevOps lifecycle, GitLab can exceed the standard and enable you to work in ways you previously couldn’t.
+<!--Managing the DevOps lifecycle requires configuration, control, and insightful data to power
+intelligent decisionmaking. The process of managing the business is always on.
+
+This involves traditional tools like authentication and authorization,
+but goes beyond into sophisticated analytics and workflow solutions that take advantage of
+GitLab's single-application approach to the DevOps lifecycle. We want to help organizations
+prosper with configuration and analytics that enables them to work more efficiently.
+-->
+
 ## Problems we're solving
 We’re realizing this vision in 2019 by delivering more powerful insights, giving you the power to automate custom workflows, and iterating on must-have features for complex organizations.
@@ -33,17 +42,17 @@ When it’s time to dig deeper into an event, we want to ensure that changes in
 By building monitoring and traceability deep into the application, our goal is to let GitLab thrive in any regulated environment.
-Keeping you informed is only a part of what administrators need; we also want to tell you something insightful and new about how you’re shipping software. We’ll offer powerful [code analytics](https://gitlab.com/groups/gitlab-org/-/epics/368) at the project level that tells owners and maintainers about hotspots in your code that churn frequently. After these have been identified, we’ll make it easy to open an issue to track the subsequent refactor. 
+Keeping you informed is only a part of what administrators need; we also want to tell you something insightful and new about how you’re shipping software. We’ll offer powerful [code analytics](https://gitlab.com/groups/gitlab-org/-/epics/368) at the project level that tells owners and maintainers about hotspots in your code that churn frequently. After these have been identified, we’ll make it easy to open an issue to track the subsequent refactor.
 * How can we make working in GitLab effortless?
-GitLab’s [single application](https://about.gitlab.com/handbook/product/#single-application) approach to DevOps puts the entire software development lifecycle in a single place. As a result, users don’t have to stitch together an overly-fragmented toolchain - and we want to go deeper in on that advantage. 
+GitLab’s [single application](https://about.gitlab.com/handbook/product/#single-application) approach to DevOps puts the entire software development lifecycle in a single place. As a result, users don’t have to stitch together an overly-fragmented toolchain - and we want to go deeper in on that advantage.
 GitLab is built to be inherently flexible, as organizations have a variety of different workflows and structures. Instead of strictly representing these workflows with manual handoffs, we want to automate the processes that define your organization. In the same way that you’re able to define a CI pipeline, we want to bring this concept to how you use the rest of the application - end-to-end.
 In 2019, we’ll make this happen with [Automations](https://gitlab.com/groups/gitlab-org/-/epics/218). Instances will be able to define complex workflows with conditional logic, vastly reducing time spent on the transactional. Instead of manually applying labels to new issues, for example, you’ll be able to automate your workflow to automatically apply a label like “Waiting for Triage”.
-Conversely, organizations may want to enforce their workflows by defining events that should’ve already taken place. Like automations, we should be able to define - and enforce - these restrictions in code, ensuring compliance and peace-of-mind. 
+Conversely, organizations may want to enforce their workflows by defining events that should’ve already taken place. Like automations, we should be able to define - and enforce - these restrictions in code, ensuring compliance and peace-of-mind.
 We’re calling these restrictions [Policies](https://gitlab.com/groups/gitlab-org/-/epics/366), and we’re adding them as a mechanism to define prerequisites for certain actions in GitLab. You’ll be able to [restrict certain actions](https://gitlab.com/gitlab-org/gitlab-ee/issues/7626) - creating an issue, for example - to certain users that have met a custom requirement that you’ve defined.
@@ -51,12 +60,14 @@ We’re calling these restrictions [Policies](https://gitlab.com/groups/gitlab-o
 As GitLab continues to grow, we want to continue to iterate and improve on existing features. This is especially true of features that help large organizations thrive in GitLab.
-We’re continuing to improve on authentication within GitLab, which is of critical importance for managing users at scale. We’re continuing to build out Group SAML for GitLab.com by automating membership and permissions management. We’re also improving OAuth by allowing you to programmatically manage tokens. 
-Finally, we’re excited to give instances more control and power over how they manage spending. You’ll be able to clearly understand how your instance’s license is being used, with granular control over seats. Alongside making billing easier to understand than ever, we’re also improving our billing portal to give you the power to self-serve changes to your subscription. 
-### Our plans
-We couldn’t be more excited to make GitLab easier than ever to manage. In 2019, we’ll do this by building out powerful configuration that reflects your unique needs and providing you with insightful analytics that helps you move faster than ever. 
-We’ll keep iterating on these concepts well into 2020, and continue adding more powerful analytics and collaboration features to help you work seamlessly in GitLab.
+We’re continuing to improve on authentication within GitLab, which is of critical importance for managing users at scale. We’re continuing to build out Group SAML for GitLab.com by automating membership and permissions management. We’re also improving OAuth by allowing you to programmatically manage tokens.
+
+Finally, we’re excited to give instances more control and power over how they manage spending. You’ll be able to clearly understand how your instance’s license is being used, with granular control over seats. Alongside making billing easier to understand than ever, we’re also improving our billing portal to give you the power to self-serve changes to your subscription.
+## Our plans
+We couldn’t be more excited to make GitLab easier than ever to manage. In 2019, we’ll do this by building out powerful configuration that reflects your unique needs and providing you with insightful analytics that helps you move faster than ever.
+We’ll keep iterating on these concepts well into 2020, and continue adding more powerful analytics and collaboration features to help you work seamlessly in GitLab.
\ No newline at end of file
+<%= partial("direction/other", :locals => { :stage => "manage" }) %>

source/direction/monitor/template.html.md.erb

+---
+layout: markdown_page
+title: "Product Vision - monitor"
+---
+
+- TOC
+{:toc}
+
+Performance is a critical aspect of the user experience, and ensuring your application is responsive and available is everyone's responsibility. We want to help address this need for development teams, by integrating key performance analytics and feedback into the tool developers already use every day.
+
+As part of our commitment to performance we are also deeply instrumenting GitLab itself, enabling our team to improve GitLab peformance and for customers to more easily manage their deployments.
+
+<%= partial("direction/other", :locals => { :stage => "monitor" }) %>

source/direction/package/template.html.md.erb

+---
+layout: markdown_page
+title: "Product Vision - Package"
+---
+
+- TOC
+{:toc}
+
+<%= partial("direction/other", :locals => { :stage => "package" }) %>

source/direction/plan/template.html.md.erb

@@ -92,14 +92,12 @@ leveraging the benefits of GitLab source control and other native GitLab feature
 - [Import Jira issues to GitLab issues](https://gitlab.com/groups/gitlab-org/-/epics/10)
 - [Better than Atlassian Jira integration](https://gitlab.com/gitlab-org/gitlab-ce/issues/27073)
-## Other areas of interest
-
-Details to come
-
 ## How we prioritize
 Details to come
 ## Feedback and contributions
-Details to come
\ No newline at end of file
+Details to come
+
+<%= partial("direction/other", :locals => { :stage => "secure" }) %>

source/direction/release/template.html.md.erb

@@ -6,29 +6,34 @@ title: "Product Vision - Release"
 - TOC
 {:toc}
+The Release stage of the DevOps pipeline covers automated, repeatable, and
+risk-reduction for releases, such as CD and feature flags, as well as the pages
+feature. We want to make delivering software reliable, repeatable, and
+successful.
+
 This is the product vision for Release in 2019 and beyond.
-### Continuous Delivery Landscape
+## Continuous Delivery Landscape
 It's an exciting time in the world of Continuous Delivery. Technologies
-like Kubernetes have created a huge splash and are driving innovation 
-forward; serverless, microservices, and cloud native in general represent 
-important evolutions as well. Monitoring technology also continues to 
-advance, making the promise of technologies like automated rollbacks based 
-on impact a reality. 
-
-We also know that Continuous Delivery is a journey - we have users everywhere 
-on the spectrum from facing transformational challenges moving away from 
-legacy stacks all the way to those looking to squeeze the last bits of 
-efficiency out of highly automated DevOps delivery platforms. By delivering 
-our features more purposefully in the context of DevOps maturity levels, 
-we are going to be able to do better bringing everyone on the journey to 
+like Kubernetes have created a huge splash and are driving innovation
+forward; serverless, microservices, and cloud native in general represent
+important evolutions as well. Monitoring technology also continues to
+advance, making the promise of technologies like automated rollbacks based
+on impact a reality.
+
+We also know that Continuous Delivery is a journey - we have users everywhere
+on the spectrum from facing transformational challenges moving away from
+legacy stacks all the way to those looking to squeeze the last bits of
+efficiency out of highly automated DevOps delivery platforms. By delivering
+our features more purposefully in the context of DevOps maturity levels,
+we are going to be able to do better bringing everyone on the journey to
 DevOps success.
-### The Journey to DevOps Maturity
-We're really taking the idea of bringing GitLab users on the CI/CD journey seriously, 
-and have used the great model [here](http://bekkopen.github.io/maturity-model/) for our 
+## The Journey to DevOps Maturity
+We're really taking the idea of bringing GitLab users on the CI/CD journey seriously,
+and have used the great model [here](http://bekkopen.github.io/maturity-model/) for our
 inspiration (though we have modified it slightly and will continue to do so over time.)
 We also use a [simplified version](https://about.gitlab.com/handbook/devops-maturity-model/) of this maturity
 model elsewhere in the product.
@@ -42,49 +47,49 @@ model elsewhere in the product.
 | Configuration Management | **Infrastructure as code:** Fully automated provisioning and validation of environments. Orchestration of environments. | **Application configuration control:** All application configuration in version control. The application is configured in one place. Self service of development- and test environments. | **Dependency control:** Dependencies and libraries are defined in version control. | **Manual configuration:** Manual configuration in each environment and on each server. |
 | Build & Continuous Integration | **Build/deploy pipeline:** Same binary is deployed to all environments. Continuous improvement and automation of repeating tasks. Optimised for rapid feedback and visualisation of integration problems. | **Continuous integration:** Continuous integration of source code to mainline. All changes (code, configuration, environments, etc.) triggers the feedback mechanisms. Artifact repository. Reuse of scripts and tools. Generation of reports for the build. Builds that fail are fixed immediately. | **CI-server:** Automation of builds/tests on CI server. Can recreate builds from source code. | **Manual routines:** Manual routines for builds. Lack of artifact repository. Lack of reports. |
-### Important Concepts
-In order to accelerate CD in this new world, there are a few particular 
+## Important Concepts
+In order to accelerate CD in this new world, there are a few particular
 ideas we are keeping close as north stars to guide us forward:
 ☁️ **Innovating with Cloud Native Capability**
-Our platform must stay current with evolving trends in platform 
-architecture. Microservices, Kubernetes, and Serverless will continue to 
-lead the way here, and our CI/CD solutions must address the unique needs 
-of these approaches by offering solutions that facilitate the 
-technological and cultural transformations these teams are going through. 
-These technologies represent a wave driving DevOps forward, and we want to 
+Our platform must stay current with evolving trends in platform
+architecture. Microservices, Kubernetes, and Serverless will continue to
+lead the way here, and our CI/CD solutions must address the unique needs
+of these approaches by offering solutions that facilitate the
+technological and cultural transformations these teams are going through.
+These technologies represent a wave driving DevOps forward, and we want to
 be on the crest of that wave helping companies to deliver using GitLab.
 💡 **Delivery Insights to Unlock DevOps Success**
-As Peter Drucker says, "if you can't measure it - you can't improve it." 
-Using the data in our CI/CD platform to help teams get the most out of 
-their delivery pipeline gives us a unique advantage in offering DevOps 
-insights to our users. Where competitors must integrate with a variety of 
-other tools, attempting to normalize and understand data structures that 
-can change at any time, we build a single application solution where 
-process, behavioral, and other insights can flow seamlessly throughout, 
-facilitating organizational transformation. Value stream mapping, wait 
-time, retries, failure rate, batch size, job duration, quality, resource 
-usage, throughput; these (and more) are all great metrics we already have 
+As Peter Drucker says, "if you can't measure it - you can't improve it."
+Using the data in our CI/CD platform to help teams get the most out of
+their delivery pipeline gives us a unique advantage in offering DevOps
+insights to our users. Where competitors must integrate with a variety of
+other tools, attempting to normalize and understand data structures that
+can change at any time, we build a single application solution where
+process, behavioral, and other insights can flow seamlessly throughout,
+facilitating organizational transformation. Value stream mapping, wait
+time, retries, failure rate, batch size, job duration, quality, resource
+usage, throughput; these (and more) are all great metrics we already have
 in the system and can increase visibility to.
 ❤️ **More Complete (Minimally Lovable) Features to Solve Complex Problems**
-V1 feature iterations are how we build software, but at the same time we 
-need to continue to curate those features that have proven their value 
-into complete, lovable features that exceed our users expectations. We will 
-achieve this by growing individual features, solving scalability challenges 
-that larger customers see, and providing intelligent connections between individual 
+V1 feature iterations are how we build software, but at the same time we
+need to continue to curate those features that have proven their value
+into complete, lovable features that exceed our users expectations. We will
+achieve this by growing individual features, solving scalability challenges
+that larger customers see, and providing intelligent connections between individual
 features. Doing this lets us solve deeper, more subtle problem sets and - by
 being focused on real problems our users face - we'll leave the competition
 behind.
-### Upcoming Categories and Focus
-To achieve our goals in the CD domain, we're looking at making big investments 
+## Upcoming Categories and Focus
+To achieve our goals in the CD domain, we're looking at making big investments
 over the medium term in several key areas, including the following. We've aligned each
 quarter in 2019 to a step along the journey where we'll focus on improving that part
 of the path, though that doesn't mean we aren't looking at the big picture
@@ -99,12 +104,12 @@ peel the onion back ensuring there's a breadcrumb trail for all users to reach t
 level of maturity (not just in these features, but for all advanced features in
 GitLab CI/CD.)
-The items below with icons (☁️💡❤️) are ones we've flagged as being particularly 
-important; the icon indicates which of the [concepts](#important-concepts) that 
+The items below with icons (☁️💡❤️) are ones we've flagged as being particularly
+important; the icon indicates which of the [concepts](#important-concepts) that
 item links back to and is an important part of achieving.
 - **Q1 2019** (with majority focus on "Advanced" Maturity Teams): We plan to kick things
-  off by delivering some important features that drive our vision for CD forward. In 
+  off by delivering some important features that drive our vision for CD forward. In
   particular, this means completing the CD feedback loop by integrating with monitoring
   to understand how your deployments are faring. We'll also be looking at group level views
   for CD to make managing large organizations easier, and taking a deep look at analyst
@@ -127,8 +132,8 @@ item links back to and is an important part of achieving.
   - Secrets Management v2 ❤️
   - Built-in helm repository & browser ☁️
 - **Q3 2019** (with majority focus on "Baseline" Maturity Teams): For teams achieving their first
-  successes with DevOps, we need to build them a clear path forward to more wins for more of their teams. 
-  To achieve this our focus here will be on building best-practice approaches built-in in to CD. 
+  successes with DevOps, we need to build them a clear path forward to more wins for more of their teams.
+  To achieve this our focus here will be on building best-practice approaches built-in in to CD.
   Documented patterns and solutions, better, more clear integration with AutoDevOps, deeper tie-ins to
   value stream mapping to understand how you're doing, and deeper dives on features like
   Feature Flags which are key enablers of achieving further success with DevOps.
@@ -156,33 +161,18 @@ Finally, it's important to mention that this is our vision on the product at thi
 time. All of this can change any moment and should not be taken as a hard commitment,
 though we do try to keep things generally stable and not change things all the time.
-### Prioritization Process
+## Prioritization Process
 In general, we follow the same [prioritization guidelines](/handbook/product/#prioritization) as the product
 team at large. Issues will tend to flow from having no milestone, to being added to the backlog (at
-which point they are welcome for community contributions!), to being added to this page and/or a 
+which point they are welcome for community contributions!), to being added to this page and/or a
 specific milestone for delivery.
 You can see our entire public backlog for Release at this [link](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&state=opened&label_name[]=devops%3Arelease); filtering by labels or milestones will
 allow you to explore. If you find something you're interested in, you're encouraged to jump into
 the conversation and participate. At GitLab, everyone can contribute!
-Issues with the "direction" label have been flagged as being particularly interesting, and 
+Issues with the "direction" label have been flagged as being particularly interesting, and
 are listed in the section below.
-### Other Interesting Items
-
-There are a number of other issues that we've identified as being interesting
-that we are potentially thinking about, but do not currently have planned by
-setting a milestone for delivery. Some are good ideas we want to do, but don't
-yet know when; some we may never get around to, some may be replaced by another
-idea, and some are just waiting for that right spark of inspiration to turn
-them into something special.
-
-Remember that at GitLab, everyone can contribute! This is one of our 
-fundamental values and something we truly believe in, so if you have 
-feedback on any of these items you're more than welcome to jump into 
-the discussion. Our vision and product are truly something we build 
-together!
-
-<%= wishlist["devops:release"] %>
\ No newline at end of file
+<%= partial("direction/other", :locals => { :stage => "release" }) %>

source/direction/secure/index.html.md → source/direction/secure/template.html.md.erb

 ---
 layout: markdown_page
-title: Secure Vision
+title: Product Vision - Secure
 ---
 ## On this page
@@ -9,30 +9,48 @@ title: Secure Vision
 - TOC
 {:toc}
-## DevOps coverage
-
-The classic DevOps includes security testing as an activity in the **Verify** stage.
-
-GitLab has a broader approach. That's why we introduced a **Secure** stage that is transversal to all other stages.
-Our Product Vision for 2019 aims to provide security support for all the stages in the [DevOps lifecycle](https://en.wikipedia.org/wiki/DevOps_toolchain): **Plan**, **Create**, **Verify**, **Package**, **Release**, **Configure**, and **Monitor**.
-
-This is possible because GitLab is a [single application](https://about.gitlab.com/handbook/product/single-application/).
-
-There are many advantages coming from complete coverage of all the stages with security features.
-It allows to shift-left security at a very early stage, even before the first lines of code are committed.
-If you start with security as a priority when you plan a new app, it is easier than just trying to add security later.
-Security should remain on the radar even when the create process happens, to support developers and help them to write secure
-code from the beginning.
-Security testing can then happen for any change, before it is merged into the stable branch of the application: in this way
-you can spot problems and fix them before they risk affecting the production environment or the stable version of your app.
-Packaging the app should also be done with security in mind, as well as the release process to the production environment:
-at that point, your code is publicly available and any remediation will impact heavily on your processes.
-You should also not forget about security after your code is online: new vulnerabilities are spotted every day, and you want
-to ensure that your deployed application is always protected and monitored, so any new threat will be detected in advance and
-you can give a prompt security response in case something should be done.
-The following features are part of the future of GitLab, and will contribute to completing the coverage of all the DevOps stages:
+The Secure stage aims to ensure that applications developed with GitLab are not
+affected by vulnerabilities that may lead to security problems and unintended
+use. This can be achieved by covering the entire DevOps lifecycle with features
+that allow both security teams and developers to know if there is something that
+they should consider in their apps, before it is too late to create a fix.
+## DevOps coverage
+The classic DevOps includes security testing as an activity in the **Verify**
+stage.
+
+GitLab has a broader approach. That's why we introduced a **Secure** stage that
+is transversal to all other stages.
+
+Our Product Vision for 2019 aims to provide security support for all the stages
+in the [DevOps lifecycle](https://en.wikipedia.org/wiki/DevOps_toolchain):
+**Plan**, **Create**, **Verify**, **Package**, **Release**, **Configure**, and
+**Monitor**.
+
+This is possible because GitLab is a
+[single application](https://about.gitlab.com/handbook/product/single-application/).
+
+There are many advantages coming from complete coverage of all the stages with
+security features. It allows to shift-left security at a very early stage, even
+before the first lines of code are committed. If you start with security as a
+priority when you plan a new app, it is easier than just trying to add security
+later. Security should remain on the radar even when the create process happens,
+to support developers and help them to write secure code from the beginning.
+Security testing can then happen for any change, before it is merged into the
+stable branch of the application: in this way you can spot problems and fix them
+before they risk affecting the production environment or the stable version of
+your app. Packaging the app should also be done with security in mind, as well
+as the release process to the production environment: at that point, your code
+is publicly available and any remediation will impact heavily on your processes.
+You should also not forget about security after your code is online: new
+vulnerabilities are spotted every day, and you want to ensure that your deployed
+application is always protected and monitored, so any new threat will be
+detected in advance and you can give a prompt security response in case
+something should be done.
+
+The following features are part of the future of GitLab, and will contribute to
+completing the coverage of all the DevOps stages:
 - [Security Assessment Questionnaires](https://gitlab.com/gitlab-org/gitlab-ee/issues/7421) <kbd>Secure+Plan</kbd>
 - [Run security testing before code is committed](https://gitlab.com/gitlab-org/gitlab-ee/issues/7099) <kbd>Secure+Create</kbd>
@@ -44,41 +62,79 @@ The following features are part of the future of GitLab, and will contribute to
 - [Auto IDS/IPS to protect deployments](https://gitlab.com/gitlab-org/gitlab-ee/issues/7100) <kbd>Secure+Monitor</kbd>
 - [Detect malicious behavior of deployed apps](https://gitlab.com/gitlab-org/gitlab-ee/issues/7209) <kbd>Secure+Monitor</kbd>
-This list is just a slice of what we want to do to increase security for our users' applications.
-Security is a never-ending priority, and at GitLab we want to make it easy for our users to manage it.
+This list is just a slice of what we want to do to increase security for our
+users' applications.
+Security is a never-ending priority, and at GitLab we want to make it easy for
+our users to manage it.
 ## Security Paradigm
-GitLab security features support users in prioritizing, managing, and solving any security issue that may affect their environment. The primary focus is to increase awareness on security (onboarding) and to provide all the information needed to take decisions about that.
-
-The approach is to _support_ decision makers, not to replace them. Instead of enforcing security, we want to give a very simple way to take the right action, and learn from it. Keeping it simple is a key value to prevent that security features will not be considered at all because they require more effort than the perceived benefit.
-
-That's why security features are not supposed to automatically block a pipeline or to prevent a new version to be released on production. Even if we try to be accurate, results may suffer of false positives by their nature. Risk assessment will be mostly a human process.
-
-Tools are actionable: it means that users can [interact with them and provide feedback](https://docs.gitlab.com/ee/user/project/merge_requests/#interacting-with-security-reports) about their content. When triaging vulnerabilities users can confirm them (creating an issue to solve the problem), or just dismiss them in case they are false positives and there is no further action to take. This information will be collected to improve the signal-to-noise ratio that the tool could provide in future executions.
-
-They also need to be easy to use, and require the minimum amount of effort from users. If not, they will likely be disabled or not considered at all, missing their primary goal. Imagine if users had to explain why they are marking an email as spam every time!
+GitLab security features support users in prioritizing, managing, and solving
+any security issue that may affect their environment. The primary focus is to
+increase awareness on security (onboarding) and to provide all the information
+needed to take decisions about that.
+
+The approach is to _support_ decision makers, not to replace them. Instead of
+enforcing security, we want to give a very simple way to take the right action,
+and learn from it. Keeping it simple is a key value to prevent that security
+features will not be considered at all because they require more effort than the
+perceived benefit.
+
+That's why security features are not supposed to automatically block a pipeline
+or to prevent a new version to be released on production. Even if we try to be
+accurate, results may suffer of false positives by their nature. Risk assessment
+will be mostly a human process.
+
+Tools are actionable: it means that users can
+[interact with them and provide feedback](https://docs.gitlab.com/ee/user/project/merge_requests/#interacting-with-security-reports)
+about their content. When triaging vulnerabilities users can confirm them
+(creating an issue to solve the problem), or just dismiss them in case they are
+false positives and there is no further action to take. This information will be
+collected to improve the signal-to-noise ratio that the tool could provide in
+future executions.
+
+They also need to be easy to use, and require the minimum amount of effort from
+users. If not, they will likely be disabled or not considered at all, missing
+their primary goal. Imagine if users had to explain why they are marking an
+email as spam every time!
 ## Target audience
 ### Security teams
-We want to support security teams as first class citizens. GitLab should be their primary tool to manage monitoring and remediation of security issues. Using the **Security Dashboard** security specialists know exactly which is the most important thing they need to take care of, while Directors of Security can manage workflows and analyze historical data to figure out how to improve the response time.
-This is a vulnerability-centric approach where items are grouped and ordered to suggest what's most important in a group, or in the entire instance.
+We want to support security teams as first class citizens. GitLab should be
+their primary tool to manage monitoring and remediation of security issues.
+Using the **Security Dashboard** security specialists know exactly which is the
+most important thing they need to take care of, while Directors of Security can
+manage workflows and analyze historical data to figure out how to improve the
+response time.
+This is a vulnerability-centric approach where items are grouped and ordered to
+suggest what's most important in a group, or in the entire instance.
 ### Developers
-Nonetheless, we want to support developers and provide feedback during the application development. [**Security Reports**](https://docs.gitlab.com/ee/user/project/merge_requests/#security-reports) in merge request widgets and pipelines allow early access to security information that can be used to fix problems even before they are merged into the stable branch or released to the public, embrancing the idea of [shift left testing](https://en.wikipedia.org/wiki/Shift_left_testing).
-This approach is valuable to highlight how specific changes could affect the security of the application.
+Nonetheless, we want to support developers and provide feedback during the
+application development.
+[**Security Reports**](https://docs.gitlab.com/ee/user/project/merge_requests/#security-reports)
+in merge request widgets and pipelines allow early access to security
+information that can be used to fix problems even before they are merged into
+the stable branch or released to the public, embrancing the idea of [shift left testing](https://en.wikipedia.org/wiki/Shift_left_testing).
+This approach is valuable to highlight how specific changes could affect the
+security of the application.
 ## Impact
-We expect that in most of the cases the number of potential security issues will be high, and we don't want that users will struggle in figuring out which is the impact of any possible item for their environment. That's why GitLab will prioritize security vulnerabilities based on different factors. The value given with this process is defined as the impact.
-These are examples of factors that may contribute to define the impact for a specific security issue:
+We expect that in most of the cases the number of potential security issues will
+be high, and we don't want that users will struggle in figuring out which is the
+impact of any possible item for their environment. That's why GitLab will
+prioritize security vulnerabilities based on different factors. The value given
+with this process is defined as the impact.
+These are examples of factors that may contribute to define the impact for a
+specific security issue:
 - severity and confidence levels, provided by the analysis tool
 - feedback given in other reports for the same vulnerability
 - exposure of the vulnerability (e.g., app has already been deployed to production)
@@ -87,12 +143,22 @@ These are examples of factors that may contribute to define the impact for a spe
 ### Ultimate/Gold subscribers
-As for now, security features are available in the [Ultimate/Gold tier](https://about.gitlab.com/pricing/) because we think that security matters for everyone, but automation of security in the development lifecycle is more valuable for organizations who want to optimize their DevOps investment to run securely at the highest business velocity.
+For now, security features are available in the [Ultimate/Gold tier](https://about.gitlab.com/pricing/)
+because we think that security matters for everyone, but automation of security
+in the development lifecycle is more valuable for organizations who want to
+optimize their DevOps investment to run securely at the highest business
+velocity.
 ### Public projects on GitLab.com
-Every project on [GitLab.com](https://gitlab.com) with [public visibility](https://docs.gitlab.com/ee/public_access/public_access.html#public-projects) can benefit of all the security features for free.
+Every project on [GitLab.com](https://gitlab.com) with
+[public visibility](https://docs.gitlab.com/ee/public_access/public_access.html#public-projects)
+can benefit of all the security features for free.
 ## Metrics
-We also want to collect and provide metrics to better understand how the security workflow is performing. For example, the overall time taken to deploy a fix for a vulnerability once spotted could be useful for flow improvements.
+We also want to collect and provide metrics to better understand how the
+security workflow is performing. For example, the overall time taken to deploy a
+fix for a vulnerability once spotted could be useful for flow improvements.
+
+<%= partial("direction/other", :locals => { :stage => "secure" }) %>

source/direction/verify/template.html.md.erb

@@ -6,29 +6,33 @@ title: "Product Vision - Verify"
 - TOC
 {:toc}
+The Verify stage of the DevOps pipeline covers the CI lifecycle as well as
+testing (unit, integration, acceptance, performance, etc.). Our mission is to
+help developers feel confident in delivering their code to production.
+
 This is the product vision for Verify in 2019 and beyond.
-### Continuous Integration Landscape
+## Continuous Integration Landscape
 It's an exciting time in the world of Continuous Integration. Technologies
 like Kubernetes have created a huge splash and are driving innovation
-forward; serverless, microservices, and cloud native in general represent 
-important evolutions as well. Monitoring technology also continues to 
-advance, making the promise of technologies like automated rollbacks based 
-on impact a reality. 
-
-We also know that Continuous Delivery is a journey - we have users everywhere 
-on the spectrum from facing transformational challenges moving away from 
-legacy stacks all the way to those looking to squeeze the last bits of 
-efficiency out of highly automated DevOps delivery platforms. By delivering 
-our features more purposefully in the context of DevOps maturity levels, 
-we are going to be able to do better bringing everyone on the journey to 
+forward; serverless, microservices, and cloud native in general represent
+important evolutions as well. Monitoring technology also continues to
+advance, making the promise of technologies like automated rollbacks based
+on impact a reality.
+
+We also know that Continuous Delivery is a journey - we have users everywhere
+on the spectrum from facing transformational challenges moving away from
+legacy stacks all the way to those looking to squeeze the last bits of
+efficiency out of highly automated DevOps delivery platforms. By delivering
+our features more purposefully in the context of DevOps maturity levels,
+we are going to be able to do better bringing everyone on the journey to
 DevOps success.
-### The Journey to DevOps Maturity
-We're really taking the idea of bringing GitLab users on the CI/CD journey seriously, 
-and have used the great model [here](http://bekkopen.github.io/maturity-model/) for our 
+## The Journey to DevOps Maturity
+We're really taking the idea of bringing GitLab users on the CI/CD journey seriously,
+and have used the great model [here](http://bekkopen.github.io/maturity-model/) for our
 inspiration (though we have modified it slightly and will continue to do so over time.)
 We also use a [simplified version](https://about.gitlab.com/handbook/devops-maturity-model/) of this maturity
 model elsewhere in the product.
@@ -42,49 +46,49 @@ model elsewhere in the product.
 | Configuration Management | **Infrastructure as code:** Fully automated provisioning and validation of environments. Orchestration of environments. | **Application configuration control:** All application configuration in version control. The application is configured in one place. Self service of development- and test environments. | **Dependency control:** Dependencies and libraries are defined in version control. | **Manual configuration:** Manual configuration in each environment and on each server. |
 | Build & Continuous Integration | **Build/deploy pipeline:** Same binary is deployed to all environments. Continuous improvement and automation of repeating tasks. Optimised for rapid feedback and visualisation of integration problems. | **Continuous integration:** Continuous integration of source code to mainline. All changes (code, configuration, environments, etc.) triggers the feedback mechanisms. Artifact repository. Reuse of scripts and tools. Generation of reports for the build. Builds that fail are fixed immediately. | **CI-server:** Automation of builds/tests on CI server. Can recreate builds from source code. | **Manual routines:** Manual routines for builds. Lack of artifact repository. Lack of reports. |
-### Important Concepts
-In order to accelerate CI in this new world, there are a few particular 
+## Important Concepts
+In order to accelerate CI in this new world, there are a few particular
 ideas we are keeping close as north stars to guide us forward:
 ☁️ **Innovating with Cloud Native Capability**
-Our platform must stay current with evolving trends in platform 
-architecture. Microservices, Kubernetes, and Serverless will continue to 
-lead the way here, and our CI/CD solutions must address the unique needs 
-of these approaches by offering solutions that facilitate the 
-technological and cultural transformations these teams are going through. 
-These technologies represent a wave driving DevOps forward, and we want to 
+Our platform must stay current with evolving trends in platform
+architecture. Microservices, Kubernetes, and Serverless will continue to
+lead the way here, and our CI/CD solutions must address the unique needs
+of these approaches by offering solutions that facilitate the
+technological and cultural transformations these teams are going through.
+These technologies represent a wave driving DevOps forward, and we want to
 be on the crest of that wave helping companies to deliver using GitLab.
 💡 **Delivery Insights to Unlock DevOps Success**
-As Peter Drucker says, "if you can't measure it - you can't improve it." 
-Using the data in our CI/CD platform to help teams get the most out of 
-their delivery pipeline gives us a unique advantage in offering DevOps 
-insights to our users. Where competitors must integrate with a variety of 
-other tools, attempting to normalize and understand data structures that 
-can change at any time, we build a single application solution where 
-process, behavioral, and other insights can flow seamlessly throughout, 
-facilitating organizational transformation. Value stream mapping, wait 
-time, retries, failure rate, batch size, job duration, quality, resource 
-usage, throughput; these (and more) are all great metrics we already have 
+As Peter Drucker says, "if you can't measure it - you can't improve it."
+Using the data in our CI/CD platform to help teams get the most out of
+their delivery pipeline gives us a unique advantage in offering DevOps
+insights to our users. Where competitors must integrate with a variety of
+other tools, attempting to normalize and understand data structures that
+can change at any time, we build a single application solution where
+process, behavioral, and other insights can flow seamlessly throughout,
+facilitating organizational transformation. Value stream mapping, wait
+time, retries, failure rate, batch size, job duration, quality, resource
+usage, throughput; these (and more) are all great metrics we already have
 in the system and can increase visibility to.
 ❤️ **More Complete (Minimally Lovable) Features to Solve Complex Problems**
-V1 feature iterations are how we build software, but at the same time we 
-need to continue to curate those features that have proven their value 
-into complete, lovable features that exceed our users expectations. We will 
-achieve this by growing individual features, solving scalability challenges 
-that larger customers see, and providing intelligent connections between individual 
+V1 feature iterations are how we build software, but at the same time we
+need to continue to curate those features that have proven their value
+into complete, lovable features that exceed our users expectations. We will
+achieve this by growing individual features, solving scalability challenges
+that larger customers see, and providing intelligent connections between individual
 features. Doing this lets us solve deeper, more subtle problem sets and - by
 being focused on real problems our users face - we'll leave the competition
 behind.
-### Upcoming Categories and Focus
-To achieve our goals in the CI domain, we're looking at making big investments 
+## Upcoming Categories and Focus
+To achieve our goals in the CI domain, we're looking at making big investments
 over the medium term in several key areas, including the following. We've aligned each
 quarter in 2019 to a step along the journey where we'll focus on improving that part
 of the path, though that doesn't mean we aren't looking at the big picture
@@ -99,8 +103,8 @@ peel the onion back ensuring there's a breadcrumb trail for all users to reach t
 level of maturity (not just in these features, but for all advanced features in
 GitLab CI/CD.)
-The items below with icons (☁️💡❤️) are ones we've flagged as being particularly 
-important; the icon indicates which of the [concepts](#important-concepts) that 
+The items below with icons (☁️💡❤️) are ones we've flagged as being particularly
+important; the icon indicates which of the [concepts](#important-concepts) that
 item links back to and is an important part of achieving.
 - **Q1 2019** (with majority focus on "Advanced" Maturity Teams): Starting with the first
@@ -160,33 +164,18 @@ Finally, it's important to mention that this is our vision on the product at thi
 time. All of this can change any moment and should not be taken as a hard commitment,
 though we do try to keep things generally stable and not change things all the time.
-### Prioritization Process
+## Prioritization Process
 In general, we follow the same [prioritization guidelines](/handbook/product/#prioritization) as the product
 team at large. Issues will tend to flow from having no milestone, to being added to the backlog (at
-which point they are welcome for community contributions!), to being added to this page and/or a 
+which point they are welcome for community contributions!), to being added to this page and/or a
 specific milestone for delivery.
 You can see our entire public backlog for Verify at this [link](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&state=opened&label_name[]=devops%3Averify); filtering by labels or milestones will
 allow you to explore. If you find something you're interested in, you're encouraged to jump into
 the conversation and participate. At GitLab, everyone can contribute!
-Issues with the "direction" label have been flagged as being particularly interesting, and 
+Issues with the "direction" label have been flagged as being particularly interesting, and
 are listed in the section below.
-### Other Interesting Items
-
-There are a number of other issues that we've identified as being interesting
-that we are potentially thinking about, but do not currently have planned by
-setting a milestone for delivery. Some are good ideas we want to do, but don't
-yet know when; some we may never get around to, some may be replaced by another
-idea, and some are just waiting for that right spark of inspiration to turn
-them into something special.
-
-Remember that at GitLab, everyone can contribute! This is one of our 
-fundamental values and something we truly believe in, so if you have 
-feedback on any of these items you're more than welcome to jump into 
-the discussion. Our vision and product are truly something we build 
-together!
-
-<%= wishlist["devops:verify"] %>
\ No newline at end of file
+<%= partial("direction/other", :locals => { :stage => "verify" }) %>