direction以下のページを追加

aa318cea · Hiroyuki Sato · 7a391134 · aa318cea · aa318cea · aa318cea
Commit aa318cea authored Aug 18, 2020 by Hiroyuki Sato 🇯🇵
232 changed files
--- a/source/direction/Fulldevops.png
+++ b/source/direction/Fulldevops.png
--- a/source/direction/Personas.png
+++ b/source/direction/Personas.png
--- a/source/direction/_categories-content.erb
+++ b/source/direction/_categories-content.erb
+<% data.categories.each do |categoryKey, category| %>
+  <% next unless (category.stage == stageKey) %>
+  <% l = [] %>
+  <% l << "Priority: #{category.priority_level}" if category.priority_level %>
+  <% l << "[Learn more](#{category.marketing_page})" if category.marketing_page %>
+  <% l << "[Documentation](#{category.documentation})" if category.documentation %>
+  <% l << "[Direction](#{category.direction})" if category.direction %>
+##### <%= category.name %>
+<% maturity = "This category is planned, but not yet available." %>
+<% if category.available != nil %>
+  <% maturity = "This category is at the \"minimal\" level of maturity." if category.available.past? %>
+<% end %>
+<% if category.viable != nil %>
+  <% maturity = "This category is at the \"viable\" level of maturity." if category.viable.past? %>
+<% end %>
+<% if category.complete != nil %>
+  <% maturity = "This category is at the \"complete\" level of maturity." if category.complete.past? %>
+<% end %>
+<% if category.lovable != nil %>
+  <% maturity = "This category is at the \"lovable\" level of maturity." if category.lovable.past? %>
+<% end %>
+<% if category.marketing == false %>
+  <% maturity = "" %>
+<% end %>
+<%= category.description + " " + maturity + "  " unless category.description.blank? %>
+<%= maturity + "  " if category.description.blank? %>
+<%= l.join(' • ') unless l.empty? %>
+<% end %>
--- a/source/direction/_categories.erb
+++ b/source/direction/_categories.erb
+## Categories
+There are a few product categories that are critical for success here; each one
+is intended to represent what you might find as an entire product out in the
+market. We want our single application to solve the important problems solved by 
+other tools in this space - if you see an opportunity where we can deliver
+a specific solution that would be enough for you to switch over to GitLab, 
+please reach out to the PM for this stage and let us know.
+Each of these categories has a designated level of maturity; you can read more about our 
+[category maturity model](/direction/maturity/) 
+to help you decide which categories you want to start using and when.
+<%= partial("direction/categories-content", :locals => { :stageKey => stageKey }) %>
--- a/source/direction/_contribute.erb
+++ b/source/direction/_contribute.erb
+## Contributing
+At GitLab, one of our values is that everyone can contribute. If you're looking to
+get involved with features in the <%= stageKey.capitalize %> area, there are a couple searches you can use
+to find issues to work on:
+- [Contribute for Prize](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Contribute%20for%20prize&label_name[]=devops%3A%3A<%= stageKey %>) items are the best place to start: these have been pre-selected as being ready to go, and you can win a prize by contributing to them. More details on the `Contribute for Prize` program is available on our [Code Contributor Programs](https://about.gitlab.com/handbook/marketing/community-relations/code-contributor-program/#contribute-for-prize) page. 
+- [UI Polish](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Accepting%20merge%20requests&label_name[]=devops%3A%3A<%= stageKey %>) items are generally frontend development (or at least minimal backend), are very self-contained, and are great, very visible items that can make a big difference when it comes to usability.
+- [Accepting Merge Request](https://gitlab.com/groups/gitlab-org/-/issues?label_name%5B%5D=UI+polish&label_name%5B%5D=devops%3A%3A<%= stageKey %>&scope=all&state=opened) items are open to contribution. These are generally a bit more complicated, so if you're interested in contributing we recommend you open up a dialog with us in the issue.
+- [Community Contribution](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Community%20contribution&label_name[]=devops%3A%3A<%= stageKey %>) items may already have some contributors working on them if you want to join up. There aren't always issues here to find.
+You can read more about our general contribution guidelines [here](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md).
--- a/source/direction/_jtbd-list.erb
+++ b/source/direction/_jtbd-list.erb
+<div>
+<% data.jobs_to_be_done.each do |primary_jtbd| %>
+    <% if primary_jtbd.group == stage_key && (primary_jtbd.parent.nil? || primary_jtbd.parent.empty?) %>
+      <h3><%= primary_jtbd.short_jtbd %></h3>
+      <p><%= primary_jtbd.jtbd %></p>
+      <table style="width: 100%">
+        <colgroup>
+          <col span="1" style="width: 60%;">
+          <col span="1" style="width: 20%;">
+          <col span="1" style="width: 13%;">
+          <col span="1" style="width: 9%;">
+        </colgroup>
+        <tr>
+          <th>Job statements</th>
+          <th>Maturity</th>
+          <th>Confidence</th>
+          <th>Source</th>
+        </tr>
+      <% data.jobs_to_be_done.each do |secondary_jtbd| %>
+          <% if primary_jtbd.group == stage_key && (secondary_jtbd.parent == primary_jtbd.slug) %>
+              <tr>
+                <td>
+                  <%= secondary_jtbd.jtbd %>
+                </td>
+                <td>
+                  <%= ux_grade(secondary_jtbd.grade) %>
+                </td>
+                <td>
+                  <%= secondary_jtbd.confidence %>
+                </td>
+                <td>
+                  <a href="<%= primary_jtbd.source %>">Issue</a>
+                </td>
+              </tr>
+          <% end %>
+      <% end %>
+      </table>
+    <% end %>
+<% end %>
+</div>
--- a/source/direction/_okrs-list.erb
+++ b/source/direction/_okrs-list.erb
+<div>
+<% data.okrs.each do |okr| %>
+  <% if okr.ref == ref_key && okr.fiscal_year == fiscal_year_key && okr.quarter == quarter_key %>
+    <table style="width: 100%">
+      <colgroup>
+        <col span="1" style="width: 90%;">
+        <col span="1" style="width: 10%;">
+      </colgroup>
+      <tr>
+        <th><strong>Objective: <a href="<%= okr.source %>"><%= okr.objective %></a></strong></th>
+        <th><code><% if okr.progress %><%= okr.progress.to_s %><% else %>X<% end %>%</code></th>
+      </tr>
+      <% if okr.key_results %>
+        <% okr.key_results.each do |kr| %>
+          <tr>
+            <td>Key Result: <a href="<%= kr.source %>"><%= kr.title %></a></td>
+            <td><code><% if kr.progress %><%= kr.progress.to_s %><% else %>X<% end %>%</code></td>
+          </tr>
+        <% end %>
+      <% end %>
+    </table>
+  <% end %>
+<% end %>
+</div>
--- a/source/direction/_other.erb
+++ b/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}"] %>
--- a/source/direction/_workflows-content.erb
+++ b/source/direction/_workflows-content.erb
+<% data.devops_workflows.each do |workflowKey, workflow| %>
+  <% next unless (workflow.stage == stageKey) %>
+  <% l = [] %>
+  <% l << "[Learn more](#{workflow.marketing_page})" if workflow.marketing_page %>
+  <% l << "[Documentation](#{workflow.documentation})" if workflow.documentation %>
+  <% l << "[Direction](#{workflow.direction})" if workflow.direction %>
+##### <%= workflow.name %>
+<% maturity = "This workflow is planned, but not yet available." %>
+<% if workflow.available != nil %>
+  <% maturity = "This workflow is at the \"minimal\" level of maturity." if workflow.available.past? %>
+<% end %>
+<% if workflow.viable != nil %>
+  <% maturity = "This workflow is at the \"viable\" level of maturity." if workflow.viable.past? %>
+<% end %>
+<% if workflow.complete != nil %>
+  <% maturity = "This workflow is at the \"complete\" level of maturity." if workflow.complete.past? %>
+<% end %>
+<% if workflow.lovable != nil %>
+  <% maturity = "This workflow is at the \"lovable\" level of maturity." if workflow.lovable.past? %>
+<% end %>
+<% if workflow.marketing == false %>
+  <% maturity = "" %>
+<% end %>
+<%= workflow.description + " " + maturity + "  " unless workflow.description.blank? %>
+<%= maturity + "  " if workflow.description.blank? %>
+<%= l.join(' • ') unless l.empty? %>
+<% end %>
--- a/source/direction/_workflows.erb
+++ b/source/direction/_workflows.erb
+## Workflows
+There are a few workflows that are critical to our users in this stage.
+Each of these workflows has a designated level of maturity; you can read more about our 
+[category maturity model](/direction/maturity/) 
+to help you decide which categories you want to start using and when.
+<%= partial("direction/workflows-content", :locals => { :stageKey => stageKey }) %>
--- a/source/direction/acquisition/index.html.md
+++ b/source/direction/acquisition/index.html.md
+---
+layout: markdown_page
+title: Product Direction - Acquisition
+description: "The Acquisition Team at GitLab focuses on running experiments to increase the paid adoption of our platform at the point of signup. Learn more!"
+canonical_path: "/direction/acquisition/"
+---
+### 概要
+The Acquisition Team at GitLab focuses on running experiments to increase the paid adoption of our platform at the point of signup, we strive to promote the value of GitLab and accelerate site visitors transition to happy valued users of our product. Acquisition sits at the beginning of the journey for individual users and organizations as they get their first introduction to the value proposition of GitLab. Our goal is to ensure that users understand the unique value that GitLab provides and thereby ensure that prospects seamlessly transition into healthy, valued users of GitLab. We will gain a deep understanding of the value that our users realize from the different Stages of GitLab, and ensure that value is susinctly communicated to our site visitors in order to efficently transition them from prospects to active, valued users.
+**Acquisition Team**
+Product Manager: [Jensen Stava](/company/team/#jstava) |
+Engineering Manager: [Jerome Ng](/company/team/#jeromezng) |
+UX Manager: [Jacki Bauer](/company/team/#jackib) |
+Product Designer: [Emily Sybrant](/company/team/#esybrant) |
+Full Stack Engineer: [Alex Buijs](/company/team/#alexbuijs) |
+Full Stack Engineer: [Nicolas Dular](/company/team/#nicolasdular)
+**Acquisition Team Mission**
+* To promote the value of GitLab and accelerate site visitors transition to happy valued users of our product.
+**Acquisition KPI**
+* Direct signup ARR growth rate
+* Definition:  (Direct signup ARR in the current period - direct signup revenue in the prior period)/direct signup revenue in the prior period
+* The Analysis can be found in the [Product KPIs Dashboard in Periscope](https://app.periscopedata.com/app/gitlab/527913/Product-KPIs?widget=7634169&udv=0)
+* Calculation:
+   * For SaaS, Direct signup ARR includes all namespaces that start a subscription for the first time, during the first 24 hours after the namespace creation.
+   * For Self-Managed, we link all subscriptions to their Salesforce accounts and leads. We include in Direct Signup ARR all subscriptions which have a lead or an account created up to 24 hours before the subscription start date.
+_Supporting performance indicators:_
+1. Time to sign up
+   - Definition: Time of account signup completion - Time of first visit
+2. Percent of paid conversion
+   - Definition: Total number of unique site visitors / Total number of  paid signups
+3. Percent of conversion
+   - Definition: Total number of unique site visitors / Total number of signups
+4. Free to paid conversion
+   - Definition: Free to paid conversion rate (free user upgrades / free user signups in period)
+5. Time to upgrade
+   - Time of account signup completion - Time of upgrade to paid package
+### Problems to solve
+Do you have issues... We’d love to hear about them, how can we help GitLab contributors find that ah-Ha! Moment.
+Here are few problems we are trying to solve:
+* **Clarity** - Whose problems do you solve?
+   * Your product does A LOT, the feature set is expansive, but I can't tell if it will work for me.
+* **Call to Action** - I want to signup! What is the best way to do that?
+   * I can't tell which offering of GitLab I should signup for?
+   * What package should I signup for?
+* **Usability** - Signing up for a paid package is a cumbersome process...
+   * As a dev-ops lead, how do I buy this product for my team?
+   * How do I signup for a paid package from my self hosted instance?
+### Our approach
+Acquisiton runs a standard growth process. We gather feedback, analyze the information, ideate then create experiments and test. As you can imagine the amount of ideas we can come up with is enormous so we use the [ICE framework](https://blog.growthhackers.com/the-practical-advantage-of-the-ice-score-as-a-test-prioritization-framework-cdd5f0808d64) (impact, confidence, effort) to ensure we are focusing on the experiments that will provide the most value. The team is dedicated to improving GitLab’s ability to convert visitors from about.gitlab.com into healthy, valued users of the product. Given GitLab’s commitment to [iteration](https://about.gitlab.com/handbook/values/#iteration) and the [Growth Groups](https://about.gitlab.com/direction/growth/#acquisition-conversion-expansion--and-retention-groups) test and learn strategy, the Acquisition Team will break down each incremental improvement in two distinct and important ways:
+1. Each item in our roadmap will be broken into an [MVC](https://about.gitlab.com/handbook/values/#minimum-viable-change-mvc)
+2. Each item in our roadmap will be rolled out incrementally and measured against a control
+Though this framework is not new to GitLab, it is especially important to note for this roadmap. Many of the items listed below have the **potential** to create negative downstream impacts to revenue and potentially a users experience with our product. While we obviously seek to avoid those cases, we believe that we should take controlled risks to quickly learn from our users behavior rather than increasing the scope of these tests to avoid all negative edge cases. That said, we will document any possible negative after effects resulting from each test, as well as a plan to monitor and potentially mitigate those negative effects. Moreover, we will call out an appropriate test rollout plan given the risk associated with running each test. That said, our prioritization will take those potential negative effects into account, and will reflect what we believe to be the highest potential impact to our growth KPI as possible given an [ICE score](https://about.gitlab.com/direction/growth/#growth-ideation-and-prioritization). Happy learning!
+### 🚀 Current Priorities
+<table>
+  <tr>
+   <td>ICE Score
+   </td>
+   <td>Focus
+   </td>
+   <td>Why?
+   </td>
+  </tr>
+  <tr>
+   <td><a href="https://docs.google.com/spreadsheets/d/1K7jfIciCso1-xHMwXRxaRjug3sBINop0v0vkFFz44ao/edit?usp=sharing">7.0</a>
+   </td>
+   <td><a href="https://gitlab.com/gitlab-org/growth/product/issues/87">SAAS Paid Sign Up Experience</a>
+   </td>
+   <td>As a user, when I sign up for a paid package, the process is convoluted, complex and confusing. I don't understand why I have to create 2 accounts in order to signup and pay. I would rather try to figure out how to use the product for free rather than invest my time trying to figure out how to pay.
+   </td>
+  </tr>
+  <tr>
+   <td><a href="https://docs.google.com/spreadsheets/d/1MaSkEOjSHJMbpC9gcEyyCj9FR3IccifcHrq90n_acrQ/edit?usp=sharing">6.7</a>
+   </td>
+   <td><a href="https://gitlab.com/gitlab-org/growth/product/issues/88">SAAS Trial Sign Up Experience</a>
+   </td>
+   <td>As a user, when I sign up for a trial, the process is convoluted, complex and confusing. I don't understand why I have to create 2 accounts in order to sign up. I would rather try to figure out how to use the product for free rather than invest my time trying to figure out how to pay.
+   </td>
+  </tr>
+  <tr>
+   <td><a href="https://docs.google.com/spreadsheets/d/1j_5Iqh0E5tZhKLrqRk27afa7hnz7BdQfYuu69Scu2TU/edit?usp=sharing">6.0</a>
+   </td>
+   <td><a href="https://gitlab.com/gitlab-org/growth/product/issues/89">Self-Hosted Paid Sign Up Experience</a>
+   </td>
+   <td>As a user, when I sign up for a paid package, the process is convoluted, complex and confusing. I don't understand why I have to create 2 accounts in order to sign up. I would rather try to figure out how to use the product for free rather than invest my time trying to figure out how to pay.
+   </td>
+  </tr>
+</table>
+### Maturity
+The growth team at GitLab is new and we are iterating along the way. As of August 2019 we have just formed the expansion group and are planning to become a more mature, organized and well oiled machine by January 2020.
+### Helpful Links
+[GitLab Growth project](https://gitlab.com/gitlab-org/growth)
+[KPIs & Performance Indicators](https://about.gitlab.com/handbook/product/metrics/)
+Reports & Dashboards
--- a/source/direction/breadth/index.html.haml
+++ b/source/direction/breadth/index.html.haml
+---
+title: Product Direction - Breadth
+description: New `planned` categories, as well as the existing, but `minimal` categories, to be brought to `viable`.
+canonical_path: "/direction/breadth/"
+suppress_header: true
+layout: default
+extra_css:
+  - home.css
+  - maturity.css
+---
+%h2 Product Direction - Breadth
+.container
+  = partial "direction/breadth/sdlc"
--- a/source/direction/breadth/sdlc.html.haml
+++ b/source/direction/breadth/sdlc.html.haml
+.sdlc-container.position-relative
+  .table-container
+    .sdlc-table
+      - Gitlab::Homepage::Stage.all!.select{|stage| stage.marketing}.each do |stage|
+        .sdlc-column
+          .stage-container
+            %a{href: "/stages-devops-lifecycle/#{stage.key}/"}
+              = partial "/includes/icons/sdlc-icons/#{stage.key}.svg"
+            %a{href: "/stages-devops-lifecycle/#{stage.key}/"}
+              %p #{stage.display_name}
+          .solutions-container
+            - breadth_categories = stage.categories.select { |category| category.marketing && category.maturity && category.maturity == 'minimal' }
+            - breadth_categories += stage.categories.select { |category| category.marketing && category.maturity && category.maturity == 'planned' }
+            - if breadth_categories.length >= 1
+              .current-categories
+                .stage-column
+                  .category-list
+                    - breadth_categories.each do |category|
+                      .category
+                        .category-cell
+                          %a{ href: "##{category.key}"}
+                            = partial "/images/maturity/#{maturity(category, Date.today)}.svg"
+                        .category-cell
+                          - url = category.best_link
+                          %a{ href: "#{url}" } #{category.name}
--- a/source/direction/categories.png
+++ b/source/direction/categories.png
--- a/source/direction/complex-pipeline.svg
+++ b/source/direction/complex-pipeline.svg
--- a/source/direction/configure/auto_devops/index.html.md
+++ b/source/direction/configure/auto_devops/index.html.md
+---
+layout: markdown_page
+title: "Category Direction - Auto Devops"
+direction: "GiitLab's direction for “Auto DevOps” is to leverage our single application to assist users in every phase of the development and delivery process. Learn more!"
+canonical_path: "/direction/configure/auto_devops/"
+---
+- TOC
+   {:toc}
+## Auto DevOps
+Our direction for “Auto DevOps” is to leverage our [single application](https://about.gitlab.com/handbook/product/single-application/) to assist users in every phase of the development and delivery process, implementing automatic tasks that can be customized and refined to get the best fit for their needs.
+With the dramatic increase in the number of projects being managed by software teams (especially with the rise of micro-services), it's no longer enough to just craft your code. In addition, you must consider all of the other aspects that will make your project successful, such as tests, quality, security, logging, monitoring, etc. It's no longer acceptable to add these things only when they are needed, or when the project becomes popular, or when there's a problem to address; on the contrary, all of these things should be available at inception.
+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).
+- [Issue List](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Category%3AAuto%20DevOps)
+- [Overall Vision](/direction/configure)
+- [UX Research](https://gitlab.com/groups/gitlab-org/-/epics/595)
+Interested in joining the conversation for this category? Please join us in our
+[public epic](https://gitlab.com/groups/gitlab-org/-/epics/480) where
+we discuss this topic and can answer any questions you may have. Your contributions
+are more than welcome.
+## What's Next & Why
+As the Kubernetes project rapidly matures and some of its API endpoints are deprecated/removed, we must ensure all the components of Auto DevOps currently interacting with its API are updated to ensure its continuing successful function.
+[Auto DevOps readiness for Kubernetes 1.16](https://gitlab.com/gitlab-org/gitlab/issues/32720)
+## Maturity Plan
+This category is currently at the "Minimal" maturity level, and our next maturity target is [Viable](/direction/maturity/). See the [Auto DevOps viable](https://gitlab.com/groups/gitlab-org/-/epics/1333) epic for more info. Deliverables:
+- [Auto DevOps readiness for Kubernetes 1.16](https://gitlab.com/gitlab-org/gitlab/issues/32720)
+### Group Ownership
+Auto Devops ties together several feature from across GitLab [product categories](/handbook/product/product-categories/). Each individual feature will have its own maturity classification.
+| Feature | Reponsible GitLab Group |
+| ------ | ------ |
+| Auto Build | [Configure](/handbook/engineering/development/ops/configure/) |
+| Auto [Test](/direction/verify/code_testing/) | [Testing](/handbook/engineering/development/ci-cd/verify/testing/) |
+| Auto [Code Quality](/direction/verify/code_quality/) | [Testing](/handbook/engineering/development/ci-cd/verify/testing/) |
+| Auto [SAST](/direction/secure/static-analysis/sast/) | [Static Analysis](/handbook/engineering/development/secure/static-analysis/) |
+| Auto [Secret Detection](/direction/secure/static-analysis/secret-detection/) | [Static Analysis](/handbook/engineering/development/secure/static-analysis/) |
+| Auto [Dependency Scanning](/direction/secure/composition-analysis/dependency-scanning/) | Composition |
+| Auto [License Compliance](/direction/secure/composition-analysis/license-compliance/) | Composition |
+| Auto [Container Scanning](/direction/secure/composition-analysis/container-scanning/) | Composition |
+| Auto [Review Apps](/direction/release/review_apps/) | [Progressive Delivery](/handbook/engineering/development/ci-cd/release/progressive-delivery/) |
+| Auto [DAST](/direction/secure/dynamic-analysis/dast/) | Dynamic Analysis |
+| Auto [Browser Performance Testing](/direction/verify/web_performance/) | [Testing](/handbook/engineering/development/ci-cd/verify/testing/) |
+| Auto [Load Performance testing](/direction/verify/load_testing/) | [Testing](/handbook/engineering/development/ci-cd/verify/testing/) |
+| Auto [Deploy](/direction/release/continuous_delivery/) | [Progressive Delivery](/handbook/engineering/development/ci-cd/release/progressive-delivery/) |
+| Auto [Monitoring](/direction/monitor/) | [APM](/handbook/engineering/development/ops/monitor/apm/) |
+## Competitive Landscape
+While there are "piece-meal" solutions that offer to automate a particular stage, there are no comprehensive tools that offer to address the entire devops lifecycle.
+### DeployHQ
+DeployHQ offers to "Automatically build and deploy code from your repositories", however, its UX is complex that its deployment targets limited.
+[deployhq.com](https://www.deployhq.com)
+## Analyst Landscape
+There is currently no analyst category that aligns with Auto DevOps.
+## Top Customer Success/Sales Issue(s)
+[Use Auto DevOps for design.gitlab.com](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/issues/96)
+## Top Customer Issue(s)
+[Add support for AWS ECS deployments to Auto DevOps](https://gitlab.com/gitlab-org/gitlab-ce/issues/38430)
+## Top Internal Customer Issue(s)
+[Use Auto DevOps for design.gitlab.com](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/issues/96)
+#### Top Vision Item(s)
+- [Disable Auto DevOps at the Group level for gitlab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues/52447)
+- [Composable Auto DevOps](https://gitlab.com/gitlab-org/gitlab-ce/issues/47234)
+- [Don't run Auto DevOps when no dockerfile or matching buildpack exists](https://gitlab.com/gitlab-org/gitlab-ce/issues/57483)
--- a/source/direction/configure/chatops/index.html.md
+++ b/source/direction/configure/chatops/index.html.md
+---
+layout: markdown_page
+title: "Category Direction - ChatOps"
+direction: "The next generation of GitLab's ChatOps implementation will allow users to have a dedicated interface to configure, invoke, and audit ChatOps actions!"
+canonical_path: "/direction/configure/chatops/"
+---
+- TOC
+   {:toc}
+## Introduction and how you can help
+Thanks for visiting this category page on ChatOps in GitLab.
+This vision is a work in progress and everyone can contribute. Sharing your feedback directly on our [chatops issues](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=chatops) and our public [epic](https://gitlab.com/groups/gitlab-org/-/epics/591) at GitLab.com is the best way to contribute to our vision.
+## 概要
+ChatOps, at its core, is a simple model of collaboration based on conversation. Conversation is the default and natural human way of working together and is still one of the most effective ways to collaborate despite changes to the medium of work conversations. In chat tools, such as [Slack](https://slack.com/), by bringing people, bots, and related tools all into the location where conversation occurs, enhanced efficiency, transparency, and learning is made possible.
+It is useful to enable operators to work with GitLab in all of the chat mediums they use in their work place. GitLab should integrate with popular tools so that ChatOps works for GitLab users out of the box.
+## What's next & why
+[GitLab ChatOps](https://docs.gitlab.com/ee/ci/chatops/) currently supports Slack and GitLab CI/CD. Additional ChatOps capability will be introduced along with the maturation of other GitLab categories, such as [Incident Management](../../monitor/debugging_and_health/incident_management/)
+We eventually plan to support integration with tools such as [Mattermost](https://mattermost.com/) or [Microsoft Teams](https://www.microsoft.com/en-us/microsoft-365/microsoft-teams/group-chat-software). Currently, we are not actively working on additional integrations. We would like the communities help to [introduce a pipeline type for chat-ops generated pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/26975).
+## Analyst landscape
+TBD