diff --git a/source/direction/Fulldevops.png b/source/direction/Fulldevops.png new file mode 100644 index 0000000000000000000000000000000000000000..a077106728e15d67993f13cdd3c2c32e6e619cb4 Binary files /dev/null and b/source/direction/Fulldevops.png differ diff --git a/source/direction/Personas.png b/source/direction/Personas.png new file mode 100644 index 0000000000000000000000000000000000000000..f694ab1b7eff19ba329362f97f8e790d386d9b0f Binary files /dev/null and b/source/direction/Personas.png differ diff --git a/source/direction/_categories-content.erb b/source/direction/_categories-content.erb new file mode 100644 index 0000000000000000000000000000000000000000..c8f78517e47920194224220521d5df5b268e7531 --- /dev/null +++ b/source/direction/_categories-content.erb @@ -0,0 +1,29 @@ +<% 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 %> diff --git a/source/direction/_categories.erb b/source/direction/_categories.erb new file mode 100644 index 0000000000000000000000000000000000000000..376233500018713b9551ded2d49b9a26c90e3b29 --- /dev/null +++ b/source/direction/_categories.erb @@ -0,0 +1,14 @@ +## 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 }) %> diff --git a/source/direction/_contribute.erb b/source/direction/_contribute.erb new file mode 100644 index 0000000000000000000000000000000000000000..ebf75400752e3032b7f631ab493add51a3c7c973 --- /dev/null +++ b/source/direction/_contribute.erb @@ -0,0 +1,12 @@ +## 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). diff --git a/source/direction/_jtbd-list.erb b/source/direction/_jtbd-list.erb new file mode 100644 index 0000000000000000000000000000000000000000..9e9334682af68d1c8ec3dcd3304992966bb767fe --- /dev/null +++ b/source/direction/_jtbd-list.erb @@ -0,0 +1,41 @@ +
+<% data.jobs_to_be_done.each do |primary_jtbd| %> + <% if primary_jtbd.group == stage_key && (primary_jtbd.parent.nil? || primary_jtbd.parent.empty?) %> +

<%= primary_jtbd.short_jtbd %>

+

<%= primary_jtbd.jtbd %>

+ + + + + + + + + + + + + + + <% data.jobs_to_be_done.each do |secondary_jtbd| %> + <% if primary_jtbd.group == stage_key && (secondary_jtbd.parent == primary_jtbd.slug) %> + + + + + + + <% end %> + <% end %> +
Job statementsMaturityConfidenceSource
+ <%= secondary_jtbd.jtbd %> + + <%= ux_grade(secondary_jtbd.grade) %> + + <%= secondary_jtbd.confidence %> + + Issue +
+ <% end %> +<% end %> +
diff --git a/source/direction/_okrs-list.erb b/source/direction/_okrs-list.erb new file mode 100644 index 0000000000000000000000000000000000000000..e80b0c8e8b60551ea45b1b63dcd9ab132a8eaa86 --- /dev/null +++ b/source/direction/_okrs-list.erb @@ -0,0 +1,24 @@ +
+<% data.okrs.each do |okr| %> + <% if okr.ref == ref_key && okr.fiscal_year == fiscal_year_key && okr.quarter == quarter_key %> + + + + + + + + + + <% if okr.key_results %> + <% okr.key_results.each do |kr| %> + + + + + <% end %> + <% end %> +
Objective: <%= okr.objective %><% if okr.progress %><%= okr.progress.to_s %><% else %>X<% end %>%
Key Result: <%= kr.title %><% if kr.progress %><%= kr.progress.to_s %><% else %>X<% end %>%
+ <% end %> +<% end %> +
diff --git a/source/direction/_other.erb b/source/direction/_other.erb new file mode 100644 index 0000000000000000000000000000000000000000..bfa3665d06c22142412a18b608ede5db705dd505 --- /dev/null +++ b/source/direction/_other.erb @@ -0,0 +1,16 @@ +## 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}"] %> diff --git a/source/direction/_workflows-content.erb b/source/direction/_workflows-content.erb new file mode 100644 index 0000000000000000000000000000000000000000..f793594ec75c0202309af7dea9fc35ad588020cb --- /dev/null +++ b/source/direction/_workflows-content.erb @@ -0,0 +1,28 @@ +<% 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 %> diff --git a/source/direction/_workflows.erb b/source/direction/_workflows.erb new file mode 100644 index 0000000000000000000000000000000000000000..2161c43edd94e9a2a3847330213a0a6f9a60a49a --- /dev/null +++ b/source/direction/_workflows.erb @@ -0,0 +1,9 @@ +## 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 }) %> diff --git a/source/direction/acquisition/index.html.md b/source/direction/acquisition/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..82a2f6ba1181aff6d9863907fe3e777b228f905a --- /dev/null +++ b/source/direction/acquisition/index.html.md @@ -0,0 +1,125 @@ +--- +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 + + + + + + + + + + + + + + + + + + + + + + +
ICE Score + Focus + Why? +
7.0 + SAAS Paid Sign Up Experience + 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. +
6.7 + SAAS Trial Sign Up Experience + 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. +
6.0 + Self-Hosted Paid Sign Up Experience + 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. +
+ +### 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 diff --git a/source/direction/breadth/index.html.haml b/source/direction/breadth/index.html.haml new file mode 100644 index 0000000000000000000000000000000000000000..2c37028ef3515221f07b5cd99376bba8ca190382 --- /dev/null +++ b/source/direction/breadth/index.html.haml @@ -0,0 +1,15 @@ +--- +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" diff --git a/source/direction/breadth/sdlc.html.haml b/source/direction/breadth/sdlc.html.haml new file mode 100644 index 0000000000000000000000000000000000000000..d215f370fc2619cacd462aebda18f8ed78968073 --- /dev/null +++ b/source/direction/breadth/sdlc.html.haml @@ -0,0 +1,25 @@ +.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} diff --git a/source/direction/categories.png b/source/direction/categories.png new file mode 100644 index 0000000000000000000000000000000000000000..213925c5168964e14d3f29ad8c4be8b71db560f5 Binary files /dev/null and b/source/direction/categories.png differ diff --git a/source/direction/complex-pipeline.svg b/source/direction/complex-pipeline.svg new file mode 100644 index 0000000000000000000000000000000000000000..4b4eb424a1c3de68f62e0bd0b0dd3086e30fa4ff --- /dev/null +++ b/source/direction/complex-pipeline.svg @@ -0,0 +1,2 @@ + + \ No newline at end of file diff --git a/source/direction/configure/auto_devops/index.html.md b/source/direction/configure/auto_devops/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..ac4c7e4fe54bba0384821346a27ad4a98235d455 --- /dev/null +++ b/source/direction/configure/auto_devops/index.html.md @@ -0,0 +1,96 @@ +--- +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) diff --git a/source/direction/configure/chatops/index.html.md b/source/direction/configure/chatops/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..fd2c0c5b9906f759f04e0618dd20a6dc13e851eb --- /dev/null +++ b/source/direction/configure/chatops/index.html.md @@ -0,0 +1,47 @@ +--- +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 + +## Top Customer Success/Sales issue(s) + +TBD + +## Top user issue(s) + +[Slack Custom Actions for Messages](https://gitlab.com/gitlab-org/gitlab-ee/issues/6154) + +## Top internal customer issue(s) + +TBD + +## Top Vision Item(s) + +TBD diff --git a/source/direction/configure/cluster_cost_optimization/index.html.md b/source/direction/configure/cluster_cost_optimization/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..6646db061313cf19f98ae4b071e3f12223e07373 --- /dev/null +++ b/source/direction/configure/cluster_cost_optimization/index.html.md @@ -0,0 +1,79 @@ +--- +layout: markdown_page +title: "Category Direction - Cluster Cost Optimization" +description: "Compute costs is a significant expenditure for many companies, whether they are in the cloud or on-premise. Learn more from GitLab here!" +canonical_path: "/direction/configure/cluster_cost_optimization/" +--- + +- TOC + {:toc} + +## Introduction and how you can help +Thanks for visiting this category page on Cluster Cost Optimization in GitLab. +This vision is a work in progress and everyone can contribute. Sharing your feedback directly on [issues](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Cluster%20Cost%20Optimization) and our public [epic](https://gitlab.com/groups/gitlab-org/-/epics/503) at GitLab.com is the best way to contribute to our vision. +If you’re a GitLab user and have direct knowledge of your need for cluster cost optimization, we’d especially love to hear from you. + +## Cluster Cost Optimization + +Cloud cost management and optimization (CCMO) is an important tool in any CIO's toolkit for the following: + +* Visibility & control - Identify and control which service or team is consuming the most resources for cost accounting and spend accountability +* Analysis - Enable decisions and teams to make the best decisions +* Reduce spend - Optimize spending in the cloud + +While these considerations also apply for organizations operating Kubernetes, Cluster cost optimization are a bit different from traditional CCMO tools. Kubernetes is by default, a multi-cloud enabler and enables auto-scaling out-of-the-box, both of which are value propositions for traditional CCMO vendors that is less applicable for companies running Kubernetes. + +GitLab is well positioned to provide a comprehensive solution for cluster cost optimization because GitLab's integration with the project or group's Kubernetes cluster. + +Potential iterations to a viable solution are listed below: + +- Flag deployments/projects that [overprovisioned resource](https://gitlab.com/gitlab-org/gitlab-ee/issues/9049) requests, wasting resources +- Recommend node changes to increase efficiency (use larger nodes, nodes with more RAM, etc.) +- Estimate costs utilized by each project +- Automatically implement the changes to right-size pod resource requests + +## What's next & why + +[Kubecost](https://www.kubecost.com), a cross-platform cluster cost management tool that can support several clusters and comes with its own Prometheus and Grafana installations, may be a quick way to get this category to minimal maturity. [gitlab-#216737](https://gitlab.com/gitlab-org/gitlab/-/issues/216737) is the first step in determining if we can display +kubecost data in GitLab. Then we can decide if we would like to partner with them to provide an integrated experience with their full product offering and support single pod installations as an MVC. + +Currently, we have a [sample kubecost project](https://gitlab.com/gitlab-examples/kubecost-cost-model) where we are testing the integration. In addition, we have also begun to evaluate this [kubecost helm chart](https://github.com/kubecost/cost-analyzer-helm-chart) as a potential integration method. + +If you are interested in learning more, consider contributing feedback to the [kubecost - GitLab integration issue](https://gitlab.com/gitlab-org/gitlab/-/issues/216737). + +Aside from the above kubecost work, we are not actively prioritizing development work in this category. We would welcome your contribution in this space. + +## Competitive landscape +There's a long tail of competitors and solutions for CIOs in this space with no clear winner. Competition have varying perspectives from different vantage points on how to optimize spend. [kubecost.com](https://www.kubecost.com) is the solution most in line with GitLab's desire to address cluster cost optimization. + +The changing landscape has led to some recent consolidation in the Cloud cost management and optimization (CCMO) space with the acquisition of [CloudHealth by VMWare](https://cloud.vmware.com/community/2018/10/04/cloud-health-acquisition/) and [Cloudability by Apptio](https://www.apptio.com/company/news/press-releases/apptio-inc-completes-acquisition-of-cloudability/). +The aquisition enabled VMWare to have a more complete multi-cloud offering, while Apptio now has a more complete on-premise+cloud offering, enabling them to target enterprises going through cloud migration with one integrated solution for optimizing spend. + +* [kubecost.com](https://www.kubecost.com) +* [cloudhealthtech.com/blog/kubernetes-cost-allocation-made-easy](https://www.cloudhealthtech.com/blog/kubernetes-cost-allocation-made-easy) +* [replex.io/blog/kubernetes-cost-allocation-in-a-nutshell](https://www.replex.io/blog/kubernetes-cost-allocation-in-a-nutshell) +* [supergiant.io/blog/supergiant-packing-algorithm-unique-save-money](https://supergiant.io/blog/supergiant-packing-algorithm-unique-save-money) +* [mist.io](https://mist.io/) +* [cloudability.com](https://www.cloudability.com/) +* [Flexera](https://www.flexera.com/) +* [Turbonomic](https://www.turbonomic.com/) + +## Analyst landscape + +TBD + +## Top Customer Success/Sales issue(s) + +TBD + +## Top user issue(s) + +TBD + +## Top internal customer issue(s) + +TBD + +## Top Vision Item(s) + +[Flag over-provisioned kubernetes deployments](https://gitlab.com/gitlab-org/gitlab-ee/issues/9049) diff --git a/source/direction/configure/infrastructure_as_code/index.html.md b/source/direction/configure/infrastructure_as_code/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..ec1064fb0082ffaf2bc77d7af10df3dfe1ccf77d --- /dev/null +++ b/source/direction/configure/infrastructure_as_code/index.html.md @@ -0,0 +1,111 @@ +--- +layout: markdown_page +title: "Category Direction - Infrastructure as Code" +description: "GitLab focus on providing tight integration with best of breed IaC tools, so that all infrastructure related workflows in GitLab are well supported. Learn more!" +canonical_path: "/direction/configure/infrastructure_as_code/" +--- + +- TOC + {:toc} + +## Infrastructure as Code + +Infrastructure as code (IaC) is the practice of managing and provisioning infrastructure through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. The IT infrastructure managed by this comprises both physical equipment such as bare-metal servers as well as virtual machines and associated configuration resources. The definitions are stored in a version control system. IaC takes proven coding techniques and extends them to your infrastructure directly, effectively blurring the line between what is an application and what is the environment. + +Our focus will be to provide tight integration with best of breed IaC tools, such that all infrastructure related workflows in GitLab are well supported. +Our initial focus will likely be on Terraform. + +- [Issue List](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name%5B%5D=Category%3AInfrastructure%20as%20Code) +- [Overall Vision](/direction/configure) +- [UX Research](https://gitlab.com/groups/gitlab-org/-/epics/595) + +Infrastructure and Application provisioning shouldn't be mixed! Application delivery is covered by our [Continuous Delivery directions](https://about.gitlab.com/direction/release/continuous_delivery/). +{: .note .font-small} + +### Vision + +Our vision is to provide several levels of Infrastructure as Code support: + +1. **GitLab Managed IaC** means that GitLab runs all your IaC code based on our reference architectures and your choice of provider +2. **Self-managed IaC through GitLab** allows you to build you custom architecture, likely based on our recommendations, but still use the engines supporting IaC provided by GitLab. +3. **Fully self-managed IaC** is always available to you. This means that you maintain your CI/CD files and pipelines totally. This is already available today. + +### Interaction with Policy as Code + +As Infrastructure as Code usage scales across teams [collaboration pain points around security, compliance and adopting best practices arise](https://www.youtube.com/watch?v=Vy8s7AAvU6g&=&feature=youtu.be). Traditionally these pain points are solved by written documentation. Modern infrastructure as code applications have implemented Policy as Code tools to enable automated checking of infrastructure definitions against easy to write policy definitions. One prime example of this is [Hashicorp's Sentinel](https://www.hashicorp.com/sentinel/). + +The principles of Policy as Code are closely aligned with Infrastructure as Code. Within GitLab our existing primitives of integrated CI with *CI job definition in-code* model similar behavior to modern Policy as Code frameworks. At present our existing CI approach allows easy integration of special Policy as Code tools and GitLab. + +### What's next + +We have a dedicated page for [Kubernetes management directions](https://about.gitlab.com/direction/configure/kubernetes_management/). The following directions are related to generic Infrastructure as Code tool support in GitLab. + +First, we are going to focus on Terraform support, the *de facto* standard in infrastructure provisioning. +As we are moving Infrastructure as Code support towards Viable, we have [a dedicated Epic to collect all our plans](https://gitlab.com/groups/gitlab-org/-/epics/1960). + +Interested in joining the conversation for this category? Please join us in our +[public epic](https://gitlab.com/groups/gitlab-org/-/epics/1960) where +we discuss this topic and can answer any questions you may have. Your contributions +are more than welcome! + +#### GitLab Managed Terraform State + +We would like to provide GitLab users with an unmatched Terraform experience. This involves a Terraform backend that integraets with GitLab pipelines without any setup from the user, and allows advanced state management from within GitLab. + +Please contribute to [our plans in the related epic](https://gitlab.com/groups/gitlab-org/-/epics/2673). + +#### Collaboration around Infrastructure changes + +In the case of Infrastructure as Code, a code change means a change in the infrastructure too. Thus we want to provide a solution that allows our users to have an overview of both the code changes and the final infrastructure changes in Merge Requests. + +We've already shipped the first iteration of the Terraform plan in MR widget, and we are working on [further improving the experience](https://gitlab.com/groups/gitlab-org/-/epics/3441). + +#### Terraform module registry + +For larger infrastructures, re-usable modules are a call part of the IaC codebase. We intend to provide a Terraform module registry as part of GitLab by extending the current module registries. Please, contribute to our plans around the registry in the [Terraform registry Epic](https://gitlab.com/groups/gitlab-org/-/epics/3221) + +#### Improving GitLab's Ansible support + +While Terraform is the *de facto standard* for infrastructure provisioning, there are other tools for configuration management, like Ansible or Chef. Following the Terraform devlopments, we intend to turn our attention to Ansible, and improve Ansible support inside GitLab. You are invited to express your interests and describe your use-case in [Ansible integration in our related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/229633). + +### Current maturity + +Even though we consider our Infrastructure as Code support to be `Minimal` at the moment, we see several GitLab customers using our CI/CD capabilities in production environments. Usually, Terraform-focused CI/CD projects are run +as [multi project pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html). + +### Analyst Landscape + +We don't consider GitLab a replacement of IaC tools, but rather a complement. Based on several discussions, we consider +Terraform the *de facto* standard of infrastructure provisioning. + +Given the trends around containerization, ephemeral and immutable infrastructures, we expect the relevance of configuration management tools to decrease, and infrastructure provisioning to gain more market share. + +### Top Customer Success/Sales issue(s) + +As already mentioned, we've several customers using IaC solutions with GitLab. The following list shows our primary +points of contacts for customer interviews around IaC. + +- Wag! +- kiwi.com +- Ooma +- GitLab + +### Top user issue(s) + +TBD + +### Top internal customer issue(s) + +### Top Strategy Item(s) + +### Competitors + +#### CloudSkiff + +CloudSkiff describes itself as a CI/CD for Terraform, on steroids. + +### Examples + +- [How GitLab uses Terraform](https://about.gitlab.com/blog/2019/11/12/gitops-part-2/) internally +- [Kiwi.com on Infrastructure as Code](https://www.youtube.com/watch?v=Un2mJrRFSm4) at GitLab Commit London, 2019 +- Presenting [code.siemens.com](https://www.youtube.com/watch?v=4Y8zv1TJRlM) at GitLab Commit London, 2019 diff --git a/source/direction/configure/kubernetes_management/index.html.md b/source/direction/configure/kubernetes_management/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..cba7b35bdff075319fb619bfe3e7ef82d2f573d2 --- /dev/null +++ b/source/direction/configure/kubernetes_management/index.html.md @@ -0,0 +1,100 @@ +--- +layout: markdown_page +title: "Category Direction - Kubernetes Management" +description: "GitLab aim to provide a simple way for users to configure their clusters and manage Kubernetes. Learn more here!" +canonical_path: "/direction/configure/kubernetes_management/" +--- + +- TOC + {:toc} + +## 概要 + +The main motivating factor behind [using a container orchestration platform is cost reduction](https://medium.com/kubernetes-tutorials/how-can-containers-and-kubernetes-save-you-money-fc66b0c94022). Kubernetes has become the most widely adopted container orchestration platform to run, deploy, and manage applications. Yet, to seamlessly connect application code with the clusters in various environments, has remained a complex task that needs various approaches of CI/CD and Infrastructure as Code. + +Our mission is to make deployments to every environment frictionless for the developer and reliable for the operator, no matter the experience level. We do this by supporting an integrated experience within GitLab and leverage the existing tools and approaches in the Kubernetes community. + +### How you can contribute + +Interested in joining the conversation for this category? Please have a look at our +[global epic](https://gitlab.com/groups/gitlab-org/-/epics/115) where +we discuss this topic and can answer any questions you may have. Your contributions are more than welcome. + +## Vision + +In two years, GitLab is an indispensable addition in the workflow of Kubernetes users by making deployments reliable, frictionless and conventional. + +## Target User + +We are building GitLab's Kubernetes Management category for the enterprise operators, who are already operating production grade clusters and work hard to remove all the roadblocks that could slow down product development without putting operations at risk. + +- [Priyanka](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) + +## What's next & why + +### GitLab agent + +The current version of GitLab Managed Clusters requires `cluster-admin` rights and direct access to the Kubernetes API server to get all the benefits and simplicity GitLab can provide. For serious, enterprise use cases allowing `cluster-admin` rights and K8s API access is not an option. In order to serve our enterprise users we intend to provide an active, cluster-side component to manage deployments and GitLab's cluster integration. + +Using the GitLab Kubernetes Agent, we want to offer a security oriented, Kubernetes-friendly integration option to Platform Engineers. Beside providing more control for the cluster operator, the agent opens up many new possibilities to make GitLab - cluster integrations easier and deeper. We expect the agent to support various GitLab features with automatic setups and integrations. + +Please, [join the discussion](https://gitlab.com/gitlab-org/gitlab/-/issues/216569). + +### GitLab Managed Applications + +GitLab Managed Applications are currently undergoing a large development by moving from the UI-only setup, to a more customizable, CI/CD-based, Infrastructure as Code setup. We want to allow our users to install off the shelf applications with necessary customizations. Moreover, we will continue to offer easy installations of the applications needed to benefit from GitLab's features like the Runner, Auto DevOps, Metrics and log collection, etc. The next step in this journey is to create CI templates for all the applications we support today. + +While this approach would allow it, we do not intend to create a marketplace of apps inside of GitLab, instead we would like to integrate with solutions like [OperatorHub](https://operatorhub.io/). As a result, we are looking at providing apps as GitLab Managed Apps if they satisfy the following criteria: + +- Each GitLab Managed App should provide sane, production-ready default configurations. +- Each GitLab Managed App should be a requirement for current or planned GitLab functionality or it should integrate deeply with GitLab. +- Each GitLab Managed App should have a clear support path, likely outside of GitLab. + +Contribute to these directions in the Epic ["Create CI templates for GitLab-managed-apps"](https://gitlab.com/groups/gitlab-org/-/epics/2103) + +## Challenges + +We see Kubernetes as a platform for delivering containerised software to users. Currently, every company builds its own workflows on top of it. The biggest challenges as we see them are the following: + +- Making Kubernetes friendly to developers is hard. We want to make deployments to every Kubernetes environment frictionless for the developer and reliable for the operator. +- As clusters are complex having an overview of the state and contents of a cluster is hard. We want to help our [monitoring efforts](/direction/monitoring) to provide clean visualisation and a rich understanding of one's cluster. + +## Approach + +- Kubernetes has a large and engaged community, and we want to build on the knowledge and wisdom of the community, instead of re-inventing existing solutions. +- In Kubernetes there are a plethora of ways for achieving a given goal. We want to provide a default setup and configuration options to integrate with all popular approaches and tools. + +## Maturity + +Kubernetes Management is currently `Viable`. We want to make it `Complete` by February 2021. + +## Competitive landscape + +### IBM Cloud Native Toolkit + +It provides an Open Source Software Development Life Cycle (SDLC) and complements IBM Cloud Pak solutions. The Cloud Native Toolkit enables application development teams to deliver business value quickly using Red Hat OpenShift and Kubernetes on IBM Cloud. + +### Spinnaker + +Spinnaker is an open-source, multi-cloud continuous delivery platform that helps you release software changes with high velocity and confidence. It provides two core sets of features 1) Application management, and 2) Application deployment. + +## Analyst landscape + +This category doesn't quite fit the "configuration management" area as it relates only to Kubernetes. No analyst area currently defined. + +## Top Customer Success/Sales issue(s) + +[Customize Kubernetes namespace per environment for managed clusters](https://gitlab.com/gitlab-org/gitlab/-/issues/38054) + +## Top user issue(s) + +[Customize Kubernetes namespace per environment for managed clusters](https://gitlab.com/gitlab-org/gitlab/-/issues/38054) + +## Top internal customer issue(s) + +[Add more configuration options for launching a new cluster directly from the GitLab application](https://gitlab.com/gitlab-org/gitlab/-/issues/30876) + +## Top Vision Item(s) + +- [Kubernetes Management - enterprise level K8s integration](https://gitlab.com/gitlab-org/gitlab/-/issues/216569) +- [UX Research](https://gitlab.com/groups/gitlab-org/-/epics/595) diff --git a/source/direction/configure/runbooks/index.html.md b/source/direction/configure/runbooks/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..d3b17c4157e4c8ccff7e46f30f5f9f2ac747b5c4 --- /dev/null +++ b/source/direction/configure/runbooks/index.html.md @@ -0,0 +1,59 @@ +--- +layout: markdown_page +title: "Category Direction - Runbooks" +description: "Runbooks are a collection of documented procedures that explain how to carry out a particular process or troubleshooting a particular system. Learn more!" +canonical_path: "/direction/configure/runbooks/" +--- + +- TOC + {:toc} + +## Runbooks + +Runbooks are a collection of documented procedures that explain how to carry out a particular process, be it starting, stopping, debugging, or troubleshooting a particular system. + +Historically, runbooks took the form of a decision tree or a detailed step-by-step guide depending on the condition or system. + +Modern implementations have introduced the concept of “executable runbooks”, where, along with a well-defined process, operators can execute pre-written code blocks or database queries against a given environment. + +We aim to extend Release Management and Incident Management further by rendering runbooks inside GitLab as interactive documents for operators. This will link from either a release or an incident management screen so when an action happens, GitLab points you to the relevant runbook. Additionally, we want to allow runbooks to trigger ChatOps functions as defined in `gitlab-ci.yml`. + +- [Issue List](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=runbooks) +- [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/380) where +we discuss this topic and can answer any questions you may have. Your contributions +are more than welcome. + +## What's next & why + +We are taking the first steps of Runbooks within the [Release](https://about.gitlab.com/handbook/engineering/development/ci-cd/release/) stage under the [Release Management Group](https://about.gitlab.com/handbook/product/product-categories/#release-management-group). We recently added the ability to create visibility to our user's runbooks by enabling an asset link to a runbook via [gitlab#9427](https://gitlab.com/gitlab-org/gitlab/-/issues/9427). In the next iteration, we plan to render a release progress view calculated from the linked runbook in [gitlab#207258](https://gitlab.com/gitlab-org/gitlab/issues/207258). + +We are also furthering GitLab's Runbooks capability by linking runbooks to [Alerts](../../monitor/debugging_and_health/alert_management/) and [Incidents](../../monitor/debugging_and_health/incident_management) as outlined in [gitlab&1436](https://gitlab.com/groups/gitlab-org/-/epics/1436). + +## Competitive landscape + +While there are some offerings in the marketplace, they rely on heavy customization for every use case and are somewhat specialized (i.e. networking). Mature organizations have stitched together their own Runbooks, such as using [Jupyter Notebooks for writing Runbooks](https://dev.to/amit1rrr/simplify-devops-with-jupyter-notebook-e33). + +Some of the main competitors for release mangement include [deployment plans](https://docs.xebialabs.com/v.9.5/xl-deploy/concept/examples-of-orchestrators-in-xl-deploy/#default-orchestrator) within XebiaLabs, release orchestration plans in [Electric Cloud's Flow](https://www.cloudbees.com/products/flow/overview), and even layers of spreadsheets that are used to track tasks manually. On the Indicident Management side, we see the top providers for runbooks or playbooks are [PagerDuty](https://www.pagerduty.com/), [VictorOps](https://victorops.com/blog/runbooks-checklist), and [Opsgenie](https://www.atlassian.com/software/opsgenie/features). The largest competitor of interest in this space would be the Opsgenie offering, as it is an Atlassian product, it can leverage a resemblance to a DevOps Platform suite. + +## Analyst landscape + +Runbook Automation (RBA) is a common terminology used in conjunction with the evaluation of monitoring and incident mangement solutions. Oftentimes, these are not evaluated exclusively by analysts as core offerings. + +## Top Customer Success/Sales issue(s) + +We have received several interested customer accounts and prospects in being able connect their own runbooks to release artifacts as described in [gitlab#9427](https://gitlab.com/gitlab-org/gitlab/-/issues/9427). + +## Top user issue(s) + +[Group-level filtering for JupyterHub deployment](https://gitlab.com/gitlab-org/gitlab-ce/issues/52536) + +## Top internal customer issue(s) + +Many GitLab teammates have cited an interest in enabling the execution of Markdown as code, which can be seen in [gitlab#198287](https://gitlab.com/gitlab-org/gitlab/-/issues/198287), given that many steps or current runbooks may be stored as Markdown files in the current state. Another popular request is to make it easier to use runbook style operational code snippets via [gitlab#36386](https://gitlab.com/gitlab-org/gitlab/-/issues/36386). Both of these issues improve the operational effectiveness surrounding native GitLab runbook capabilties. + +## Top Vision Item(s) + +A keystone of runbooks and making them highly usable can center around building out more comprehensive [Runbook Automation](https://gitlab.com/gitlab-org/gitlab-ee/issues/3911) to support all parties that use runbooks whether for Release Management, Incident Response, configuration of infrastructure, or even Alerting. In the Release Management space, we are working on building our more native GitLab runbooks as seen in [gitlab&2665](https://gitlab.com/groups/gitlab-org/-/epics/2665). Jupyter Hub offers compelling functionality in their notebooks, so we are also interested in expanding the Jupyter Notebook support for releases via [gitlab&2663](https://gitlab.com/groups/gitlab-org/-/epics/2663). One way to support the execution of these scripts could be to leverage and partner with a provider like [Rundeck](https://www.rundeck.com/open-source), which is being considered in [gitlab#36655](https://gitlab.com/gitlab-org/gitlab/-/issues/36655). diff --git a/source/direction/configure/serverless/index.html.md b/source/direction/configure/serverless/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..9954554f19df5ef3634e3fdd18c41d46aa2ee43e --- /dev/null +++ b/source/direction/configure/serverless/index.html.md @@ -0,0 +1,84 @@ +--- +layout: markdown_page +title: "Category Direction - Serverless" +description: "GitLab is a preferred tool for developers and operators looking after an integrated continuous delivery and monitoring of serverless applications." +canonical_path: "/direction/configure/serverless/" +--- + +- TOC + {:toc} + +## Introduction and how you can help + +Thanks for visiting this category page on Serverless in GitLab. + +This vision is a work in progress and everyone can contribute. Sharing your feedback directly on [issues](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=serverless) and our public [epic](https://gitlab.com/groups/gitlab-org/-/epics/155) at GitLab.com is the best way to contribute to our vision. + +If you’re a GitLab user and have direct knowledge of your need for serverless, we’d especially love to hear from you. + +## 概要 + +[Serverless computing](https://en.wikipedia.org/wiki/Serverless_computing) is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Currently, serverless computing doesn't yet have standardization, this means that developers have to choose between functionality, capability, and the overall ecosystem between cloud vendors. With Kubernetes, increasingly, also adopted increasingly as the de facto platform for many cloud native practitioners, operators have the challenge of making serverless play well with clusters, in a multi-cloud environment. + +The mission of the GitLab Serverless category is to make GitLab the preferred tool for developers and operators taking advantage of serverless computing, making integrated continuous delivery and monitoring easy - no matter if those serverless applications are run inside a Kubernetes cluster or with a public serverless services provider. + +## The first step we took + +Our initial hypothesis was that leveraging Knative and Kubernetes (See [Knative epic](https://gitlab.com/groups/gitlab-org/-/epics/1726) and associated [UX Research](https://gitlab.com/gitlab-org/ux-research/issues/99)), users will be able to define and manage functions in GitLab. This includes managing the security, logging, scaling, and costs of their serverless implementation for a particular project/group. + +## What's next & why + +While [Knative is the most popular installable serverless plaforms in use](https://www.cncf.io/wp-content/uploads/2020/03/CNCF_Survey_Report.pdf), Serverless is still largely about hosted services that is dominated by AWS Lambda. As a result, we don't have any plans around improving the cluster based [GitLab Serverless](https://docs.gitlab.com/ee/user/project/clusters/serverless/) offering. + +Looking forward, we would like to strengthen our integration with existing hosted serverless provider offerings, especially around deploying and monitoring serverless deployments. + +## Ecosystem and Partners + +To get a great overview of the serverless world, we recommend having a look at the [CNCF Serverless Landscape](https://landscape.cncf.io/format=serverless). +We are working hard to be great partners with the most widely used tools and fulfill the gap in every other area. + +### Knative and Kubernetes + +Users should be able to easily spin a new Kubernetes cluster under various providers using GitLab to start using the GitLab serverless offering. + +### Managed serverless providers + +AWS Lambda is a serverless compute service created by Amazon in 2015. It runs a function triggered by an event and manages the compute resources automatically so you don’t have to worry about what is happening under the hood. + +Azure Functions is Microsoft’s response to Amazon’s Lambda. It offers a very similar product for the same cost. It uses Azure Web Jobs; the delay between hot cold invocations is less visible. + +It’s a fully managed Node.js environment that will run your code handling scaling, security, and performance. It’s event-driven and will trigger a function returning an event, very much in the same way AWS Lambda works. It’s intended to be used for small units of code that are placed under heavy load. + +### Serverless Framework + +The Serverless Framework is an open-source tool for managing and deploying serverless functions. It supports multiple programming languages and cloud providers. Its two main components are + +- [Event Gateway](https://serverless.com/event-gateway/), which provides an abstraction layer to easily design complex serverless applications, and +- [Serverless Dashboard](https://serverless.com/dashboard/), for a better management of the application, as well as collaboration. + +Serverless Framework applications are written as YAML files (known as serverless.yml) which describe the functions, triggers, permissions, resources, and various plugins of the serverless application. + +## Analyst landscape + +The Serverless category is currently coupled with IaaS reports. + +Gartner's `Magic Quadrant for Cloud Infrastructure as a Service` places AWS, Azure, and Google Cloud as leaders. + +Forrester places `Serverless Computing` in their `Emerging Technology Spotlight` category, with the big three as leaders (AWS, Azure, Google Cloud) + +## Top Customer Success/Sales issue(s) + +n.a. + +## Top user issue(s) + +[Automatic domain for a serverless function](https://gitlab.com/gitlab-org/gitlab/issues/30151) +[SSL for Knative services](https://gitlab.com/gitlab-org/gitlab-ce/issues/56467) + +## Top internal customer issue(s) + +We collect [GitLab related issues under our dogfooding epic](https://gitlab.com/groups/gitlab-org/-/epics/1951). + +## Top Vision Item(s) + +[Serverless Vision: primary user](https://gitlab.com/gitlab-org/gitlab/issues/32543) diff --git a/source/direction/configure/template.html.md.erb b/source/direction/configure/template.html.md.erb new file mode 100644 index 0000000000000000000000000000000000000000..1ef96394b1a8d878fd70bbda699e7d048bf1f529 --- /dev/null +++ b/source/direction/configure/template.html.md.erb @@ -0,0 +1,260 @@ +--- +layout: markdown_page +title: "Product Direction - Configure" +description: "GitLab's Configure stage solves user problems related to the configuration and operation of applications and infrastructure. Learn more!" +canonical_path: "/direction/configure/" +--- + +- TOC + {:toc} + +The Configure stage solves user problems related to the configuration and operation of applications +and infrastructure. At the Configure stage within GitLab, we aim to make developers and operators more productive while +conforming to their platform/technology of choice and providing integrated workflows. We +want to enhance these tools by providing integrated workflows and views inside GitLab. + +Our vision is that DevOps teams will use GitLab as their primary day-to-day tool as it will provide first-class operator support. + +- See a high-level + [roadmap](https://gitlab.com/groups/gitlab-org/-/roadmap?scope=all&utf8=✓&state=opened&label_name[]=devops%3A%3Aconfigure). + +## 概要 + +The Configure stage solves user problems related to the configuration and operation of applications +and infrastructure, including features like Auto DevOps, Kubernetes integration, runbooks, serverless workloads, and ChatOps. +We aim to make complex tasks (such as standing up new environments) fast and +easy. We provide operators all the necessary tools to execute their +day-to-day actions upon their infrastructure. + +### Target personas + +We build solutions targeting the following personas: + +* [Application Operator](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) +* [Platform engineer](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) + ​ + On small teams, these personas may be just one individual, while on larger teams they may be dedicated roles. + +In keeping with our [single application](https://about.gitlab.com/handbook/product/single-application/) promise, we want +GitLab to be a robust, best-of-breed tool for operators as much as it is for developers. Our vision is that operators +will use GitLab as their main day-to-day tool for provisioning, configuring, testing, and decomissioning infrastructure. + +### 料金 + +GitLab's Configure stage is focused on providing enterprise ready configure capabilities to enable users to operate and deploy modern applications and cloud infrastructure. However, since all application code needs a form of infrastructure, there will continue to be basic offering that targets Core/Free users. + +#### Core/Free + +Every customer, including individual developers, need to be able to configure and deploy infrastructure. As such, integration with Terraform for Infrastructure as code is available to all GitLab users. + +Cloud native development is container based. More and more are using Kubernetes for container orchestration, even on personal projects. As part of the GitLab Core offering, Kubernetes management is also available with a limit to manage a single cluster. + +#### Starter/Bronze + +Individual teams are more likely to operate more than one single cluster. The limits on cluster management is increased to 5 clusters. + +#### Premium/Silver + +For medium sized organizations, limits on clusters under management are lifted so that teams can use GitLab GitOps without restriction. In addition as the infrastructure complexities increase, as part of our policy management capability, Premium users can see and visualize policy violations to provide safeguards to teams operating quickly. + +#### Ultimate/Gold + +For enterprises, when the complexity in infrastructure becomes unmanageable manually, Configure will provide more insights and visualization into various infrastructure elements. This includes cluster cost management and the ability to visualize the whole infrastructure. + +### Strategic directions + +We build products primarily for an 8 team SaaS product company, likely with a serverless or docker based architecture. +In the latter case, we assume it's deployed either to Kubernetes or with Terraform to anything that Terraform supports. + +### Challenges + +We understand GitLab will play side-by-side with existing tools which teams have already invested considerable time and +money. As a result, we will extend GitLab's Configure features to provide an outstanding, integrated experience with the +preferred tools in the industry. Keeping up with the quickly changing nature of these tools is our primary challenge. + +The technologies where we want to provide an outstanding, integrated experience with are + +- Kubernetes deployment, management, and monitoring +- Terraform usage, planning, and application +- Configuration management behind Terraform scripts + +### Opportunities + +Our opportunities in the Configure stage are derived from the [Ops Section opportunities](/direction/ops/#opportunities). +Namely: + +* **IT operations skills gap:** Operations skills are difficult to attract. We'll make it easier for you to leverage your + operations expertise by efficiently managing your infrastructure platform. +* **Clear winner in Kubernetes:** Our focus on enabling cloud-native applications based on the winner in container + orchestration and management, Kubernetes, means you can leverage the broader Cloud Native ecosystem as you adopt modern + application architectures. + +This leads us to look into common workflows that we would like to support with a market-leading experience: + +1. Flexible and robust Kubernetes cluster management +1. Infrastructure as Code, Policy as Code +1. サーバーレス +1. Runbooks +1. ChatOps +1. GitOps + +## North Stars + +We're working on increasing the number CI/CD pipelines going through our infrastructure management features +(either K8s, Auto DevOps, Serverless or IaC in general, ChatOps). + +We aim to achieve these by focusing on the following principles. + +### Easily run your application on any infrastructure + +We recognize getting started with modern devops practices from zero is hard. With Auto DevOps, GitLab already +provides a great framework to automatically detect, build, test, secure, deploy, and monitor your application. +We'll extend Auto DevOps to provide further customization of your application, such as automatically securing +it with an SSL certificate or easily define a custom domain. Additionally, we will extend its deployment capabilities +to provide built-in best practices, such as blue/green deployments, postgress replication, and postgres backup/restore. + +If your application is not a good candidate for Auto DevOps, GitLab will provide great templates with smart defaults +which will provide a great experience for other approaches (such as serverless and micro-services) making tasks such as +scaling functions and inter-connecting micro-services, quick & easy. + +### Detect and track automatically + +Teams who begin their journey with GitLab may already have existing Kubernetes resources in place. So these can be +used effectively, we will detect and track the state of applications which are already installed in-cluster. +Following sensible conventions, once a cluster is added to any level of your workflow, GitLab will show which +apps are installed and offer all relevant features, regardless of how those apps have been installed. + +### Provision everywhere + +Provisioning infrastructure is a critical responsibility of the operations team. GitLab will make it easy to provision +resources either directly with your cloud of choice or by leveraging your existing infrastructure-as-code resources. To +that end, GitLab will offer cluster creation workflows with every major cloud provider as well as robust integration +with leading IaC providers such as Terraform. + +For those teams just getting started with IaC, GitLab will lower the intial investment to use Terraform, with Git +as the source of truth for IaC. + +### First-class operator support + +We want operators to use GitLab as their main day-to-day system. In addition to managing infrastructure, GitLab will +provide features for downtime action planning (via Runbooks) as well as ways to quickly execute actions on both +applications and infrastructure (via ChatOps). + +## Performance Indicators (PIs) + +Our [Key Performance Indicator](https://about.gitlab.com/handbook/ceo/kpis/) for the Configure stage is the **Configure +SMAU** ([stage monthly active users](https://about.gitlab.com/handbook/product/performance-indicators/#stage-monthly-active-users-smau)). + +Configure SMAU is a proxy metric of all the active project users for any projects with a cluster attached. | + +See the corresponding [Sisense dashboard](https://app.periscopedata.com/app/gitlab/511813/Configure-team-business-metrics) (internal) for our primary KPIs. + +## 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 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. + +That's why we created Auto DevOps. We also made it composable so you can pick and choose which [stages](https://docs.gitlab.com/ee/topics/autodevops/#stages-of-auto-devops) to use our default templates in. +The relevant [Auto DevOps components](https://docs.gitlab.com/ee/topics/autodevops/#using-components-of-auto-devops) for each GitLab stage are maintained by the product groups in those stages. +For example the [Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/#auto-deploy) [jobs](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib%2Fgitlab%2Fci%2Ftemplates%2FJobs) are maintained by the Progressive Delivery group and the [Auto SAST](https://docs.gitlab.com/ee/topics/autodevops/#auto-sast-ultimate), [Dependency Scanning](https://docs.gitlab.com/ee/topics/autodevops/#auto-dependency-scanning-ultimate), [License Compliance](https://docs.gitlab.com/ee/topics/autodevops/#auto-license-compliance-ultimate), [Container Scanning](https://docs.gitlab.com/ee/topics/autodevops/#auto-container-scanning-ultimate) and [DAST](https://docs.gitlab.com/ee/topics/autodevops/#auto-dast-ultimate) jobs are [maintained by the relevant Secure groups](/direction/secure#auto-devops). + +[Watch the video explaining our vision on Auto DevOps](https://www.youtube.com/watch?v=KGrJguM361c) + +[Learn more](/product/auto-devops/) • [Documentation](https://docs.gitlab.com/ee/topics/autodevops/) • [Direction](/direction/configure/auto_devops/) + +## Kubernetes Management + +Configuring and managing your Kubernetes clusters can be a complex, time-consuming task. +We aim to provide a simple way for users to configure their clusters within GitLab; tasks +such as scaling, adding, and deleting clusters become simple, single-click events. + +[Learn more](/solutions/kubernetes/) • [Documentation](https://docs.gitlab.com/ee/user/project/clusters/) • [Direction](/direction/configure/kubernetes_management/) + +## Infrastructure as Code + +Infrastructure as code (IaC) is the practice of managing and provisioning infrastructure through +machine-readable definition files, rather than manual hardware configuration or interactive +configuration tools. The IT infrastructure managed by this comprises both physical equipment +such as bare-metal servers as well as virtual machines and associated configuration resources. +The definitions are stored in a version control system. IaC takes proven coding techniques and +extends them to your infrastructure directly, effectively blurring the line between what is an +application and what is the environment. + +Our focus will be to provide tight integration with best of breed IaC tools, such that all +infrastructure related workflows in GitLab are well supported. Our initial focus will be on Terraform. + +[Direction](/direction/configure/infrastructure_as_code/) + +## Cluster Cost Optimization + +Compute costs are a significant expenditure for many companies, whether they +are in the cloud or on-premise. Managing these costs is an important function +for many companies. We aim to provide easy-to-understand analysis of your infrastructure +that could identify overprovisioned infrastructure (leading to waste), recommended changes, +estimated costs, and automatic resizing. + +[Direction](/direction/configure/cluster_cost_optimization/) + +## サーバーレス + +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. + +[Learn more](/product/serverless/) • [Documentation](https://docs.gitlab.com/ee/user/project/clusters/serverless/) • [Direction](/direction/configure/serverless/) + +## Runbook の設定 + +[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`. + +[Documentation](https://docs.gitlab.com/ee/user/project/clusters/runbooks/) • [Direction](/direction/configure/runbooks/) + +## 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. + +[Documenation](https://docs.gitlab.com/ee/ci/chatops/) • [Direction](/direction/configure/chatops/) + +<%= partial("direction/contribute", :locals => { :stageKey => "configure" }) %> + +## Prioritization Process + +In general, we follow the same [prioritization guidelines](/handbook/product/product-processes/#how-we-prioritize-work) +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 sections below. + +## Upcoming Releases + +<%= direction["all"]["all"] %> + +<%= partial("direction/other", :locals => { :stage => "configure" }) %> diff --git a/source/direction/conversion/index.html.md b/source/direction/conversion/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..dee677fed71b35cbc873148cc7663bc2f7d82ffd --- /dev/null +++ b/source/direction/conversion/index.html.md @@ -0,0 +1,123 @@ +--- +layout: markdown_page +title: Product Direction - Conversion +description: "The Growth Conversion Team at GitLab focuses on running experiments to increase the rate at which free accounts upgrade to become paying customers." +canonical_path: "/direction/conversion/" +--- + +## 概要 +The Growth:Conversion Team at GitLab focuses on running experiments to increase the rate at which free accounts upgrade to become paying customers. Today, it can be challenging for a free user to understand the features that are available within each tier of GitLab when navigating within the app. We want to make it as easy as possible for teams to collaborate together on the features that are best for them and to explore purchasing on their own terms whether that's starting a trial, speaking with someone at GitLab, or upgrading on their own. + +### Mission +* To continually improve the user experience when interacting with locked features, limits, and trials. + +### Team +Product Manager: [Sam Awezec](/company/team/#s_awezec) | +Engineering Manager: [Jerome Ng](/company/team/#jeromezng) | +UX Manager: [Jacki Bauer](/company/team/#jackib) | +Product Designer: [Kevin Comoli](/company/team/#kcomoli) | +Fullstack Engineer: [Alper Akgun](/company/team/#a_akgun) | +Fullstack Engineer: [Dallas Reedy](/company/team/#dreedy) + +### Conversion KPI +* Free-to-paid signup ARR growth rate +* Definition: (Free-to-paid signup ARR in the current period – free-to-paid signup revenue in the prior period) / free-to-paid signup ARR in the prior period +* The Analysis can be found in the [Product KPIs Dashboard in Periscope](https://app.periscopedata.com/app/gitlab/527913/WIP:-Product-KPIs?widget=7065032&udv=0) +* Calculation: + * For SaaS, free-to-paid signup ARR includes all namespaces that start a subscription for the first time, at least 24 hours after the namespace creation. + * For Self-Managed, we select all subscriptions that have a SFDC lead created at least 1 day before the start of the subscription and coming from one of these sources that have been identified as indicating prior usage of GitLab products: + * GitLab.com + * Trial, Enterprise + * GitLab Subscription Portal + * Trial, GitLab.com + * CE Download + +### Supporting performance indicators + +* New ARPU +* IACV +* Free-to-paid conversion rate (free user upgrades / free user signups in period) +* Number of trials started (by namespace type): number of namespaces (individual or group) that start a Gold Trial during a specific period +* Number of subscriptions started: we count a subscription as started when it is not refunded (TCV > 0) and has a MRR greater than 0 +* Day 60 free trial conversion rate: at a namespace level, ratio of namespaces that start a trial and then convert to a paid product category within 60 days after the start of the trial +* Product driven revenue by channel (e-commerce, sales rep assisted) & funnel +* E-commerce and sales rep assisted will track our core funnel efficiency. Funnel will allow us to understand the value of core actions taken within the app. We will define these actions to start – they may be `upgrade now`, `talk to sales`, `start a trial`, & `request access`. We then take the total occurrences and multiply it by the close rate and ASP to understand the value of the action in-app + +### Other reports we’re going to be monitoring + +#### In-app "upgrade now" buttons +* In-app "upgrade now" button selection to customers app purchase and ASP +* In-app "upgrade now" button selection to sales representative purchase and ASP + +#### Started trial after GitLab.com signup +* Trial to customers app purchase and ASP +* Trial to sales representative purchase and ASP + +#### GitLab.com influenced revenue – User +* Time from GitLab.com user signup to .com purchase (customers app or through sales representative) +* Breakdown of percent of .com purchases from customers app vs sales representative + Group +* Time from GitLab.com group signup to .com purchase (customers app or through sales representative) +* Group ASP +* Breakdown of percent of .com purchases from customers app vs sales representative +* Breakdown of percent of .com ARR from customers app vs sales representative + + +### GitLab self-hosted cross-over revenue – User +* Time from GitLab.com user signup to .com purchase (customers app or through sales representative) +* User ASP +* Breakdown of percent of .com purchases from customers app vs sales representative + Instance +* Time from GitLab.com group signup to .com purchase (customers app or through sales representative) +* Instance ASP +* Breakdown of percent of .com purchases from customers app vs sales representative + +## Problems to solve +Have you experienced an issue with a free user attempting to upgrade or do you have ideas on how we can improve the experience? We'd love to hear from you! + +## To effectively impact our KPI we'll focus on three core moments +Once a user has signed up for the free product, we have three core moments to convince them to become a customer. By getting them to initially activate and see value in the free product, exposing them to ah-ha moments with paid features, and ensuring they see value in the trial experience. + +1. Initial product activation + + By focusing experiments on activation and increasing the activation rate, we will impact downstream efforts in points 2 and 3. Note, this still needs to be validated once we have user tracking in place. How we'll get there: + + * Qualitative data collection – Understand what jobs GitLab is being hired to complete along with user-specific information so we can assist in making their adoption of GitLab as successful as possible + * Quantitative experiments – We will use discoveries in the data collected in the bullet above to support onboarding experiments. For example, if we find common themes include an engineer signing up planning to migrate a single project over, then we bring them directly into the project migration process and walk them through it. If someone indicates they plan to bring multiple dev ops teams over, we can start by having them create a group and then projects, walking them through the process + +2. Ah-ha moments with paid features and/or limits + + When users are actively using a tier of the product, they should be aware of when GitLab has the capability to make their job easier. We can do this by displaying premium features at key moments in the use of the product. How we'll get there: + + * Qualitative data collection – Survey existing free users to understand why they haven’t upgraded and ask what feature GitLab needs for them to upgrade. If users list features that we already have, then we know what features have discoverability issues + * Quantitative experiments – We will run experiments where we increase the discoverability of paid features and the associated value. We will use both the qualitative and quantitative data collected over time to generate future experiment ideas + +3. Trial and upgrade experience/value + + When an account starts a trial, they are making a conscious decision to test out paid features; this represents an opportune time for us to ensure we display the value of the paid features. We need to ensure that trial users experience the value of the paid features and decide to hire GitLab to improve their existing workflows. This same philosophy applies to users who are choosing to upgrade. How we'll get there: + + * Qualitative data collection – Survey users as they start a trial asking what jobs they’re looking to complete within the trial + * Quantitative experiments – We will focus experiments on how to ensure users are getting value out of trials as well as ensuring they are able to see the value in the paid tiers if they're debating upgrading. Our goal is to make it as easy as possible for the user to decide to hire GitLab + +## Our approach +We will utilize the ICE framework (impact, confidence, ease) to ensure we're best utilizing our time and resources. The following table displays the top issues we're currently prioritizing. + +| ICE Score | Description | Why/Hypothesis | +| ------ | ------ | ------ | +| 7 | [Test new upgrade module for feature weights](https://gitlab.com/gitlab-org/growth/engineering/issues/49) | We believe users may not actually see the value in some locked features, we want to set up a testing framework where we can easily test and iterate on these paywall states, this is the first test in this area. | +| 7 | [Expose Security nav item to a cohort of new signups](https://gitlab.com/gitlab-org/growth/engineering/issues/67) | We believe some users may not be aware that GitLab offers some of our premium features due to the navigation items being hidden from free users. This test will be the first test in a series where we expose the value of the premium features within the free navigation. | +| 8.33 | [Expose an upgrade or trial option in the top right account dropdown](https://gitlab.com/gitlab-org/growth/product/issues/116/) | We believe that some users may not know where to go to start a trial or upgrade. This test will help us understand if discoverability is an issue for users when it comes to starting a trial or upgrading. | +| TBD | [Walk new signups through group/project creation process](https://gitlab.com/gitlab-org/growth/product/issues/122) | We believe that given how central a group/project is to the successful adoption of GitLab, we'd like to test walking new users through this process. | +| TBD | [Onboard new users through an onboarding issue board](https://gitlab.com/gitlab-org/growth/product/issues/107) | We believe onboarding to a platform as large as GitLab is a task that will likely take more than one session to complete and the order will be dependant on the job GitLab has been hired to complete. This test will allow us to experiment with onboarding users to the issues feature while also giving them a home for their onboarding with issues already created for core actions they should be completing. | + +See also our [full backlog of work](https://gitlab.com/groups/gitlab-org/growth/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aconversion). + +## Maturity +The team is brand new as of August 2019, our goal is to build out an experimentation framework and the backlog of experiment ideas so we can become a well-oiled machine in the months to come. + +## Helpful links +[GitLab Growth project](https://gitlab.com/gitlab-org/growth) + +[KPIs & Performance Indicators](https://about.gitlab.com/handbook/product/metrics/) + +Reports & Dashboards (these will be linked once they are created) diff --git a/source/direction/create/code_review/competitors/index.html.md b/source/direction/create/code_review/competitors/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..2bcb07cf4cd865cfb0e04f9c198059ed25f26cd8 --- /dev/null +++ b/source/direction/create/code_review/competitors/index.html.md @@ -0,0 +1,233 @@ +--- +layout: markdown_page +title: "Competitors - Code Review" +--- + +- TOC + {:toc} + +## Competitive Analysis + +This is a brief competitive analysis for Code Review, focused on the user experience and feature set of [our competitors](/direction/create/code_review/#competitive-landscape). Each one starts with a summary, followed by the list of findings, with the most interesting highlighted. Tools are separated into two sections: mature and not mature. + +### Mature + +#### Gerrit + +[Homepage](https://www.gerritcodereview.com/) • [Docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html) • [Example code review](https://gerrit-review.googlesource.com/c/gerrit/+/211672) + +##### 要約 + +A tool specific for reviewing code, everything about the experience is focused on that. The UI is quite dense. Merge requests are called “Changes”. It focuses on only one commit, where authors can upload patch sets (revisions). “Changes” have an overview page and to see the files one must click-through into a specific “diff mode”. The overview page acts as a summary and lists the activity in chronological order, with comments unthreaded. Three interesting features are the ability to review commit messages, show the git blame inline, and auto-add reviewers based on git blame. + +##### Findings + +1. The commit message is effectively the Change’s description. ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#commit-message)) + 1. Commit messages have a max-height and are then expandable/collapsible. +1. Status: Needs kind-of-review, Not Current, Ready to Submit, Merged, Abandoned. +1. Fields are organized in an area called “Change info” ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#change-info)) +1. Owner: displayed as a link to a list of the owner’s changes that have the same status as the currently viewed change. ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#change-owner)) +1. Reviewers: each has a tooltip that shows on which [labels](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#labels) the reviewer is allowed to vote. +1. Labels: our “approval rules” ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#labels)) +1. Topics: a way to group changes (commits) related to a single topic. Could be considered our “issues” ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#project-branch-topic)) +1. {: .mark} File list contains auto-generated “magic files” Commit Message and Merge List ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#files)). It shows type of file modification, file path, number and status of comments (new, drafts, count), the size changes (additions/deletions), and a total of the size changes. Checkboxes in the file list allow files to be marked as reviewed. In the header of the file list there’s a “Diff Against” selection to compare patch sets and an “Open All” button that opens the diff view separately. +1. If a non-current patch set is viewed this is highlighted by the Not Current change state ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#patch-sets)) +1. The Download drop-down offers commands and links for downloading the currently viewed patch set. There is a drop-down to switch between the download schemes (SSH or HTTPS). The last chosen download scheme is remembered. ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#download)) +1. Uses the “star” metaphor and icon to subscribe to notifications. ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#star)) +1. {: .mark} Related changes tab: shows descendant and ascendant changes (dependencies) in a list view where the current change is in the middle ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#related-changes-tab)) +1. Same topic tab: open changes that share the topic ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#same-topic)) +1. {: .mark} Reply button: opens a popup panel to publish inline comments, allows voting (approval) and adds a summary comment. The inline draft comments are listed to be reviewed before publishing, with links. ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#reply)) +1. {: .mark} History: very compact list, similar-looking to an email inbox. New comments since the user’s last review are automatically expanded and bolded. Inline comments are directly displayed in the history with links to jump there, they are grouped per review. It has an expand/collapse all button. ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#history)) +1. Updates: there’s a polling system that shows a notification (similar to Gmail) when there updates. Users can Show or Ignore. ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#update-notification)) +1. Checks tab (pipelines) +1. Diffs ([docs](https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#side-by-side)): + 1. Can be marked as reviewed (can be done automatically per user preference) + 1. {: .mark} Scrollbar with map of diffs and comments + 1. Patch set comparisons can be changed in the file header via a numbered list. + 1. Arrows to move between files. + 1. Option to expand all comments as a user preference. + 1. Drafts are “saved” or “discarded”. + 1. {: .mark} Inline comments can be started by clicking on a line or selecting lines and then clicking a button. + 1. Comments can be added to the whole file. + 1. Uses “Done” instead of “Resolve” in comments. + 1. {: .mark} Ability to show blame in diff view. +1. {: .mark} List: Changes (merge requests) are classified in Size per the number of changed lines, using t-shirt sizes (e.g. XS = +1,-1) +1. {: .mark} Add reviewers based on the git blame computation of the changed files ([docs](https://gerrit-review.googlesource.com/Documentation/intro-project-owner.html#reviewers)) + +#### Phabricator + +[Homepage](https://www.phacility.com/phabricator/) • [Docs](https://secure.phabricator.com/book/phabricator/article/differential/) • [Example code review](https://secure.phabricator.com/D20659) + +##### 要約 + +The code review experience in Phabricator is similar to Gerrit’s. However, the whole review UI is one big scrollable page, instead of being sectioned into different views/pages. Three other notable differences are the support for both pre and post-merge reviews, showing older inline comments in updated diffs (ported/ghost comments), and showing test and coverage reports inline. + +##### Findings + +1. {: .mark} Supports two similar but separate code review workflows: "review" and "audit" (post-commit). +1. List view: + 1. Action Required is revisions you are the author of or a reviewer for, which you need to review, revise, or push. + 1. Waiting on Others is revisions you are the author of or a reviewer for, which someone else needs to review, revise, or push. +1. Detail view is a single-view, scrollable: + 1. Details: reviewers and review status, links to Trac issues, summary, test plan + 1. Actions, tags, and subscribers + 1. Diff detail: repository, branch, lint status and warnings, unit test result, build status + 1. Activity + 1. Changes +1. {: .mark} Separate view with audit table for inline comments with the attributes: diff no., status, reviewer, comment, created date (relative) ([example](https://secure.phabricator.com/differential/revision/inlines/20659/)) +1. Activity is shown chronologically, unthreaded + 1. When adding inline comments OR marking inline comments as done, a regular comment acts as a summary. Inline comments are listed at the bottom of the summary, indicating the file and with a link to the line. + 1. If the history is large, older items are hidden with a “Show Older Changes” button that progressively shows more and more older items. +1. {: .mark} Inline comments are threaded, and can be hidden/shown by the following aspects: “Done”, collapsed, older, all. +1. Multiline comments can be added by clicking one line number and dragging to a nearby line number. +1. Inline comments are initially unpublished (drafts). They are published in batch, alongside an optional normal comment and optional action (like accepting the revision). +1. {: .mark} Ported/ghost comments: When a revision is updated, it attempts to port inline comments forward and display them on the new diff. Ported comments have a pale, ghostly appearance and include a button that allows you to jump back to the original context where the comment appeared. Ported comments sometimes appear in unexpected locations, especially in the presence of heavy changes, but this helps prevent mistakes and makes it easier to verify feedback has been addressed. +1. Highlights when changes are pushed, when pipelines fail +1. Image macros to add frequent GIFs to comments +1. {: .mark} Ability to add test and coverage reporting in the specific lines of code +1. By default, approvals are not reset when new commits are pushed. +1. {: .mark} People can be automatically notified about a review based on rules (like content, author, files affected, etc.). + +#### Crucible + +[Homepage](https://www.atlassian.com/software/crucible) • [Docs](https://confluence.atlassian.com/crucible/the-crucible-workflow-298977485.html) + +##### 要約 + +It’s the only code review tool we reviewed that attempts to port the IDE experience to a browser UI for code review, with a navigation sidebar to jump between sections and files, and a fixed content view. Like Phabricator, it supports pre and post-merge reviews but is more flexible about the review’s starting point: specific commits, whole branches, committed files, patch files, or attachments. + +##### Findings + +1. Roles: author, reviewer, and moderator (optional) + 1. {: .mark} Reviewers can be auto-suggested, by analyzing the users that have contributed to the files you've selected and also don't have a lot of open reviews. +1. {: .mark} Reviews can be created from commits/changesets, branches, specific files, patch files (pre-commit), or attachments. ([docs](https://confluence.atlassian.com/crucible/creating-a-review-298977457.html)) +1. {: .mark} Allowing anyone to join the review is an option configured per review. Else, only selected reviewers can participate. +1. Status: Draft (default on creation), Under review (after Start review is selected), Summarized (once all reviews are submitted), Closed or Abandoned ([docs](https://confluence.atlassian.com/crucible/roles-and-status-classifications-298977466.html)) + 1. Start Review sends a notification email to all participants. +1. Ability to link to issues and other reviews on creation. +1. Comments: can be added to the whole review, to a file, to a single line, to multiple lines (click and drag to select multiple lines or select text) + 1. Can be marked read/unread, marked as defect or needs resolution, saved as draft or published immediately + 1. Defects can be ranked (major, minor, etc.) and also classified: Wrong, Can be improved, Risk-prone, Security hole, Over engineered, Code duplication + 1. {: .mark} In the file tree, there’s a counter of total comments per file (and unread comments) +1. User switches between 3 main views: Summary, Activity, Files. +1. Summary: Details, Objectives, General comments + 1. Details: list of participants, role, time spent, no. of comments, and link to the last comment +1. Activity: All activities in chronological order, filterable by resolved and/or unresolved comments. +1. List view: + 1. Inbox: To Review, Ready to Close, In Draft, Require My Approval + 1. Outbox: Out for Review, Completed + 1. Archive: Closed, Abandoned, My Open Snippets, My Snippets + +### Not mature + +#### Atlassian Bitbucket + +[Homepage](https://bitbucket.org/product) • [Docs](https://confluence.atlassian.com/bitbucketserver/review-and-discuss-a-pull-request-808488540.html) • [Example code review](https://bitbucket.org/atlassian/atlassian-aws-deployment/pull-requests/137/itops-373-make-synchrony-a-service/diff) + +##### 要約 + +In general, its pull requests and review experience are very similar to GitHub. + +##### Findings + +1. {: .mark} Ability to create tasks from comments and view a list of unresolved tasks. ([docs](https://confluence.atlassian.com/bitbucketserver/review-and-discuss-a-pull-request-808488540.html#Reviewanddiscussapullrequest-tasks)) +1. Iterative reviews: Within the diff view you can select a specific commit to review, or choose to view all changes within a pull request. If you return to a pull request you previously reviewed, you'll only see the new commits added since you last reviewed the pull request. +1. Default reviewers can be added to a combination of source-target branches with the following options: Branch name, Branch pattern, Branching model, or Any branch. ([docs](https://confluence.atlassian.com/bitbucketserver/add-default-reviewers-to-pull-requests-834221295.html)) + +#### Azure DevOps + +[Homepage](https://azure.microsoft.com/en-us/services/devops/) • [Docs](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests) + +##### 要約 + +Like Bitbucket, it largely follows the GitHub’s experience, but manages to give it more structure and add many more features. Of note are their consistent locations for actions and secondary information, granular types of approval, good approach to merge confirmation and actions, and the visibility of policies (items blocking the merge) and status of the pull request. + +##### Findings + +1. List view of created and assigned pull requests ([docs](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#view-and-manage-your-pull-requests)) +1. Allows selection of “Reviewers” and “Work Items” (related issues) in the PR creation form ([docs](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#add-detail-to-your-pull-request)) +1. Specific area just for related work items (issues) ([docs](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#link-work-items)) +1. States: Draft (WIP) > Published > Complete (merged) +1. Main actions: Complete (Merge), Set auto-complete (Merge when all [branch policies](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#complete-the-pull-request) pass), Mark as draft (WIP), and Abandon (Close) ([docs](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#complete-the-pull-request)) + 1. {: .mark} Completing (merging) opens a dialog to edit the merge commit message and select merge options ([docs](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#complete-the-pull-request)) + 1. Setting auto-complete a banner is shown, confirming that the changes will be merged as soon as the policies are satisfied. Has + {: .mark} a “Cancel auto-complete” option and displays the outstanding list of policy criteria. +1. Main sections: Overview (state at a glance and discussion), Files (changes), Updates (versions/pushes), Commits +1. {: .mark} Uses the concept of [branch policies](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#complete-the-pull-request) to block pull requests from being merged. It shows an easy to read list of things remaining. ([docs](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#link-work-items)) +1. Ability to open file changes in full-screen mode +1. Comment states: Active (default), Resolved, Pending, Won’t Fix, Closed ([docs](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#leave-comments)) +1. Mixes the concept of approving with casting votes ([docs](https://docs.microsoft.com/en-us/azure/devops/repos/git/pull-requests?view=azure-devops#vote-on-the-changes)) +1. Votes: Approve, Approve with suggestions, Wait for author, Reject, or Reset feedback + 1. Approve with suggestions: Agree with the pull request, but provide optional suggestions to improve the code. + 1. Wait for author: Do not approve the changes, and ask the author to review your comments. The author should let you know when you should re-review the code after they have addressed your concerns. + +#### GitHub + +[Homepage](https://github.com/) • [Docs](https://help.github.com/en/articles/about-pull-request-reviews) • [Example](https://github.com/gitlabhq/gitlabhq/pull/9138) + +##### 要約 + +GitLab’s current code review experience is largely modeled after GitHub’s, with a discussion/activity view and a changes view with all of the files stacked vertically. Some relevant differences in GitHub are resolving whole discussions (instead of comments), the concept of reviewers, submitting a summary comment with the review, and viewing only the changes done since the user’s last review. Some of its frequently mentioned issues are the difficulty in finding who is responsible for looking at the code, the lack of inline test and coverage reports, and the lack of an audit trail. + +##### Findings + +1. {: .mark} Uses the concept of “Reviewers” to request reviews. Code owners are automatically requested for review when someone opens a pull request that modifies code that they own. ([docs](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews#about-pull-request-reviews)) +1. When submitting a review, the reviewer can attach a summary comment to their inline comments. Besides “Approve”, a review has two additional types: “Comment” and “Request changes”. ([docs](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request#submitting-your-review)) +1. {: .mark} Supports resolving whole discussions, instead of comment by comment. ([docs](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-reviews#resolving-conversations)) +1. Uses the term “conversations” instead of “threads” or “discussions”. +1. Allows navigating changes commit-by-commit, with convenient previous-next buttons. ([example](https://gitlab.com/gitlab-org/gitlab/issues/18140#further-details)) +1. Allows commenting on multiple lines. ([example](https://twitter.com/github/status/1179101186437324801)) +1. {: .mark} Allows viewing only the changes done since the user’s last review. +1. Users can mark files as viewed to collapse them until they are changed again. ([docs](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-proposed-changes-in-a-pull-request#marking-a-file-as-viewed)) + +#### Review board + +[Homepage](https://www.reviewboard.org/) • [Docs](https://www.reviewboard.org/docs/manual/dev/users/) • [Example code review](http://demo.reviewboard.org/r/844/) + +##### 要約 + +Even though the UI is not the most appealing or modern, Review board has some interesting features that set it apart. Specifically, the ability to filter comments by type and author, and the personal dashboard that is organized like a “code review inbox”. + +##### Findings + +1. Supports both pre and post-merge reviews. +1. Dashboard: Outgoing (All, Open); Incoming (Open, To Me, Starred) +1. {: .mark} Review requests list: Flag with published/unpublished comments, No. of reviews, New updates since last view, Ship it!/Issue counts (approvals, open comments), Flag to me (which directly list you in the “people” field) +1. Status: Draft, Published, Closed (“submitted” or as “discarded) + 1. Closing allows to describe the reason why it was closed (optional). +1. Roles: Owner, Reviewers (group or people) +1. Reviews consist of a header, a list of comments, and a footer. Comments can be general, to a file, and diffs. +1. In reviews, “issues” can be flagged. They can then be marked as resolved or dropped. Can be re-opened. + 1. {: .mark} If an issue is particularly important, you can select Require Verification when creating the comment. This will make it so the owner of the review request cannot directly mark the issue as fixed or dropped. Instead, only the reviewer (or an administrator) can then verify whether the issue should be closed or reopen it. +1. {: .mark} Below the description a list of open issues (comments) is filterable by: type and author. +1. Deleted file contents are not shown by default, as this code often doesn’t need to be reviewed. Instead, you’ll see a simple message stating that the file was deleted and the option to expand. +1. Multiline comments are started with click and drag through multiple line numbers. +1. {: .mark} Diff comments are shown next to the file with a comment counter per line. Published comments are blue, drafts are green. + +#### Reviewable + +[Homepage](https://reviewable.io/) • [Docs](https://docs.reviewable.io/) • [Example code review](https://reviewable.io/reviews/Reviewable/demo/1) + +##### 要約 + +It has a fresh approach to navigating a code review, with its intuitive toolbar that allows cycling between files, discussions, and drafts, and also a visual way to change which revisions are compared. There’s a big focus on the reviewer experience, especially when re-reviewing changes, by highlighting what files and discussions they need to review again or reply to. The status of the pull request is given visually with a small circular chart that shows the passed/failed checks. Other highlights include the ability to track of who re­viewed which re­vi­sion of each file, automatically entering single file mode to preserve performance, and setting merge options and commit message before merging. + +##### Findings + +1. Roles: Author, Reviewers, Mentionee (mentioned, becomes reviewer if starts a discussion or marks a file as reviewed) +1. Approval levels: Comment, Approve, Request changes +1. Merge ([docs](https://docs.reviewable.io/#/reviews?id=merge)) + 1. When a review is complete, a victory graphic appears. + 1. {: .mark} You can set merge options and edit the merge commit message via the dropdown attached to the button. + 1. To merge the pull request, click and hold the button for a couple seconds until the arming indicator fills with yellow and starts pulsing, then release. This procedure is in place to reduce the chances of accidentally merging a pull request without requiring a separate confirmation. +1. {: .mark} Review toolbar: + 1. {: .mark} Checks: This item summarizes the current condition of GitHub's CI commit statuses and checks, mergeability, and review completion. The donut chart icon indicates the relative proportion of successful, pending, and error/fail states. + 1. {: .mark} Changes: This item summarizes the changes you're currently looking at. + 1. {: .mark} Counters: Files, discussions, and drafts. Red counters indicate that you must address the given number of items to advance the review. Grey counters indicate that other participants must address the given number of items, but you're in the clear. Click to cycle through them + 1. {: .mark} Main action: switches between Publish and Merge, if the user has unpublished comments. +1. {: .mark} Mark as reviewed: letting you track the reviewed state of each file at each revision, for each reviewer. This enables you to easily remember — and indicate to others — where you left off in the review and easily view only subsequent changes. Review marks remain in a draft state and are only visible to you until published. +1. File tree: shows which files you have reviewed (even in draft) and who else has reviewed them. +1. {: .mark} Single file mode: Automatically enters a single file mode to preserve performance when the number of visible files exceeds a threshold (25 files as of this writing). In this mode, only one file will appear at a time. You'll also see a summary explanation just above the first (and only) file diff, together with a button that you can click to force all files to appear anyway until you leave the page. +1. Comment status: Discussing, Satisfied, Informing, Working, or Blocking. +1. Dashboard: Waiting on me, Assigned to me + 1. Review state is visible, with counters reflect the same information as you'll see on the review page diff --git a/source/direction/create/code_review/index.html.md b/source/direction/create/code_review/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..a1b832769543cf559983b0e3a81a38d70dd3a3e2 --- /dev/null +++ b/source/direction/create/code_review/index.html.md @@ -0,0 +1,326 @@ +--- +layout: markdown_page +title: "Category Direction - Code Review" +description: "The Code Review strategy page belongs to the Source Code group of the Create stage. Learn more here!" +canonical_path: "/direction/create/code_review/" +--- + +- TOC + {:toc} + +## コードレビュー + +| Section | Stage | Maturity | Last Reviewed | +| --- | --- | --- | --- | +| [Dev](/direction/dev/) | [Create](https://about.gitlab.com/stages-devops-lifecycle/create/) | [Loveable](/direction/maturity/) | 2020-07-20 | + +## Introduction and how you can help + +The Code Review strategy page belongs to the [Source Code](/handbook/product/product-categories/#source-code-group) group of the [Create](/direction/dev/#create) stage, +and is maintained by [Daniel Gruesso](https://gitlab.com/danielgruesso). + +This strategy is a work in progress, and everyone can contribute. +Please comment and contribute in the linked issues and epics. +Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision. + +- [Issue list](https://gitlab.com/groups/gitlab-org/-/issues?&label_name%5B%5D=Category%3ACode%20Review) +- [Epic list](https://gitlab.com/groups/gitlab-org/-/epics?label_name[]=Category%3ACode%20Review) + +## 概要 + + + +Code Review is an essential practice of every successful project. +It is necessary for maintaining and improving code quality, +and is one of the primary avenues of mentorship for software engineers, +but it is also time consuming. + +GitLab's vision for code review is a place where: + +- changes can be discussed, +- developers can be mentored, +- knowledge can be shared, and +- defects identified. + +GitLab should make these tasks efficient and easy, +so that velocity and code quality both increase. + +### Metrics of success + +The primary metric by which we measure the success of the Code Review category +is: **reducing the duration of the Code Review**. +This is measured as the duration from the first merge request version to merged. + + + +Category-level UX baselines conducted quarterly will provide qualitative +feedback to validate perceived efficiency and our hypothesis. + + + +### Target Audience + + + +Code review is used by software engineers and individual contributors of all kinds. Depending on their context, however, the workflow and experience of code review can vary significantly. + +- **full time contributor** to a commercial product where reducing cycle time is important. The review cycle is tight and focussed as a consequence of best practices where keeping merge requests small and iterating at a high velocity are objectives. Code review workflows for these users are **Complete** +- **occasional contributor** to an open source product where cycle time is typically longer as a consequence that they are not working on the project full time. This results in longer review times. When long review times occur, the participants in the merge request will need to spend more time reacquainting themselves with the change. When there are non-trivial amounts of feedback this can be difficult to understand. Code review workflows for these users are **Complete** +- **scientific projects** frequently have a different flow to typical projects, where the development is sporadic, and changes are often reviewed after they have been merged to master. This is a consequence of the high code churn associated with high exploratory work, and having infrequent access to potential reviewers. Post-merge code review workflows are not yet viable in GitLab. + + +### Challenges to address + + + +There are many code review tools in the market as well as multiple workflows. Deciding which features/workflows to build-in to GitLab +is important so that users can migrate seamlessly. However, it is not realistic for us to support every feature/workflow out there, as +such we must suss out the most popular, forward-looking features/workflows, and support them in GitLab. + +* Some of the features/workflows we are planning to build into GitLab: + + * [Merge request reviewer assignment](https://gitlab.com/groups/gitlab-org/-/epics/1823) + * [Easily tracking unread diffs, files, commits and discussions in merge requests](https://gitlab.com/groups/gitlab-org/-/epics/1409) + * [Commit by commit code review](https://gitlab.com/groups/gitlab-org/-/epics/285) + +* Some of the features/workflows we are currently researching: + + * [Cross project merge requests](https://gitlab.com/groups/gitlab-org/-/epics/882) + +## Where we are Headed + + + +The code review process involves at least two roles (author, and reviewer) but may involve many people, +who work together to achieve code quality standards and mentor the author. +Furthermore, many reviewers are often not Developers. +Reviewers may be Developers, UX Designers, Product Managers, Technical Writers, Security Engineers and more. + +In support of GitLab's vision for code review, +areas of interest and improvement can be organized by the following goals: + +- **Ease of use** influences whether users choose to use the GitLab tool to merge branches instead of simply interacting with the Git server via command line. Merge request should be easy to use and provide enough visible value such that users will default to use merge requests. +- **Love-ability** captures the essence that GitLab is enjoyable to use, which may mean that it is fast, invisible and allows you to get your work done. Particularly, GitLab should encourage the best of communication between colleagues and contributors, helping teams celebrate great contributions of all kinds, and express their ideas without misunderstandings. How GitLab communicates with people, will influence how people communicate with each other inside GitLab. +- **Efficiency** directly influences velocity within the time span of a single merge request + - *Author efficiency* considers how a merge request author can create and address code review feedback, find a relevant reviewer for their merge request, and incorporate incoming feedback. + - *Reviewer efficiency* considers how an individual reviewer can review a code change, leave feedback, and also verify their own feedback has been addressed. Provide enhanced context when reviewing new information (for example, through code intelligence) for efficiency. + - *Team efficiency* considers a team can coordinate and communicate responsibilities, progress and status of a merge request, and quickly the entire process can be completed. Support workflows that enable new and better ways of working (for example, suggest changes, commit by commit review). +- **Best practices** Influence efficiency of teams and projects over a longer time scale, and can include fostering norms and behaviours that aren't explicitly enforced through the application. Amplifying best practices, great defaults and documentation play a significant role in this. +- **Policy** controls that allows code review requirements to be set and enforced, going above and beyond amplifying and encouraging best practice. + +The following improvements will help us make significant progress towards the above goals: + +* [Improve merge request reviewer assignment](https://gitlab.com/groups/gitlab-org/-/epics/1823) +* [File-by-file merge request diff navigation](https://gitlab.com/groups/gitlab-org/-/epics/516) + +### What's Next & Why + + + +- **In Progress:** [Smarter merge request diffs using merge refs](https://gitlab.com/groups/gitlab-org/-/epics/854) + + Code reviews are time consuming, requiring engineers to carefully review and + understand the proposed change. The accuracy of the diff is therefore + critical. + + Additionally, both Atlassian and GitHub have made their diffs smarter, + showing the actual difference between the source and target branch, not the + source branch and the merge base of the target branch. + +- **In progress:** [Code intelligence](https://gitlab.com/groups/gitlab-org/-/epics/1576) (e.g. symbol docs, jump to definition) + + The purpose of code reviews is to identify defects, and ensure the code + meets quality guidelines for style, readability, and maintainability. In + order to do this, the code reviewer must understand the proposed change + well. + + We know that code intelligence is an important tool for understanding code, + and has been available in local development environemnts since the 1980s. + Because of this many developers rely on local code intelligence when + performing code reviews. Providing this to all reviewers in GitLab will + improve the quality and efficiency of code reviews. + +- **In progress:** [Comment on multiple lines](https://gitlab.com/groups/gitlab-org/-/epics/1431) + + Feedback doesn't always relate to a single line, and it can be restrictive + to be unable to comment on a range of lines. Similarly, suggested changes + to merge requests can also span multiple lines in a diff, but it is + difficult to use this feature without a natural interface to select + multiple lines. + +- **In progress:** [Improved merge request reviewer assignment](https://gitlab.com/groups/gitlab-org/-/epics/1823) + + Detecting defects, and providing meaningful code review feedback requires + understanding the code being changed. This is most effectively done by + subject matter experts, which are typically people who have previously + edited or reviewed the areas of the code being changed. + + Helping authors find the right reviewer will yield better code reviews, and + carefully distributing them across many engineers will prevent individual + engineers becoming over burdened. + +### What is Not Planned Right Now + + + +### Maturity Plan + + + +This category is currently at the **Loveable** maturity level (see our [definitions of maturity levels](https://about.gitlab.com/handbook/product/product-categories/maturity/#legend)). + +## Competitive Landscape + + + +GitLab competes with both integrated and dedicated code review tools. Because merge requests (which is the code review interface), and more specifically the merge widget, is the single source of truth about a code change and a critical control point in the GitLab workflow, it is important that merge requests and code review in GitLab is excellent. Our primary source of competition and comparison is to dedicated code review tools. + +Prospects and new customers, who previously used dedicated code review tools typically have high expectations and accustomed to a high degree of product depth. Given that developers spend a significant portion (majority?) of their in application time in merge requests, limitations are quickly noticed and become a source of frustration. + +GitLab’s current code review experience is largely modeled after GitHub’s, with most of its pros and cons. Gerrit and Phabricator are [frequently mentioned](https://news.ycombinator.com/item?id=12487695) as the best alternatives to the GitHub code review model. See the [competitive analysis](/direction/create/code_review/competitors/#competitive-analysis) for a closer look at the user experience and feature set of competitor tools. + +Integrated code review packaged with source code management: + +- [Phabricator](https://www.phacility.com/phabricator/) by Phacility • _Free, open source_ • **Mature** • [Example code review](https://phabricator.haskell.org/D4953) +- [Gerrit](https://www.gerritcodereview.com/index.html) • _Free, open source_ • **Mature** • [Example code review](https://gerrit-review.googlesource.com/q/status:open+project:gerrit) +- [GitHub](https://github.com/features/code-review/) • _Free option, closed source_ +- [Bitbucket](https://bitbucket.org/product/features) by Atlassian • _Free option, closed source_ +- [Azure DevOps](https://azure.microsoft.com/en-us/services/devops/) by Microsoft • _Free option, closed source_ + +Dedicated code review tools: + +- [Crucible](https://www.atlassian.com/software/crucible) by Atlassian • _Paid, closed source_ • **Mature** ([Bitbucket vs Crucible](https://confluence.atlassian.com/bitbucketserverkb/what-s-the-difference-between-crucible-and-bitbucket-server-do-i-need-both-779171640.html)) +- [Review Board](https://www.reviewboard.org/) • _Free, open source_ • [Example code review](http://demo.reviewboard.org/r/844/diff/1/#index_header) +- [Reviewable](https://reviewable.io/) • _Free option, closed source_ • [Example code review](https://reviewable.io/reviews/Reviewable/demo/1) + +IDE-related: +- [CodeStream](https://www.codestream.com/) • _Free option, closed source_ +- [GitLens](https://gitlens.amod.io/) • _Free, open source_ +- [Visual Studio Live Share](https://visualstudio.microsoft.com/services/live-share/) • _Free, open source_ +- [Gitpod](https://www.gitpod.io/docs/59_code_reviews/) • _Free option, closed source_ + + +## Analyst Landscape + + + +## Top Customer Success/Sales issue(s) + + + +The highest priority customer requests are for improved application performance, accuracy and efficiency for reviewing merge request diffs of all sizes, small and extremely large. + +- [Smarter merge request diffs using merge refs](https://gitlab.com/groups/gitlab-org/-/epics/854) address accuracy problems in some situations, thereby improving **efficiency** of reviews by showing the expected diff contents. +- [Track unread diffs, files, and discussions](https://gitlab.com/groups/gitlab-org/-/epics/1409) improves usability. primarily improves **reviewer efficiency** by allowing reviews to be performed incrementally over multiple sittings, and better handling the iterative process of leaving feedback and the author proposing improvements. + +Other notable requests include: + +- [Cross-project code review (group merge requests)](https://gitlab.com/groups/gitlab-org/-/epics/457) +- [Post-merge code review](https://gitlab.com/groups/gitlab-org/-/epics/872) is of interest to a variety of organizations where changes are merged with a high velocity (e.g daily) and they desire to review aggregate set of changes semi-regularly. + +## Top user issue(s) + + + +- [Smarter merge request diffs using merge refs](https://gitlab.com/groups/gitlab-org/-/epics/854) +- [Increased focus of merge request changes tab](https://gitlab.com/groups/gitlab-org/-/epics/1406) will make code review more **love-able** by reducing distraction, and making use of the navigational affordances of the top of the page which is quickly accessed by mouse and keyboard. +- [Multi-line comments](https://gitlab.com/groups/gitlab-org/-/epics/1431) + +## Top internal customer issue(s) + + + +- [Suggest and assign reviewers and maintainers](https://gitlab.com/groups/gitlab-org/-/epics/1823) will replace the Reviewer Roulette implemented with Danger. + +## Top Vision Item(s) + + + +- **Investigating:** [Commit focused code review](https://gitlab.com/groups/gitlab-org/-/epics/285) + + Small changes are easier and faster to review, and commits are the smallest + unit of change. Some of the largest projects in the world use commit based + workflows for this reason. + + We are investigating how we can amplify best practices in commit focussed + workflows, and bring these into GitLab to improve code quality and + efficiency. + +- **Investigating:** [Real-time merge request collaboration](https://gitlab.com/groups/gitlab-org/-/epics/2082) + + Merge requests are highly asynchronous today. A code review is requested, + and then at some point later the author returns to address the feedback. + This causes all but the simplest of merge requests to go through multiple + slow review cycles. + + GitLab aims to help teams compress cycle time and increase velocity. To + this end, reducing the number of review cycles, and preventing frequent + context switching should help. + + Since we know many teams are located in similar timezones, if not located + in the same physical location, we can improve notifications and workflows to + help people work together on the same merge request in real-time. + + Read more in our [blog + post](https://about.gitlab.com/blog/2019/12/19/future-merge-requests-realtime-collab/). + +- **Investigating:** [Track unread merge request comments and commits](https://gitlab.com/groups/gitlab-org/-/epics/1409) + + When reviewing a merge request with multiple commits, a large number of + changes, or that requires many revisions, it's hard to know what requires + your attention, and what you have previously reviewed. This is a factor in + making code review inefficient. diff --git a/source/direction/create/design_management/images/GitLab-designer-workflow.png b/source/direction/create/design_management/images/GitLab-designer-workflow.png new file mode 100644 index 0000000000000000000000000000000000000000..b831c9c2e6f753035736967825de943d6f880517 Binary files /dev/null and b/source/direction/create/design_management/images/GitLab-designer-workflow.png differ diff --git a/source/direction/create/design_management/images/Typical-designer-workflow.png b/source/direction/create/design_management/images/Typical-designer-workflow.png new file mode 100644 index 0000000000000000000000000000000000000000..900c4cfcac717271731699fb7d6268af055bf36f Binary files /dev/null and b/source/direction/create/design_management/images/Typical-designer-workflow.png differ diff --git a/source/direction/create/design_management/index.html.md b/source/direction/create/design_management/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..4422e4afdaca1db8c8b4447f828ce9bca4ef6534 --- /dev/null +++ b/source/direction/create/design_management/index.html.md @@ -0,0 +1,206 @@ +--- +layout: markdown_page +title: "Category Direction - Design Management" +description: "Our goal at GitLab with Design Management is to treat Designers as first-class users within GitLab and support their workflows as good as any product can." +canonical_path: "/direction/create/design_management/" +--- + +- TOC + {:toc} + +## デザイン管理 + +| | | +| --- | --- | +| Stage | [Create](/direction/create/) | +| Maturity | [Minimal](/direction/maturity/) | +| Content Last Reviewed | `2020-07-24` | + +## Introduction + + + +Design Management at GitLab encompasses two broad areas of features: **1) Transient "Communication-based" features** which have a beginning and end similar to Issues and **2) Evergreen "Project-based"** features which live as a project or asset on their own. GitLab is in a unique position to offer both types of Design features because our platform supports Issues (collaboration with engineering) and Repositories (where the actual code lives). + +**Examples of Transient "Communication-based" Design Management features:** +- Attaching Designs to Issues +- Visual communication in comments on designs +- Approvals of Designs +- Links to prototypes in description of issue +- Developer handoff with specifications +- Production Design Inspect to compare the code to the design +- Issues are closed and Designs are "done" + +**Examples of Evergreen "Project-based" Design Management features** +- Customized Design repositories for backing up native design files +- Customized Design repositories for connecting local design system files to their live frontend assets +- Deep linking of assets to original repo files + + +**Our goal with Design Management is to treat Designers as first-class users within GitLab and support their workflows as good as any product can. Design management will consider the design life cycle from generating ideas, design reviews, design systems, and more.** + +- [Issue List](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Category%3ADesign%20Management) +- [Epic List](https://gitlab.com/groups/gitlab-org/-/epics?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Category%3ADesign%20Management) +- [Overall Vision](/direction/create/) + +Please reach out to PM Christen Dybenko ([E-Mail](mailto:cdybenko@gitlab.com)) if you'd like to provide feedback or ask +questions about what's coming. + +## Long Term Strategy + +Long term, we'll need we need to adapt GitLab to incorporate Design users as first class users as this design workflows are often different from the typical DevOps flow. Many companies that employ "Design First" workflows are often working so far ahead of the DevOps process we need to consider this as its own ecosystem and key in on. We recognize that this workflow can be quite iterative and often done and presented/approved ahead well ahead of an issue ever being written. + +Ideally, GitLab will support the flexiblity of any design workflow, while featuring a simplified way to share of Design work. It would allow for independent design deadlines or separate milestones from engineering, and empower the Designer to easily track/follow the issue through to production. + +### Typical designer workflow across tools + +![Typical designer workflow across tools](images/Typical-designer-workflow.png) + +### GitLab vision for a new designer workflow + +![Typical designer workflow across tools](images/GitLab-designer-workflow.png) + + +## Target Audience and Experience + + +**In 13.0, we [moved Design Managment to Core/Foss](https://gitlab.com/gitlab-org/gitlab/-/issues/212566) so it can but used by everyone for free.** Read more about in the blog: https://about.gitlab.com/blog/2020/03/30/new-features-to-core/ + +Design Management is targeted at [product designers](/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) who collaborate with [product managers](/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) and [software developers](/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer). + +The **minimal** user journey will provide designers with the ability to upload mockups to an issue, and for point of interest discussions to happen on each image. Over time these mockups can be updated to resolve the discussions. As the mockups are changed, new versions will be created so that process can iterate. + +## What's Next & Why + + +**MVC Done in 12.9: [Versioned designs and point of interest discussions](https://gitlab.com/groups/gitlab-org/-/epics/660)** - Currently, collaboration between designers, developers and product managers on issues is hard and unstructured. This first iteration will make it possible to upload discuss designs far more efficiently. Point of interest comments are the key feature, that allows much precise discussion rather than trying to verbally discuss multiple items of feedback on a single image in a single thread. We plan to [move this feature down to Core](https://gitlab.com/gitlab-org/gitlab/-/issues/212566) in the next few releases. + +**Next: Improve the useability of the MVC for Versioned designs and point of interest discussions by Dogfooding** - We're working on an [Internal dogfooding epic](https://gitlab.com/groups/gitlab-org/-/epics/2582) which contains the issues that gets us through the major pain points that our internal GitLab team has surfaced. This will take us a long way towards viable as these are the biggest useability concerns. + +**Next: [Integrate with major design tools to support current workflows and increase users](https://gitlab.com/groups/gitlab-org/-/epics/2405)** - We started official [Figma](https://gitlab.com/gitlab-org/gitlab-figma-plugin) and [Sketch](https://gitlab.com/gitlab-org/gitlab-sketch-plugin) projects to work on our plgugins. The Figma MVC will ship in 13.2 - track progress in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/3449). Next: Collaborate with the other design tool companies as partners and build out API support so Product Designers can post to GitLab Issues from their preferred workflow. While working on this, upgrade our Issue Descriptions to support unfurled links (with thumbnail preview) from our own Designs as well as the partner design tools. Move engineering heavy lifting to the partner integration teams so we can power through. + +**Next: [Empower Product Designers and Leaders to easily stay on top of design progress at GitLab](https://gitlab.com/gitlab-org/gitlab/issues/196240)** - Move "Designs" to its own space on the left side menu above Issues. Here we'll see all design updates in real time and map design images to issues in a more seamless and connected flow. Also to consider here would be to allow designs posted without an issue to encourage rapid feedback and turn around on ideas. + +**Next: [Developer Handoff in Review Apps](https://gitlab.com/groups/gitlab-org/-/epics/2406)** - Upgrade the existing Visual Review feature to have original Epic or Issue Designs move forward in the GitLab workflow for visual inspection in the merge request. The Product Designer would be notified and invited to also inspect which would cut down on a lot of back and forth communication that currently happens offline. Empower the Engineer and the Product Designer to compare the original design with live app. Allow them to give visual feedback by attaching comments to dom elements or on an x,y access. For example: Move a transparent overlay of the original design around to ensure check measurements and other visual aspects. + +**Later: [Design reviews and approvals](https://gitlab.com/groups/gitlab-org/-/epics/990)** - Once we have more usage of our designs throughout the DevOps flow, add approvals or other checks and balances that may be needed to lock down a design. The first step is to understand how current review and approval processes work outside of GitLab and how we could adapt those to GitLab. + +**Later: [Design Management prototyping support](https://gitlab.com/groups/gitlab-org/-/epics/1728)** - currently Design Management only supports static images which are a valuable part of the design process, but may not be able to fully communicate the user experience. Part of enabling communication around that process is to allowing users to create simple click-through prototypes for designs. + +**Later: [Adding drawing and diagram files to the Design Tab](https://gitlab.com/gitlab-org/gitlab/issues/199694)** - Allow the creation of a diagram or drawing directly inside the browser via an integration. We'll investigate the right ways to "open up the drawing board" to anyone working on an Issue. + +**Later: [Git backup of design files](https://gitlab.com/gitlab-org/gitlab/issues/200088)** - When teams share source files such as the Pajamas Sketch file there is a lot of overhead with checkign that file in and out of a repo and having a design team share the file. We also would consider LFS (Large file system) and design agencies who may have huge repositories and would only be able to check out just a part of the entire repo for use. + +## Future considerations + +**Live Sketching in Issues** Allow users to draw freehand on a digital whiteboard and see the real time cursor and sketching of other users who are live with them. We think this will enable more "off-the-cuff" brainstorming and foster an in-person experience with colleagues, even if working remote. + +**Later: Deep linking of assets** - Imagine seeing an image asset in your repo or within a wiki and being able to click a button to pull down its original artwork from Sketch/Photoshop or beyond. If we achieve git backup of design files, we should be able to create deep links to their source artboards. + +**Future: AI to compare Designs to Production** With the emergence of AI technologies, eventually Design AI could be a part of the CI pipeline to scan for visual changes against the original design, report differences, and recommend changes. + + + +## Competitive Landscape + + +Within the Design Tools market, each product broadly solves one or more of these problems: + +- Approvals and lock down of designs +- Generate developer specifications (Developer handoff) +- Version control +- Visual communication via comments +- UX Research and UI Testing +- Designing and prototyping +- Design System creation and management + +The most full featured Design Tools, that are attempting to solve all these problems are: + +- [Invision Studio](https://www.invisionapp.com/studio) +- [Figma](https://figma.com) +- [UX Pin](https://www.uxpin.com/) + +What is missed in the current market: + +- "Production Design Inspect": Visual inspection of frontend code against the original designs on the issue or original prototype with a focus on the fidelity review of the code a developer actually implemented vs. the design they meant to implement +- Tracking and conversion of local design elements to their live Design System counterpart in the repo + +Given GitLab's unique strength as the single source of truth for planning and source code, we are well positioned to work with Product Design teams and encourage Product Designers to participate from design iteration through to production: + +- Review and collaboration, bringing designers deeper into the tool that they already use to understand what needs to be designed and built, and integrating the design workflow into the planning and development workflow. +- Version control for source code is a core competency of GitLab, with great support for LFS and upcoming native support for large files in Git. Building on this to support versioning of designs and automation with CI is a natural fit. + +## Market Research + + +A [competitive analysis](https://docs.google.com/document/d/12o6h6Fm7bAjhW5AK1r-PNhvn0QrQwZncorYNia12e3Q/edit) was also conducted to further understand existing players in the market. + +## Business Opportunity + + +### Estimating our TAM for Design Management + +We've learned that a typical designer:developer ratio is [1:8](https://techcrunch.com/2017/05/31/here-are-some-reasons-behind-techs-design-shortage/) (at GitLab, our ratio is 1:7). + +Also, we know there are [24M developers worldwide](https://www.statista.com/statistics/627312/worldwide-developer-population/). + +24M / 8 = 3M designers worldwide + +If we achieved signing up all of these designers for GitLab, our TAM would be $144M on Starter/Bronze, $684M on Premium/Silver, and $3.6B on Ultimate/Gold. + +### Growth of other tools + +There is a significant opportunity for an application that can successfully engage developers and design teams before and during the DevOps lifecycle. If GitLab integrates with the major design tools such as InVision (5,000,000 users), Sketch (1,000,000 users,) and Figma (1,000,000 users) and adds value in the form of visual developer handoffs, we believe product quality will increase. + + + +## Analyst Landscape + + +In the past month, we've had briefings with Redmonk, Forrester and Gartner. We've validated that we are solving a big problem with our proposal to bring Designers into Devops. + +We learned that a new potential term for this type of software is: "Digital product design platforms" and we are also considering the term "DesignOps" which might play well with DevOps at GitLab. + +## Top Customer Success/Sales issue(s) + + +No customer issues yet, because the feature is so new + +## Top user issue(s) + + +* [Design Activity should be supported on Project, Group and User Activity Pages](https://gitlab.com/gitlab-org/gitlab/-/issues/33051) - 9 +* [Adoption: GitLab <> Figma plugin prototype MVC](https://gitlab.com/gitlab-org/gitlab/-/issues/207433) - 7 +* [Rethinking information architecture of Design Management](https://gitlab.com/gitlab-org/gitlab/-/issues/204743) - 5 +* [Design Comment: Edit Comment text](https://gitlab.com/gitlab-org/gitlab/-/issues/118609) - 5 + +## Top internal customer issue(s) + + +* [Internal dogfooding epic](https://gitlab.com/groups/gitlab-org/-/epics/2582) - this gets us through the major pain points that our internal GitLab team has surfaced +* [Versioned designs and point of interest discussions](https://gitlab.com/groups/gitlab-org/-/epics/660) - the MVC addresses the most frequent frustrations with the current workflow which involves uploading images in a markdown table. + +## Top Vision Item(s) + + +* [Design process automation](https://gitlab.com/groups/gitlab-org/-/epics/991) - version control the source files in a git repo, and push to update the designs attached to issues. +* [Design Management prototyping support](https://gitlab.com/groups/gitlab-org/-/epics/1728) - static designs don't fully communicate the user experience; adding support for prototypes can further expand collaboration +* [Design reviews and approvals](https://gitlab.com/groups/gitlab-org/-/epics/990) - like merge requests, designs need reviews and approvals before being approved to proceed. diff --git a/source/direction/create/design_system/index.html.md b/source/direction/create/design_system/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..19a918799625010bd59e3f0af786e6ed78718ded --- /dev/null +++ b/source/direction/create/design_system/index.html.md @@ -0,0 +1,140 @@ +--- +layout: markdown_page +title: "Category Direction - Design System" +description: "Design Systems at GitLab compliments Design Management by adding the ability to manage, document and version your design system." +canonical_path: "/direction/create/design_system/" +--- + +- TOC + {:toc} + +## Design System + +| | | +| --- | --- | +| Stage | [Create](/direction/create/) | +| Maturity | [Planned](/direction/maturity/) | +| Content Last Reviewed | `2020-07-24` | + +## Introduction + + + +The category of *Design System at GitLab* compliments *[Design Management](https://about.gitlab.com/direction/create/design_management/)* category by adding the ability to manage, document and version your design system. + + +Please reach out to PM Christen Dybenko ([E-Mail](mailto:cdybenko@gitlab.com)) if you'd like to provide feedback or ask questions about what's coming. + +## What is a Design System? + +A Design System is a living, breathing repository that sets the look and feel of a production web app. Quite often they incorporate variables and generate production `.css` from [LESS](http://lesscss.org/) or [SASS](https://sass-lang.com/). + +The simplest way to implement a Design System is to start with an open-source library (containing HTML, CSS, and JS) like [Bootstrap](https://getbootstrap.com/) or [Material UI](https://material-ui.com/). From there you can easily include these libraries in your repository and modify the variables to set colors, spacing, and brand-specific look and feel of the styles. + +However, since it's hard to preview your changes to these libraries, most companies require a more robust system that lets them view their changes in a separate repository from the production app. This reduces the risk of putting something live that doesn't work and increases code re-use. + +At GitLab, our Design System static site called [Pajamas](https://design.gitlab.com/) and our components are edited (via code) in [Storybook](https://storybook.js.org/) in the [GitLabUI repo](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/*). + +The best Design Systems allow the creation of components in their smallest format - for example, a button (atom) or a more complex layout like a table header (molecule). Code is re-used between atoms, molecules, organisms, templates, and pages for consistency. + +It's also important that the design process for creating these new components in a design tool like Figma are connect to their live counterparts in the repository. + + +## Long Term Strategy + +`TBD` + +## Target Audience and Experience + + +The Design System category is targeted at [product designers](/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) and [software developers](/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) who are both primary contributors and consumers. The belief that design systems are just for designers is a main hurdle that teams have to get over. Design systems are not fully adopted when this is the belief. Organizations have to understand that a design system improves the efficiency of their development teams while also improving the overall user experience in order for teams to invest. GitLab can help shape this story + +These two personas may interact with [product managers](/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) or [software engineers in test](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) to get these components ready for the actual app. + +The **minimal** user journey will provide designers with the ability to: `TBD` + + +## What's Next & Why + + +* Consider why this wouldn't just be a feature of Design Management as a category +* Evaluate the feature set of [zeroheight.com](https://www.zeroheight.com/) and [Invision DSM (Design System Management)](https://www.invisionapp.com/design-system-manager) + +## Future considerations + +`TBD` + + + +## Competitive Landscape + + + +- [Zeroheight](https://www.zeroheight.com/) +- [Invision DSM (Design System Management)](https://www.invisionapp.com/design-system-manager) +- [Storybook](https://storybook.js.org/) and [Chromatic](https://www.chromatic.com/) + + +What is missed in the current market: + +- Linking components to their repo counterparts + + + +## Market Research + + + +Forrester now reports that [50% of companies are using some form of a Design System](https://www.forrester.com/report/Digital+CX+And+Design+Trends+2020/-/E-RES160056). + +A [competitive analysis](https://docs.google.com/document/d/1_OpUpozFjMdRPMM7Wd6R9SPJO2PGOuyKCCW-miGDkEE/edit#) *is in progress to define players in the design system market*. + +## Business Opportunity + + +Expert from [Design Management Direction](https://about.gitlab.com/direction/create/design_management/#business-opportunity) +> The total market potential of Design Tools is over US $4 billion and growing. There is a significant opportunity for an application that can successfully engage developers and design teams before and during the DevOps lifecycle. If GitLab integrates with the major design tools such as InVision (5,000,000 users), Sketch (1,000,000 users,) and Figma (1,000,000 users) and adds value in the form of visual developer handoffs, we believe product quality will increase. + + +## Analyst Landscape + + +`TBD` + +## Top Customer Success/Sales issue(s) + + +No customer issues yet, because the feature is so new + +## Top user issue(s) + + +`TBD` + +## Top internal customer issue(s) + + +`TBD` + +## Top Vision Item(s) + + +`TBD` diff --git a/source/direction/create/ecosystem/api/index.html.md b/source/direction/create/ecosystem/api/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..72aeb064020bc32fbb4f64d89730870432bf9273 --- /dev/null +++ b/source/direction/create/ecosystem/api/index.html.md @@ -0,0 +1,141 @@ +--- +layout: markdown_page +title: "Category Direction - API" +--- + +- TOC + {:toc} + +| ------ | ------ | +| **Stage** | [Create](/direction/dev/#create-1) | +| **Maturity** | [Viable](/handbook/product/categories/maturity/) | +| **Last reviewed** | 2020-07-28 | + +- [Issue List](https://gitlab.com/gitlab-org/gitlab/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem&label_name[]=Category%3AAPIs%2FSDKs) +- [Overall Ecosystem Direction](/direction/create/ecosystem/) + +_This direction is a work in progress, and [everyone can contribute](#contributing):_ + +* Please comment, thumbs-up (or down!), and contribute to the linked issues and + epics on this category page. Sharing your feedback directly on GitLab.com is + the best way to contribute to our vision. +* Direct feedback can be shared via [email](mailto:pdeuley@gitlab.com), + [Twitter](https://twitter.com/gitlab) or on a video call. +* _If you're a GitLab user or developer and have direct feedback about our API, we'd love to hear from you._ + +## 概要 + +GitLab's **API** category provides all the tools and resources for +developers to integrate externally with GitLab as a platform. Our [Integrations category](/direction/create/ecosystem/integrations/) +supports key integrations directly inside the GitLab codebase. + +Currently, a REST and GraphQL API are available for developers to use to +integrate with GitLab. You can learn more about our APIs in [our developer documentation](https://docs.gitlab.com/ee/api/). + +Beyond accessing these endpoints directly, [API Clients](/partners/#api-clients) +and [CLI Clients](/partners/#cli-clients) that have been created by our community +are availalbe for a variety of platforms and languages. + +## Direction + +As the GitLab community grows and increasingly relies on GitLab as a central +part of their toolchain, it is critical that we provide support for integrating +our product with a wider variety of systems. These integrations could be with +project management systems, ERPs, custom dashboards and reporting systems, or +any other type of custom-built tool. + +To serve these needs, the [Groups and Categories](/handbook/product/categories/) +across GitLab contribute to our APIs with functionality for each of their +individual sets of functionality. Because of this distributed nature, the +`API` category is responsible for guiding the path of this development on +a holistic level. + +Over the next year, we will work with key stakeholders to refine guidelines and +best practices that will inform how these teams are designing and building their +APIs and how they will ensure that these resources remain performant for +consumers. Additionally, this team will act as a centralized resource, helping +to triage critical problems with our APIs as the need arises. + +## Future Vision + +By providing powerful and flexible development resources, we allow creators to +consume GitLab _as a platform_—giving them the freedom to create anything +they may need. [Penflip](https://www.penflip.com/) is a great example of a novel +product that was built upon GitLab that uses the core GitLab functionality to +produce a whole new experience. These developers took GitLab's core functionality +and reimagined it for a wholly different purpose and a totally different type of user. + +Making room for this sort of innovation and creativity will let us grow our +community and impact in novel ways, and the more we expand the resources we +provide, the more of this impact we will see. Over time, we would like to expand +our developer tooling to allow more of this type of creativity and build a +framework that allows us to better serve the broader variety of creative work, +driving us closer to our [Big Hairy Audacious Goal](/company/strategy/#big-hairy-audacious-goal). + +## Maturity + +Today, we consider our **API** to be [Viable](/direction/maturity/). Below is +how we think about how we'll grow that maturity level over time: + +* **Viable** APIs give developers access to the majority of core GitLab + functionality and offer basic documentation covering the usage of the API. + _(Where we are today)_ +* **Complete** APIs give developers access to almost all GitLab functionality + through direct API access, supported by robust documentation that covers + the usage of the API, best practices, and offers examples and sample code to + try yourself. +* **Lovable** APIs give developers access to almost all GitLab functionality + through direct API access, supported by robust documentation that covers + the usage of the API, best practices, and offers examples and sample code to + try yourself. Additionally, these resources are supplemented by well-supported + client libraries, CLI tools that make jumping in and developing simple. + +_[Learn more about how GitLab thinks about Maturity here.](/direction/maturity/)_ + +## What's next and why + +Based on these goals, our current priorities are: + +* **[Create a GitLab Developer Portal](https://gitlab.com/gitlab-org/gitlab/issues/34256)** + to make it easier for developers to find the resources that are currently available. +* **Refine our API guidelines and best practices** + to ensure a more consisently great experience across our APIs, and make it + clearer to our contributors what they need to be building, and why. +* **[Establish telemetry for our API and SDK](https://gitlab.com/gitlab-org/gitlab/issues/34095)** + to allow us to better understand how these resources are being used, and give + us insight to which areas need improvement or expansion. + +## What we're not doing + +### Building "all" of GitLab's APIs + +Each [Group](/handbook/product/categories/) is ultimately responsible for +building and maintaining their own APIs. Ecosystem's role is to be a source of +guidance and governance across them as a whole. + +### Creating new API client libraries + +There are currently [many client libraries](/partners/#api-clients) that were +created and are maintained by our community. We don't currently have any +plans on creating our own libraries, but are happy to support the efforts +of those contributors and community members. + +## Contributing + +At GitLab, one of our values is that everyone can contribute. If you're looking +to contribute to our API or otherwise get involved with features in the +Ecosystem area, [you can find open issues here](https://gitlab.com/gitlab-org/gitlab/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem&label_name[]=Category%3AAPIs%2FSDKs). + +Feel free to reach out to the team directly if you need guidance or want +feedback on your work by pinging [@deuley](https://gitlab.com/deuley) or +[@gitlab-ecosystem-team](https://gitlab.com/gitlab-org/ecosystem-team) on your +open MR. + +You can read more about our general contribution guidelines [here](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md). + +## Feedback & Requests + +If there's an integration that you'd like to see GitLab offer, or if you have +feedback about an existing integration: please [submit an issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue%5Btitle%5D=New%20GitLab%20Integration%20with) with the label +`~Category:Integrations`, or contact [Patrick Deuley](mailto:pdeuley@gitlab.com), +Sr. Product Manager, Ecosystem. diff --git a/source/direction/create/ecosystem/frontend-ux-foundations/index.html.md b/source/direction/create/ecosystem/frontend-ux-foundations/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..388d017bcaf718c0ae1520aacbaaebf2ebd5721d --- /dev/null +++ b/source/direction/create/ecosystem/frontend-ux-foundations/index.html.md @@ -0,0 +1,116 @@ +--- +layout: markdown_page +title: "Category Direction - Frontend & UX Foundations" +--- + +- TOC + {:toc} + +| ------ | ------ | +| **Stage** | [Create](/direction/dev) | +| **Maturity** | [Viable](/handbook/product/categories/maturity/) | +| **Last reviewed** | 2020-07-28 | + +- [GitLab UI Project](https://gitlab.com/gitlab-org/gitlab-ui/) +- [Pajamas Project](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com) +- [Issue list](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem&label_name[]=Category%3AFE%2FUX%20Foundations) +- [Epic list](https://gitlab.com/groups/gitlab-org/-/epics?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Category%3AFE%2FUX%20Foundations) +- [Overall direction](/direction/create/ecosystem/) + +_This direction is constantly evolving, and [everyone can contribute](#contributing):_ + +* Please comment, thumbs-up (or down!), and contribute to the linked issues and + epics on this category page. Sharing your feedback directly on GitLab.com is + the best way to contribute to our vision. +* Please share feedback directly via [email](mailto:pdeuley@gitlab.com), + [Twitter](https://twitter.com/gitlab) or on a video call. If you’re a GitLab + UI or Pajamas user and have direct knowledge of your needs, we’d especially + love to hear from you. + +## 概要 + +The Frontend & UX Foundations team is responsible for leading the direction of the experience design, visual style, and technical tooling of the GitLab product. This category encompasses two broad areas of focus: + +1. Tooling-focused enhancements +1. User-focused enhancements + +Tooling-focused enhancements include: + +* Improving webpack and optimizing frontend assets. +* Improving the debugging experience, linters, and documentation with an emphasis on performance. +* Shepherding migrations away from deprecated technologies. +* Reducing technical debt. +* Addressing [Progressive Web Application](https://developers.google.com/web/progressive-web-apps) needs. + +User-focused enhancements include: + +* Building a cohesive and consistent user experience, visually and functionally. +* Providing comprehensive usage guidelines, reusable components, content standards, and usability documentation. +* Building in [accessibility](https://www.w3.org/WAI/). +* Reducing user experience and design debt. + +Both of these areas lead to a greater user and contributor experience while also increasing operational efficiencies. Our goal with the foundations team is to treat the underlying foundation of GitLab as a first-class internal product which supports product designers, engineers, and product managers to more efficiently perform their roles. + +## Direction + +As the GitLab product expands to include offerings for the entire DevOps lifecycle, it is critical to provide support for building a cohesive product that has the ability to replace disparate DevOps toolchains. + +To serve these needs, we will work with the [Groups and Categories](/handbook/product/categories/) +across GitLab to contribute to our design system, [Pajamas](https://design.gitlab.com/), while also continuing to define guidelines and best practices that will inform how these teams are designing and building products. Additionally, this team will act as a centralized resource, helping to triage large scale technical and experience problems as the need arises. + +## Target audience + +Foundations is focused on supporting internal users and product teams, with a focus on four cross-functional counterparts: Product Designers, Technical Writers, Engineers, and Product Managers. + + + +We also aim to improve the community contributor experience by streamlining the process of writing consistent code that conforms to set practices. + + + +## What’s in progress, next, and later + +### In progress + +* [Creating, building, and styling foundation components](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/boards/1261225?&label_name[]=OKR). We identified 36 foundational components that are central to building and maintaining features at GitLab. In order to streamline the process of implementing components, we’ve defined four stages of a component lifecycle: Create, Build, Style, and Integrate. This first effort is aimed at completing the first three stages (create, build, and style) of the 36 foundational components. This will allow designers and engineers to have a robust system to draw from when designing and building GitLab products. +* [Moving our Pajamas UI Kit from Sketch to Figma](https://gitlab.com/gitlab-org/gitlab-design/-/boards/1511008?&label_name[]=Figma). The move to Figma allows for greater collaboration, as well as community contributions. Currently, Sketch is only available on Mac platforms and there is no real-time collaboration features. Figma will allow us to provide a UI Kit that is available across platforms, while being available for community contributors to utilize for free. It will also promote collaboration through its use of real-time editing capabilities and version history. We will also be able to streamline developer handoff by simply linking to the design file, reducing the need for additional plugins such as Sketch Measure. +* [Updating our color palette](https://gitlab.com/groups/gitlab-org/-/epics/2964) to address color contrast for accessibility, and to normalize the palette across hues so that we can better systematize variable use throughout the UI. + +### Next + +* Creating a comprehensive action plan for integrating components into the GitLab product. +* Auditing and updating our existing VPAT. +* Building comprehensive accessibility standards into our workflows. +* Deprecating FontAwesome icons in favor of our own [SVG library](http://gitlab-org.gitlab.io/gitlab-svgs/). + +### Later +* [Updating our (Beta!) dark mode](https://gitlab.com/groups/gitlab-org/-/epics/2902), improving accessibility, audit/testing, and completeness. + +### What we’re not doing + +**Building and integrating all components across GitLab.** The scope of this category is to provide guidance and governance for our design system and related tooling, and is staffed with dedicated UX designers to support that. However, _creating_ those components and implementing them throughtout the application is a massive lift that requires participation from every [Group and Category](/handbook/product/categories/). While FE/UX Foundations has _some_ Frontend Engineering capacity, it can’t be responsible for creating and implementing everything. + +## Maturity plan +Today, we consider our **FE/UX Foundations** to be [Viable](/handbook/product/categories/maturity/). Below is how we think we’ll grow that maturity level over time: + +* **Viable:** A centralized system exists for product teams to contribute cohesive and consistent assets that aid in building the GitLab product. Documentation is in place to help offer guidance. Some reusable components exist and adhere to usage guidelines. Accessibility standards are followed in some cases. _(Where we are today)_ +* **Complete:** A centralized system exists for product teams to contribute cohesive and consistent assets that aid in building the GitLab product. Documentation is in place to help offer guidance and these docs are consistently disseminated, enabling product teams to make autonomous decisions about component usage. Almost all reusable components exist, adhere to usage guidelines, and are referenced as the single source of truth. Some components are fully integrated into the GitLab product. Accessibility standards are followed in most cases. +* **Lovable:** A centralized system exists for product teams to contribute cohesive and consistent assets that aid in building the GitLab product. Documentation is in place to help offer guidance and these docs are consistently disseminated, enabling product teams to make autonomous decisions about component usage. Almost all reusable components exist, adhere to usage guidelines, and are referenced as the single source of truth. Almost all components are fully integrated into the GitLab product. Accessibility standards are followed in almost all cases. + + \ No newline at end of file diff --git a/source/direction/create/ecosystem/gdk/index.html.md b/source/direction/create/ecosystem/gdk/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..f80d0fc4dfac9d5d443b0f4e21d05a74ac65b644 --- /dev/null +++ b/source/direction/create/ecosystem/gdk/index.html.md @@ -0,0 +1,149 @@ +--- +layout: markdown_page +title: "Category Direction - GDK" +--- + +- TOC + {:toc} + +| ------ | ------ | +| **Stage** | [Create](/direction/create) | +| **Maturity** | [Viable](/handbook/product/categories/maturity/) | +| **Last reviewed** | 2020-07-28 | + +- [GDK Project](https://gitlab.com/gitlab-org/gitlab-development-kit) +- [Issue List](https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues) +- [Epic List](https://gitlab.com/groups/gitlab-org/-/epics?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Category%3AGDK) +- [Overall Direction](/direction/create/ecosystem/) + +_This direction is constantly evolving, and [everyone can contribute](#contributing):_ + +* Please comment, thumbs-up (or down!), and contribute to the linked issues and + epics on this category page. Sharing your feedback directly on GitLab.com is + the best way to contribute to our vision. +* Please share feedback directly via [email](mailto:contributors@gitlab.com), + [Twitter](https://twitter.com/gitlab). There's also a [Gitter contributor channel](https://gitter.im/gitlabhq/contributors) you can give us feedback and ask questions in. +* If you're a GDK user, we'd always love to hear from you! + +### 概要 + +The GDK team is responsible for the GitLab Development Kit (GDK). The GDK +provides a self-contained GitLab environment, which can be run locally or in a +virtual machine. It's useful for developers contributing to the [GitLab project](https://gitlab.com/gitlab-org/gitlab), +or anyone needing to test, experiment with, or validate GitLab functionality. + +This category is responsible for improving the usability and reliability of the +the [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit). +The GDK is essential for locally developing and testing changes. +It is used by nearly all of the product development organization at GitLab as +well as our community of contributors and partners. + +It is therefore critical to optimize this experience for two reasons: +productivity gains made through tool enhancements have compounding returns, +and it makes it easier to get started contributing. + +In the longer term, the vision is for the GDK to be a simple, reliable, and +flexible tool that allows everyone to contribute. Developers should be able to +keep their local development environment up-to-date painlessly, designers +should be able to quickly check out a branch and validate a feature they +designed, and everyone using the GDK should be running few commands to achieve +this, and experience a highly-performant local installation when they do so. + +#### Target audience + +The GDK serves as a simple way to set up a local development environment for +working on GitLab. With that in mind, the target audience for the GDK is +_anyone who is contributing to the GitLab project_. This includes: + +* **Software engineers** directly writing code +* **Software engineers in test** who are testing that code +* **Product designers** verifying designs are implemented correctly +* **UX researchers** demonstrating functionality to users for research purposes +* **Product managers and engineering managers** performing acceptance testing + before code is merged to master +* **All of the above**, whether they are working for GitLab or are part of + our broader community of contributors. + +GitLab is an [Open Core](https://en.wikipedia.org/wiki/Open-core_model) product, +and our community is central to the continued success of our mission. This +means that tools that allow anyone to jump in and contribute are vital to +keeping that momentum going. + +### Future Vision + +We want to build towards a state in which any GitLab contributor can easily install and use the GDK +with minimal effort. By "lowering the bar" to getting started, we allow our contributors to focus +on designing and building our next great feature. + +We're iterating toward a version of the GDK that can install in a single command, updates itself +painlessly, and allows contributors to check out a feature branch with minimal effort. + +#### Challenges to address + +**Getting started with the GDK** is straightforward for GitLab employees because +of the tribal knowledge and in-company training we do. We need to move that +knowledge in to the documentation and the handbook to make it just as easy for +anyone in the community to get ramped up. + +**Examining a specific branch** is a central workflow for many of our personas. +These users would benefit greatly from a minimal-fuss, no-configuration way to +switch to a specific branch to verify various aspects of the application with +high velocity. + +**Making GDK updates a smooth experience** is a high-priority issue, as there +are a large number of reports of breaks happening when upgrading. This makes it +painful to upgrade and smoothly continue working, or (even worse) discourages +developers from upgrading in a timely manner. + +**Getting help with the GDK** isn't so bad for GitLab Team Members, since they +can just join the **#gdk** (internal) Slack channel. This +approach is not suitable for community members, and we need a better solution +that works well for everyone (so that everyone can contribute.) + +#### What's Next & Why + +[Adding `gdk checkout ` for reviewing specific branches](https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/139) +to make it simpler for users to check out a specific feature branch quickly and +easily. Currently the process is fragile and poorly documented and introducing +a simple, reliable command will make it easier for all involved. + +[Update the GDK Documentation](https://gitlab.com/groups/gitlab-org/-/epics/3218) +to increase clarity particularly for new contributors. This will include +reorganizing content to make it more discoverable and scannable, improving our +_"Preparing your computer"_ recommendations, and updating the documentation +for the latest requirements and prerequisites. + +[Introduce `gdk pristine` command](https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/843) +to allow contributors a way to get a potentially broken GDK back to a working +state in a low-touch way. + +[Allow some services to be run under Docker](https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/867) - +Convert "data-oriented" services to have the option of being run natively or via +Docker to reduce the complexity of installing/upgrading indivdual services. + +[Include 'stale process' detection as part of `gdk doctor`](https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/856). +This has bitten us a few times recently with some existing services that were re-engineered. It would have been really +helpful for `gdk doctor` to detect and suggest solutions when it detects +potential conflicts with old services that were left running after an update. + +#### What is Not Planned Right Now + +**Working on the GitLab Compose Kit (GCK).** The [GCK project](https://gitlab.com/gitlab-org/gitlab-compose-kit) +is also building local development environment tooling, however with an aim of +allowing users to spin up a container-based environment that only runs the bare +minimum of services required to maximize performance and ease of use. Whatever +the future may hold, the current standard for our developers is the _GDK_, which +is where the focus of this category will remain for the time being. + +We should investigate integrating/combining these two projects, but there are a few requirements (such as [allowing some services to be run under Docker](https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/867)) that must be completed before we can even test this out. We're keeping these requirements in mind during planning, and are hoping to revisit this soon. + +### Why is this important? + +The GDK is key to our [GitLab's Strategy](https://about.gitlab.com/company/strategy/#how) +as it is the entrypoint to contribution to the GitLab project itself. Without +the GDK, many contributors would have to learn the specifics of every required +service that a local environment must run to function, the commands required to +run each of those services, and the order they must be stood up in to function +properly. They'd have to run these commands manually, or more likely, write some +tooling that automates the process for them... which after significant amounts +of time and effort were put in to those scripts, they'd look a lot like the GDK. diff --git a/source/direction/create/ecosystem/index.html.md b/source/direction/create/ecosystem/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..37b3478ad398db93091948887ab61b22b170d63a --- /dev/null +++ b/source/direction/create/ecosystem/index.html.md @@ -0,0 +1,157 @@ +--- +layout: markdown_page +title: "Group Direction - Ecosystem" +--- + +- TOC + {:toc} + +| ------ | ------ | +| **Stage** | [Create](/direction/dev/#create-1) | +| **Last reviewed** | 2020-07-28 | + +- [Issue List](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem) + +## 概要 + +Ecosystem's mission is to foster both GitLab as a platform as well as its community. +Ecosystem supports our **Integrations** with other products, our **APIs** for +connecting GitLab to external products and services, and our **GDK** and +**Frontend Foundations** that enable our community of contributors to +to develop the application itself. + +Our goal is to make integrating with, extending the functionality of, or +developing GitLab itself an easy, delightful experience. As with all things +GitLab, we strongly believe that [Everyone can contribute](#contributing), and +Ecosystem supports that mission directly through its work. + +## Categories + +### Integrations + +Integrations are places GitLab connects to features and services from other products, +_directly from the GitLab codebase_. These integrations +range from things like lightweight [Slack notifications](https://docs.gitlab.com/ee/user/project/integrations/slack.html) +for projects, to complex integrations with [Atlassian Jira](https://docs.gitlab.com/ee/user/project/integrations/jira.html). + +Today, there are several ways to integrate into GitLab—by adding your +integration to the [GitLab codebase](https://gitlab.com/gitlab-org/gitlab), by consuming our [public APIs](https://docs.gitlab.com/ee/api/), or by +using a community library to connect your code to GitLab. Many products, +tools, and services that have already integrated with GitLab can be found on +our [partner integration page](https://about.gitlab.com/partners/integrate/). + +Integrations will focus primarily on adding new integrations that are +_key to the needs of our enterprise customers_ and providing guidance for 3rd parties that are +contributing integrations for their own products. + +[Category Direction](/direction/create/ecosystem/integrations/) · +[Documentation](https://docs.gitlab.com/ee/integration/) · +[Epic](https://gitlab.com/groups/gitlab-org/-/epics/1515) · +[Open Issues](https://gitlab.com/gitlab-org/gitlab/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem&label_name[]=Category%3AIntegrations) + +### API + +The GitLab APIs enable_external products and services to access GitLab data and functionality. + +The GitLab API **category** provides guidance and governance for all the +Groups inside of GitLab that are creating and maintaining our REST and GraphQL +APIs. The goal of this effort is to define best practices and requirements +for the development of our APIs to create a consistently great experience for +those integrating with GitLab as a platform. + +[Category Direction](/direction/create/ecosystem/api/) · +[Documentation](https://docs.gitlab.com/ee/api/) · +[Epic](https://gitlab.com/groups/gitlab-org/-/epics/2040) · +[Open Issues](https://gitlab.com/gitlab-org/gitlab/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem&label_name[]=Category%3AAPIs%2FSDKs) + +### GDK + +The GitLab Development Kit (GDK) is a tool for developers contributing +to GitLab. It provides a simple way to install, configure, and run a local +development environment. This tool is key to the success of our contributor +community—both internal GitLab Team Members and the broader community of +contributors. + +[Category Direction](/direction/create/ecosystem/gdk) · +[Project Home](https://gitlab.com/gitlab-org/gitlab-development-kit/) · +[Setup Documentation](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/set-up-gdk.md) · +[Open Issues](https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues) + +### FE/UX Foundations + +The work of Frontend and UX Foundations centers around resources and tools that +allow Frontend Engineers and Product Designers to design and implement the UI of +GitLab more effectively. This includes the [Pajamas Design System](https://design.gitlab.com/), +and frontend tooling such as our webpack implementation. The goal of these +efforts are to make developing the GitLab UI straightforward, performant, +and maintainable. + +[Category Direction](/direction/create/ecosystem/frontend-ux-foundations) · +[Pajamas Documentation](https://design.gitlab.com/) + +## Ecosystem Themes + +### Freedom of choice + +We firmly believe that a [single application](https://about.gitlab.com/handbook/product/single-application/) +can successfully serve all the needs of the entire DevOps lifecycle. However, we there are a myriad +of reasons that many customers can't adopt GitLab in this way. + +Customers may have specific tools they are committed to using due to factors like: + +1. The cost of migrating off of it, either based on the volume of content to + migrate, the risk of errors during the migration, the cost of training, etc. +1. The cost of building _new integrations_ with other tools in their existing toolchain +1. Specific regulatory, security, or compliance needs they must be able to meet +1. Niche or unique functionality that isn't available in GitLab + +Because of these realities, we believe that our customers should have the +**freedom to choose their tools**, and use what makes the most sense for their +business—and we will support that freedom as best we can by [playing well with others](https://about.gitlab.com/handbook/product/gitlab-the-product/#plays-well-with-others). + +### Flexibility and Extensibility + +We'll never anticipate every possible use-case, nor can we afford to support the +development of every possible integration. So to that end, our aim is to create +flexible and extensible tools so that those integrating with us can create whatever they need. + +## Further Reading + +### Problem/Solution Validation + +We work hard to understand the space we operate in, and to better understand our +customers and the problems we're solving for them, we conduct [Validation exercises](https://about.gitlab.com/handbook/product-development-flow/#validation-track). + +* [ServiceNow Problem Validation](https://gitlab.com/gitlab-org/ux-research/-/issues/518) +* [Solution Validation: Mass Integrations](https://gitlab.com/gitlab-org/ux-research/-/issues/789) +* [Integration Settings Prototype Testing](https://gitlab.com/gitlab-org/ux-research/-/issues/601) +* [Understanding our developer experience](https://gitlab.com/gitlab-org/ux-research/-/issues/511) +* [Understanding group-level integration with Jira](https://gitlab.com/gitlab-org/ux-research/-/issues/393) + +## Contributing + +At GitLab, one of our values is that everyone can contribute. If you're looking +to contribute your own integration or otherwise get involved with features in +the Ecosystem area, [you can find open issues here](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem). + +Feel free to reach out to the team directly if you need guidance or want +feedback on your work by pinging [@deuley](https://gitlab.com/deuley) or +[@gitlab-ecosystem-team](https://gitlab.com/gitlab-org/ecosystem-team) on your +open MR. + +You can read more about our general contribution guidelines [here](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md). + +## Influences + +We're inspired by other companies with rich, developer-friendly experiences like +[Salesforce](https://developer.salesforce.com/), +[Shopify](https://help.shopify.com/en/api/getting-started), +[Twilio](https://www.twilio.com/docs/), +[Stripe](https://stripe.com/docs/development), +and [GitHub](https://developer.github.com/). + +A large part of the success of these companies comes from their enthusiasm +around enabling developers to integrate, extend, and interact with their +services in new and novel ways, creating a spirit of [collaboration](https://about.gitlab.com/handbook/values/#collaboration) +and [diversity](https://about.gitlab.com/handbook/values/#collaboration) that +simply can't exist any other way. diff --git a/source/direction/create/ecosystem/integrations/index.html.md b/source/direction/create/ecosystem/integrations/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..d8eb2735ebad9f45925f71d7274b324b262249ec --- /dev/null +++ b/source/direction/create/ecosystem/integrations/index.html.md @@ -0,0 +1,218 @@ +--- +layout: markdown_page +title: "Category Direction - Integrations" +--- + +- TOC + {:toc} + +| ------ | ------ | +| **Stage** | [Create](/direction/dev/#create-1) | +| **Maturity** | [Viable](/handbook/product/categories/maturity/) | +| **Last reviewed** | 2020-07-28 | + +- [Issue List](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem&label_name[]=Category%3AIntegrations) +- [Epic List](https://gitlab.com/groups/gitlab-org/-/epics/1515) +- [Overall Ecosystem Direction](/direction/create/ecosystem/) + +_This direction is a work in progress, and [everyone can contribute](#contributing):_ + +* Please comment, thumbs-up (or down!), and contribute to the linked issues and + epics on this category page. Sharing your feedback directly on GitLab.com is + the best way to contribute to our vision. +* Alternately, please share feedback directly via [email](mailto:pdeuley@gitlab.com) or + [Twitter](https://twitter.com/gitlab). If you're a GitLab user and have direct + knowledge of your need from a particular integration, we'd love to hear from you. + +## 概要 + +GitLab's vision is to be the best [single application for every part of the DevOps toolchain](/handbook/product/single-application/). +However, some customers use tools other than our included features, [and we respect those decisions](/handbook/product/gitlab-the-product/#plays-well-with-others). +Currently, GitLab offers [30+ Integrations](https://docs.gitlab.com/ee/user/project/integrations/overview.html) +that work with a variety of external systems. Integrations are important to +GitLab's success, and the **Integrations category** was established to develop and +maintain these integrations with key 3rd party systems and services. + +This category will primarily focus on creating new integrations that support the +needs of enterprise customers, as those customers often have hard integration-related +requirements that can fully prevent them from adopting GitLab. By supporting +these requirements, we unlock new parts of the market which are otherwise +wholly inaccessible. + +## Direction + +The **Integrations** direction is to support GitLab's efforts at making our +application _[Enterprise Ready](https://about.gitlab.com/direction/#1-year-plan)_ +by expanding and creating new high-impact integrations most in-demand by these +customers. + +Many enterprise organizations rely on systems like Jira, Jenkins, and +ServiceNow. It is often a _hard requirement_ to have a robust integration with +these services, and _not_ having that integration already can block adoption of +GitLab completely. + +By making these integrations powerful and useful, we make the lives of our +users better—even when they're using other products. This is what we mean +when we say that GitLab [plays well with others](/handbook/product/gitlab-the-product/#plays-well-with-others). + +Particularly for large organizations, existing tools and services +can be extremely difficult to migrate off of, even without any explicit vendor +lock-in. Moving _thousands of users_ or _hundreds of thousands_ of existing files +or objects off of one system to GitLab can incur more costs than might be +obvious at first. Internal tools may be tightly knit with the other internal +systems meaning numerous new integrations have to be developed just to keep +the business running. + +While GitLab has a robust API that supports integrating _almost anything you may need_, +it's a much more powerful experience to have a _native_ integration already +inside the application. + +## Maturity + +The Integrations category tracks [Maturity](/direction/maturity/) +on a per-integration basis. Each integration is evaluated based on the following +criteria: + +* A **Minimal** integration meets a single basic need for a small set of + customers, and may only push data one way from one system to the other without + surfacing much data or functionality directly in the UI. +* A **Viable** integration meets the core needs of most customers, and is robust + or configurable enough to meet all the needs of a some customers. +* A **Complete** integration meets the needs of the vast majority of usecases + for the majority of users, and the integration allows users to work painlessly + between the two products. +* A **Lovable** integration not only meets the needs of the vast majority of + users, but it makes the experience of using both products as productive and + easy as possible. This may mean things like special consideration taken to + intra-product navigation and how we surface notifications from the other + service, for example. + +## Current High-priority Integrations + +_You can view a list of all of our current integrations on our [Integrations page](https://docs.gitlab.com/ee/user/project/integrations/overview.html)_ + +| Integration | Maturity Level | ドキュメント | Epic/Issue | +| --- | --- | --- | --- | +| Atlassian Jira | Viable | [Documentation](https://docs.gitlab.com/ee/user/project/integrations/jira.html) | [Epic](https://gitlab.com/groups/gitlab-org/-/epics/1522) | +| Jenkins | Viable | [Documentation](https://docs.gitlab.com/ee/integration/jenkins.html) | [Epic](https://gitlab.com/groups/gitlab-org/-/epics/1757) | +| ServiceNow | Minimal | | [Epic](https://gitlab.com/groups/gitlab-org/-/epics/1712) | +| Rally | Planned | | [Issue](https://gitlab.com/gitlab-org/gitlab/issues/169) | +| Microsoft Teams | Minimal | | [Epic](https://gitlab.com/groups/gitlab-org/-/epics/880) | +| Jama | Under Consideration | | [Issue](https://gitlab.com/gitlab-org/gitlab/issues/16182) | + +## Prioritization + +We prioritize our Integrations work based on: + +* Reach (Customer demand) -- We want work on what the majority of our customers + need. We evaluate this based number of current users impacted, how much an + addition would increase our Total Addressable Market, and external market trends. +* Impact -- Integrations that are vital to an organizations processes and + workflow are also the ones most likely to be hard requirements for adoption. + It's unlikely that a simple notification integration would block adoption, + but not supporting Change Management tooling very much can. +* Effort (Integration complexity) -- The amount of work and time it would take + to complete that work absolutely factors in to priority. We have a limited + amount of time and resources, so we have to choose our work wisely. + +Based on the above scope and these priorities, we're currently only targeting a +limited set of products and services--specifically, those listed above and those +that are [scheduled on our backlog](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem&label_name[]=Category%3AIntegrations&milestone_title=Any). +All prioritized integrations have a target maturity of `Complete`, and will +take precedent over other integrations until they hit that maturity level. + +_For all other integrations, our team also supports our [API](/handbook/direction/create/ecosystem/api) +so that developers can build anything else they need._ + +## What's next and why + +Over the next year, Ecosystem will work on improving our integrations with +existing tools and create integrations for a number of new systems. Enterprise +systems that we are working on are: + +### Improving our Jira integration + +Jira is one of our most popular integrations, and a common thread we hear is that "developers want +to be able to stay in GitLab" and not have to go to Jira to view their work. We're kicking off an +MVC experiment to try to pull some minimal Jira functionality in to GitLab to try to address this +user concern. + +* [Allow federation of Atlassian users](https://gitlab.com/gitlab-org/gitlab/-/issues/220991) +* [Add Issue Detail view from Jira Issue List](https://gitlab.com/gitlab-org/gitlab/-/issues/220999) + +### Group and Instance level integration + +This is our current top priority. Many of the integrations that we support are +key to our customers workflows, which mean that they end up getting enabled on +a majority of the projects that that customer has active. Practically, this can +mean _thousands of individual projects_ have to be enabled individually. +This causes particular pain with even simple actions like rotating an access +token or changing a URL endpoint. When integrations are set on a per-project +basis, that one token rotation could mean thousands of individual updates that +someone has to go do. + +* [Mass-integration at a Group and Instance Level](https://gitlab.com/groups/gitlab-org/-/epics/2137) + +### Integrating Rally for Project Management + +Like Jira, there are many large enterprises using Rally for their project +management needs, and being able to connect where projects are being planned +directly to the code that is being written is core to the value that GitLab +provides. + +## What we're not doing + +### Building a "marketplace" + +GitLab does not utilize a plugin model for integrations with other common tools +and services, or provide a marketplace for them. As an [open core project](https://en.wikipedia.org/wiki/Open-core_model), +integrations can live directly inside the product. Learn more about our reasons +for this in our [Product Handbook](/handbook/product/product-principles/#avoid-plugins-and-marketplaces). + +This does not mean we will **never** build a "marketplace" inside of GitLab, it +just means we have no intention of doing that at this time. + +### Integrating "everything" + +There are hundreds of products and services that customers have requested that +we build an integration with, and we sincerely wish we had the time and funding +to be able to build all of them. However, since we are a team of limited size +and there are only so many hours in a day, we are currently focused on creating +the integrations requested by our biggest customers and userbases. + +However, we're happy to [partner with your company](/partners/integrate/) if +you'd like to contribute an integration with your product. As an As an [open core project](https://en.wikipedia.org/wiki/Open-core_model), +anyone in our community is welcome to add the integrations they need. + +## Contributing + +This category develops and maintains specific integrations inside the GitLab +codebase, but that doesn't preclude you and your team from adding your own. At +GitLab, one of our values is that everyone can contribute. If you're looking +to contribute your own integration, or otherwise get involved with features in +the Ecosystem area, [you can find open issues here](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Aecosystem&label_name[]=Category%3AIntegrations). + +Feel free to reach out to the team directly if you need guidance or want +feedback on your work by pinging [@deuley](https://gitlab.com/deuley) or +[@gitlab-ecosystem-team](https://gitlab.com/gitlab-org/ecosystem-team) on your +open MR. + +You can read more about our general contribution guidelines [here](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md). + +## Partnership + +If your company is interested in partnering with GitLab, check out the [Partner with GitLab](https://about.gitlab.com/partners/integrate/) +page for more info. + +## Integration design guidelines + +Special considerations apply to integrations that don't apply to building native functionality. The +product handbook [has a set of recommendations and guidelines](/handbook/product#integrate-other-applications-thoughtfully) +to consider when working on these types of projects. + +## Feedback & Requests + +If there's an integration that you'd like to see GitLab offer, or if you have +feedback about an existing integration: please [submit an issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue%5Btitle%5D=New%20GitLab%20Integration%20with) +with the label `~Category:Integrations`, or contact [@deuley](https://gitlab.com/deuley), +Sr. Product Manager, Ecosystem, on any open issues. diff --git a/source/direction/create/editor_extension/index.html.md b/source/direction/create/editor_extension/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..70cd06876e54983e1ffe9670439ff90c784aba30 --- /dev/null +++ b/source/direction/create/editor_extension/index.html.md @@ -0,0 +1,106 @@ +--- +layout: markdown_page +title: "Category Direction - Editor Extension" +--- + +- TOC + {:toc} + +## Editor Extension + +| | | +| --- | --- | +| Stage | [Create](/direction/dev/#create) | +| Maturity | [Minimal](/direction/maturity/) | +| Content Last Reviewed | `2020-08-12` | + +### Introduction and how you can help +Thanks for visiting this direction page on Editor Extension. This page belongs to the [Editor](/handbook/product/product-categories/#editor-group) group of the Create stage and is maintained by Kai Armstrong ([E-Mail](mailto:karmstrong@gitlab.com)). + +This direction is constantly evolving and everyone can contribute: + +- Please comment and contribute in the linked issues and epics on this page. Sharing your feedback directly on GitLab.com or submitting a Merge Request to this page are the best ways to contribute to our strategy. +- Please share feedback directly via email, Twitter, or on a video call. If you're a GitLab user and have direct knowledge of your need for Local Development Tools, we'd especially love to hear from you. + +### 概要 + +GitLab supports teams collaborating and building software together, however that collaboration is only available inside GitLab application. + +Developers, on the other hand, spend the majority of their time working in local editors implementing work outlined in issues, responding to merge request feedback and testing/debugging their applications. These tasks are the core of the developer experience, but GitLab is missing from this experience in any integrated way. + +### Target Audience and Experience + + +#### Challenges to address + + +### Where we are headed + +GitLab should support developers closer to where they're doing their meaningful work and enable them to be more efficient in the delivery of that work. + +### Maturity + +### Problems to Solve + +There are many specific problems that can be solved by focusing on local developer tooling: + +1. [Developers working in local editors](https://gitlab.com/groups/gitlab-org/-/epics/2431) +1. Developers working locally with local runtime +1. [Developers working locally with remote runtime](https://gitlab.com/groups/gitlab-org/-/epics/3230) + +### What's Next & Why + +**Next:** Remote Development Environments [&3230](https://gitlab.com/groups/gitlab-org/-/epics/3230) + +Developing a strategy and MVC for enabling developers to test and debug their applications utilizing remote compute will be key in expanding in this path. + +### What is Not Planned Right Now + +We're not currently focused on extensions for any other local editors or IDEs. We recognize there are a variety of these environments and we'll continue to monitor demand and market trends to look for other opportunities to support developers. + +The editor group is also not looking to connect our existing [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/index.html) to any runtime environments or local tools for further development. We may continue to explore a more advanced Web IDE that could support these itmes in the future. + +### Competitive Landscape + +#### Local Editors + +- [GitHub Pull Requests and Issues](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github) + +#### Local Runtime + +- [Skaffold](https://skaffold.dev/) + +#### Remote Runtime + +- [Okteto](https://okteto.com) +- [Tilt](https://tilt.dev) +- [Dev Pods](https://jenkins-x.io/docs/reference/devpods/) + + + + + + + + + + + + + + + + + + + diff --git a/source/direction/create/gitaly/index.html.md b/source/direction/create/gitaly/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..7ddb40f3bf96e565d52d91357309cc77a286a1af --- /dev/null +++ b/source/direction/create/gitaly/index.html.md @@ -0,0 +1,225 @@ +--- +layout: markdown_page +title: "Category Direction - Gitaly" +description: "Gitaly is a Git RPC service for handling all the Git calls made by GitLab. Find more information here!" +canonical_path: "/direction/create/gitaly/" +--- + +- TOC + {:toc} + +## Gitaly + +| Section | Stage | Maturity | Last Reviewed | +| --- | --- | --- | --- | +| [Dev](/direction/dev/) | [Create](https://about.gitlab.com/stages-devops-lifecycle/create/) | Non-marketable | 2020-08-04 | + +## Introduction and how you can help + +The Gitaly direction page belongs to the [Gitaly](/handbook/product/product-categories/#source-code-group) +group of the [Create](/direction/create) stage, +and is maintained by [James Ramsay](https://gitlab.com/jramsay) . + +This strategy is a work in progress, and everyone can contribute. +Please comment and contribute in the linked issues and epics. +Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision. + +- [Issue List](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Agitaly) +- [Epic list](https://gitlab.com/groups/gitlab-org/-/epics?label_name[]=group%3A%3Agitaly) + +## 概要 + + + +Gitaly is the service responsible for the storage and maintenance of all Git repositories in GitLab. +Git repositories are essential to GitLab, for [Source Code Management](/direction/create/source-code-managent), [Wikis](/direction/create/wiki),[Snippets](/direction/create/snippets), [Design Management](/direction/create/design-management), [Web IDE](/direction/create/web-ide), and every stage to the DevOps lifecycle to the right of Create - Verify, Release, Package, Release, Configure, Monitor, Secure, and Defend - depend on the project repositories. Because the majority of GitLab capabilities depend on that information stored in Git repositories, performance and availability are of primary importance. + +GitLab is used to store Git repositories by small teams and large enterprises with many terabytes of data. For this reason, Gitaly has been built to scale from small single server GitLab instances, to large high availability architectures. The [recent release of Gitaly Cluster](/releases/2020/05/22/gitlab-13-0-released/#gitaly-cluster-for-high-availability-git-storage) is a major achievement in improving fault tolerance and performance, and is the foundation on which we are continuing to iterate to improve Gitaly for large instances. + +Continued investment in large software projects over many years can result in extremely large Git repositories. Contributing to the development of features like partial clone in Git, and improving Gitaly and GitLab for these enterprise scale repositories is an ongoing area of investment. + +Gitaly provides multiple interface to read and write Git data: + +- Git protocol over SSH, through the GitLab Shell component. +- Git protocol over HTTP, through the GitLab Workhorse component. +- gRPC internally to GitLab components. The public REST and GraphQL APIs to Git data are implemented using these RPCs. + + +
+ +
+ + +### Target Audience + + + +**Systems Administrators** directly interact with Gitaly when installing, configuring, and managing a GitLab server, particularly when high availability is a requirement. Today systems administrator must create and manage an NFS cluster to configure a high availability GitLab instance, and manual manage the failover to new Gitaly nodes mounted on the same NFS cluster. Once a HA Gitaly reaches minimal viability, it will be possible to eliminate the NFS cluster from architecture and rely on Gitaly for replication. At HA Gitaly continues to mature, automatic failover, automatic Gitaly node rebalancing and horizontal scaling read access across replicas will deliver 99.999% uptime (five 9's) and improved performance without regular intervention. Systems Administrators will have fewer applications to manage as other version control systems are retired as the last projects are migrated to GitLab. + +**Developers** will benefit from increasing performance for repositories of all shapes and sizes, on the command line and in the GitLab application as performance improvements continue. Once support for monolithic repositories reaches minimal and continues maturing, developers will no longer be split between Git and legacy version control systems, as projects consolidate increasingly on Git. Developers that heavily use binary assets, like **Game Developers**, will at long last be able to switch to Git and eliminate Git LFS by adopting native large file support in Git. + + + +## Where we are Headed + + + +The performance and availability of Gitaly is matter of importance for GitLab Administrators. The inability to access Git repositories on a GitLab server is an outage event, and for a large instance would prevent thousands of people from doing their job. The [recent release of Gitaly Cluster](/releases/2020/05/22/gitlab-13-0-released/#gitaly-cluster-for-high-availability-git-storage) is a major achievement in improving fault tolerance and performance. Continued iteration is need to further improve fault tolerance, performance, and complete roll out to GitLab.com. + +- [Gitaly Clusters: strong consistency](https://gitlab.com/groups/gitlab-org/-/epics/1189) +- [Gitaly Clusters: distribute read operations](https://gitlab.com/groups/gitlab-org/-/epics/2013) +- [Elastic Gitaly Clusters](https://gitlab.com/groups/gitlab-org/-/epics/3372) + +Git is the market leading Version Control System (VCS), but many organizations with extremely large projects continue to use centralized version control systems like CVS, SVN, and Perforce. These organizations have often widely adopted Git, but isolated large legacy repositories remain elsewhere. Improvements to Git like partial clone and spare checkout, to Gitaly, GitLab will make it possible to standardize on Git for extremely large repositories, and allow organizations to consolidate on Git. + +- [Git for enormous repositories](https://gitlab.com/groups/gitlab-org/-/epics/773) + +### What's Next & Why + + + +- **In progress:** [Gitaly Clusters: strong consistency](https://gitlab.com/groups/gitlab-org/-/epics/1189) + + When a developer pushes changes to GitLab, if a success signal is returned, + GitLab should have more than one copy of this data to prevent data loss. + Strong consistency is the highest priority after shipping the eventually + consistent MVC. + +- **In progress:** [Incremental repository backups](https://gitlab.com/groups/gitlab-org/-/epics/2094) + + Backing up GitLab instances with massive amounts of Git data is slow and + difficult. The built-in backup script can't cope with large amounts of Git + data. Workarounds include disk snapshots and rsync, and even then backups + may take many many hours, and are likely to be inconsistent. A frequent + request is point in time recovery from backups. + +### What is Not Planned Right Now + + + +- [VFS for Git](https://gitlab.com/groups/gitlab-org/-/epics/93) + + Partial Clone is built-in to Git and available in GitLab 13.0 or newer. + [Scalar](https://devblogs.microsoft.com/devops/introducing-scalar/) is + compatible with partial clone, and Microsoft is contributing to its + improvement based on their learnings from the GVFS protocol. + +### Maturity Plan + + + +Gitaly is a **non-marketable** category, and is therefore not assigned a maturity level. + +## Competitive Landscape + + + +Important competitors are [GitHub.com](https://github.com) and [Perforce](https://perforce.com) which, in relation to Gitaly, compete with GitLab in terms of raw Git performance and support for enormous repositories respectively. + +Customers and prospects evaluating GitLab (GitLab.com and self hosted) benchmark GitLab's performance against GitHub.com, including Git performance. The Git performance of GitLab.com for easily benchmarked operations like cloning, fetching and pushing, show that GitLab.com similar to GitHub.com. + +Perforce competes with GitLab primarily on it's ability to support enormous repositories, either from binary files or monolithic repositories with extremely large numbers of files and history. This competitive advantage comes naturally from it's centralized design which means only the files immediately needed by the user are downloaded. Given sufficient support in Git for partial clone, and sufficient performance in GitLab for enormous repositories, existing customers are waiting to migrate to GitLab. + +- [Git for enormous repositories](https://gitlab.com/groups/gitlab-org/-/epics/773) + +## Business Opportunity + + + +The version control systems market is expected to be valued at close to US$550mn in the year 2021 and is estimated to reach US$971.8md by 2027 according to [Future Market Insights](https://www.futuremarketinsights.com/reports/version-control-systems-market) which is broadly consistent with revenue estimates of GitHub ([$250mn ARR](https://www.owler.com/company/github)) and Perforce ([$130mn ARR](https://www.owler.com/company/perforce)). The opportunity for GitLab to grow with the market, and grow it's share of the version control market is significant. + +Git is the market leading version control system, demonstrated by the [2018 Stack Overflow Developer Survey](https://insights.stackoverflow.com/survey/2018/#work-_-version-control) where over 88% of respondents use Git. Although there are alternatives to Git, Git remains dominant in open source software, usage by developers continues to grow, it installed by default on macOS and Linux, and the project itself continues to adapt to meet the needs of larger projects and enterprise customers who are adopting Git, like the Microsoft Windows project. + +According to a [2016 Bitrise survey](https://blog.bitrise.io/state-of-app-development-2016#self-hosted) of mobile app developers, 62% of apps hosted by SaaS provider were hosted in GitHub, and 95% of apps are hosted in by a SaaS provider. These numbers provide an incomplete view of the industry, but broadly represent the large opportunity for growth in SaaS hosting on GitLab.com, and in self hosted where GitLab is already very successful. + +## Analyst Landscape + + + +- [Native support for large files](https://gitlab.com/groups/gitlab-org/-/epics/773) is important to companies that need to version large binary assets, like game studios. These companies primarily use Perforce because Git LFS provides poor experience with complex commands and careful workflows needed to avoid large files entering the repository. GitLab has been supporting work to provide a more native large file workflow based on promiser packfiles which will be very significant to analysts and customers when the feature is ready. + +## Top Customer Success/Sales issue(s) + + + +- [Gitaly Clusters: strong consistency](https://gitlab.com/groups/gitlab-org/-/epics/1189) will provide improved fault tolerance by guaranteeing a quorum of Gitaly nodes have accepted write operations before reporting a success to the client. This will make automatic fail possible with a high degree of confidence that no data loss will occur. +- [Incremental repository backups](https://gitlab.com/groups/gitlab-org/-/epics/2094) will provide a comprehensive backup solution for GitLab instances with large amounts of Git data. +- [Native support for extremely large repositories](https://gitlab.com/groups/gitlab-org/-/epics/773) prevents existing customers and prospects from being able to migrate enormous repositories from Perforce or SVN to Git. It is frequently requested and many organizations want to standardize on a single version control system and tool like GitLab across all projects. + +## Top user issue(s) + + + +Users do not see Gitaly as a distinct feature or interface of GitLab. +Git performance is the most significant user facing area where improvements are frequently requested, +however the source of the performance problem can vary significantly. + +## Top internal customer issue(s) + + + +- [Gitaly Clusters: strong consistency](https://gitlab.com/groups/gitlab-org/-/epics/1189) will provide improved fault tolerance by guaranteeing a quorum of Gitaly nodes have accepted write operations before reporting a success to the client. This will make automatic fail possible with a high degree of confidence that no data loss will occur. +- [Streaming incremental Git backups](https://gitlab.com/groups/gitlab-org/-/epics/2094) will replace inconsistent disk snapshots for GitLab.com. + +## Top Vision Item(s) + + + +- [Gitaly Clusters: strong consistency](https://gitlab.com/groups/gitlab-org/-/epics/1189) will provide improved fault tolerance by guaranteeing a quorum of Gitaly nodes have accepted write operations before reporting a success to the client. This will make automatic fail possible with a high degree of confidence that no data loss will occur. +- [Native support for large files](https://gitlab.com/groups/gitlab-org/-/epics/773) prevents existing customers and prospects being able to migrate repositories with large files to Git. Git LFS isn't a sufficient solution for these organisations in comparison with the native support of other version control systems. The most pressing problem is avoiding the need to download enormous amounts of data, and not having to remember to use different commands for different files so as not to make life worse for everyone. diff --git a/source/direction/create/gitlab_docs/index.html.md b/source/direction/create/gitlab_docs/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..188f8977e3c7c51bf470ced42d18fe29facd6730 --- /dev/null +++ b/source/direction/create/gitlab_docs/index.html.md @@ -0,0 +1,110 @@ +--- +layout: markdown_page +title: "Category Direction - GitLab Documentation Site" +canonical_path: "/direction/create/gitlab_docs/" +--- + +- TOC + {:toc} + +## GitLab Documentation Site + +| Stage | Maturity | Content Last Reviewed | +| --- | --- | --- | +| [Create](/direction/dev/index.html#create) | [Complete](/direction/maturity/) | `2020-06-30` | + +## 概要 + +GitLab’s documentation is crafted to help users, admins, and decision-makers learn about GitLab features and to optimally implement and use GitLab to meet their [DevOps](https://about.gitlab.com/stages-devops-lifecycle/) needs. Its source is developed and stored with the product in its respective paths within the GitLab [CE](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc), [EE](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/doc), [Runner](https://gitlab.com/gitlab-org/gitlab-runner/tree/master/docs), and [Omnibus](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/doc) repositories. The documentation is published at [docs.gitlab.com](https://docs.gitlab.com/) (offering multiple versions of all products’ documentation) and at the `/help/` path on each GitLab instance’s domain, with content for that instance’s version and edition. + +Our goal is to create documentation that is complete, accurate, and easy to use. It should be easy to browse or search for the information you need, and easy to contribute to the documentation itself. All standards and practices for contributing documentation are found within the docs in the [GitLab Documentation guidelines](https://docs.gitlab.com/ee/development/documentation/) section. + +### Target Audience + +**GitLab Users:** Users of GitLab rely on accurate, up-to-date, and comprehensive documentation of the features available. + +**GitLab Team Members:** GitLab team members are both contributors to and consumers of the documentation. While the [Technical Writing](https://about.gitlab.com/handbook/product/technical-writing/) team owns the documentation, all team members can and do contribute to the them. + +**Leadership & Decision-makers:** The GitLab documentation site is a valuable resource for decision-makers to compare features across versions and evaluate implementation details that may impact a purchasing decision. + + + + + +### Where we are Headed + +Our current focus is on improving the information architecture, usability, and overall content of the documentation. Specifically, we're working to: + +* Complete information architecture and user experience audit +* Complete a gap analysis of the documentation content itself +* Improve search and discoverability across the site + +Additionally, we want to lower the barrier to contributing changes by integrating the [static site editor](https://about.gitlab.com/direction/create/static_site_editor/). + + + + + + + +### What is Not Planned Right Now + +At this time, we are not investigating any significant architecture changes like migrating to a new static site generator. + +We're not currently investing in localization of the documentation. + +### Maturity Plan + + + + +Currently, the GitLab Documentation Site category is a *non-marketing category* which means its maturity does not get tracked. However, for the sake of measuring improvement, the GitLab Documentation Site is marked as `Complete` with intentions of moving it to `Lovable`. + + + + + + + +### Competitive Landscape + + +* [Stripe's documentation](https://stripe.com/docs) is considered the gold standard of documentation sites +* [Algolia](https://www.algolia.com/doc/) has excellent documentation and information architecture + + + diff --git a/source/direction/create/gitlab_handbook/index.html.md b/source/direction/create/gitlab_handbook/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..415ad20c48d645d271686710ecf6e3ce53b2f790 --- /dev/null +++ b/source/direction/create/gitlab_handbook/index.html.md @@ -0,0 +1,68 @@ +--- +layout: markdown_page +title: "Category Direction - GitLab Handbook" +description: "The GitLab Handbook is an incredible tool for documenting GitLab processes and is used as the single source of truth for many things inside the company." +canonical_path: "/direction/create/gitlab_handbook/" +--- + +- TOC + {:toc} + +## GitLab Handbook + +| Stage | Maturity | Content Last Reviewed | +| --- | --- | --- | +| [Create](/direction/dev/index.html#create) | [Complete](/direction/maturity/) | `2020-08-07` | + +## 概要 + +The [GitLab Handbook](/handbook) is the single source of truth for how we operate at GitLab, including processes, policies, and product direction. In keeping with our [value of transparency](/handbook/values/#transparency), the GitLab Handbook is entirely open to the world. We welcome feedback from the community and hope that it serves as [inspiration](/handbook/inspired-by-gitlab/) for other current or future companies. The GitLab Handbook is also an incredible recruiting tool, providing candidates with valuable insight into how GitLab runs as a company. + +A sub-section of the [about.gitlab.com](https://about.gitlab.com) website, the GitLab Handbook specifically refers to content that is in the `/handbook/` namespace of the website. The overall user experience and architecture of the GitLab Handbook is maintained by the [Static Site Editor team](https://about.gitlab.com/handbook/engineering/development/dev/create-static-site-editor/). + +### Target Audience + +**GitLab Team Members:** Every GitLab team member is responsible for using and updating our handbook. It is the central repository for process documentation and product direction. + +**Leadership:** GitLab leadership uses the handbook like any other member of the team, but additionally needs to reference the content during presentations to stakeholders or investors. Since everything we do is open to the public, members of leadership teams outside of GitLab may also use the GitLab Handbook as reference or inspiration for their own team processes and policies. + +**Potential Applicants:** Candidates for job opportunities at GitLab use the handbook to learn more about expectations for the role, compensation and benefits, GitLab's company values, and other policies. GitLab team members also use the handbook extensively to share specific, relevant information with potential applicants, making it a powerful recruiting tool in itself. + +**Current and Potential Users:** GitLab's product direction, strategy, and vision are documented in the handbook alongside our product and engineering processes. This allows current users a glimpse into GitLab's future priorities and can help potential users make an informed decision related to adopting GitLab as a tool. + +## Where we are Headed + +At GitLab, we encourage everyone to work [handbook first](/handbook/handbook-usage/#why-handbook-first) in order to promote asynchronous collaboration and documentation. Working this way has its challenges, not the least of which is the time and effort involved in making a change. While this extra investment can encourage contributors to be more considered and deliberate with their changes, at a certain point it discourages meaningful collaboration and works against our goals. + +Making a change to the GitLab Handbook requires either building and running the site locally or using the Web IDE, both of which can be intimidating for less technical users. Once a change has been made, the current build process for the GitLab Handbook makes it difficult to predict when a change will be deployed, often taking between 10 and 45 minutes. + +Our hope is that the GitLab Handbook is something that others want to emulate. To facilitate that, we are investigating ways we can templatize the handbook itself and make it something that any user can install at a group level. To get there, we need to have: + +* Incredible, organized, and up-to-date content +* An amazing editing experience for all users using a [Static Site Editor](/direction/create/static_site_editor/) +* Fast, predictable deployments within a couple of minutes of making a change to a single page +* Sharing tools for spreading the word about GitLab on social media +* A clean, scalable information architecture and modern codebase + +### What's Next & Why + +- **[Monorepo refactor:](https://gitlab.com/groups/gitlab-com/-/epics/282)** The [`www-gitlab-com`](https://gitlab.com/gitlab-com/www-gitlab-com/) project is home to multiple sub-sites including the blog, our marketing pages, and the GitLab Handbook which all deploy to the [about.gitlab.com](https://about.gitlab.com) domain. In order to ensure stability, accountability, and efficiency, we are working to separate and isolate these sub-sites into distinct projects within the main project. This will allow us to implement separate CI pipelines for each project, so that changes will only build, test, and deploy the relevant project. +- **[Pipeline performance improvements:](https://gitlab.com/groups/gitlab-com/-/epics/255)** Getting the build and deploy time down to a reasonable level is one of the most important things we can do to encourage more collaboration among users already familiar with how to edit the handbook. Recent efforts have reduced the average build and deploy time by over 50% but there are still opportunities for further optimization, mostly around reducing the overall size of the project repository. +- **[Evaluate Frontman as a replacement for Middleman:]](https://gitlab.com/groups/gitlab-com/-/epics/871)** We had previously decided against moving away from Middleman as our static site generator, but a [new project from the team at Algolia](https://github.com/algolia/frontman) has the potential to dramatically speed up our development and build times with very few tradeoffs. We have not committed fully to the migration yet, but we intend to evaluate the new generator and weigh the performance gains against the potential drawbacks. +- **[Improved reading and sharing experience:](https://gitlab.com/groups/gitlab-com/-/epics/326)** The content needs to remain the primary focus but it should be easier to search, navigate, and share the content. +- **[Freshness tools:](https://gitlab.com/groups/gitlab-com/-/epics/325)** To ensure that content is relevant, up-to-date, not duplicative, and to give readers the tools they need to flag content that doesn't meet those criteria. +- **Improved content editing experience:** As delivered by the [Static Site Editor](/direction/create/static_site_editor/). + +### What is Not Planned Right Now + +We are not currently investigating a transition to a separate, external content management system or publishing platform. + +The needs of the GitLab Handbook [have outgrown what can be handled in a wiki](https://about.gitlab.com/handbook/handbook-usage/#wiki-handbooks-dont-scale) (or similar) product, so we are not planning to migrate any content into that format. + +Since the content is [changing quite literally every day](https://gitlab.com/gitlab-com/www-gitlab-com/-/commits/master/source/handbook), we are not looking to generate a digital or printed book from the GitLab Handbook content. + +The GitLab Handbook is not currently optimized for serving as a searchable Knowledge Base or FAQ repository similar to what you would find on [Quora](https://www.quora.com/) or [Stack Overflow](https://stackoverflow.com/). The problems to be solved in those areas are likely to be addressed by the [Knowledge group](/handbook/product/product-categories/#knowledge-group). + +### Maturity Plan + +Currently, the GitLab Handbook category is a *non-marketing category* which means its maturity does not get tracked. However, for the sake of measuring improvement, the GitLab Handbook is marked as `Complete` with intentions of moving it to `Lovable`. diff --git a/source/direction/create/gitter/index.html.md b/source/direction/create/gitter/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..26ed9868c6196736f06ecee43fdaf1addfe33f58 --- /dev/null +++ b/source/direction/create/gitter/index.html.md @@ -0,0 +1,97 @@ +--- +layout: markdown_page +title: "Category Direction - Gitter" +description: "Since GitLab acquired Gitter, the team has open sourced it's web app, iOS app and Android app. Find more information here!" +canonical_path: "/direction/create/gitter/" +--- + +- TOC + {:toc} + +## Gitter + +| Stage | Maturity | Content Last Reviewed | +| --- | --- | --- | +| [Create](/direction/dev/index.html#create) | [Minimal](/direction/maturity/) | `2020-07-01` | + +Gitter is an open source chat application for developers, and is the place to connect the open source and software development community. + +Gitter is a popular tool for building/supporting open source communities and is well integrated with GitHub. Since GitLab acquired Gitter, the team has open sourced it's [web app](https://gitlab.com/gitlab-org/gitter/webapp), [iOS app](https://gitlab.com/gitlab-org/gitter/gitter-ios-app) and [Android app](https://gitlab.com/gitlab-org/gitter/gitter-android-app). We want Gitter to be the best place for building open source communities, particularly when the project is hosted on GitLab, and make it [available by default to projects](https://gitlab.com/groups/gitlab-org/-/epics/359). There are also exciting possibilities to use Gitter to streamline the transition from async communication in issues and merge requests to synchronous forms of communication like real-time chat. And [opportunities to transition some of the open source community over to GitLab](#business-opportunity). + +- [Issue List](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Agitter) +- [Epic List](https://gitlab.com/groups/gitlab-org/-/epics?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Agitter) +- [Overall GitLab Vision](/direction/create/) + +Please reach out to PM Eric Schurter ([E-Mail](mailto:eschurter@gitlab.com) +[Twitter](https://twitter.com/e_shirt)) if you'd like to provide feedback or ask +questions about what's coming. + +## Target Audience and Experience + +**Open source developers:** As Gitter was originally highly integrated with GitHub, there is an existing base of developers. This audience is valuable in order to position [GitLab as the most popular collaboration tool](https://about.gitlab.com/company/strategy/#big-hairy-audacious-goal). Helping people communicate to get their problems solved and questions answered. + +**Open source project maintainers:** Be the place that project maintainers want to setup their community on. This means integrating with their project so the team can talk and reference easily and jump to where they want to go. + +## What's Next & Why + +**In Progress: [GitLab communities and rooms](https://gitlab.com/groups/gitlab-org/-/epics/398)** are needed to grow the user base of Gitter by making it work well with GitLab, which includes making it easy for [every project to have a Gitter community](https://gitlab.com/groups/gitlab-org/-/epics/359). This is step one to making the GitLab transition attractive for an existing project on Gitter. Support for GitLab communities and rooms is nearly complete, with only support for GitLab [user namespace communities](https://gitlab.com/gitlab-org/gitter/webapp/-/issues/2397) remaining. + +**In Progress:** Moving to a [Progressive Web App](https://gitlab.com/gitlab-org/gitter/webapp/-/issues/1992) will align the Gitter mobile and desktop experiences around a single codebase and improve productivity for the team. + +## Competitive Landscape + +Our competitors have a lot more polish which makes them attractive. Gitter's competitive advantage is developer friendly and familiar Markdown formatting support, publicly viewable archives, and free without limits. + +- [Slack](https://slack.com) + - Lots of polish + - Invite system and closed ecosystem which makes the information hidden and harder to jump in + - Limited message archive unless you pay +- [Discord](https://discordapp.com/) + - Lots of polish + - More gamer centric but plenty of thriving variety communities +- [Mattermost](https://mattermost.com/) + - Open source + - Very competitive with Slack + - Doesn't offer a free hosted SaaS tier which may be why we don't see it mentioned often +- [Spectrum](https://spectrum.chat/) + - Developer focused + - Not exactly chat but going after the same open source crowd and has big projects onboard + - Question and answer forum style (but is realtime) +- IRC ([Freenode](https://freenode.net/)) + - Longstanding dead simple chat + - Plenty of developer communities still using IRC + +## Business Opportunity + +Gitter is uniquely positioned to introduce open source developers to the GitLab ecosystem. With the existing open source community on Gitter being GitHub centric, any branding, [cross-references](https://gitlab.com/groups/gitlab-org/-/epics/402), or unique features for GitLab communities will make people more familiar with GitLab. The ideal outcome to make the switch over to GitLab obvious. + +## Top Customer Success communities + +- **[FreeCodeCamp](https://gitter.im/FreeCodeCamp/home):** Free courses on how to learn to code +- **[Angular](https://gitter.im/angular/angular):** JavaScript framework to build applications +- **[Cypress](https://gitter.im/cypress-io/cypress):** Frontend testing framework +- **[Microsoft](https://gitter.im/Microsoft/home):** TypeScript, VSCode, and many more +- **[Scala](https://gitter.im/scala/scala):** Programming language +- [List of Gitter's most active communities](https://gitlab.com/gitlab-org/gitter/webapp/issues/2356#note_249999842) + +## Top user issue(s) + +- [Message reactions](https://gitlab.com/groups/gitlab-org/-/epics/396) +- [Link GitLab account to existing Gitter account](https://gitlab.com/gitlab-org/gitter/webapp/issues/1752) + - This entails supporting multiple backing identities for a single user and [setting your own username](https://gitlab.com/gitlab-org/gitter/webapp/issues/1851) which is another top issue +- [Better notification settings and emails](https://gitlab.com/gitlab-org/gitter/webapp/issues/1205) + +## Top internal customer issue(s) + +The GitLab team does not use Gitter for internal communication. + +There is a [GitLab community](https://gitter.im/gitlabhq/home) on Gitter with rooms for [general GitLab support](https://gitter.im/gitlabhq/gitlabhq) and where [GitLab contributors can chat](https://gitter.im/gitlabhq/contributors). + +## Top Vision Item(s) + +- [Message reactions](https://gitlab.com/groups/gitlab-org/-/epics/396) +- [Multiple identity users](https://gitlab.com/groups/gitlab-org/-/epics/400) +- [Better search](https://gitlab.com/groups/gitlab-org/-/epics/387) +- [Gitter x GitLab cross-references](https://gitlab.com/groups/gitlab-org/-/epics/402) +- [Post-creation community and room customization](https://gitlab.com/groups/gitlab-org/-/epics/399) +- [Progressive web app(PWA) as iOS/Android app alternative](https://gitlab.com/groups/gitlab-org/-/epics/386) diff --git a/source/direction/create/live_preview/index.html.md b/source/direction/create/live_preview/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..686d102d49ed79284719718fa6b16244432ec2c7 --- /dev/null +++ b/source/direction/create/live_preview/index.html.md @@ -0,0 +1,32 @@ +--- +layout: markdown_page +title: "Category Direction - Live Preview" +description: "With Live Preview can view your simple JavaScript apps and static sites in the Web IDE, in real time, right next to the code." +canonical_path: "/direction/create/live_preview/" +--- + +- TOC + {:toc} + +## Live Preview + +| | | +| --- | --- | +| Stage | [Create](/direction/dev/#create) | +| Maturity | [Minimal](/direction/maturity/) | +| Content Last Reviewed | `2020-06-24` | + +### Introduction and how you can help +Thanks for visiting this direction page on the [Live Preview](https://docs.gitlab.com/ee/user/project/web_ide/index.html#enabling-client-side-evaluation) features of the [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/index.html). This page belongs to the [Editor](/handbook/product/product-categories/#editor-group) group of the Create stage and is maintained by Kai Armstrong ([E-Mail](mailto:karmstrong@gitlab.com)). + +Learn more about the [Web IDE direction](/direction/create/web_ide/). + +### 概要 + +With Live Preview can view your simple JavaScript apps and static sites in the Web IDE, in real time, right next to the code. + +We're not currently investing in the Live Preview features of the Web IDE, but welcome contributions to improve the existing feature or extend our Live Preview capabilities to full stack applications. + +### What is Not Planned Right Now + +Live Preview is currently limited to Javascript applications that can be evaluated in the browser, called client-side evaluation. Extending support to include server-side evalaution would allow more complex applications to be previewed in real time through the Web IDE. Currently this is not possible, and is not planned. diff --git a/source/direction/create/snippets/index.html.md b/source/direction/create/snippets/index.html.md new file mode 100644 index 0000000000000000000000000000000000000000..bace50724648074f3d537935335725ba909b84cd --- /dev/null +++ b/source/direction/create/snippets/index.html.md @@ -0,0 +1,152 @@ +--- +layout: markdown_page +title: "Category Direction - Snippets" +description: "GitLab Snippets allow users to share small bits of code and text by directly linking, downloading, or embedding them in web apps within a