Fix broken links

  - pattern: '^/videos/'

  - pattern: '^/images/'

  # The team page uses the `{{< team >}}` shortcode, so most anchors cannot be found by hugolint.

  - pattern: '^/handbook/company/team/?#'

  # The product categories page uses the `{{% categories %}}` shortcode, creating per-group headings.

  - pattern: '^/handbook/product/categories/?#'

  # The "Features by Group" page uses the `{{% categories-features %}}` shortcode, creating dynamic headings.

  - pattern: '^/handbook/product/categories/features/?#'

  # Pages using the `{{% performance-indicators %}}` shortcode.

  - pattern: '^/handbook/ceo/office-of-the-ceo/performance-indicators/?#'

  - pattern: '^/handbook/engineering/development/performance-indicators/?#'

  - pattern: '^/handbook/product/ux/performance-indicators/?#'

  - pattern: '^/handbook/support/performance-indicators/?#'

  # Pages using the `include` shortcode.

# Other pages where the majority of the content is generated from a shortcode

  - pattern: '^/handbook/#'

  - pattern: '^/handbook/business-technology/tech-stack/?#'

  - pattern: '^/handbook/company/team/?#'

  - pattern: '^/handbook/product/categories/?#'

  - pattern: '^/handbook/product/categories/features/?#'

  - pattern: '^/handbook/engineering/okrs/?#'

## Handbook Contents

{{< cardpane >}}

{{< card >}}

{{< handbook-data-toc >}}

{{< /card >}}

{{< /cardpane >}}

{{% include "includes/take-gitlab-for-a-spin.md" %}}

AMAs are generally coordinated, scheduled, and planned by the [Executive Business Administrator](/handbook/eba/) team when an E-Group member is the host. Anytime that an AMA is to be hosted by an executive, VP, or Director at GitLab, it should be arranged and scheduled by that functions EBA. AMAs of Board Members are scheduled by the Staff EBA to the CEO.

Other non-Executive AMAs are scheduled by the [People Operations](/handbook/people-group/#people-experience-vs-people-operations-core-responsibilities--response-timeline) team. These AMAs are typically a result of a change that impacts the company as a whole and may often be hosted by multiple leadership members in the company. Whenever there is an open slot in the Group Conversation calendar, the People Operations Team will reach out to the EBA team to create an AMA.

Other non-Executive AMAs are scheduled by the [People Operations](/handbook/people-group/#people-connect-responsibilities--response-timeline) team. These AMAs are typically a result of a change that impacts the company as a whole and may often be hosted by multiple leadership members in the company. Whenever there is an open slot in the Group Conversation calendar, the People Operations Team will reach out to the EBA team to create an AMA.

When scheduling an AMA, be mindful of timezones.  Generally it is best to have two AMAs, one for the Americas/EMEA time zone, and one for the APAC time zones.

| `#mr-buddies`                        | For any questions regarding merge requests.                                                                                                                                                                                          |

| `#new_team_members`                  | For new GitLab team members to introduce themselves to the company and for existing team members to share updates with new hires.                                                                                                    |

| `#new-vacancies`                  | For all GitLab team members to be aware of internal opportunities, as well as all job openings as they are listed. Please review the [referral process](/handbook/hiring/referral-process/) page to find out more about referring someone for a role.                                                                                                   |

| `#payroll`                           | For questions pertaining to [payroll](/handbook/finance/payroll/) and [contractor invoices](/handbook/finance/payroll/#non-us) (e.g. ADP, etc.).                                                                                     |

| `#payroll`                           | For questions pertaining to [payroll](/handbook/finance/payroll/) and [contractor invoices](https://internal.gitlab.com/handbook/finance/payroll/#non-us) (e.g. ADP, etc.).                                                                                     |

| `#safe`                            | SAFE                                                                                  |

| `#security`                            | Security                                                                                  |

| `#talent-acquisition`                | For questions about [referrals](/handbook/hiring/referral-process/), the [hiring process](/handbook/hiring/), and/or candidate status.                                                                                               |

#### Group Channels (g_)

Group channels (prefixed with a `g_`) correspond to a [DevOps Stage group](/handbook/product/categories/#hierarchy) and other [engineering departments and teams](/handbook/engineering/#engineering-departments--teams).

Group channels (prefixed with a `g_`) correspond to a [DevOps Stage group](/handbook/product/categories/#hierarchy) and other [engineering departments and teams](/handbook/engineering/#engineering-departments).

**Example**

To achieve fair value with limited relative volatility as a publicly traded company, we are focused on the following:

1. Ability to meet the quarter close schedule outlined on the [Investor Relations](/handbook/finance/investor-relations/#earnings-release-calendar-workback-schedule) page

1. Ability to meet the quarter close schedule outlined on the [Investor Relations](/handbook/finance/investor-relations/) page

1. Consistent execution against key operating metrics and initiatives

1. Demonstrate a reliable trajectory of revenue growth to operating cash flow that aligns to our target [operating model](/handbook/finance/financial-planning-and-analysis/#long-term-profitability-targets) and hypergrowt objectives

1. Demonstrate a reliable trajectory of revenue growth to operating cash flow that aligns to our target [operating model](/handbook/finance/financial-planning-and-analysis/#long-range-outlook-lro) and hypergrowt objectives

1. Assessing the maturity of our model in conjunction with equity market volatility to determine an appropriate time for a public offering

1. Building out a fulsome compliance program which includes: securities law trainings, communications policies, handbook adjustments, required policies such as insider / [trading window](/handbook/finance/investor-relations/#trading-window)

1. Maintaining a high degree of [transparency](/handbook/values/#transparency) that we believe increases contributions and makes collaboration easier. This is a core value and may result in higher than expected volatility.

1. Size of [total addressable market](/handbook/sales/tam/)

1. Consistency of execution

1. [Competitive position](https://internal.gitlab.com/handbook/leadership/mitigating-concerns/#introduction)

1. Clarity of [value proposition](/handbook/company/strategy/#organization)

1. Clarity of [value proposition](/handbook/company/strategy/)

1. Perception of management [team](/handbook/company/team/)

As GitLab team members, delivering on our annual plan and long-term strategy are the most productive ways to contribute to the company achieving full, fair value with limited relative volatility. At a departmental level, we have [key performance indicators](/handbook/company/kpis/#what-are-kpis) aligned to our plan and performance to empower "everyone to contribute" to GitLab's long term success and public market valuation.

## Transparency

1. Transparency is a [core value of GitLab](/handbook/values/#transparency).

1. We want to maintain the same overall level of transparency as a public company that we have as a private company. For example, indicators of revenue such as our [win rate](/handbook/sales/#win-rate) will no longer be accessible externally, but in other areas transparency will be increased: financial profile.

1. We want to maintain the same overall level of transparency as a public company that we have as a private company. For example, indicators of revenue such as our win rate will no longer be accessible externally, but in other areas transparency will be increased: financial profile.

1. There are high expectations to do what you say. With our level of transparency people may not be used to how much we say, and we will be held to a new level of expectations on what we do.

1. When we are required to publicly release quarterly financials, we may be required to adjust the timing of or level of detail associated with certain key metrics.