Commit 87ba91c7 authored by Patrick Deuley's avatar Patrick Deuley 🔁

fixing links to product handbook

parent 14fc1703
Pipeline #161375303 skipped with stage
......@@ -14,7 +14,7 @@ features:
Until now, the only way to get Jira issues into GitLab was manually,
with our CSV importer, or by hand-rolling your own migration utility.
GitLab 12.10 includes an
[MVC](/handbook/product/#the-minimally-viable-change-mvc)
[MVC](/handbook/product/product-principles/#the-minimal-viable-change-mvc)
to automatically import your Jira issues into GitLab. This is the first
of [many planned
enhancements](https://gitlab.com/groups/gitlab-org/-/epics/2738) to
......
......@@ -10,4 +10,4 @@ features:
- 'DevOps Reports'
issue_url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/207164'
description: |
Development leaders and GitLab administrators often wish to understand how their teams are using GitLab. In this MVC you'll see three counts on the group landing page: Merge Requests, Issues, and Users added to the group, all over the past 90 days. This feature is being released in [beta](https://about.gitlab.com/handbook/product/#beta).
Development leaders and GitLab administrators often wish to understand how their teams are using GitLab. In this MVC you'll see three counts on the group landing page: Merge Requests, Issues, and Users added to the group, all over the past 90 days. This feature is being released in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta).
......@@ -5,7 +5,7 @@ features:
performance_url: 'https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=performance&milestone_title=12.10'
reporter: multiple
description: |
We are continuing to make great strides improving the performance of GitLab in every release. [We're committed](/handbook/product/#performance) to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
We are continuing to make great strides improving the performance of GitLab in every release. [We're committed](/handbook/product/gitlab-the-product/#performance) to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
In GitLab 12.10 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.10 are:
......
......@@ -5,7 +5,7 @@ features:
performance_url: 'https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=performance&milestone_title=12.8'
reporter: multiple
description: |
We are continuing to make great strides improving the performance of GitLab in every release. [We're committed](/handbook/product/#performance) to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
We are continuing to make great strides improving the performance of GitLab in every release. [We're committed](/handbook/product/gitlab-the-product/#performance) to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
In GitLab 12.8 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.8 are:
......
......@@ -11,4 +11,4 @@ features:
description: |
Migrations between GitLab instances can be challenging, especially from self-managed GitLab to GitLab.com, because organizations can have their work organized in many Projects and Groups. Until now, these migrations had to be done by exporting and importing one Project at a time.
With the release of the Group Export/Import [MVC](https://about.gitlab.com/handbook/product/#the-minimally-viable-change-mvc), users can export an entire Group and easily import it into the desired instance of GitLab, whether their destination is GitLab.com or another self-managed GitLab instance.
With the release of the Group Export/Import [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc), users can export an entire Group and easily import it into the desired instance of GitLab, whether their destination is GitLab.com or another self-managed GitLab instance.
......@@ -5,7 +5,7 @@ features:
performance_url: 'https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=performance&milestone_title=12.9'
reporter: multiple
description: |
We are continuing to make great strides improving the performance of GitLab in every release. [We're committed](/handbook/product/#performance) to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
We are continuing to make great strides improving the performance of GitLab in every release. [We're committed](/handbook/product/gitlab-the-product/#performance) to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
In GitLab 12.9 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 12.9 are:
......
......@@ -20,5 +20,5 @@ features:
improve performance.
This feature is being released as
[beta](/handbook/product/#alpha-beta-ga) while we evaluate its performance
[beta](/handbook/product/gitlab-the-product/#alpha-beta-ga) while we evaluate its performance
under production loads.
......@@ -5,7 +5,7 @@ features:
performance_improvements_url: 'https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=performance&milestone_title=13.1'
reporter: multiple
description: |
In every release, we continue to make great strides improving GitLab's performance. [We're committed](/handbook/product/#performance) to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million users!
In every release, we continue to make great strides improving GitLab's performance. [We're committed](/handbook/product/gitlab-the-product/#performance) to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million users!
In GitLab 13.1, we're shipping performance improvements for CI pipeline processing, viewing git blame, and much more! Some improvements in GitLab 13.1 are:
......
......@@ -580,7 +580,7 @@ features:
issue_url: 'https://gitlab.com/groups/gitlab-org/issues?state=all&utf8=%E2%9C%93&milestone_title=10.0&label_name%5B%5D=Deliverable&label_name%5B%5D=performance'
description: |
With every release we aim to make GitLab faster, more available, and more stable.
[We're committed](/handbook/product/#performance) not only to making
[We're committed](/handbook/product/gitlab-the-product/#performance) not only to making
individual instances of GitLab even faster, but also to greatly improving
the performance of GitLab.com, an instance that hosts 1 million users!
......
......@@ -565,7 +565,7 @@ features:
description: |
We are continuing to make great strides in improving
the performance of GitLab in every release.
[We're committed](/handbook/product/#performance) to not only
[We're committed](/handbook/product/gitlab-the-product/#performance) to not only
making individual instances of GitLab even faster,
but also to greatly improving the performance of GitLab.com,
an instance that has over one million users!
......
......@@ -371,7 +371,7 @@ features:
description: |
We are continuing to make great strides in improving the performance of
GitLab in every release.
[We're committed](/handbook/product/#performance) not only to making
[We're committed](/handbook/product/gitlab-the-product/#performance) not only to making
individual instances of GitLab even faster but also greatly
improving the performance of GitLab.com, an instance that has over one
million users!
......
......@@ -388,7 +388,7 @@ features:
team: configure
issue_url: 'https://gitlab.com/gitlab-org/gitlab-ce/issues/39923'
description: |
At GitLab, one of our product values is to [default to on](/handbook/product/#principles).
At GitLab, one of our product values is to [default to on](/handbook/product/product-principles/#configuration-principles).
When we introduce a new configurable feature we know to be of great value, we will
default to ON so that everyone can benefit from it. While Auto DevOps supports
projects using the most popular programming languages, there may be some specialized
......
......@@ -322,7 +322,7 @@ features:
via MinIO, and use Geo to replicate data to secondary nodes.
Native Geo support for object storage replication is currently a [beta
feature](https://about.gitlab.com/handbook/product/#beta) and is not
feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta) and is not
ready yet for production use.
- name: "Geo Supports Using a Single, Location-aware Git URL"
......
......@@ -106,7 +106,7 @@ features:
provide clear links to the relevant scanner documentation.
**Note:** as this is the initial
[MVC](https://about.gitlab.com/handbook/product/#the-minimally-viable-change-mvc)
[MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc)
of this new feature, there currently is no advanced configuration, so
you cannot disable or enable the scans from this screen.
{: .note}
......
......@@ -44,7 +44,7 @@ features:
description: |
We are happy to announce the availability of Windows Shared
Runners hosted by GitLab, now in
[beta](/handbook/product/#beta). You can
[beta](/handbook/product/gitlab-the-product/#beta). You can
take advantage of a fully-managed, auto-scaling, and secure environment
for running your CI/CD jobs on Windows virtual machines, hosted on
the same GCP infrastructure as GitLab.com. Windows Shared Runners are
......
......@@ -14,7 +14,7 @@ I rang in my first month at GitLab in spectacular fashion, by meeting up with te
## MVC applies even to marketers
The product team at GitLab lives and breathes the principle of [“Minimum Viable Change”](/handbook/product/#the-minimally-viable-change-mvc) (MVC). This meant nothing to me in my day-to-day as a writer and marketer, until I joined GitLab and got an engineer as my team lead. We don’t apply the exact same language and principles to our content projects, but I believe that the spirit of MVC still informs our work. For example, our team lead Sean [explained](/blog/2016/10/24/how-we-ship-so-quickly/) his simple test for reviewing our merge requests — he asks himself, “is this better than what was here before?” If the answer is ‘yes’, it gets approved. We now operate with the attitude that it’s better to jump in and do the work, than ask for approval, which not only makes us faster but increases our sense of agency over projects. We don’t need to establish consensus among innumerable team members before making a documentation or handbook update live on the site; if someone thinks of an improvement, they create a subsequent merge request, and the same rule applies. This feels like a radical way for a team of writers to work, but so far it’s all upside.
The product team at GitLab lives and breathes the principle of [“Minimum Viable Change”](/handbook/product/product-principles/#the-minimal-viable-change-mvc) (MVC). This meant nothing to me in my day-to-day as a writer and marketer, until I joined GitLab and got an engineer as my team lead. We don’t apply the exact same language and principles to our content projects, but I believe that the spirit of MVC still informs our work. For example, our team lead Sean [explained](/blog/2016/10/24/how-we-ship-so-quickly/) his simple test for reviewing our merge requests — he asks himself, “is this better than what was here before?” If the answer is ‘yes’, it gets approved. We now operate with the attitude that it’s better to jump in and do the work, than ask for approval, which not only makes us faster but increases our sense of agency over projects. We don’t need to establish consensus among innumerable team members before making a documentation or handbook update live on the site; if someone thinks of an improvement, they create a subsequent merge request, and the same rule applies. This feels like a radical way for a team of writers to work, but so far it’s all upside.
## Feedback flows thick and fast
......
......@@ -33,7 +33,7 @@ Container schedulers, such as [Kubernetes](/solutions/kubernetes/), provide a co
## GitLab has you covered
GitLab is the leader in cloud native development and has pioneered everything you need for end-to-end software development and operations. We have developed a compelling product that covers the entire DevOps lifecycle with a [single application](/direction/#single-application) based on [convention over configuration](/handbook/product/#convention-over-configuration). With a [built-in container registry](https://docs.gitlab.com/ee/user/project/container_registry.html), Kubernetes integration, and [CI/CD](/stages-devops-lifecycle/continuous-integration/), GitLab is a complete, easy-to-implement solution for your cloud strategy. GitLab is the first end-to-end application to meet the needs of developers at all stages of the development and operations lifecycle.
GitLab is the leader in cloud native development and has pioneered everything you need for end-to-end software development and operations. We have developed a compelling product that covers the entire DevOps lifecycle with a [single application](/direction/#single-application) based on [convention over configuration](/handbook/product/product-principles/#convention-over-configuration). With a [built-in container registry](https://docs.gitlab.com/ee/user/project/container_registry.html), Kubernetes integration, and [CI/CD](/stages-devops-lifecycle/continuous-integration/), GitLab is a complete, easy-to-implement solution for your cloud strategy. GitLab is the first end-to-end application to meet the needs of developers at all stages of the development and operations lifecycle.
As a new generation of software emerges, GitLab has set the standard in providing you with the tools to build, test, deploy, and run your app at scale. A hybrid cloud strategy is no longer a unique way to gain a competitive advantage. It’s the only way to ensure visibility, security, and stability across multiple environments.
......
......@@ -46,7 +46,7 @@ The article doesn't mention how Cloud Native Jenkins addresses the problem; mayb
## Assembly required
Legacy Jenkins doesn't work out of the box because too many choices are confusing users.
GitLab CI and GitLab are [based on convention over configuration](/handbook/product/#convention-over-configuration), where we prefer choices that are well thought out and based on current best practices and avoid unnecessary configuration.
GitLab CI and GitLab are [based on convention over configuration](/handbook/product/product-principles/#convention-over-configuration), where we prefer choices that are well thought out and based on current best practices and avoid unnecessary configuration.
Cloud Native Jenkins redesigns Jenkins from the ground up on simpler primitives.
Jenkins Evergreen still uses the same plugins so it would be harder to simplify, but maybe by selecting a set of blessed essential plugins, you can make them work better together because they can assume the other plugin is installed.
......
......@@ -11,7 +11,7 @@ tags: features, inside GitLab, open source
Iteration is [one of our values](/handbook/values/#iteration), and it's often the hardest to stick to. It’s difficult to determine the smallest feature or update that will still bring additional value to users. The benefit is that we can ship quickly and get feedback from GitLab users within days or weeks, instead of months or quarters.
At GitLab we practice iteration by shipping Minimally Viable Changes (MVCs). This can be a new feature scoped to a small functionality, or incremental improvements on it thereafter. Read more about MVC in our [Product handbook](/handbook/product/#the-minimally-viable-change-mvc).
At GitLab we practice iteration by shipping Minimally Viable Changes (MVCs). This can be a new feature scoped to a small functionality, or incremental improvements on it thereafter. Read more about MVC in our [Product handbook](/handbook/product/product-principles/#the-minimal-viable-change-mvc).
Despite being small, these new features often nonetheless have a big impact. Here are some of our recent MVCs that did just that:
......
......@@ -13,7 +13,7 @@ featured: yes
we want all of GitLab's users to take advantage of its great features. From Auto Build to Auto Monitoring,
Auto DevOps brings valuable benefits out of the box.
At GitLab, one of our product values is to [default to on](/handbook/product/#principles).
At GitLab, one of our product values is to [default to on](/handbook/product/product-principles/#configuration-principles).
When we introduce a new configurable feature we know to be of great value, we will default to ON so that everyone can
benefit from it. While Auto DevOps supports projects using the most popular programming languages, there may be some
specialized projects for which additional configuration is required. Therefore, before we
......
......@@ -23,7 +23,7 @@ We use Sketch for our day-to-day design work. The UX department's Sketch files l
## A competitive analysis of design platforms and applications
To start looking for solutions to these problems, we conducted a competitive analysis of the other platforms and applications out there tackling design creation, collaboration, and handoff. We wanted to know: What are other design teams doing to address these problems? Are there existing aspects of GitLab we can leverage to solve these problems? If not, what would an [MVC](/handbook/product/#the-minimally-viable-change-mvc) look like to integrate designers more efficiently into GitLab?
To start looking for solutions to these problems, we conducted a competitive analysis of the other platforms and applications out there tackling design creation, collaboration, and handoff. We wanted to know: What are other design teams doing to address these problems? Are there existing aspects of GitLab we can leverage to solve these problems? If not, what would an [MVC](/handbook/product/product-principles/#the-minimal-viable-change-mvc) look like to integrate designers more efficiently into GitLab?
### Summary of findings
......
......@@ -27,7 +27,7 @@ There was no controversy with my first MR, and therefore not much debate before
First, I recommend reviewing existing MRs and issues before submitting an MR. In many cases, there are already discussions and potential solutions for a certain feature or bug fix. It's also helpful to find out [who from GitLab](/company/team/) is relevant or responsible for a certain area so you can ping the right person from the start.
The initial contribution should always be a minimal solution or what GitLab calls a ["Minimum Viable Change (MVC)"](/handbook/product/#the-minimally-viable-change-mvc), because the solution will often change with feedback. The initial contribution should be considered a starting point for collaboration between the contributor and GitLab team-members.
The initial contribution should always be a minimal solution or what GitLab calls a ["Minimum Viable Change (MVC)"](/handbook/product/product-principles/#the-minimal-viable-change-mvc), because the solution will often change with feedback. The initial contribution should be considered a starting point for collaboration between the contributor and GitLab team-members.
In some cases, a contributor may need to be patient with their MR, as depending on the topic and complexity it may take some time to move things forward. The people from GitLab are always very kind and friendly so the discussions are respectful.
......
......@@ -46,7 +46,7 @@ When choosing a team or developing an innovation group, avoid thinking along leg
Keep in mind that the impetus for digital transformation and, more specifically, application modernization, is driven from a business need to deliver value to customers faster. So, making smaller changes to release faster is the single most important change you can make.
Adopt the mindset: what is the smallest possible change I can make to improve something, and how do I get it out as quickly as possible? At GitLab, we call this the [minimally viable change (MVC)](/handbook/product/#the-minimally-viable-change-mvc), and it’s what allows us to ship nearly anything within a single release. This is especially important when approaching legacy software. If you start making a ton of big changes over a few weeks, the risk of breaking something and not understanding what change caused the error grows exponentially with every change.
Adopt the mindset: what is the smallest possible change I can make to improve something, and how do I get it out as quickly as possible? At GitLab, we call this the [minimally viable change (MVC)](/handbook/product/product-principles/#the-minimal-viable-change-mvc), and it’s what allows us to ship nearly anything within a single release. This is especially important when approaching legacy software. If you start making a ton of big changes over a few weeks, the risk of breaking something and not understanding what change caused the error grows exponentially with every change.
With an MVC mindset, you can experiment with what works best without risking downtime. Smaller changes are easier to review, understand, and roll back if necessary.
......
......@@ -16,7 +16,7 @@ postType: product
UPDATE: We've [extended again until Mar. 22, 2020](/blog/2019/09/09/ci-cd-github-extended-again/)
CI/CD is one of the best parts of GitLab. Our robust feature set and powerful Runner architecture have earned us some strong industry accolades. While we believe using GitLab end to end as a single application is the best experience, we also believe in [playing well with others](/handbook/product/#plays-well-with-others) so that you can use the tools you want without vendor lock-in. In this spirit, we built [CI/CD for external repos](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/) and [CI/CD for GitHub](/solutions/github/) to allow you to host your code repositories on GitHub.com, GitHub Enterprise, BitBucket, or any Git server, while using GitLab CI/CD to build, test, and deploy your code.
CI/CD is one of the best parts of GitLab. Our robust feature set and powerful Runner architecture have earned us some strong industry accolades. While we believe using GitLab end to end as a single application is the best experience, we also believe in [playing well with others](/handbook/product/gitlab-the-product/#plays-well-with-others) so that you can use the tools you want without vendor lock-in. In this spirit, we built [CI/CD for external repos](https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/) and [CI/CD for GitHub](/solutions/github/) to allow you to host your code repositories on GitHub.com, GitHub Enterprise, BitBucket, or any Git server, while using GitLab CI/CD to build, test, and deploy your code.
We decided to extend the deadline for using CI/CD for external repos, including CI/CD for GitHub, until **Sep. 22, 2019**. You’ll now have an additional six months to enjoy CI/CD for external repos as a [Free or Bronze](/pricing/) user on GitLab.com. This feature will continue to be part of the [Premium tier](/pricing/#self-managed) for GitLab Self-managed.
......
......@@ -152,7 +152,7 @@ our research.
## What comes next?
We will investigate the paths that users take throughout GitLab and consider how we should balance
the needs of users who have contrasting team sizes, roles, and product tiers. Our goal is to find ways
to align with the principle of [convention over configuration](/handbook/product/#convention-over-configuration)
to align with the principle of [convention over configuration](/handbook/product/product-principles/#convention-over-configuration)
while still addressing the diverse needs of our users. Please see
the [navigation research initiative epic](https://gitlab.com/groups/gitlab-org/-/epics/1342) for more information.
......
......@@ -26,7 +26,7 @@ There are a variety of testing tools available to developers within GitLab.
Generally, they alert developers to vulnerabilities within their code and report
them within the merge request so developers can adjust their code as they
go. In addition to the testing methods outlined below, developers can also [use
other tools outside of GitLab](/handbook/product/#plays-well-with-others) by integrating
other tools outside of GitLab](/handbook/product/gitlab-the-product/#plays-well-with-others) by integrating
the results of your scanners with our merge request security reports.
### Static application security testing
......
......@@ -22,7 +22,7 @@ twitter_text: "How to overcome toolchain #security challenges with @gitlab"
---
Integrated toolchains [are on the rise](https://go.forrester.com/blogs/the-rise-fall-and-rise-again-of-the-integrated-developer-tool-chain/), according to Forrester analyst Christopher Condo. Integrated toolchains actually faded out for a while
because developers wanted to avoid vendor lock in - and because sometimes solutions didn’t [play well with others](/handbook/product/#plays-well-with-others).
because developers wanted to avoid vendor lock in - and because sometimes solutions didn’t [play well with others](/handbook/product/gitlab-the-product/#plays-well-with-others).
But today, the growing popularity of CI/CD and open source means more free tools in the software delivery market and dev teams are happily adding them to their arsenal.
Unfortunately, too much of a good thing can be a bad thing. Integrating,
......
......@@ -88,7 +88,7 @@ For example, GitLab will provide:
### Enterprise digital transformation
While we will continue to solve for the [modern DevOps use case first](/handbook/product/#modern-first), most enterprise customers have custom requirements that GitLab does not solve for today. This is a wide-ranging set of custom controls that spans systems such as permissions, approvals, compliance, governance, workflows, and requirements mapping. It is our belief these needs will exist for many years to come, and we will need to incorporate these to truly become a flexible DevOps platform that serves enterprise segments. We will strive to do this in ways that are modern and, where possible, adhere to a [“convention over configuration”](/handbook/product/#convention-over-configuration) approach, living with the cognitive dissonance that sometimes flexibility will be required in areas we have not been willing to venture into thus far.
While we will continue to solve for the [modern DevOps use case first](/handbook/product/product-principles/#modern-first), most enterprise customers have custom requirements that GitLab does not solve for today. This is a wide-ranging set of custom controls that spans systems such as permissions, approvals, compliance, governance, workflows, and requirements mapping. It is our belief these needs will exist for many years to come, and we will need to incorporate these to truly become a flexible DevOps platform that serves enterprise segments. We will strive to do this in ways that are modern and, where possible, adhere to a [“convention over configuration”](/handbook/product/product-principles/#convention-over-configuration) approach, living with the cognitive dissonance that sometimes flexibility will be required in areas we have not been willing to venture into thus far.
Additionally, compliance, auditing, and surfacing evidence of security/compliance posture will become more important as more GDPR-like legislation is enacted and passed into law. GitLab should make it easy to not only surface and deliver evidence for GitLab controls (i.e., who has access to GitLab, who did what on what group, etc.), but also to track and manage compliance requirements for various legislation our customers may be bound to.
......
......@@ -55,7 +55,7 @@ Through research, we identified that our next focus areas should be setting Depl
## From user insights to user stories
As I start working on the design phase of the [MVC](/handbook/product/#the-minimally-viable-change-mvc), I'll break my tasks into the following steps:
As I start working on the design phase of the [MVC](/handbook/product/product-principles/#the-minimal-viable-change-mvc), I'll break my tasks into the following steps:
1. Work with my Product Manager to identify the main user story.
1. Identify possible scenarios and edge cases with the entire team.
......
......@@ -12,7 +12,7 @@ featured: no
postType: product
merch_banner: merch_six
---
We're testing Geo at scale on GitLab.com – our largest installation of GitLab – because we believe the best way to guarantee that Geo works as expected is to [use it ourselves](/handbook/product/#dogfood-everything).
We're testing Geo at scale on GitLab.com – our largest installation of GitLab – because we believe the best way to guarantee that Geo works as expected is to [use it ourselves](/handbook/product/product-processes/#dogfood-everything).
Geo is GitLab's [solution for distributed teams](/solutions/geo/). We want teams all over the world to have a great user experience - independent of how far away users are from their primary GitLab installation. To accomplish this goal, read-only Geo nodes can be created across the world in close geographical proximity to your teams. These Geo nodes replicate important data, such as projects or LFS files, from the primary GitLab instance and thereby make the data available to users. Geo can also be used as part of a disaster recovery strategy because it adds data redundancy. Geo nodes follow the primary installation closely and allow customers to failover to this node in case the primary node becomes unavailable.
......
......@@ -71,7 +71,7 @@ Other Resources
- [Chat channel](https://gitlab.slack.com/archives/g_geo); please use the `#g_geo`
chat channel for questions that don't seem appropriate to use the issue tracker
for.
- [Product Support Requests](/handbook/product/#product-support-requests)
- [Product Support Requests](/product/product-processes/#product-support-requests)
- [Geo on staging.gitlab.com](./staging.html)
- Research Items : [Next Gen Geo](./2019-next-gen-geo.html)
......
......@@ -223,7 +223,7 @@ We tag each issue and MR with the planned milestone or the milestone at time of
### Iteration
We always push ourselves to be iterative and make the [minimal viable change](https://about.gitlab.com/handbook/product/#the-minimal-viable-change-mvc). Defining the minimal viable change takes practice.
We always push ourselves to be iterative and make the [minimal viable change](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc). Defining the minimal viable change takes practice.
![build a car vs start with skateboard and move to car](https://gitlab.com/gitlab-org/gitlab/uploads/590251a5311fb50e4dcb174f214e1340/Screen_Shot_2020-02-06_at_3.29.48_PM.png)
......
......@@ -12,4 +12,4 @@ title: Manager Onboarding
## Training
### Iteration Training
Besides normal onboarding training with various tools and processes. Engineering Managers should also take the [Iteration](https://about.gitlab.com/handbook/product/#iteration) Training. Engineering Managers can start the process of training by following the steps in this [template](https://gitlab.com/gitlab-com/Product/-/issues/new?issuable_template=iteration-training). Iteration is a important value of GitLab and not easily learned. Working with other Engineering Managers and Product Managers during this exercise is encouraged to further enhance the experience.
Besides normal onboarding training with various tools and processes. Engineering Managers should also take the [Iteration](https://about.gitlab.com/handbook/product/product-principles/#iteration) Training. Engineering Managers can start the process of training by following the steps in this [template](https://gitlab.com/gitlab-com/Product/-/issues/new?issuable_template=iteration-training). Iteration is a important value of GitLab and not easily learned. Working with other Engineering Managers and Product Managers during this exercise is encouraged to further enhance the experience.
......@@ -46,7 +46,7 @@ B2 -->|retag edge| E4[edge]
Per our Continuous Deployment flow, for new components that do not have a counterpart in the GitLab
Rails application, the component can be released at any time. Until the components
are integrated with the existing application, iteration should not be blocked by [our
standard release cycle and process](https://about.gitlab.com/handbook/product/#product-process)
standard release cycle and process](https://about.gitlab.comproduct-process)
### Release Manager
......
......@@ -129,7 +129,7 @@ An Engineering Manager recognizes that a repo that is part of the shipping produ
### Incremental Velocity and Measurement
Our velocity should be incremental in nature. It's derived from our [MVC](https://about.gitlab.com/handbook/product/#the-minimal-viable-change-mvc), which encourages "delivering the smallest possible solution that offers value to our users". This could be a small new feature, but also includes code improvements, fixing bugs, etc.
Our velocity should be incremental in nature. It's derived from our [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc), which encourages "delivering the smallest possible solution that offers value to our users". This could be a small new feature, but also includes code improvements, fixing bugs, etc.
To measure this, we count and define the target here: [MRs per Development Engineer](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#average-mrs-development-engineers-month) which is a goal for managers and not ICs. Historically, we have seen this as high as 14-19 MRs per Product Development Engineer per Month.
......@@ -138,7 +138,7 @@ Ten MRs per month per Product Development Engineer translates to roughly an MR e
* For feature issues, break the issue into several smaller MRs that are delivered incrementally. Small here translates to less than two days.
* Help dogfood a GitLab feature by using it to fix an issue identified within the code base. As examples, fix code climate issue for one file OR SAST scanner potential errors found.
* Raise concerns for issues where our incremental philosophy does not work when the issue cannot be broken down further.
* Raise concerns for issues that Product Development Engineers do not feel fits the [MVC](https://about.gitlab.com/handbook/product/#the-minimal-viable-change-mvc) definition.
* Raise concerns for issues that Product Development Engineers do not feel fits the [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) definition.
### Velocity over predictability
......@@ -151,7 +151,7 @@ There is variance in how much time an issue will take versus what you estimated.
Both measures reduce the overall velocity of shipping features.
The way to prevent this is to accept that we don't want perfect predictability.
Just like with our [OKRs](/company/okrs/), which are so ambitious that we expect to reach about 70% of the goal, this is also fine for shipping [planned features](/handbook/product/#how-this-impacts-planning).
Just like with our [OKRs](/company/okrs/), which are so ambitious that we expect to reach about 70% of the goal, this is also fine for shipping [planned features](/handbook/product/product-principles/#how-this-impacts-planning).
_Note:_ This does not mean we place zero value on predictability. We just optimize for velocity first.
......
......@@ -24,7 +24,7 @@ title: "Performance"
### Target
Performance of GitLab and GitLab.com is ultimately about the user experience. As also described in the [product management handbook](/handbook/product/#performance), "faster applications are better applications".
Performance of GitLab and GitLab.com is ultimately about the user experience. As also described in the [product management handbook](/handbook/product/gitlab-the-product/#performance), "faster applications are better applications".
Our target is: an average **Speed Index of less than 2 seconds** for GitLab.com
......
......@@ -21,7 +21,7 @@ This page acts as a quick reference of mental models for sync and async collabor
### 2 steps forward, 1 step back design
At GitLab we ship using the [Minimal Viable Change](https://about.gitlab.com/handbook/product/#the-minimal-viable-change-mvc) (MVC). Designing in this context can often be confusing for newcomers because it's important to consider the big picture as well as the steps for how we get there. To deal with this dichotomy, we design by initially thinking about the mid to long-term vision and then reducing the scope of the experience (in a lovable way) to make implementation quicker. In other words, we design by taking 2 steps forward and 1 step back.
At GitLab we ship using the [Minimal Viable Change](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) (MVC). Designing in this context can often be confusing for newcomers because it's important to consider the big picture as well as the steps for how we get there. To deal with this dichotomy, we design by initially thinking about the mid to long-term vision and then reducing the scope of the experience (in a lovable way) to make implementation quicker. In other words, we design by taking 2 steps forward and 1 step back.
**Actions**
- Use this model with your team to break a vision down into a series of small (MVC) issues
......
......@@ -11,7 +11,7 @@ title: "Iteration"
## Overview
In order to provide the changes in an [iterative](https://about.gitlab.com/handbook/values/#iteration) and [incremental manner](https://about.gitlab.com/handbook/product/#iteration), complex changes should be [split into smaller ones](https://about.gitlab.com/handbook/values/#make-small-merge-requests) to simplify the review process. As a result, more people are involved in the particular feature development as a whole that helps to receive [diverse](https://about.gitlab.com/handbook/values/#diversity-inclusion) feedback. Meanwhile, fewer people are involved in one particular merge request that makes the [collaboration](https://about.gitlab.com/handbook/values/#collaboration) more effective and scoped to a particular piece of functionality.
In order to provide the changes in an [iterative](https://about.gitlab.com/handbook/values/#iteration) and [incremental manner](https://about.gitlab.com/handbook/product/product-principles/#iteration), complex changes should be [split into smaller ones](https://about.gitlab.com/handbook/values/#make-small-merge-requests) to simplify the review process. As a result, more people are involved in the particular feature development as a whole that helps to receive [diverse](https://about.gitlab.com/handbook/values/#diversity-inclusion) feedback. Meanwhile, fewer people are involved in one particular merge request that makes the [collaboration](https://about.gitlab.com/handbook/values/#collaboration) more effective and scoped to a particular piece of functionality.
## How to split a merge request
......
......@@ -1098,7 +1098,7 @@ extras:
_To be added by Product Managers or Engineering Managers and merged by either._
Describe the deprecations happening in that release or in upcoming releases. Note that there are differences in [deprecations and removals](https://about.gitlab.com/handbook/product/#deprecating-and-removing-features),
Describe the deprecations happening in that release or in upcoming releases. Note that there are differences in [deprecations and removals](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecating-and-removing-features),
so be sure to include the relevant details on when the feature will be removed from GitLab in the post. Let our community know about a future deprecation as soon as possible. When adding deprecations be sure to keep with the same structure of "XYZ feature or function will be deprecated at ABC time."
The due date is defined by the removal of that feature. The field is required, and should be set as:
......@@ -1153,7 +1153,7 @@ _To be added by Product Managers or Engineering Managers and merged by either._
Describe the features that are being removed in the upcoming release. Removals should be planned.
If possible, set up a [deprecation](#deprecation) notice at least one minor release before removing a feature.
Note the differences between [deprecations and removals](https://about.gitlab.com/handbook/product/#deprecating-and-removing-features),
Note the differences between [deprecations and removals](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecating-and-removing-features),
so be sure to include the relevant details on when the feature will be removed from GitLab in the post.
The `date_of_removal`due date is defined by the removal of that feature. The field is required, and should be set as:
......
......@@ -38,7 +38,7 @@ At Gitlab, anyone can contribute to the Competitive Intelligence process. We s
GitLab exists in an ecosystem of **[DevOps tools](/devops-tools)** and might need to interact with any number of these tools. Many have over-lapping capabilities, but that does not mean that we necessarily directly compete with them. A user would need to patch together multiple solutions from this list in order to get all the functionality that is built-in to GitLab as a **[single application for end-to-end DevOps](/)**.
We tend to include those products also in the DevOps Tools comparison pages so customers have a comprehensive understanding of how we view the full landscape, not necessarily in competitive terms. Refer to this handbook page for more information on [who GitLab competes with](/handbook/product/#who-gitlab-competes-with).
We tend to include those products also in the DevOps Tools comparison pages so customers have a comprehensive understanding of how we view the full landscape, not necessarily in competitive terms. Refer to this handbook page for more information on [who GitLab competes with](/handbook/product/gitlab-the-product/#who-gitlab-competes-with).
## The Customer's Voice
......
......@@ -95,7 +95,7 @@ Also, [we do not say no by-default to having existing paid features contributed
**Vendor Lock-In.**
Premium features make it more difficult to switch workflows. -
GitLab the product [plays well with others](/handbook/product/#plays-well-with-others). As we outline,
GitLab the product [plays well with others](/handbook/product/gitlab-the-product/#plays-well-with-others). As we outline,
> Many other applications [integrate with GitLab](/partners/integrate/), and we are open to adding new integrations to our [technology partners page](/partners/). New integrations with GitLab can vary in richness and complexity; from a simple webhook, and all the way to a [Project Service](https://docs.gitlab.com/ee/user/project/integrations/project_services.html).
> GitLab [welcomes and supports new integrations](/integrations/) to be created to extend collaborations with other products. GitLab plays well with others by providing APIs for nearly anything you can do within GitLab. GitLab can be a [provider of authentication](https://docs.gitlab.com/ee/integration/oauth_provider.html) for external applications. **GitLab is open source so people are very welcome to add anything that they are missing.**
......@@ -134,7 +134,7 @@ When someone contributes an _existing_ feature to open-source it, we weigh a num
1. What is the quality of the submitted code?
1. Is it a complete replacement of the source-available functionality?
1. Does it meet the [contribution acceptance criteria](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#contribution-acceptance-criteria)?
1. Is it [more relevant for mid-market organizations or larger](/handbook/product/#paid-tiers)?
1. Is it [more relevant for mid-market organizations or larger](/handbook/product/gitlab-the-product/#paid-tiers)?
1. Is the person or organization submitting this using GitLab in an [SMB](/handbook/sales/#market-segmentation)?
1. Did the person or organization submitting this contribute to GitLab before?
1. Is it something that many of our existing customers chose our paid tiers for?
......
This diff is collapsed.
......@@ -107,7 +107,7 @@ Customers may have specific tools they are committed to using due to factors lik
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/#plays-well-with-others).
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
......
......@@ -27,7 +27,7 @@ _This direction is a work in progress, and [everyone can contribute](#contributi
## Overview
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/#plays-well-with-others).
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
......@@ -53,7 +53,7 @@ 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/#plays-well-with-others).
when we say that GitLab [plays well with others](/handbook/product/gitlab-the-product/#plays-well-with-others).
Particularly for with large organizations, existing tools and services
can be particularly difficult to migrate off of, even without any explicit vendor
......@@ -184,7 +184,7 @@ provides.
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/#avoid-plugins-and-marketplaces).
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.
......
......@@ -66,14 +66,14 @@ connected. Defend will identify and protect against threats as they happen, but
to other stages to give you actionable next steps to close a vulnerability or point of exploit, not just defend it.
Not only does shifting left and acting on results earlier give your apps better security, it helps
[enable collaboration](/handbook/product/#enabling-collaboration) with everyone at your company.
[enable collaboration](/handbook/product/product-principles/#enabling-collaboration) with everyone at your company.
We believe that security is everyone's responsibility and that [everyone can contribute](/company/strategy/#mission),
and informing other stages is a powerful way to do this.
### Emphasize usability and convention over configuration
Defend capabilities will be pre-configured to provide value to protecting your applications.
Rather than require you to read documentation manuals and provide complex configuration files,
[GitLab will always provide reasonable defaults](/handbook/product/#convention-over-configuration)
[GitLab will always provide reasonable defaults](/handbook/product/product-principles/#convention-over-configuration)
out of the box.
We will provide the ability for advanced and customized configurations, but these will
......
### Enterprise Compliance
Most enterprise customers have custom requirements that GitLab does not solve for today. This is a wide-ranging set of custom controls that spans systems such as permissions, approvals, compliance, governance, workflows, and requirements mapping. It is our belief these needs will exist for many years to come, and we will need to incorporate these to truly become a flexible DevOps platform that serves enterprise segments. We will strive to do this in ways that are modern and, where possible, adhere to a [“convention over configuration”](/handbook/product/#convention-over-configuration) approach, living with the cognitive dissonance that sometimes flexibility will be required in areas we have not been willing to venture into thus far.
Most enterprise customers have custom requirements that GitLab does not solve for today. This is a wide-ranging set of custom controls that spans systems such as permissions, approvals, compliance, governance, workflows, and requirements mapping. It is our belief these needs will exist for many years to come, and we will need to incorporate these to truly become a flexible DevOps platform that serves enterprise segments. We will strive to do this in ways that are modern and, where possible, adhere to a [“convention over configuration”](/handbook/product/product-principles/#convention-over-configuration) approach, living with the cognitive dissonance that sometimes flexibility will be required in areas we have not been willing to venture into thus far.
Additionally, compliance, auditing, and surfacing evidence of security/compliance posture will become more important as more GDPR-like legislation is enacted and passed into law. GitLab should make it easy to not only surface and deliver evidence for GitLab controls (i.e. who has access to GitLab, who did what on what group, etc.), but also to track and manage compliance requirements for various legislation our customers may be bound to.
......
......@@ -128,7 +128,7 @@ This is probably the top popular issue from the category (i.e. the one with the
thumbs-up), but you may have a different item coming out of customer calls.-->
<!-- ### Top internal customer issue(s)
These are sourced from internal customers wanting to [dogfood](https://about.gitlab.com/handbook/product/#dogfood-everything)
These are sourced from internal customers wanting to [dogfood](https://about.gitlab.com/handbook/product/product-processes/#dogfood-everything)
the product.-->
<!-- ### Top Strategy Item(s)
......
......@@ -79,7 +79,7 @@ As a new user, you install GitLab. Then what? Our goal is to guide you through t
<!--
This is almost always sourced from the following sections, which describe top
priorities for a few stakeholders. This section must provide a link to an issue
or [epic](https://about.gitlab.com/handbook/product/#epics-for-a-single-iteration) for the MVC or first/next iteration in the category.-->
or [epic](https://about.gitlab.com/handbook/product/product-processes/#epics-for-a-single-iteration) for the MVC or first/next iteration in the category.-->
- Add support for the latest versions of PostgreSQL so we can improve the performance of GitLab. As part of this work, we will add Patroni as another option for handling replication and failover, which aligns with the architecture of gitlab.com, aims to eliminate split brain issues, and enables cascading replication for Geo. Epic: [Move to PostgreSQL 11 and 12](https://gitlab.com/groups/gitlab-org/-/epics/2184)
- Build an automation tool to deploy multi-node instances of GitLab and significantly reduce the time required for initial setup. Epic: [Simplify GitLab instance management on multi-node installations](https://gitlab.com/groups/gitlab-org/-/epics/1949)
......@@ -119,7 +119,7 @@ This category is currently at the Lovable maturity level. This is the highest ma
### Competitive Landscape
<!-- The top two or three competitors, and what the next one or two items we should
work on to displace the competitor at customers, ideally discovered through
[customer meetings](https://about.gitlab.com/handbook/product/#customer-meetings). We’re not aiming for feature parity with competitors, and we’re not just looking at the features competitors talk
[customer meetings](https://about.gitlab.com/handbook/product/product-processes/#customer-meetings). We’re not aiming for feature parity with competitors, and we’re not just looking at the features competitors talk
about, but we’re talking with customers about what they actually use, and
ultimately what they need.-->
......@@ -140,7 +140,7 @@ thumbs-up), but you may have a different item coming out of customer calls.-->
<!--
### Top internal customer issue(s)
<!-- These are sourced from internal customers wanting to [dogfood](https://about.gitlab.com/handbook/product/#dogfood-everything)
<!-- These are sourced from internal customers wanting to [dogfood](https://about.gitlab.com/handbook/product/product-processes/#dogfood-everything)
the product.-->
<!--
......
......@@ -61,7 +61,7 @@ The user workflows on GitLab.com and our Self-managed instances are very differe
The external user personas on GitLab.com and our Self-Managed instances are very different and should be treated as such. We will be focusing on the 2 described below.
In addition to the personas, it's also important to understand the permissions available for users (limits and abilities) at each level.
* [Handbook page on permissions in GitLab](https://about.gitlab.com/handbook/product/#permissions-in-gitlab)
* [Handbook page on permissions in GitLab](https://about.gitlab.com/handbook/product/gitlab-the-product/#permissions-in-gitlab)
* [Docs on permission on docs.gitlab.com](https://docs.gitlab.com/ee/user/permissions.html)
* *Note: GitLab.com and Self-Managed permission do differ.*
......
......@@ -37,7 +37,7 @@ can contribute. We believe in the emergent benefits of a
DevOps lifecycle.
You can read more about the principles that guide our prioritization process in
our [product handbook](/handbook/product/#product-principles). You can also read
our [product handbook](/handbook/product/product-principles/). You can also read
our [GitLab as a Product](/handbook/product/#gitlab-as-a-product) section which
describes the principles that are used to guide GitLab itself forward.
......@@ -329,7 +329,7 @@ acceptance criteria].
## How we plan releases
At GitLab, we strive to be [ambitious](/handbook/product/#how-this-impacts-planning),
At GitLab, we strive to be [ambitious](/handbook/product/product-principles/#how-this-impacts-planning),
maintain a strong sense of urgency, and set aspirational targets with every
release. The direction items we highlight in our [kickoff](/handbook/product/product-management/process/#kickoff-meetings)
are a reflection of this ambitious planning. When it comes to execution we aim
......
......@@ -15,7 +15,7 @@ Thanks for visiting this category page on Subgroups in GitLab. This page is bei
## Overview
Groups are a fundamental building block (a [small primitive](https://about.gitlab.com/handbook/product/#prefer-small-primitives)) in GitLab that serve to:
Groups are a fundamental building block (a [small primitive](https://about.gitlab.com/handbook/product/product-principles/#prefer-small-primitives)) in GitLab that serve to:
- Define workspace boundaries, particularly on GitLab.com, where a top level group frequently represents an organization
- Group users to manage authorization at scale
- Organize related projects together
......
......@@ -136,7 +136,7 @@ According to a 2019 IDC report, only 11% of survey respondents had security and
* Preventing configuration drift jeopardizing your compliance posture with alerts and evidence reports that delight auditors.
### Shortening time-to-value
On theme with a wide variety of industries adopting DevOps, our goal is getting customers into the product, getting them started, and getting out of the way. Our challenge is to make GitLab intuitive and easy to use without a steep learning curve; we've built our application on a foundation of [small primitives](https://about.gitlab.com/handbook/product/#prefer-small-primitives), and our goal is to reduce the amount of configuration and setup you need to get your team productive. We'll get users and organizations to their "ah-ha" moment faster by:
On theme with a wide variety of industries adopting DevOps, our goal is getting customers into the product, getting them started, and getting out of the way. Our challenge is to make GitLab intuitive and easy to use without a steep learning curve; we've built our application on a foundation of [small primitives](https://about.gitlab.com/handbook/product/product-principles/#prefer-small-primitives), and our goal is to reduce the amount of configuration and setup you need to get your team productive. We'll get users and organizations to their "ah-ha" moment faster by:
* Allowing instances to import from and integrate a wide variety of tools that customers use and love.
* Adopting lovable templates for common use cases throughout the product, teaching our users best practices from industry leaders.
* Making user onboarding lovable and intuitive across a variety of personas.
......
......@@ -51,7 +51,7 @@ We believe this will continue in the Monitor stage categories. A pertinent examp
## Vision
In 2 year’s time, the Monitor stage categories of observability, incident management, and product feedback are the default choice for cloud-native teams using GitLab by being complete, cost effective, and simple to setup and operate, enabling continuous improvement.
GitLab is uniquely qualified to deliver on this bold and [ambitious](/handbook/product/#how-this-impacts-planning) vision because:
GitLab is uniquely qualified to deliver on this bold and [ambitious](/handbook/product/product-principles/#how-this-impacts-planning) vision because:
1. GitLab is a complete devops tool that is connected across the devops stages. Being one tool makes the circular devops workflow, and feedback, seamless and achievable.
2. The Monitor stage is pursuing a differentiated strategy from other observability vendors by not pursuing a usage based model business model by charging for processing and storage of observability.
......
......@@ -21,7 +21,7 @@ title: "Section Direction - Ops"