Commit 7b727585 authored by William Chia's avatar William Chia

Update links

parent 9c1f9429
Pipeline #33798831 passed with stages
in 25 minutes and 55 seconds
......@@ -169,7 +169,7 @@ gitlab_com:
questions:
- question: Does GitLab offer a money-back guarantee?
answer: |
Yes, we offer a 45-day money-back guarantee for any GitLab self-hosted or GitLab.com plan. See full details on refunds in our [terms of service](https://about.gitlab.com/terms/)
Yes, we offer a 45-day money-back guarantee for any GitLab self-hosted or GitLab.com plan. See full details on refunds in our [terms of service](/terms/)
- question: What are pipeline minutes?
answer:
Pipeline minutes are the execution time for your pipelines on our shared runners. Execution on your own runners will not increase your pipeline minutes count and is unlimited.
......@@ -184,7 +184,7 @@ gitlab_com:
The minutes limit only applies to private projects. Public projects include projects set to "Internal" as they are visible to everyone on GitLab.com.
- question: Is there a catch with the free forever plan?
answer:
There is no catch. Part of <a href="https://about.gitlab.com/strategy/#sequence">our strategy sequence</a> is to make GitLab.com the most popular SaaS solution for private and public repositories. To achieve this goal you get unlimited public and private projects, and there is no limit to the number of collaborators on a project.
There is no catch. Part of <a href="/company/strategy/#sequence">our strategy sequence</a> is to make GitLab.com the most popular SaaS solution for private and public repositories. To achieve this goal you get unlimited public and private projects, and there is no limit to the number of collaborators on a project.
- question: Can I acquire a mix of licenses?
answer:
No, all users in the group need to be on the same plan.
......
......@@ -9,9 +9,9 @@ title: About Us
1. GitLab Inc. is a open-core company that sells [subscriptions that offer more feature and support for GitLab](/products).
1. The company is [remote only](/culture/remote-only/) with [300+ people working from their own location in more than 39 countries](/team/).
1. GitLab Inc. is an active participant in this community, see [our stewardship](/stewardship) for more information.
1. [Our history](/history) starts in 2011 for the open source project, and in 2015 we joined Y Combinator and started growing faster, we have a public [strategy](/strategy/#sequence).
1. [Our mission](/strategy/#mission) is to change all creative work from read-only to read-write so that **everyone can contribute**.
1. [Our history](/history) starts in 2011 for the open source project, and in 2015 we joined Y Combinator and started growing faster, we have a public [strategy](/company/strategy/#sequence).
1. [Our mission](/company/strategy/#mission) is to change all creative work from read-only to read-write so that **everyone can contribute**.
1. Our Tanuki (Japanese for raccoon dog) logo symbolizes this with a smart animal that works in a group to achieve a common goal, you can download it on our [press page](/press).
1. [Our values](/handbook/values) are Collaboration, Results, Efficiency, Diversity, Iteration, and Transparency (CREDIT) and these form an important part of our [culture](/culture).
1. Most of our internal procedures can be found in [publicly viewable 1000+ page handbook](/handbook) and our objects are documented in our [OKRs](/okrs/).
1. Most of our internal procedures can be found in [publicly viewable 1000+ page handbook](/handbook) and our objects are documented in our [OKRs](/company/okrs/).
1. We [release](/releases/) every month on the 22nd and there is a [publicly viewable direction for the product](/direction/#scope).
......@@ -11,16 +11,16 @@ title: "Objectives and Key Results (OKRs)"
## Quarterly OKRs
### [2018-Q4 (active)](/okrs/2018-q4/)
### [2018-Q3](/okrs/2018-q3/)
### [2018-Q2](/okrs/2018-q2/)
### [2018-Q1](/okrs/2018-q1/)
### [2017-Q4](/okrs/2017-q4/)
### [2017-Q3](/okrs/2017-q3/)
### [2018-Q4 (active)](/company/okrs/2018-q4/)
### [2018-Q3](/company/okrs/2018-q3/)
### [2018-Q2](/company/okrs/2018-q2/)
### [2018-Q1](/company/okrs/2018-q1/)
### [2017-Q4](/company/okrs/2017-q4/)
### [2017-Q3](/company/okrs/2017-q3/)
## What are OKRs?
OKRs are our quarterly goals to execute our [strategy](/strategy/). To make sure our goals are clearly defined and aligned throughout the organization. For more information see [Wikipedia](https://en.wikipedia.org/wiki/OKR) and [Google Drive](https://docs.google.com/presentation/d/1ZrI2bP-XKEWDWsT-FLq5piuIwl84w9cYH1tE3X5oSUY/edit) (GitLab internal). The OKRs are our quarterly goals.
OKRs are our quarterly goals to execute our [strategy](/company/strategy/). To make sure our goals are clearly defined and aligned throughout the organization. For more information see [Wikipedia](https://en.wikipedia.org/wiki/OKR) and [Google Drive](https://docs.google.com/presentation/d/1ZrI2bP-XKEWDWsT-FLq5piuIwl84w9cYH1tE3X5oSUY/edit) (GitLab internal). The OKRs are our quarterly goals.
## Format
......@@ -80,7 +80,7 @@ Timeline of how we draft the OKRs:
It's important to score OKRs after the quarter ends to make sure we celebrate what went well, and learn from what didn't in order to set more effective goals and/or execute better next quarter.
1. Move the current OKRs on this page to an archive page _e.g._ [2017 Q3 OKRs](/okrs/2017-q3/)
1. Move the current OKRs on this page to an archive page _e.g._ [2017 Q3 OKRs](/company/okrs/2017-q3/)
1. Add in-line comments for each key result briefly summarizing how much was achieved _e.g._
* "=> Done"
* "=> 30% complete"
......
......@@ -32,7 +32,7 @@ Everyone can contribute to digital products with GitLab, to GitLab itself, and t
1. To ensure that **everyone can contribute with GitLab** we allow anyone to create a proposal, at any time, without setup, and with confidence.
- Anyone: Every person in the world should be able to afford great DevOps software. GitLab.com has free private repos and CI runners and GitLab CE is [free as in speech and as in beer](http://www.howtogeek.com/howto/31717/what-do-the-phrases-free-speech-vs.-free-beer-really-mean/). But open source is more than a license, that is why we are [a good steward of GitLab CE](/stewardship/) and keep both GitLab CE and EE open to inspection, modifications, enhancements, and suggestions.
- Anyone: Every person in the world should be able to afford great DevOps software. GitLab.com has free private repos and CI runners and GitLab CE is [free as in speech and as in beer](http://www.howtogeek.com/howto/31717/what-do-the-phrases-free-speech-vs.-free-beer-really-mean/). But open source is more than a license, that is why we are [a good steward of GitLab CE](/company/stewardship/) and keep both GitLab CE and EE open to inspection, modifications, enhancements, and suggestions.
- Create: It is a [single application](/direction/#single-application) based on [convention over configuration](/handbook/product/#convention-over-configuration).
- Proposal: with Git, if you can read it, you can fork it to create a proposal.
- At any time: you can work concurrently to other people, without having to wait for permission or approval from others.
......@@ -56,7 +56,7 @@ Everyone can contribute to digital products with GitLab, to GitLab itself, and t
5. Stay independent so we can preserve our values. Since we took external investment we need a [liquidity event](https://en.wikipedia.org/wiki/Liquidity_event). To stay independent we want that to become a public company instead of being acquired.
## Sequence <a name="sequence"></a>
## Sequence
We want to achieve our goals in the following order:
......@@ -106,7 +106,7 @@ If you want an analogy think of our product team as a plow way in front that til
1. [Open source user benefits](http://buytaert.net/acquia-retrospective-2015): significant advantages over proprietary software because of its faster innovation, higher quality, freedom from vendor lock-in, greater security, and lower total cost of ownership.
2. [Open Source stewardship](/about/#stewardship): community comes first, we [plays well with others](/direction/#plays-well-with-others) and share the pie with other organizations commercializing GitLab.
2. [Open Source stewardship](/company/stewardship/): community comes first, we [plays well with others](/direction/#plays-well-with-others) and share the pie with other organizations commercializing GitLab.
3. [Innersourcing](/2014/09/05/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization/) is needed and will force companies to choose one solution top-down.
......@@ -122,11 +122,11 @@ If you want an analogy think of our product team as a plow way in front that til
## Pricing
Most of GitLab functionality is and will be available for free in Core. Our paid tiers includes features that are [more relevant for organizations that have more than 100 potential users](/about/stewardship/#what-features-are-paid-only). [We promise](/stewardship/#promises) all major features in [our scope](/direction/#scope) are available in Core too. Instead of charging for specific parts of our scope (CI, Monitoring, etc.) we charge for smaller features that you are more likely to need if you use GitLab with a lot of users. There are a couple of reasons for this:
Most of GitLab functionality is and will be available for free in Core. Our paid tiers includes features that are [more relevant for organizations that have more than 100 potential users](/company/stewardship/#what-features-are-paid-only). [We promise](/company/stewardship/#promises) all major features in [our scope](/direction/#scope) are available in Core too. Instead of charging for specific parts of our scope (CI, Monitoring, etc.) we charge for smaller features that you are more likely to need if you use GitLab with a lot of users. There are a couple of reasons for this:
1. We want to be a good [steward of our open source product](/about/stewardship).
1. We want to be a good [steward of our open source product](/company/stewardship/).
1. Giving a great free product is part of our go to market, it helps create new users and customers.
1. Having our scope available to all users increases adoption of our scope and helps people see the benefit of an [single application](/direction/#single-application).
1. Having our scope available to all users increases adoption of our scope and helps people see the benefit of an [single application](/handbook/product/single-application/).
1. Including all major features in Core helps reduce merge conflicts between CE and EE
Because we have a great free product we can't have one price.
......
......@@ -62,4 +62,4 @@ extra_css:
%div
%h2 Questions from visitors
%p
Most visitors have questions about our #{link_to "team size and distribution", "/team"}, how people are #{link_to 'spread among departments', "/team/chart/"}, our #{link_to "strategy", "/strategy/"}, and other things for which it helps to have a quick walk through through our #{link_to "handbook", "/handbook"} and general pages mentioned on our #{link_to "About page", "/about"}
Most visitors have questions about our #{link_to "team size and distribution", "/team"}, how people are #{link_to 'spread among departments', "/team/chart/"}, our #{link_to "strategy", "/company/strategy/"}, and other things for which it helps to have a quick walk through through our #{link_to "handbook", "/handbook"} and general pages mentioned on our #{link_to "About page", "/about"}
......@@ -101,7 +101,7 @@ extra_css:
%h4 Twitter
%p Follow us on Twitter for the most up-to-date info about @gitlab.
.flex-container.community-content-row
%a.community-item{href: "/visiting/"}
%a.community-item{href: "/company/visiting/"}
%img{src: "/images/contact/contact-office.svg"}
.community-item-info
%h4 Visit Our Office
......
......@@ -9,7 +9,7 @@ title: "GitLab 101"
There is a monthly GitLab CEO 101 call with new hires and the CEO. Here we talk about the following topics. This is a zoom call that will be uploaded to YouTube. Please read the history and values links provided below and come prepared with questions. The call will be driven by questions asked by new employees. Make sure your full name is set in Zoom.
1. Questions about GitLab history [/history/](/history/)
1. Questions about GitLab history [/company/history/](/company/history/)
1. Questions about our values [/handbook/values](/handbook/values)
1. Team structure [/team/structure/](/team/structure/) or [organization chart](/team/chart)
1. How we work [/handbook/general-guidelines](/handbook/general-guidelines)
......@@ -46,7 +46,7 @@ Please keep your introduction to less than 1 minute 30 seconds. After you're fin
### People Ops 101s
There is a monthly People Ops 101 Zoom call with new hires, our Chief Culture Officer (CCO), and members of the People Ops team. It is meant to occur following GitLabbers' participation in the CEO 101. The links above are good reading for both meetings. In addition to the topics above, new hires may be interested in our culture, [people priorities](/okrs/), [diversity](/handbook/values/#diversity) and [inclusion](/culture/inclusion/), [hiring](/handbook/hiring/), and a variety of other topics. Our CCO welcomes the team's questions and comments, but also appreciates hearing suggestions and ideas from GitLab's new hires.
There is a monthly People Ops 101 Zoom call with new hires, our Chief Culture Officer (CCO), and members of the People Ops team. It is meant to occur following GitLabbers' participation in the CEO 101. The links above are good reading for both meetings. In addition to the topics above, new hires may be interested in our culture, [people priorities](/company/okrs/), [diversity](/handbook/values/#diversity) and [inclusion](/culture/inclusion/), [hiring](/handbook/hiring/), and a variety of other topics. Our CCO welcomes the team's questions and comments, but also appreciates hearing suggestions and ideas from GitLab's new hires.
### Frequently Asked Questions about the GitLab Culture
......
......@@ -14,7 +14,7 @@ title: "GitLab Culture"
## Introduction
Please see our [About Us page](/about/) for more general information about GitLab. And see how our team has grown at the [GitLab Summits page](/culture/summits)
Please see our [company page](/company/) for more general information about GitLab. And see how our team has grown at the [GitLab Summits page](/culture/summits)
<figure class="video_container">
<iframe src="https://www.youtube.com/embed/Mkw1-Uc7V1k" frameborder="0" allowfullscreen="true"> </iframe>
......
......@@ -330,11 +330,11 @@ responsibility, willingness of GitLabbers to teach new GitLabbers, transparency,
#### What are you wondering about / What we are missing
1. Are we growing too fast?
* Check out our [strategy](/strategy/) page for why we are growing faster than feels intuitive.
* Check out our [strategy](/company/strategy/) page for why we are growing faster than feels intuitive.
1. How to improve myself as a professional?
* Aside from the internal tools at GitLab, you can expense any course or training that falls in line with [Spending Company Money](/handbook/spending-company-money). Questions? Just ask your manager or People Ops.
1. How are we using our series B funding?
* We have released our [master plan](/2016/09/13/gitlab-master-plan/) for how we plan on growing as a company as a result of our Series B Funding. Also, check out our [Strategy Page](/strategy/).
* We have released our [master plan](/2016/09/13/gitlab-master-plan/) for how we plan on growing as a company as a result of our Series B Funding. Also, check out our [Strategy Page](/company/strategy/).
1. What are the plans for parental leave?
* We are currently working on this [issue](https://gitlab.com/gitlab-com/peopleops/issues/88).
1. What are the mid to long term engineering strategies?
......
......@@ -12,7 +12,7 @@ title: "Board of Directors"
## Board Meeting Process
1. The CFO is responsible for scheduling the meeting, preparing the agenda and recording minutes.
1. Collaborate on public webpages such as [/strategy](/strategy/) as much as possible.
1. Collaborate on public webpages such as [/strategy](/company/strategy/) as much as possible.
1. Financial information and other non public items go into a shared Google Sheet and/or Google Presentation.
1. The CFO will send a reminder to those who are requested to prepare materials two weeks in advance of the meeting.
1. Final draft presentations are due one week prior to the meeting.
......
......@@ -143,7 +143,7 @@ Enjoy your stay!
There are three levels of performance:
1. Commitment: what we promise to our stakeholders.
1. Aspiration: want to get to 70% of this, these are our [OKRs](/okrs/)
1. Aspiration: want to get to 70% of this, these are our [OKRs](/company/okrs/)
1. Possibility: what are intrigued by, inspired by, and what I talk about
I'm driven by what is possible, the aspiration, what can be.
......
......@@ -46,14 +46,14 @@ Make sure to include the following in the description:
### Videocalls
<br>
- Please read our About page as preparation for this meeting: /about/<br>
- Please read our Company page as preparation for this meeting: /company/<br>
- **ONLY calls in the hiring process** Please fill out this form a day in advance, to discuss during the call: https://docs.google.com/a/gitlab.com/forms/d/e/1FAIpQLScXUW07w36Ob2Y2XQuESBaYqU5_c1SoweGS1BzGHnbesISGXw/viewform<br>
<br>
### Meetings in the boardroom
<br>
Please read our About page as preparation for this meeting: /about/<br>
Please read our Company page as preparation for this meeting: /company/<br>
Executive cell: <br>
Guest cell:<br>
<br>
......@@ -145,7 +145,7 @@ Current preferences for flights are:
If people want advice on open source, remote work, or other things related to GitLab we'll consider that. If Sid approves of the request we suggest the following since we want to make sure the content is radiated as wide as possible.:
1. We send an email: "Thanks for being interested in GitLab. If we schedule a meeting it will follow the format on /handbook/ceo/#pick-your-brain-meetings Are you able to submit a draft post with us within 48 hours of interview?"
1. If we receive a positive answer we schedule a 50 minute Zoom video call or [visit to our boardroom](/visiting/) that is recorded by us, uploaded to Youtube as a private video, and shared with you.
1. If we receive a positive answer we schedule a 50 minute Zoom video call or [visit to our boardroom](/company/visiting/) that is recorded by us, uploaded to Youtube as a private video, and shared with you.
1. Within 48 hours you share a draft post with us in a Google Doc with suggestion or edit rights for anyone that knows the url.
1. You can redact anything you don't want to publish.
1. Our content department will work with you to publish the post within the agreed timeframe.
......
......@@ -49,7 +49,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 our [OKRs](/okrs/) are so ambitious that we expect to reach about 70% of the goal this is fine for shipping [planned features](/handbook/product/#ambitious-planning) too.
Just like our [OKRs](/company/okrs/) are so ambitious that we expect to reach about 70% of the goal this is fine for shipping [planned features](/handbook/product/#ambitious-planning) too.
_Note:_ This does not mean we place zero value on predictability. We just optimize for velocity first.
......@@ -66,9 +66,9 @@ When adding a repository please follow these steps:
1. Add a link to `CONTRIBUTING.md` from the project's `README.md`
## Access Requests
GitLab consists of many different type of applications and resources.
GitLab consists of many different type of applications and resources.
When you require escalated permissions or privileges to a resource to conduct task(s), or support for creating resource(s) with specific endpoints, please submit an issue to the [Access Requests Issue Tracker](https://gitlab.com/gitlab-com/access-requests/issues) using the template provided.
When you require escalated permissions or privileges to a resource to conduct task(s), or support for creating resource(s) with specific endpoints, please submit an issue to the [Access Requests Issue Tracker](https://gitlab.com/gitlab-com/access-requests/issues) using the template provided.
Below is a short list of supported technologies:
* For complete list, please see the issues template(s)
......@@ -186,7 +186,7 @@ It is important to remember that quality is everyone's responsibility. Everythi
## Error Budgets
In Q3 of 2018 we are trying [SRE](https://en.wikipedia.org/wiki/Site_Reliability_Engineering)-like error budgets in [OKRs](/okrs/2018-q3/) to incentivize risk management help and make GitLab.com ready for mission critical customer workloads.
In Q3 of 2018 we are trying [SRE](https://en.wikipedia.org/wiki/Site_Reliability_Engineering)-like error budgets in [OKRs](/company/okrs/2018-q3/) to incentivize risk management help and make GitLab.com ready for mission critical customer workloads.
Each backend and frontend development team will be responsible for preserving 100 points (or percent) of their budget this quarter. The severity of issues caused will subtract from their budget accordingly:
......
......@@ -30,12 +30,12 @@ GitLab.com is a production site with an availability OKR of 99.95% uptime, so a
approach to drive change into the environment is necessary, one which allows us to:
* dial in an optimal change speed to increase product velocity safety,
* maintain predictable levels of stability to support mission-critical workloads, and
* maintain predictable levels of stability to support mission-critical workloads, and
* contain the risk surface area so we can quickly address issues introduced by changes.
The overall strategy to meet this challenge is through CI/CD, which is in fact an important
feature of our product. While there is little or no disagreement on this approach, we have
found it difficult, as an organization, to get started. This blueprint is intended to produce
found it difficult, as an organization, to get started. This blueprint is intended to produce
a first step on the iterations towards CI/CD.
The end goal of this effort is to allow [GitLab Auto DevOps](https://about.gitlab.com/auto-devops/)
......@@ -47,15 +47,15 @@ Deployments to GitLab.com consist of Release Candidates (RCs) and Hot Patches (H
Release Candidates are, by definition, not fully production-ready code, and contain large
numbers of changes. Hot Patches address issues on GitLab.com that cannot wait for the next
release.
release.
#### Release Candidates
Whenever a RC is deployed to GitLab.com and causes instability, tracking and finding the
source of the problem in such large changesets can be difficult; once the source of a
source of the problem in such large changesets can be difficult; once the source of a
problem has been identified, a determination is made whether to fix the issue in-place
(through a hotpatch) or to wait for the next release candidate addressing the issue.
In either case, there is a waiting period to actually implement the fix, which happens
(through a hotpatch) or to wait for the next release candidate addressing the issue.
In either case, there is a waiting period to actually implement the fix, which happens
under the pressure of an ongoing incident.
![RC Deployments](0_RC.png)
......@@ -68,7 +68,7 @@ exacerbates the negative effects of this methodology on GitLab.com.
#### Hot Patches
Hot patches are lifesavers in that they allow us to address critical issues on the spot.
Yet their very existence is a sign that our development process is in need of change:
Yet their very existence is a sign that our development process is in need of change:
they exist because rolling back a RC is rarely possible and very labor intensive. They
are deployed through an entirely different process and come with their own set of dangers.
Most notably, we have experienced issues in which hotpatches applied to GitLab.com at a
......@@ -93,7 +93,7 @@ CI/CD. [Martin Heller](https://techbeacon.com/continuous-integration-answer-life
GitLab *builds* technology to implement CI/CD, and [we believe in dogfooding](/handbook/values/) our own product, so we already have *most of* the
technical answer and cultural driver to adopt CI/CD. We must contend with the remaining
challenges as outlined above. The first step is to translate those generic challenges
challenges as outlined above. The first step is to translate those generic challenges
into GitLab specifics.
We also face some special but not entirely unique challenges.
......@@ -105,10 +105,10 @@ deviates from this process slightly: it uses the same package install as custome
but they’re wrapped up in [`takeoff`](https://gitlab.com/gitlab-org/takeoff), which issues
`HUP`s and restarts the environment a bit differently. This methodology does not inherently
support hotpatches: self-managed customers do not require it as it is primarily used to
address significant issues on GitLab.com. Customers get security releases. The challenge
address significant issues on GitLab.com. Customers get security releases. The challenge
of adopting CI/CD is that it will likely entail breaking up this notion entirely in one
of two ways:
* GitLab.com and self-managed use completely different deployment methods
* Self-managed's delivery method changes to mimic that of GitLab.com
......@@ -123,9 +123,9 @@ solution to this challenge must support both speeds of delivery.
### Fail-Safe Mechanisms
Dogfooding is important to us but we must make a clear distinction between **dogfooding
Dogfooding is important to us but we must make a clear distinction between **dogfooding
the product** and **dogfooding the actual instance of the product**. Managing GitLab.com
through GitLab.com requires fail-safe mechanisms to allow us to recover GitLab.com in
through GitLab.com requires fail-safe mechanisms to allow us to recover GitLab.com in
case of a failure that would prevent us from operating GitLab.com itself. We have already
made some progress on this front, where our automation framework no longer depends on
GitLab.com itself to operate but on a separate GitLab instance.
......@@ -151,8 +151,8 @@ The second fundamental question is to determine if there is indeed a single solu
Quoting [ourselves](/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/):
> **Continuous Integration** is a software development practice in which you build and
> test software every time a developer pushes code to the application, and it happens
> **Continuous Integration** is a software development practice in which you build and
> test software every time a developer pushes code to the application, and it happens
> several times a day.
> **Continuous Deployment** is a software development practice in which every code change
......@@ -162,7 +162,7 @@ Quoting [ourselves](/2016/08/05/continuous-integration-delivery-and-deployment-w
There is ample literature on the benefits of adopting CI/CD. One particularly relevant quote for Infrastructure is from Martin Fowler:
> Continuous Integration doesn’t get rid of bugs, but it does make them dramatically
> Continuous Integration doesn’t get rid of bugs, but it does make them dramatically
> easier to find and remove.
This is, of course, aligned with our most important OKR for GitLab.com: its **availability**.
......@@ -178,10 +178,10 @@ and allowing for higher change velocity at higher levels of confidence and safet
We must adopt development practices such as:
* service versioning,
* rearchitecture through abstraction,
* rearchitecture through abstraction,
* feature flags, and
* evolutionary database design techniques.
From a cultural standpoint, we must move towards the mindset that **`master` is production**,
which entails understanding that all code in master must be production quality, and as such,
is code that should be able to be shipped to the production environment at any time.
......@@ -197,8 +197,8 @@ refocus on code written days ago is a significant context switch.
## CI/CD and Self-Managed
CI/CD is squarely geared towards GitLab.com, but it does not exclude self-managed. While we
will no longer be testing the normal distribution process that self-managed uses, it will
ensure the code has been extensively validated on GitLab.com, which is significant plus.
We can and will continue to support self-managed installation, upgrade and updates tools,
ensure the code has been extensively validated on GitLab.com, which is significant plus.
We can and will continue to support self-managed installation, upgrade and updates tools,
and we can and will continue to test them extensively, just not on GitLab.com.
## Alignment
......@@ -211,7 +211,7 @@ an even wider perspective than the one outlined in this blueprint (which, as not
Rather than putting together a grand plan to dogfood CI/CD, let's deploy our [values](/handbook/values/) to help us navigate through this transition:
* **Collaboration: Dogfooding** Let's dogfood GitLab's top-of-class CI/CD features.
* **Results: Write Promises Down** Let's commit [OKRs](/okrs/) on best-practice items we
* **Results: Write Promises Down** Let's commit [OKRs](/company/okrs/) on best-practice items we
know we must start thinking about: service versioning, feature flags and evolutionary
database design techniques, to name a few.
* **Results: Tenacity** Let's commit to this transition.
......@@ -221,5 +221,5 @@ Rather than putting together a grand plan to dogfood CI/CD, let's deploy our [va
* **Efficiency: Boring Solutions** Using GitLab CI/CD *is* a boring solution.
* **Efficency: Minimum Viable Change** Let's identify and deliver on MVCs.
* **Iteration: Make a Proposal** [Recursive](./).
* **Transparency: Public by Default** [Also recursive](./).
* **Transparency: Public by Default** [Also recursive](./).
......@@ -25,7 +25,7 @@ title: "GitLab General Guidelines"
- This makes them easier to find and suggest changes to with the organization and shows our commitment to open collaboration outside the organization.
- This means discussion and collaboration on this content should happen in issue comments or merge request comments.
1. When creating any content, create it **web-first**, as opposed to using Google slides, sheets, docs, etc, because they can only be found and contributed to by team members, and not by Users, Customers, Advocates, Google Handbook searches, or Developers.
1. We take ownership and start by creating an merge request. If you see something that needs to be improved submit a merge request. Don't tell someone else about the problem and expect them to start the merge request. "If you see something don't say something, if you see something create an MR."
1. We take ownership and start by creating an merge request. If you see something that needs to be improved submit a merge request. Don't tell someone else about the problem and expect them to start the merge request. "If you see something don't say something, if you see something create an MR."
1. Work out in the **open**, try to use public issue trackers and repositories when possible.
1. {: #not-public} Most things are **public** unless there is a reason not to. Not public by default are:
- security vulnerabilities
......@@ -40,7 +40,7 @@ title: "GitLab General Guidelines"
1. If you are unhappy with anything (your duties, your colleague, your boss, your salary, your location, your computer) please let your boss, or the CEO, know as soon as you realize it. We want to solve problems while they are **small**.
1. We want to have a great company so if you meet people that are **better** than yourself try to recruit them to join the company.
1. Make a conscious effort to **recognize** the constraints of others within the team. For example, sales is hard because you are dependent on another organization, and Development is hard because you have to preserve the ability to quickly improve the product in the future.
1. Please read and contribute to our [**strategy**](/strategy/).
1. Please read and contribute to our [**strategy**](/company/strategy/).
1. For each action or comment, it helps to ask yourself (i) does this help the company achieve its strategic goals? (ii) is this in the company's interest, and finally, (iii) how can I contribute to this effort/issue in a constructive way?
1. There is no need for **consensus**, make sure that you give people that might have good insights a chance to respond (by /cc'ing them) but make a call yourself because [consensus doesn't scale](https://twitter.com/sama/status/585950222703992833).
1. Everyone at the company cares about your **output**. Being away from the keyboard during the workday, doing private browsing or making personal phone calls is fine and encouraged.
......
......@@ -26,7 +26,7 @@ Give your agenda document four headers:
## OKRs
1. The Key Results for that report [from the OKRs](/okrs/) are the top of the document. This is the first thing to indicate that this is the focus and priority. Because we're a remote company there will be many small items on the agenda that in other environments would be handled throughout the week. It is important to periodically tell the report that the agenda should not be confused with the priorities. The Key Results is the only things that represents the priorities. The first business subject of every conversation should be the status of the top three priorities (the manager key results relevant to the report).
1. The Key Results for that report [from the OKRs](/company/okrs/) are the top of the document. This is the first thing to indicate that this is the focus and priority. Because we're a remote company there will be many small items on the agenda that in other environments would be handled throughout the week. It is important to periodically tell the report that the agenda should not be confused with the priorities. The Key Results is the only things that represents the priorities. The first business subject of every conversation should be the status of the top three priorities (the manager key results relevant to the report).
1. Review the OKRs every two weeks (every other meeting), it is very important that people don't confuse the details with priorities.
## Details
......
......@@ -30,7 +30,7 @@ Our personality is built around four main characteristics.
These four characteristics work together to form a personality that is authentic to GitLab team members, communioty, and relatable to our audience. If we were `quirky` without being `human` we could come across as eccentric. If we were `competent` without being `humble` we could come across as arrogant.
GitLab has a [higher purpose](/strategy/#mission). We want to inspire a sense of adventure in those around us so that they join us in contributing to making that mission a reality.
GitLab has a [higher purpose](/company/strategy/#mission). We want to inspire a sense of adventure in those around us so that they join us in contributing to making that mission a reality.
## Style guide and tone of voice
......@@ -234,7 +234,7 @@ The x-height also determines the proper spacing between icon and workdmark, as w
### The Tanuki
The [tanuki](https://en.wikipedia.org/wiki/Japanese_raccoon_dog) is a very smart animal that works together in a group to achieve a common goal. We feel this symbolism embodies GitLab's [vision](/about/#vision) that everyone can contribute, our [values](/about/#values), and our [open source stewardship](/2016/01/11/being-a-good-open-source-steward/).
The [tanuki](https://en.wikipedia.org/wiki/Japanese_raccoon_dog) is a very smart animal that works together in a group to achieve a common goal. We feel this symbolism embodies GitLab's [mission](/company/strategy/#mission) that everyone can contribute, our [values](/handbook/values/), and our [open source stewardship](/company/stewardship/).
### GitLab trademark & logo guidelines
......@@ -546,11 +546,11 @@ Email your request to sponsorships@gitlab.com (managed by [community advocacy te
* For printed materials (one pager, cheat sheets) please email events@gitlab.com.
* For larger swag orders (stickers in a quantity of 100 or greater), do not go through the swag store but rather use our [Stickermule](https://www.stickermule.com/) account or ping emily@gitlab.com. You will need the same information (address and order quantity).
* If you have items that need to be returned to the warehouse (Fulfillment Center, 700 W 48th Ave Unit C, Denver, CO 80216, please contact events@gitlab.com for the FexEx account number to create a return label. This option is only recommended if you have a very large number fo items or a booth setup (banner, tablecloth, backdrop) that need to be returned.
* If you have any issues with your order please email support@printfection.com with your concerns. This email can also be found at the bottom of your order confirmation.
* If you have any issues with your order please email support@printfection.com with your concerns. This email can also be found at the bottom of your order confirmation.
* GitLabbers- if you would like to order something from the GitLab swag shop we have a discount code you can use for 30% off. Please see the swag slack channel to get code to be used in the [store](https://shop.gitlab.com/) at checkout. It can be found in the channel description.
### Returning Swag to Warehouse
* If you have items that need to be returned to the warehouse (Fulfillment Center, 700 W 48th Ave Unit C, Denver, CO 80216, please contact events@gitlab.com for the FexEx account number to create a return label. This option is only recommended if you have a very large number fo items or a booth setup (banner, tablecloth, backdrop) that need to be returned.
* If you have items that need to be returned to the warehouse (Fulfillment Center, 700 W 48th Ave Unit C, Denver, CO 80216, please contact events@gitlab.com for the FexEx account number to create a return label. This option is only recommended if you have a very large number fo items or a booth setup (banner, tablecloth, backdrop) that need to be returned.
### Swag for customer/ prospects
Anyone with access to Salesforce can send swag through Salesforce directly. Please review [sending swag to customers paramaters](https://gitlab.com/gitlab-com/sales/issues/144). Instructions on how to do so below:
......@@ -616,8 +616,8 @@ Corporate handles the creating and ordering of all new swag. All swag designs sh
### How to add events to the [about.gitlab.com/events](/events/) page
In an effort to publicly share where people can find GitLab at events in person throughout the world, we have created [about.gitlab.com/events](/events). This page is to be updated by the person responsible for the event. To update the page, you will need to contribute to the [event master.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/events.yml).
If you need more information about our exact involment in an specific event please visit the marketing project in gitlab.com and search the name of the event for any realted issues. The "Meta" issue should include the most thorough and high level details about each event we are participating in.
In an effort to publicly share where people can find GitLab at events in person throughout the world, we have created [about.gitlab.com/events](/events). This page is to be updated by the person responsible for the event. To update the page, you will need to contribute to the [event master.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/events.yml).
If you need more information about our exact involment in an specific event please visit the marketing project in gitlab.com and search the name of the event for any realted issues. The "Meta" issue should include the most thorough and high level details about each event we are participating in.
#### Details to be included (all of which are mandatory in order for your MR to pass the build):
......
......@@ -30,7 +30,7 @@ Welcome to the People Operations handbook! You should be able to find answers to
- [Courses](/courses/)
- [Onboarding](/handbook/general-onboarding/)
- [Offboarding](/handbook/offboarding/)
- [OKRs](/okrs/)
- [OKRs](/company/okrs/)
- [People Operations Vision](/handbook/people-operations/people-ops-vision)
- [360 Feedback](/handbook/people-operations/360-feedback/)
- [Guidance on Feedback](/handbook/people-operations/guidance-on-feedback)
......@@ -79,7 +79,7 @@ If an ex team member acted in a malicious way against GitLab we'll do a company
## Boardroom addresses
{: #addresses}
- For the SF boardroom, see our [visiting](/visiting/) page.
- For the SF boardroom, see our [visiting](/company/visiting/) page.
- For the NL office, we use a postbox address listed in the "GitLab BV address" note in the Shared vault on 1Password. We use [addpost](https://www.addpost.nl) to scan our mail and send it along to a physical address upon request. The scans are sent via email to the email alias listed in the "Email, Slack, and GitLab Groups and Aliases" google doc.
- For the UK office, there is a Ltd registered address located in the "GitLab Ltd (UK) Address" note in the Shared vault on 1Password
- For the Germany office, there is a GmbH address located in the "GitLab GmbH Address" note in the Shared vault on 1Password
......
......@@ -127,8 +127,8 @@ which track labels beginning with `docs-`:
## Planning horizon
1. [Mission](/strategy/#mission): generation
1. [Strategy](/strategy/#sequence-): lustrum
1. [Mission](/company/strategy/#mission): generation
1. [Strategy](/company/strategy/#sequence-): lustrum
1. [Vision](/direction/product-vision/): year
1. [Milestones](/direction/#future-releases): quarter (we have issues assigned to specific release milestone for a rolling 3 months)
1. [Release](https://gitlab.com/gitlab-org/release-tools/blob/master/templates/monthly.md.erb): month (we try to not change the release that is started)
......@@ -619,7 +619,7 @@ if you're using feature branches, to one that works for other git strategies).
### Breadth over depth
See our thoughts on breadth over depth [on our strategy page](/strategy/#breadth-over-depth).
See our thoughts on breadth over depth [on our strategy page](/company/strategy/#breadth-over-depth).
### Prioritization
......@@ -647,7 +647,7 @@ split up, so that individual steps can be achieved within a single milestone.
New features are prioritized based on several factors:
- Is it a top project from the [OKRs](/okrs/)?
- Is it a top project from the [OKRs](/company/okrs/)?
- Does it bring our [vision](/direction/#vision) closer to reality?
- Does it help make our community safer though [moderation tools](https://gitlab.com/gitlab-org/gitlab-ce/issues/19313)?
- Is this something requested by many of our customers?
......@@ -874,7 +874,7 @@ deprecated state
### No artificial limits in Core
Per [GitLab Stewardship](/stewardship/#promises), we will not introduce _artificial_ limits in Core. Artificial means
Per [GitLab Stewardship](/company/stewardship/#promises), we will not introduce _artificial_ limits in Core. Artificial means
arbitrarily setting a small number (such as: 1) as a limit on a given GitLab object category,
that would incur _no additional_ effort or cost had we chosen a larger number. The additional
effort includes product, design, and engineering effort to create the feature in the first place,
......@@ -1538,7 +1538,7 @@ about the problem to be solved in the first place. Offer directions on
what could be done instead. If she's not willing to do it, indicate that you will
have to close the issue/merge request because it will go nowhere.
* Brings an Enterprise exclusive feature to the Community Edition: this problem
is already addressed in the [Stewardship page](/stewardship/#contributing-an-existing-ee-feature-to-ce).
is already addressed in the [Stewardship page](/company/stewardship/#contributing-an-existing-ee-feature-to-ce).
Indicate that we will investigate whether the feature can be ported to the
Community Edition, discuss it with other teams members and come back to the user
in a timely fashion.
......@@ -1719,7 +1719,7 @@ even though their language in the office is different.
When talking about why a certain change goes into a Paid tier instead of Core, mention the [stewardship page][stewardship] in the handbook
directly and link to it.
[stewardship]: /stewardship/#what-features-are-paid-only
[stewardship]: /company/stewardship/#what-features-are-paid-only
### Stewardship
......
......@@ -21,7 +21,7 @@ Therefore this pricing page is in the product handbook.
## Four tiers
We have four pricing tiers.
How we make decisions on a day to day basis are specified on our [stewardship page](/stewardship/#what-features-are-paid-only).
How we make decisions on a day to day basis are specified on our [stewardship page](/company/stewardship/#what-features-are-paid-only).
| Self-managed tier | Core | Starter | Premium | Ultimate |
| GitLab.com | Free | Bronze | Silver | Gold |
......@@ -62,7 +62,7 @@ Most companies in a similar situation would focus only on the highest tiers.
There will be pressure to increase our lowest tier to for example $8.
But we want to make a our hybrid model work for the following reasons:
1. We want to keep being a [good steward of the open source project](/stewardship/).
1. We want to keep being a [good steward of the open source project](/company/stewardship/).
1. The lower two tiers are a scalable way to create future customers.
1. If organization are already using Atlassian JIRA we want to be competitive with BitBucket on pricing. If they buy BitBucket it is hard for us to win them back. If they buy GitLab they discover that it can replace JIRA and over time they might buy a higher tier.
......@@ -189,7 +189,7 @@ Most companies evolve in the following way:
An example is Microsoft Office where it is costly to buy components of Office365 separately, although higher tiers include more products.
At GitLab we decided to skip the intermediate steps and immediately only offer a suite that includes all our products.
Having our complete scope included in our open source version is even part of our [stewardship promises](/stewardship/#promises).
Having our complete scope included in our open source version is even part of our [stewardship promises](/company/stewardship/#promises).
Selling only a suite has risks, after the => is how we mitigate those at GitLab:
......@@ -259,7 +259,7 @@ Alternatives that don't work:
1. [Scope and size](#value-capture) don't work.
1. Pricing based on maturity is strange because organizations at the beginning of their journey should pay the most, since in a greenfield you benefit the most quickly and extensively from GitLab.
Apart from this framework we also need to keep our [stewardship promises](/stewardship/#what-features-are-paid-only).
Apart from this framework we also need to keep our [stewardship promises](/company/stewardship/#what-features-are-paid-only).
Please we owe it to our users to only move features from higher paid tiers to lower ones, not the other way.
This means that when in doubt we will select the higher tier and move it down later if data shows that this is better.
It also means that all tier changes will involve moving things to lower plans.
......
......@@ -31,7 +31,7 @@ title: "Stock Options"
> stock option grants at its sole discretion including the decision not to make
> a grant at all.
## Promotions
## Promotions
If you are promoted, you are eligible to receive a new stock option grant for the
difference between your old level and your new level based on the grant levels currently in effect.
......@@ -140,7 +140,7 @@ a successful IPO. We want to motivate and reward our people for reaching that go
window extensions only on a case by case basis at our discretion. An example of a situation we'll consider is a valued
team member quitting because of personal circumstances. In most cases there will be no extension and you will either have
to pay for shares and the taxes yourself or lose the options, even when you are fully vested. And of course [an IPO in 2020
is our public ambition](/strategy/) but neither timing or if it happens at all is guaranteed.
is our public ambition](/company/strategy/) but neither timing or if it happens at all is guaranteed.
## Administration
......
......@@ -21,7 +21,7 @@ title: Support Handbook
## <i class="fas fa-question-circle fa-fw icon-color font-awesome" aria-hidden="true"></i> Support Direction
The overall direction for Support in 2018 is set by our overall [strategic objectives](/strategy), with a particular emphasis on continued improvement of (Premium) Customer satisfaction. As can also be inferred from our [publicly visible OKR page](/okrs/), the effort focuses on the following elements.
The overall direction for Support in 2018 is set by our overall [strategic objectives](/strategy), with a particular emphasis on continued improvement of (Premium) Customer satisfaction. As can also be inferred from our [publicly visible OKR page](/company/okrs/), the effort focuses on the following elements.
**Triaging Support Effort**
......@@ -113,7 +113,7 @@ If you're on the Support Team and have something you'd like to surface, or would
| Recruiting | Nadia Vatalidis | Tom Cooney | weekly |
| Docs | Docs Team | Tom Atkins | every 2 weeks join docs meeting |
| Sales + CS | EMEA Sales/CS | Tom Atkins | weekly on Fri join EMEA scrum |
## Time Off
The Support Team follows [GitLab's paid time off policy](/handbook/paid-time-off). However, do note that if a large number of people are taking the same days off, you may be asked to reschedule. If a holiday is important to you, please schedule it early.
......
......@@ -41,7 +41,7 @@ We do what we promised to each other, customers, users, and investors.
1. **Measure results not hours** We care about what you achieve; the code you shipped, the user you made happy, and the team member you helped. Someone who took the afternoon
off shouldn't feel like they did something wrong. You don't have to defend how you spend your day. We trust team members to do the right thing instead of having rigid rules. Do not incite competition by proclaiming how many hours you worked yesterday. If you are working too long hours talk to your manager to discuss solutions.
1. **Write promises down** Agree in writing on measurable goals. Within the company we use [public OKRs](/okrs/) for that.
1. **Write promises down** Agree in writing on measurable goals. Within the company we use [public OKRs](/company/okrs/) for that.
1. **Growth mindset** You don't always get results and this will result in criticism from yourself and/or others. We believe our talents can be developed through hard work, good strategies, and input from others. We try to hire people based on [their trajectory, not their pedigree](https://hbr.org/2016/01/what-having-a-growth-mindset-actually-means).
1. **Global optimization** This name comes from the [quick guide to Stripe's culture](https://stripe.com/us/jobs/candidate-info?a=1#culture). Our definition of global optimization is that you do what is best for the organization as a whole. Don't optimize for the goals of your team when it negatively impacts the goals of other teams, our users, and/or the company. Those goals are also your problem and your job. Keep your team as lean as possible, and help other teams achieve their goals.
1. **Tenacity** We refer to this as "persistence of purpose". As talked about in [The Influence Blog](https://www.learntoinfluence.com/developing-tenacity-when-facing-opposition/) tenacity is the ability to display commitment to what you believe in. You keep picking yourself up, dusting yourself off, and quickly get going again having learned a little more.
......@@ -73,7 +73,7 @@ We care about working on the right things, not doing more than needed, and not d
The community consists of people from all over the world, with different backgrounds and opinions. We hire globally and encourage hiring in a diverse set of countries. We work to make everyone feel welcome and to increase the participation of underrepresented minorities and nationalities in our community and company. For example our sponsorship of [diversity events](/2016/03/24/sponsorship-update/) and a [double referral bonus](/handbook/incentives/#referral-bonuses).
1. **Culture fit is a bad excuse** We don't hire based on culture or select candidates because we'd like to have a drink with them. We hire and reward employees based on our shared values as detailed on this page. If they are measured against our shared values, they will already be a fit.
We want cultural diversity instead of cultural conformity, for example, a [brogrammer](https://en.wikipedia.org/wiki/Brogrammer) atmosphere. Said differently: ["culture add" > "culture fit"](https://twitter.com/Una/status/846808949672366080) or "hire for culture contribution" since our [mission is everyone can contribute](/strategy/#mission).
We want cultural diversity instead of cultural conformity, for example, a [brogrammer](https://en.wikipedia.org/wiki/Brogrammer) atmosphere. Said differently: ["culture add" > "culture fit"](https://twitter.com/Una/status/846808949672366080) or "hire for culture contribution" since our [mission is everyone can contribute](/company/strategy/#mission).
1. **Don't bring religion or politics to work** We don't discuss religion or politics because it is easy to alienate people that have a minority opinion. Feel free to mention you attended a ceremony or rally, but don't mention the religion or party.
1. **Quirkiness**: Unexpected and unconventional things make life more interesting.
Celebrate and encourage quirky gifts, habits, behavior, and points of view. An example
......@@ -206,4 +206,4 @@ During every [GitLab 101 session with new hires](/culture/gitlab-101/) we discus
## Mission
Our [mission](/strategy/#mission) guides our path, during this path live our values.
Our [mission](/company/strategy/#mission) guides our path, during this path live our values.
......@@ -50,7 +50,7 @@
.col-sm-6.col-md-2.col-lg-2.footer-link-holder
%h3.footer-link-title Company
%ul.animated.footer-links
%li= link_to('About Us', '/about/', :class => 'footer-nav-link')
%li= link_to('About GitLab', '/company/', :class => 'footer-nav-link')
%li= link_to('Jobs', '/jobs/', :class => 'footer-nav-link')
%li= link_to('Culture', '/culture/', :class => 'footer-nav-link')
%li= link_to('Press', '/press/', :class => 'footer-nav-link')
......@@ -58,7 +58,7 @@
%li= link_to('Analyst Relations', '/analysts/', :class => 'footer-nav-link')
%li= link_to('Security', '/security/', :class => 'footer-nav-link')
%li= link_to('Handbook', '/handbook/', :class => 'footer-nav-link')
%li= link_to('Strategy', '/strategy/', :class => 'footer-nav-link')
%li= link_to('Strategy', '/company/strategy/', :class => 'footer-nav-link')
%li= link_to('Terms', '/terms/', :class => 'footer-nav-link')
%li= link_to('Privacy', '/privacy/', :class => 'footer-nav-link')
......
......@@ -37,16 +37,13 @@
%a.main-nav-sub-link{href: "/pricing/#self-managed"} Self-managed
%a.main-nav-sub-link{href: "/pricing/#gitlab-com"} GitLab.com
%li{class: ("menu-item-active" if current_page.url == "/Company/")}
%a.main-nav-link{href: "/about/"} Company
%a.main-nav-link{href: "/company/"} About GitLab
.dropdown
%a.main-nav-sub-link{href: "/about"} About us
%a.main-nav-sub-link{href: "/jobs/"} Jobs
%a.main-nav-sub-link{href: "/culture/"} Culture
%a.main-nav-sub-link{href: "/press/"} Press
%a.main-nav-sub-link{href: "/analysts/"} Analyst Relations
%a.main-nav-sub-link{href: "/handbook/"} Handbook
%a.main-nav-sub-link{href: "/strategy/"} Strategy
%a.main-nav-sub-link{href: "/terms/"} Terms
%li
%button.search-icon.js-search-toggle{ type: "button", "aria-label" => "Search" }
%i.fa.fa-search
......
......@@ -18,7 +18,7 @@
- Build and lead the team of Support Engineers by actively seeking and hiring globally distributed talent
- Lead team meetings, conduct 1:1's, and continuously improve the onboarding and training process / experience.
- Develop and implement data-driven tactics to deliver on the strategic goals for Support, as set out on the overall team's [strategy](/strategy/) page as well as outlined in the [direction for Support](/handbook/support/#support-direction).
- Develop and implement data-driven tactics to deliver on the strategic goals for Support, as set out on the overall team's [strategy](/company/strategy/) page as well as outlined in the [direction for Support](/handbook/support/#support-direction).
- Develop and use various analytics to review the Support Engineering team performance - from individual to group - and adjust processes or provide mentorship as needed to improve performance and enjoyment.
- Organize and maintain the [on-call schedule](/handbook/on-call/) for customer emergencies.
- Construct and monitor metrics to maintain customer and user SLA's, and customer experience.
......
......@@ -21,7 +21,7 @@ As the Services Support Manager, you will be responsible for making sure that Gi
- Create a sense of psychological safety on their team
- Develop onboarding and training process for new Service Support Agents.
- Fully capable and excited to step into the role of a [Support Engineer](/job-families/engineering/support-engineer/) when needed.
- Develop and implement data-driven tactics to deliver on the strategic goals for Support, as set out on the overall team's [strategy](/strategy/) page as well as outlined in the [direction for Support](/handbook/support/#support-direction).
- Develop and implement data-driven tactics to deliver on the strategic goals for Support, as set out on the overall team's [strategy](/company/strategy/) page as well as outlined in the [direction for Support](/handbook/support/#support-direction).
- Develop and use analytics to measure and improve the Services Support team
- Provide mentorship as needed to improve performance and enjoyment.
- Construct and monitor metrics to maintain customer and user SLA's
......
......@@ -70,4 +70,4 @@ In our policy, we focused on all of the things we have promised we won’t do. W
We invite members of the community to read the policy. With this policy published, they will be able to hold us accountable.
Please read [“Our stewardship of GitLab CE”](/stewardship/).
Please read [“Our stewardship of GitLab CE”](/company/stewardship/).
......@@ -45,4 +45,4 @@ Merge requests to suggest improvements to the Strategy document are welcome.
[stewardship]: /2016/01/11/being-a-good-open-source-steward/
[direction]: /direction/
[handbook]: /handbook/
[strategy]: /strategy/
[strategy]: /company/strategy/