Commit a7779873 authored by Tony Kwok's avatar Tony Kwok 💬

resolving team url changes in content

parent 33fb756a
Pipeline #34485723 passed with stages
in 28 minutes and 56 seconds
......@@ -408,7 +408,7 @@ features:
This month, we're glad to announce two new great tutorials:
- [How to deploy Maven projects to Artifactory with GitLab CI/CD](https://docs.gitlab.com/ee/articles/artifactory_and_gitlab/), by our Senior Product Manager [Fabio Busatto](/team/#bikebilly).
- [How to deploy Maven projects to Artifactory with GitLab CI/CD](https://docs.gitlab.com/ee/articles/artifactory_and_gitlab/), by our Senior Product Manager [Fabio Busatto](/company/team/#bikebilly).
- [Numerous _undo_ possibilities in Git](https://docs.gitlab.com/ee/articles/numerous_undo_possibilities_in_git/), by the Community Writer [Crt Mori](https://gitlab.com/Letme).
Would you like to contribute as well? Please do! Check our
......
......@@ -84,7 +84,7 @@ title: "2018 Q4 OKRs"
* Monitor:
* Preserve 100% of [error budget]: 100% ()
* Merge smaller changes more frequently: > 6 average MRs merged per week
* [Kamil](https://about.gitlab.com/team/#ayufanpl):
* [Kamil](https://about.gitlab.com/company/team/#ayufanpl):
* Improve scalability: Reduce CI database footprint as part of [Ensure CI/CD can scale in future](https://gitlab.com/gitlab-org/gitlab-ce/issues/46499) with [Use BuildMetadata to store build configuration in JSONB form](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21499).
* Continuous Deployment: Help with building CD features needed to continously deploy GitLab.com by closing 5 [issues related to Object Storage](https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name=Object%20Storage) that are either ~"technical debt" or ~"bug"
* Infrastructure: Make GitLab.com ready for mission critical workloads
......
......@@ -23,7 +23,7 @@ image_title: /images/team.jpg
The GitLab Inc. team consists of the following
%strong #{team_size} team members
and their
#{link_to("#{data.pets.size} pets", '/team-pets')}.
#{link_to("#{data.pets.size} pets", '/company/team-pets')}.
We're a #{link_to('remote only', 'http://www.remoteonly.org/')} organization
and we currently have team members in #{link_to(Gitlab::Homepage::Team.new.countries.size.to_s + " countries and regions", "#countries")}.
This page lists who people report to, and on a separate page we
......
......@@ -36,7 +36,7 @@ Some of individual contributors (without any direct reports) have manager in the
## Specialists, experts, and mentors
People can be a specialist in one thing and be an expert in multiple things. These are listed on the [team page](/team/).
People can be a specialist in one thing and be an expert in multiple things. These are listed on the [team page](/company/team/).
### Specialist
......@@ -47,7 +47,7 @@ You can be a specialist in only one topic.
The specialist description is a paragraph in the job description for a certain title.
A specialist is listed after a title, for example: Developer, database specialist (do not shorten it to Developer, database).
Many specialties represent stable counterparts. For instance, a "Test Automation Engineer, Create" specializes in the "Create" [stage group](#stage-groups) and is dedicated to that group.
The if you can have multiple ones and/or if you don't spend the majority of your time there it is probably an [expertise](/team/structure/#expert).
The if you can have multiple ones and/or if you don't spend the majority of your time there it is probably an [expertise](/company/team/structure/#expert).
Since a specialist has the same job description as others with the title they have the same career path and compensation.
### Expert
......
......@@ -458,7 +458,7 @@ There are two types of code names:
At GitLab we use ubiquitous language to increase communication efficiency.
This is defined in [Domain-driven design](https://en.wikipedia.org/wiki/Domain-driven_design) as: "A language structured around the domain model and used by all team members to connect all the activities of the team with the software.".
We use it for activities in GitLab, even ones not implemented in software.
By having ubiquitous words to identify concepts we prevent confusion over what is meant, for example we refer to [parts of our organization](/team/structure/) as a function, department, or group depending on exactly what is meant.
By having ubiquitous words to identify concepts we prevent confusion over what is meant, for example we refer to [parts of our organization](/company/team/structure/) as a function, department, or group depending on exactly what is meant.
Make sure that domains don't overlap, for example [organization size](/handbook/sales/#organization-size) and [deal size](/handbook/sales/#deal-sizes) don't reuse words to prevent overlap.
If a term is ambiguous don't use it, for example our [hiring definitons](/handbook/hiring/#definitions) have roles and vacancies but avoid the ambiguous word job.
Make sure that people can infer as much as possible from the word, for example our [subscription options](/handbook/marketing/product-marketing/#tiers) allow you to know if someone if using self-managed or GitLab.com.
......
......@@ -13,7 +13,7 @@ title: "Engineering Manager, Distribution and Delivery"
Inspired by the [CEO page](https://about.gitlab.com/handbook/ceo/) and [Director of Dev Backend readme](/handbook/engineering/dev-backend/director/),
this page is a readme for the current Engineering Manager of Distribution and Delivery teams,
[Marin Jankovski](/team/#maxlazio).
[Marin Jankovski](/company/team/#maxlazio).
## Team(s)
......
......@@ -56,7 +56,7 @@ The following people are members of the Distribution Team:
### Stable counterparts
The following members of other functional teams are our [stable counterparts](https://about.gitlab.com/team/structure/#stage-groups):
The following members of other functional teams are our [stable counterparts](https://about.gitlab.com/company/team/structure/#stage-groups):
<%= stable_counterparts(role_regexp: /[,&] Distribution/, direct_manager_role: 'Engineering Manager, Distribution & Release Management') %>
......
......@@ -10,7 +10,7 @@ This page was inspired by the recent trend of Engineering Manager README's. _e.g
My name is Eric Johnson and I'm the VP of Engineering at GitLab.
* [GitLab Handle](https://gitlab.com/edjdev)
* [Team Page](/team/#edjdev)
* [Team Page](/company/team/#edjdev)
Here are some things about me that may help us collaborate effectively:
......
......@@ -26,16 +26,16 @@ title: "Frontend Department"
You have a question concerning the frontend for a product area? As a product manager you want to run a new idea by a frontend engineer? You want to learn more about how the current implementation works? You have specific frontend technology questions or have some idea/inputs?
**Wait no more, here are our frontend domain experts who can help you out**
- CI/CD + Security product - [Filipa Lacerda](/team/#FilipaLacerda)
- Discussion + MR View - [Fatih Acet](/team/#fatihacet)
- Portfolio Management + Geo - [Kushal Pandya](/team/#Kushal_Pandya)
- Web IDE - [Phil Hughes](/team/#iamphill)
- CI/CD + Security product - [Filipa Lacerda](/company/team/#FilipaLacerda)
- Discussion + MR View - [Fatih Acet](/company/team/#fatihacet)
- Portfolio Management + Geo - [Kushal Pandya](/company/team/#Kushal_Pandya)
- Web IDE - [Phil Hughes](/company/team/#iamphill)
Technical:
- Security - [Filipa Lacerda](/team/#FilipaLacerda)
- Testing - [Winnie Hellmann](/team/#winh)
- UI Components - [Clement Ho](/team/#ClemMakesApps)
- Webpack + Tooling - [Mike Greiling](/team/#mikegreiling)
- Security - [Filipa Lacerda](/company/team/#FilipaLacerda)
- Testing - [Winnie Hellmann](/company/team/#winh)
- UI Components - [Clement Ho](/company/team/#ClemMakesApps)
- Webpack + Tooling - [Mike Greiling](/company/team/#mikegreiling)
**They are responsible for**
- Person to contact about a specific topic
......
......@@ -234,7 +234,7 @@ These guidelines also describe who would need to review, approve and merge your
All GitLab developers can, and are encouraged to, perform code review on merge requests of colleagues and community contributors. If you want to review merge requests, you can wait until someone assigns you one, but you are also more than welcome to browse the list of open merge requests and leave any feedback or questions you may have.
To let other developers know that you are interested in performing code reviews, you can add this to your [team page entry](/team/) by editing [`data/team.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/team.yml).
To let other developers know that you are interested in performing code reviews, you can add this to your [team page entry](/company/team/) by editing [`data/team.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/team.yml).
You can find someone to review your own merge requests by looking on the [team page](/company/team/), or on the list of [GitLab Engineering Projects](/handbook/engineering/projects/), both of which are fed by `data/team.yml`.
......@@ -252,7 +252,7 @@ Great developers are often also great reviewers, but code review is a skill in a
To protect and ensure the quality of the code base and the product as a whole, people become maintainers only once they have convincingly demonstrated that their reviewing skills are at a comparable level to those of existing maintainers.
As with regular reviewers, maintainers can be found on the [team page](/team/), or on the list of [GitLab Engineering Projects](/handbook/engineering/projects/).
As with regular reviewers, maintainers can be found on the [team page](/company/team/), or on the list of [GitLab Engineering Projects](/handbook/engineering/projects/).
#### How to become a maintainer
......
......@@ -68,7 +68,7 @@ people resources is higher the closer said resources are to the environment.
### Stable Counterparts
Every SRE is aligned with an engineering team. Each SRE can help the teams at each stage of the process. Planning, discovery, implementation, and further iteration. The area an SRE is responsible for is part of their title, e.g. "SRE, Plan, Monitor." You can see which area of the product each SRE is aligned with in the [team org chart](company/team/chart/).
Every SRE is aligned with an engineering team. Each SRE can help the teams at each stage of the process. Planning, discovery, implementation, and further iteration. The area an SRE is responsible for is part of their title, e.g. "SRE, Plan, Monitor." You can see which area of the product each SRE is aligned with in the [team org chart](company/team/org-chart/).
Multiple SREs are aligned with areas of the product. This area will be listed on the [team page](/company/team/) under their title as an expertise, e.g. "Plan expert." This way there is a team of SREs available to provide help in the case that another is out of the office or busy with another incident or team.
......
......@@ -82,7 +82,7 @@ We'll organize our work into 2 week [milestones](https://gitlab.com/gitlab-com/i
1. Give us a timebox to gain some measure of velocity over time.
1. Give us a window of time to focus on a particular team for planned work. As themes go, it is better to try to focus on one theme for a few time boxes rather than start 3 things and not finish any.
1. Ideally, as we have more clarity on velocity 50-60% of a milestone's velocity will be scheduled/known work while the remaining work will be room for emergent or toil related work.
1. Ideally, as we have more clarity on velocity 50-60% of a milestone's velocity will be scheduled/known work while the remaining work will be room for emergent or toil related work.
1. We will hold monthly async planning sessions to pick the particular areas the team will focus on
1. Issues that fit the theme will be scheduled into milestones as velocity allows.
......@@ -92,7 +92,7 @@ There will always be a "Current Milestone" and a "Next Milestone". This way whe
When a milestone is complete, we'll rename the finished milestone to the YYYY-MM-DD Milestone and update the Current and Next milestones.
We also want to value handing off issues to take advantage of the many timezones our team covers. An issue may be started by any team member in any timezone, but we can mark an issue with ~Ready_to_Handoff for issues that can go to someone in another timezone. If we mark an issue with the ~Ready_to_Handoff label, it should have clear notes about where it is being left off and next steps. Handing off is not required, anyone can own an issue to completion too, but we want to be able communicate and work across the many people on our team were it makes sense.
We also want to value handing off issues to take advantage of the many timezones our team covers. An issue may be started by any team member in any timezone, but we can mark an issue with ~Ready_to_Handoff for issues that can go to someone in another timezone. If we mark an issue with the ~Ready_to_Handoff label, it should have clear notes about where it is being left off and next steps. Handing off is not required, anyone can own an issue to completion too, but we want to be able communicate and work across the many people on our team were it makes sense.
The Milestones will run from a Monday to a Friday that is 12 days away. The Milestone will be named with the Month and End date of the timebox. For example August Milestone 2 - ending 2018-08-24.
......@@ -103,7 +103,7 @@ We do standups with [a bot](https://geekbot.io/dashboard/standup/25831/view) tha
Retros:
We are testing async retros with [another bot](https://geekbot.io/dashboard/standup/26259/view) that happens the second Wednesday of our milestone. Updates from that retro will again go to our slack channel.
A summary will also be made so that we can vote on important issues to talk about in more depth. These can then help us update our themes for milestones.
A summary will also be made so that we can vote on important issues to talk about in more depth. These can then help us update our themes for milestones.
## Why `infrastructure` and `production` queues?
......@@ -255,7 +255,7 @@ Ongoing outages, as well as issues that have the `~(perceived) data loss` label
## On-Call Support
To ensure 24x7 coverage of emergency issues, we currently have split on-call rotations between EMEA and AMER regions; team members in [EMEA](https://en.wikipedia.org/wiki/List_of_country_groupings) regions are on-call from 0400-1600 UTC, and team members in [AMER](https://en.wikipedia.org/wiki/List_of_country_groupings) regions are on-call from 1600-0400 UTC. We plan to extend this to include team members from the [APAC](https://en.wikipedia.org/wiki/List_of_country_groupings) region in the future, as well. This forms the basis of a [follow-the-sun](https://en.wikipedia.org/wiki/Follow-the-sun) support model, and has the benefit for our team members of reducing (or eliminating) the stress of responding to emergent issues outside of their normal work hours, as well as increasing communication and collaboration within our [global team](https://about.gitlab.com/team/).
To ensure 24x7 coverage of emergency issues, we currently have split on-call rotations between EMEA and AMER regions; team members in [EMEA](https://en.wikipedia.org/wiki/List_of_country_groupings) regions are on-call from 0400-1600 UTC, and team members in [AMER](https://en.wikipedia.org/wiki/List_of_country_groupings) regions are on-call from 1600-0400 UTC. We plan to extend this to include team members from the [APAC](https://en.wikipedia.org/wiki/List_of_country_groupings) region in the future, as well. This forms the basis of a [follow-the-sun](https://en.wikipedia.org/wiki/Follow-the-sun) support model, and has the benefit for our team members of reducing (or eliminating) the stress of responding to emergent issues outside of their normal work hours, as well as increasing communication and collaboration within our [global team](https://about.gitlab.com/company/team/).
For further details about managing schedules, workflows, and documentation, see the [on-call runbook](https://gitlab.com/gitlab-com/runbooks/blob/master/howto/oncall.md).
......
......@@ -9,7 +9,7 @@ title: "Ops Backend Department"
- TOC
{:toc}
[Dalia Havens](https://about.gitlab.com/team/#dhavens) is the Director for Ops Backend. Feel free to check out her [README](https://about.gitlab.com/handbook/engineering/ops-backend/director/).
[Dalia Havens](https://about.gitlab.com/company/team/#dhavens) is the Director for Ops Backend. Feel free to check out her [README](https://about.gitlab.com/handbook/engineering/ops-backend/director/).
## Teams
There are a number of teams within the Ops Backend group:
......
......@@ -27,10 +27,10 @@ are responsible for coverage of **Dev** stage
## Members
* [Dan Davison](/team/#sircapsalot): Test Automation Infrastructure, Maintainer of the [Selenium Docker project](https://github.com/SeleniumHQ/docker-selenium).
* [Mark Lapierre](/team/#mdlap): Test Automation Strategy for **Create**, Cognitive Psychology (Ph.D.)
* [Ramya Authappan](/team/#atramya): Test Automation Strategy for **Plan**
* [Sanad Liaquat](/team/#sanadliaquat): Test Automation Strategy for **Manage**
* [Dan Davison](/company/team/#sircapsalot): Test Automation Infrastructure, Maintainer of the [Selenium Docker project](https://github.com/SeleniumHQ/docker-selenium).
* [Mark Lapierre](/company/team/#mdlap): Test Automation Strategy for **Create**, Cognitive Psychology (Ph.D.)
* [Ramya Authappan](/company/team/#atramya): Test Automation Strategy for **Plan**
* [Sanad Liaquat](/company/team/#sanadliaquat): Test Automation Strategy for **Manage**
[Manage]: /handbook/product/categories/#Manage
[Plan]: /handbook/product/categories/#Plan
......
......@@ -35,9 +35,9 @@ Engineers in this team are dedicated to our [Developer productivity](/handbook/e
### Members
* [Rémy Coutable](/team/#rymai): General expert.
* [Lin Jen-shin](/team/#godfat): CE / EE architecture, and CI expert.
* [Mark Fletcher](/team/#markglenfletcher): Issue triage expert.
* [Rémy Coutable](/company/team/#rymai): General expert.
* [Lin Jen-shin](/company/team/#godfat): CE / EE architecture, and CI expert.
* [Mark Fletcher](/company/team/#markglenfletcher): Issue triage expert.
[measurements and dashboards]: http://quality-dashboard.gitlap.com/groups/gitlab-org
[GitLab Insights]: https://gitlab.com/gitlab-org/gitlab-insights
......
......@@ -121,7 +121,7 @@ We were able to reproduce the bug on GitLab.com, this is a proper regression! Le
- [ ] Explore the existing issues and notice the labels that have been applied
- [ ] Explore and understand the labels that are available for each project. Start with the [GitLab-CE project's labels](https://gitlab.com/gitlab-org/gitlab-ce/labels)
- [ ] Explore the Teams in the [handbook](/handbook/engineering/)
- [ ] Explore the domain experts listed on the [team page](/team/)
- [ ] Explore the domain experts listed on the [team page](/company/team/)
- [ ] Identify the current release's regression issue and take a look at the referenced regression issues
----
......
......@@ -467,7 +467,7 @@ GitLab utilizes [HackerOne](https://www.hackerone.com) for its bug bounty progra
above.
- HackerOne provides an "export" option that simplifies copying data from the HackerOne issue to GitLab. Export the data in markdown format and paste it into the new issue.
- Always add the `~HackerOne` label to these issues, for later reporting and tracking.
- @ mention engineering managers of appropriate teams, based on the [current organization chart](/team/chart).
- @ mention engineering managers of appropriate teams, based on the [current organization chart](/company/team/org-chart).
- As applicable, notify relevant team members via the issue, chat, and email, depending on the chosen security level.
- Change the state of the report to "Triaged" in HackerOne and include a link to the issue as the reference.
- Fill in the comment using the `Traiged-Escalated to engineering` Common
......
......@@ -84,7 +84,7 @@ It is the responsibiliy of each UX Designer to understand how users may flow in
Every UX Designer and UX Researcher is aligned with a PM. The UXer is responsible for the same features their PM oversees. UXers work alongside PM and engineering at each stage of the process. Planning, discovery, implementation, and further iteration. The area a UXer is responsible for is part of their title, e.g. "UX Designer, Plan." You can see which area of the product each UX Designer is aligned with in the [team org chart](/company/team/org-chart/).
UXers may also serve as a "backup" designer for other areas of the product. This area will be listed on the [team page](/team/) under their title as an expertise, e.g. "Plan expert." UX backups should be just that, backups. They are there to conduct UX reviews on MRs when the UX Designer for that area is out. The UX lead for a given area should coordinate with the PM and their backup during scheduling for any work that is critical. Critical UX work is defined as any work that addresses an outage, a broken feature with no workaround, or the current workaround is unacceptable.
UXers may also serve as a "backup" designer for other areas of the product. This area will be listed on the [team page](/company/team/) under their title as an expertise, e.g. "Plan expert." UX backups should be just that, backups. They are there to conduct UX reviews on MRs when the UX Designer for that area is out. The UX lead for a given area should coordinate with the PM and their backup during scheduling for any work that is critical. Critical UX work is defined as any work that addresses an outage, a broken feature with no workaround, or the current workaround is unacceptable.
#### Everyone can contribute
......
......@@ -12,7 +12,7 @@ title: "UX Department Workflow"
## Meet The UX Department
Our UX department is made up of designers and researchers from all around the world. Each of them brings their own unique cultures, experiences, and strengths to GitLab. You can learn about each member of UX by visiting our [team page](/team/) and filtering by "UX".
Our UX department is made up of designers and researchers from all around the world. Each of them brings their own unique cultures, experiences, and strengths to GitLab. You can learn about each member of UX by visiting our [team page](/company/team/) and filtering by "UX".
## UX Weekly Call
......
......@@ -63,7 +63,7 @@ Workflow for creating an issue:
* Fill in all the relevant sections.
* `@mention` someone in the issue to attract attention to it. Choose an expert [here](/team/) or feel free to ask in the #ux channel on Slack who it should be reviewed by. Do not worry that you are poking someone to review a job when you don't even know them and they might be much more senior than you, if it's not appropriate for them, they will know the right person to pass it along to and do that.
* `@mention` someone in the issue to attract attention to it. Choose an expert [here](/company/team/) or feel free to ask in the #ux channel on Slack who it should be reviewed by. Do not worry that you are poking someone to review a job when you don't even know them and they might be much more senior than you, if it's not appropriate for them, they will know the right person to pass it along to and do that.
Typical kinds of issues created:
......
......@@ -48,7 +48,7 @@ Workflow for creating an issue:
* Fill in all the relevant sections.
* @mention someone in the issue to attract attention to it. Choose an expert [here](/team/) or feel free to ask in the #ux channel on slack who it should be reviewed by. Do not worry that you are poking someone to review a job when you don't even know them and they might be much more senior than you, if it's not appropriate for them, they will know the right person to pass it along to and do that.
* @mention someone in the issue to attract attention to it. Choose an expert [here](/company/team/) or feel free to ask in the #ux channel on slack who it should be reviewed by. Do not worry that you are poking someone to review a job when you don't even know them and they might be much more senior than you, if it's not appropriate for them, they will know the right person to pass it along to and do that.
Typical kinds of issues created:
......
......@@ -4,7 +4,7 @@ title: "Authorization Matrix"
---
For instruction on how to get approval to purchase goods or services see our [Procure to Pay Process](/handbook/finance/procure-to-pay/).
Our process for signing any contract is documented in [/handbook/signing-legal-documents/](/handbook/signing-legal-documents/).
Our process for signing any contract is documented in [/handbook/signing-legal-documents/](/handbook/signing-legal-documents/).
## Authorization Matrix
......@@ -514,12 +514,12 @@ Our process for signing any contract is documented in [/handbook/signing-legal-d
</tr>
</table>
**Notes/Comments**:
**Notes/Comments**:
- (1) If in Plan
- (1) If in Plan
- (2) If Not Included in Company Plan
- (3) Approved by Compensation Committee (or Board if no Compensation Committee)
- (4) Approval from [function](https://about.gitlab.com/team/structure/#table) responsible for supporting associated objectives and goals
- (4) Approval from [function](https://about.gitlab.com/company/team/structure/#table) responsible for supporting associated objectives and goals
## Banking Controls
......
---
---
layout: markdown_page
title: "Department Structure"
---
## Department Structure
Below is a table showing the structure of GitLab departments as they exist in NetSuite. Please [check out the Team Page](/team/chart) to see our org chart.
Below is a table showing the structure of GitLab departments as they exist in NetSuite. Please [check out the Team Page](/company/team/org-chart) to see our org chart.
| Sales | Cost of Sales | Marketing | Development | General & Administrative |
| :-----------: | :------: | :------------: | :-----------: | :------: |
| Business Development | Customer Solutions | Corporate Marketing | Meltano | CEO |
| Business Development | Customer Solutions | Corporate Marketing | Meltano | CEO |
| Field Sales | Customer Support | Field Marketing | Infrastructure | Data & Analytics |
|Account Management | GitLab.com |Pipe-to-Spend | PM Dev | Finance
| Customer Success | GitHost| Inbound Demand Generation | PM Ops | People Ops |
| Customer Success | GitHost| Inbound Demand Generation | PM Ops | People Ops |
| Indirect Channel || Outbound Demand Generation | |Recruiting|
|Sales Management|| Outreach ||
|SMB|| Product Marketing ||
## Allocation Methodology
GitLab uses an indirect cost allocation. GitLab allocates various cost items throught its departments based on consumption of resources or headcount. Below are the departments or diagrams that illustrate how various cost items are allocated at GitLab.
GitLab uses an indirect cost allocation. GitLab allocates various cost items throught its departments based on consumption of resources or headcount. Below are the departments or diagrams that illustrate how various cost items are allocated at GitLab.
### GitLab.com & GitHost
* [Hosting Allocation](https://drive.google.com/a/gitlab.com/file/d/0B-i7xiLa4PPCZ2JKRkItRmtaV1U/view?usp=sharing)
......@@ -29,6 +29,3 @@ GitLab uses an indirect cost allocation. GitLab allocates various cost items thr
### Departments
* Data & Analytics
* Recruiting
......@@ -24,11 +24,11 @@ Onboarding buddies are crucial to making the onboarding experience for a new Git
* **Check how far the new GitLabber has gotten in their onboarding issue.** The onboarding issue that all new GitLabbers are assigned can be overwhelming at first glance, particularly on the first day of work. Check to see how much, if any, the new GitLabber has done by the time your call happens, and offer some direction or advice on areas the new hire may be having trouble with.
* **Suggest helpful handbook pages.** Chances are that you've discovered some particularly helpful pages in the handbook during your time at GitLab. Point them out to the new GitLabber, and help them get used to navigating the handbook. Some examples might include:
* [The tools page](/handbook/tools-and-tips)
* [The team chart](/team/chart)
* [The team chart](/company/team/org-chart)
* [The positioning FAQ](/handbook/positioning-faq)
* **Remind them about the team call.** New GitLabbers are typically asked to introduce themselves to the rest of the team during the team call on their second day. Remind them and help them know what to expect, and explain the personal updates sections and how they can add themselves to the agenda. Encourage them to participate!
* **Introduce them to Slack.** Slack may seem like it's ubiquitous, but that doesn't necessarily mean the new GitLabber will have had experience using it before. Since it's a central part of how we communicate at GitLab, consider showing them around, and give them some pointers about [how we use it](/handbook/communication/#chat).
* **Help with the team page.** For less technical new hires, adding themselves to the [team page](/team/) might feel like the most daunting task on the onboarding issue. Offer to help with the process. This doesn't necessarily have to happen on day one, but you should let them know that you're available to help if and when they need it. Consider scheduling a second meeting later in the week to walk them through [the process](/handbook/git-page-update/#11-add-yourself-to-the-team-page)
* **Help with the team page.** For less technical new hires, adding themselves to the [team page](/company/team/) might feel like the most daunting task on the onboarding issue. Offer to help with the process. This doesn't necessarily have to happen on day one, but you should let them know that you're available to help if and when they need it. Consider scheduling a second meeting later in the week to walk them through [the process](/handbook/git-page-update/#11-add-yourself-to-the-team-page)
* In particular, help them to create their SSH key as this tends to be a sticking point for many new hires. You can also show them [Lyle's walkthrough](https://youtu.be/_FIOhk03VtM)
* **Check in regularly.** You may very well be the first friend the new GitLabber makes on the team. Checking in with them regularly will help them feel welcome and supported. Reach out via Slack, and schedule at least one follow-up call for the week after their start date.
......
......@@ -19,7 +19,7 @@ Once you're set up, you will find the source files for the Handbook here [/sourc
If you work for GitLab Inc. we don't expect you to figure this out by yourself.
If you have questions ask anyone for help, you're more likely to have success with:
- People that have been here longer than 3 months, the [team page](/team/) lists people in order of how long they have been here.
- People that have been here longer than 3 months, the [team page](/company/team/) lists people in order of how long they have been here.
- People that have engineer in their title.
- We encourage you to meet someone new by asking someone you don't know for help. You can also ask for help in #questions or #peopleops by posting 'Who can do a video call with me to help me work on the website locally /handbook/git-page-update/ ?'. If the other options don't work for you please ask your buddy.
......@@ -97,7 +97,7 @@ Instructions on how to update the website are in the
## 11. Add yourself to the Team Page
We are happy to have you join our company and to include you in our [team page](/team/)! Ask anyone in the company for
We are happy to have you join our company and to include you in our [team page](/company/team/)! Ask anyone in the company for
help if you need it. Choose the method below that feels most comfortable and have the following information handy:
* An invitation to the [www-gitLab-com project](https://gitlab.com/gitlab-com/www-gitlab-com) at your GitLab email account.
......
......@@ -47,7 +47,7 @@ Please follow these guidelines and remind others of them.
1. When communicating something always include a link to the relevant (and up-to-date) part of the **handbook** instead of including the text in the email/chat/etc. You can remind other people of this by asking "Can you please link to the relevant part of the handbook?"
1. Everyone should subscribe to the #handbook channel to stay up-to-date with changes to the handbook
### How to change or define a process
1. To change a guideline or process, **suggest an edit** in the form of a merge request.
After it is merged you can talk about it during the company call if applicable. You can remind other people of this by asking "Can you please send a merge request for the handbook?"
......@@ -92,7 +92,7 @@ If you have any specific questions or concerns regarding the merge request, you
## Management
It is each department and team member's responsibility to ensure the handbook stays current. People Operations will partner with a representative from each department (engineering, marketing, etc) through weekly reviews to verify the content in the handbook is accurate and follows the same format as outlined in the [Guidelines](/handbook/handbook-usage/#guidelines). For questions on who to submit a merge request to, or assistance with the handbook, please ping [the handbook content manager](https://about.gitlab.com/team/#ashtonherrmann)on GitLab or reach out on the '#handbook' Slack channel.
It is each department and team member's responsibility to ensure the handbook stays current. People Operations will partner with a representative from each department (engineering, marketing, etc) through weekly reviews to verify the content in the handbook is accurate and follows the same format as outlined in the [Guidelines](/handbook/handbook-usage/#guidelines). For questions on who to submit a merge request to, or assistance with the handbook, please ping [the handbook content manager](https://about.gitlab.com/company/team/#ashtonherrmann)on GitLab or reach out on the '#handbook' Slack channel.
Any changes to the handbook as part of this review will be shared in the `#handbook` channel in Slack. People Ops will also ensure that questions asked in `#questions` are documented and all announcements on the company call have a relevant link.
......
......@@ -79,7 +79,7 @@ TODO
#### Top Team Member
1. A Top Team Member (T2M) exemplifies the [GitLab Values](/handbook/values/) beyond of the [team of people](/team/structure/) they directly work with.
1. A Top Team Member (T2M) exemplifies the [GitLab Values](/handbook/values/) beyond of the [team of people](/company/team/structure/) they directly work with.
1. Each quarter People Ops will request managers to nominate a team member who is not on their own team to receive the T2M award. All team members can submit nominations, but just ping your manager in the issue to upvote.
* The request will be sent on the 5th of month and nominations will close at the end of the day (EST) on the 10th. The prize will be awarded on the 15th or the following business day (if on a weekend). The People Ops Analyst will tally the nominations. The decision will be finalized by a review committee made up of the Chief Culture Officer, CEO, CTO and the VP of Product. The executive team member of the winner will confirm the award to ensure there are no pending performance issues.
* Nominations should focus on efforts and explain specific situations that represent any of our [values](/handbook/values/).
......@@ -149,7 +149,7 @@ Note: This is a temporary process until People Ops and Tinggly can build an API
### Referral Bonuses
Chances are that if you work at GitLab, you have great friends and peers who would
also be fantastic additions to our [Team](/team/) and who
also be fantastic additions to our [Team](/company/team/) and who
may be interested in one of the current [Job Openings](/jobs/).
To help us grow the team with exceptional people, we have referral bonuses that work as follows:
......@@ -184,7 +184,7 @@ Once the bonus has been processed, change the note in BambooHR to denote the ref
### Visiting grant
GitLab is an [all-remote company](http://www.remoteonly.org/) with GitLabbers all over the world (see the map on our [Team page](/team/). If you want to visit other team members to get to know them, GitLab will pay for your travel expenses. You don't need to work on the same project or team, either, so long as you discuss work for at least part of the time you're meeting. GitLab will pay for **flights, trains, and transportation to and from the airport,** up to a total of [$150](/handbook/people-operations/global-compensation/#exchange-rates) per team member that you visit and work with.
GitLab is an [all-remote company](http://www.remoteonly.org/) with GitLabbers all over the world (see the map on our [Team page](/company/team/). If you want to visit other team members to get to know them, GitLab will pay for your travel expenses. You don't need to work on the same project or team, either, so long as you discuss work for at least part of the time you're meeting. GitLab will pay for **flights, trains, and transportation to and from the airport,** up to a total of [$150](/handbook/people-operations/global-compensation/#exchange-rates) per team member that you visit and work with.
Note that lodging, meals, and local travel while visiting are not typically covered for anyone as that wouldn't really be fair to those being visited. It may be acceptable to cover a meal, however, if the meeting is pre-announced to other people in the region to encourage as many of them to attend as possible and there are four or more GitLabbers attending.
......
......@@ -11,7 +11,7 @@ title: "Leadership"
This page contains leadership pointers.
The first couple of headers indicate which group they apply to, using the groupings
defined on our [team structure page](/team/structure/).
defined on our [team structure page](/company/team/structure/).
## GitLabbers
......@@ -181,7 +181,7 @@ Please see [/handbook/leadership/skip-levels](/handbook/leadership/skip-levels).
1. Everyone deserves a great manager that helps you with your career. They should let you know when you should improve, hire a great team, and motivate and coach you to get the best out of you.
1. "Nuke all matrices. Nuke all dual reporting structures. And nuke as many shared services functions as you possibly can." from the great [guide to big companies from Marc Andreessen](http://pmarchive.com/guide_to_big_companies_part2.html) (the other guides are awesome too).
1. We recommend reading [High Output Management](/handbook/leadership/#books), and its author coined Grove's law: All large organizations with a common business purpose end up in a hybrid organizational form. We believe a dual reporting structure is inevitable, we just want to delay it as long as possible.
1. We do make features with a ad-hoc cross-functional group called a [crew](/team/structure/#crew). This group is not a permanent team reporting to a project manager. The group consists of people that are assigned by their functional manager to work on an issue at the beginning of our monthly sprint. In practice it make sense to assign the same people if possible, but the composition of the group is variable. This is more flexible due to cases where people are not available, there is more work for a certain functional group, or when a specific expertise is needed. An example of a crew is the people working on our project to migrate GitLab.com to Google Cloud Platform who are from the production, build, database, and Geo groups.
1. We do make features with a ad-hoc cross-functional group called a [crew](/company/team/structure/#crew). This group is not a permanent team reporting to a project manager. The group consists of people that are assigned by their functional manager to work on an issue at the beginning of our monthly sprint. In practice it make sense to assign the same people if possible, but the composition of the group is variable. This is more flexible due to cases where people are not available, there is more work for a certain functional group, or when a specific expertise is needed. An example of a crew is the people working on our project to migrate GitLab.com to Google Cloud Platform who are from the production, build, database, and Geo groups.
1. Having a crew requires a lot of discipline from the people in that group to work together. People need to be managers of one. There is no safety net in the form of a project manager. It means that people that do not manage themselves well are not a good fit. It also means that people that do manage themselves well have more freedom.
1. Functional companies are easier when you focus on one product. Apple focusses on the iPhone and can have a [unitary/functional/integrated organizational form](https://stratechery.com/2016/apples-organizational-crossroads/). The advantage is that you can make one strong integrated product. We can also maintain a functional organization as long as we keep offering new functionality as features of GitLab instead of different products. The fact that we're in touch with the market because we use our own product helps as well.
1. Having functional managers means that they are rarely spending 100% of their time managing. They always get their hands dirty. Apart from giving them relevant experience, it also focuses them on the output function more than the process. Hopefully both the focus and not having a lot of time for process reduces the amount of politics.
......@@ -235,4 +235,4 @@ When you give leadership training please [screenshare the handbook instead of cr
## People Operations
Feel free to reach out to anyone in the People Operations Team for further support on leadership development topics. You can find us on the [team page](/team/), search for `People Operations`.
\ No newline at end of file
Feel free to reach out to anyone in the People Operations Team for further support on leadership development topics. You can find us on the [team page](/company/team/), search for `People Operations`.
\ No newline at end of file
......@@ -48,7 +48,7 @@ The goal of community advocacy is to grow the number of active GitLab content co
1. Our most active content contributors come to our summits
1. 100's of people contribute content about GitLab every month
1. We use software that helps us to keep track of core contributors (can be forum, Highrise, software made for advocacy, or a custom Rails app)
1. There is a core contributors page organized per region with the same information as the [team page](/team/) and what they contributed, where they work (if they have a linkedin profile), and a button to sent them an email via a form.
1. There is a core contributors page organized per region with the same information as the [team page](/company/team/) and what they contributed, where they work (if they have a linkedin profile), and a button to sent them an email via a form.
1. We measure and optimize every step of the [contributor journey](/handbook/journeys/#contributor-journey)
### Respond to every community question about GitLab asked online
......
......@@ -166,7 +166,7 @@ Zendesk is our Community Advocacy Centre and our main communication line with ou
1. [ ] Read about the [other channels](/handbook/marketing/developer-relations/community-advocacy/#specific-channels) the Community Advocacy team supports
1. [ ] Check out your colleagues' responses
1. [ ] Read through about 20 old tickets that your colleagues have worked on and their responses
1. [ ] Take a look at the [GitLab.com Team page](/team/) to find the resident experts in their fields
1. [ ] Take a look at the [GitLab.com Team page](/company/team/) to find the resident experts in their fields
1. [ ] Learn about our [mentions-of-gitlab](/handbook/marketing/developer-relations/community-advocacy/#mentions) Slack channel
* This tracks all channels that are not routed through ZenDesk
* HackerNews is routed through this channel - This is the top priority channel
......
......@@ -35,7 +35,7 @@ And add an internal note with the link of the Slack message to the associated Ze
## Best practices
When trying to figure out who has expertise on what segment of the product, the handbook Product page has a section called ["Who to talk to for what"](/handbook/product/#who-to-talk-to-for-what). The [team page](/team/) can also be useful.
When trying to figure out who has expertise on what segment of the product, the handbook Product page has a section called ["Who to talk to for what"](/handbook/product/#who-to-talk-to-for-what). The [team page](/company/team/) can also be useful.
## Automation
......
......@@ -43,7 +43,7 @@ Create issue for new hire in marketing with following checklist.
1. [ ] Add these suggested [canned responses](https://docs.google.com/a/gitlab.com/document/d/1EektuIAJKo9fBe-EiAnPR3BHhlkdaWE4wqG2z3QuP5o/edit?usp=sharing) to your gmail for quick replies
1. [ ] Create SFDC tasks for the leads you choose to work
1. [ ] Create a task list in SFDC of at least 15 leads
1. [ ] Shadow 3 Inbound BDRs for one hour (See [Team Page](/team/))
1. [ ] Shadow 3 Inbound BDRs for one hour (See [Team Page](/company/team/))
#### Metrics
......@@ -56,7 +56,7 @@ Create issue for new hire in marketing with following checklist.
1. [ ] Mine 5 leads each day using Linkedin Sales Navigator and Inside View then add them as contacts to SFDC
1. [ ] Create tasks for each contact
1. [ ] Create a task list in SFDC of at least 25 contacts/leads
1. [ ] Shadow 3 Outbound BDRs for one hour (See [Team Page](/team/))
1. [ ] Shadow 3 Outbound BDRs for one hour (See [Team Page](/company/team/))
#### Metrics
......@@ -90,7 +90,7 @@ Create issue for new hire in marketing with following checklist.
1. [ ] Start receiving live leads
1. [ ] Schedule time with 3 AE's to collaborate and learn about lead management **Note** There is no agenda for this meeting, attend prepared with questions
1. [ ] Develop a healthy task list of at least 25 leads to target
1. [ ] Sit in on three discovery calls with the AE's (See [Team Page](/team/))
1. [ ] Sit in on three discovery calls with the AE's (See [Team Page](/company/team/))
#### Metrics
......@@ -103,7 +103,7 @@ Create issue for new hire in marketing with following checklist.
1. [ ] Schedule 30 minutes with the AE’s that own your accounts (Accounts will assigned to you by your team lead) to collaborate, strategize, and plan.
1. [ ] Have a healthy task list of at least 30 contacts/leads to target
1. [ ] Sit in on three discovery calls with the AE's (See [Team Page](/team/))
1. [ ] Sit in on three discovery calls with the AE's (See [Team Page](/company/team/))
#### Metrics
......
......@@ -13,7 +13,7 @@ title: "Cloud Native Ecosystem Sales Enablement"
## [Slide deck](https://docs.google.com/presentation/d/1e8Eo35KOJMYyCTKvKYeFK1KtP0YOHJGj8LIX-2keoC4/edit#slide=id.g447dd6ad94_0_540)
"The advent of cloud native has empowered engineering leaders to procure and purchase software that helps them ship faster and reliably. These engineering leaders are different from the usual high ticket item buyer and an understanding of their persona is critical to success when selling DevOps software." - [Priyanka Sharma](/team/#priyanka-sharma)
"The advent of cloud native has empowered engineering leaders to procure and purchase software that helps them ship faster and reliably. These engineering leaders are different from the usual high ticket item buyer and an understanding of their persona is critical to success when selling DevOps software." - [Priyanka Sharma](/company/team/#priyanka-sharma)
## The Champion Persona
......
......@@ -30,18 +30,18 @@ Product marketing includes:
- **PM** - Product Management or Product Manager. The [product team](/handbook/product/) as a whole, or the specific person responsible for a product area.
- **PMM** - Product Marketing Management or Product Marketing Manager. The product marketing team as a whole, or the specific person responsible for a product marketing area.
- PMM Team
- [Ashish](/team/#kuthiala), Director PMM
- [John](/team/#j_jeremiah), PMM for [Dev Product Categories](/handbook/product/categories/#dev)
- [William](/team/#thewilliamchia), PMM for [Ops Product Categories](/handbook/product/categories/#ops)
- [Dan](/team/#dbgordon), Technical PMM, Demos, Competitive
- [Cindy](/team/#cblake2000), PMM for [Security Product Categories](/handbook/product/categories/#secure))
- [Joyce](/team/#joycetompsett), AR & Evangalist Manager
- [Tina](/team/#t_sturgis), PMM for Partner and Channel
- [Kim](/team/#kimlock), Customer Reference Manager
- [Ashish](/company/team/#kuthiala), Director PMM
- [John](/company/team/#j_jeremiah), PMM for [Dev Product Categories](/handbook/product/categories/#dev)
- [William](/company/team/#thewilliamchia), PMM for [Ops Product Categories](/handbook/product/categories/#ops)
- [Dan](/company/team/#dbgordon), Technical PMM, Demos, Competitive
- [Cindy](/company/team/#cblake2000), PMM for [Security Product Categories](/handbook/product/categories/#secure))
- [Joyce](/company/team/#joycetompsett), AR & Evangalist Manager
- [Tina](/company/team/#t_sturgis), PMM for Partner and Channel
- [Kim](/company/team/#kimlock), Customer Reference Manager
- Design & Dev Team
- [Luke](/team/#lukebabb), Designer
- [Jarek](/team/#jaaaaarek), Web Developer/Designer
- [Luke](/company/team/#lukebabb), Designer
- [Jarek](/company/team/#jaaaaarek), Web Developer/Designer
## What is PMM working on?
- View the [Product Marketing Issue Board](https://gitlab.com/gitlab-com/marketing/general/boards/397296?=&label_name[]=Product%20Marketing) to see what's currently in progress.
......
......@@ -196,10 +196,10 @@ When adding an image to a webpage, be sure that you optimize the image first.
### Updating the team page and org chart
1. Both the [team page](/team/) and [org chart](/company/team/org-chart/) are updated based on [`team.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/team.yml)
1. Both the [team page](/company/team/) and [org chart](/company/team/org-chart/) are updated based on [`team.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/team.yml)
2. Edit [`team.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/team.yml) and create an MR
3. The org chart is built automatically based on `slug` and `reports_to` lines.
4. See the [team structure](https://about.gitlab.com/team/structure/#specialists-experts-and-mentors) page for more info on specialties, expertise, and mentorship availability to a listing.
4. See the [team structure](https://about.gitlab.com/company/team/structure/#specialists-experts-and-mentors) page for more info on specialties, expertise, and mentorship availability to a listing.
### Updating the homepage promo banner (`hello-bar`)
......
......@@ -53,7 +53,7 @@ We recorded a training on this subject:
* Share the form with the team member in advance of the meeting so they can prepare and come to the meeting with questions and discussion points.
* Make sure you (Manager) are also prepared for the discussion, write down some notes and key points you want to make. What are the major themes coming out of the feedback?
* Make time to talk about the future - [career development](/handbook/leadership/1-1/#career-development-discussion-at-the-1-1) by working through the [Experience Factor Guidelines](/handbook/people-operations/global-compensation/#experience-factor-guidelines) to progress against those factors.
* Make sure to discuss and document on the team page any [expertises](/team/structure/#expert) the team member has obtained.
* Make sure to discuss and document on the team page any [expertises](/company/team/structure/#expert) the team member has obtained.
* If there are areas that need improvement, consider if the use of a [PIP](/handbook/underperformance/) would be helpful.
* This should be a conversation, try to avoid doing all the talking and get feedback from the team member. As a manager, you can help your teammate process and understand the feedback, helping to avoid over/under reactions or defensiveness. Ask questions such as:
1. Is there feedback that you received that is surprising or upsetting to you?
......
......@@ -50,7 +50,7 @@ GitLab will make all reasonable efforts to initiate an investigation into the al
The investigation findings will be reported back to the Senior Director of Legal Affairs. Based on the investigation findings, Legal will make a determination as to whether the allegation(s) were founded, unfounded or inconclusive. This determination will be documented in writing and made part of the investigation report. The determinations are as follows:
* Violation Found. Where a violation of GitLab policies, workplace rules or law is found to have occurred, Legal will review the findings and make a recommendation for corrective action to the Chief Culture Officer and the executive leader of the accused's reporting line. Together the CCO, the business unit and Legal will determine the proper corrective action. If the accused is a member of the executive team then Legal will confer with the CEO, and where necessary, the Board of Directors. Once a corrective action has been determined, the accused will be notified of the finding and of the specific corrective actions to be taken. The accused employee's manager will also be notified if appropriate. No details about the nature or extent of disciplinary or corrective actions will be disclosed to the complainant(s) or witness(es) unless there is as compelling reason to do so (e.g., personal safety)
* No Violation Found. In this situation, the complainant (if known) and the accused should be notified that GitLab investigated the allegation(s) and found that the evidence did not support the claim.
* Inconclusive investigation. In some cases, the evidence may not conclusively indicate whether the allegation(s) was founded or unfounded. If such a situation occurs, the complainant (if known) and the accused will be notified that a thorough investigation has been conducted, but GitLab has been unable to establish the truth or falsity of the allegation(s). GitLab will take appropriate steps to ensure that the persons involved understand the requirements of GitLab's policies and applicable law, and that GitLab will monitor the situation to ensure compliance in the future.
* Inconclusive investigation. In some cases, the evidence may not conclusively indicate whether the allegation(s) was founded or unfounded. If such a situation occurs, the complainant (if known) and the accused will be notified that a thorough investigation has been conducted, but GitLab has been unable to establish the truth or falsity of the allegation(s). GitLab will take appropriate steps to ensure that the persons involved understand the requirements of GitLab's policies and applicable law, and that GitLab will monitor the situation to ensure compliance in the future.
**How to Contact GitLab's 24-hour hotline:**
......@@ -102,7 +102,7 @@ GitLab strives to maintain a workplace that is free from illegal use, possession
GitLab respects the confidentiality of the personal information of employees and contractors. This includes employee and contractor medical and personnel records. All team members records are kept in [BambooHR](/handbook/people-operations/#sts=Using BambooHR). Team members have self service access to their profile. Where available, documents and information are shared with the team member within the platform. If the team member would like to view their entire profile from the admin view, please schedule a call with People Operations to walk through a screen share or request screenshots to be sent to your personal email address. Access to personal information is only authorized when there is a legitimate and lawful reason, and access is only granted to appropriate personnel. Requests for confidential employee or contractor information from anyone outside our company under any circumstances must be approved in accordance with applicable laws. It is important to remember, however, that employees and contractors should have no expectation of privacy with regard to normal course workplace communication or any personal property used for GitLab business.
If there is no requirement within someone's job description to be public-facing, then team members can opt-out of any public exposure. Team members can opt-out of being added to the [team page](https://about.gitlab.com/team/) or what content about them is shown on the team page and can use either only their initials or an alias if desired. Since GitLab publishes much of our content, including video calls and meetings, the only way to ensure no unwanted exposure from these videos is to have video turned off and initials or an alias added to the Zoom profile name whenever a call is being recorded. Zoom shows whether a call is being recorded at the top right of the video screen, and team members are always encouraged to ask if a video will be shared or not. For any GitLab livestreams through YouTube, a team member can watch and comment through YouTube instead of through the internal video call. Any questions can be sent directly to our People Ops and Legal teams.
If there is no requirement within someone's job description to be public-facing, then team members can opt-out of any public exposure. Team members can opt-out of being added to the [team page](https://about.gitlab.com/company/team/) or what content about them is shown on the team page and can use either only their initials or an alias if desired. Since GitLab publishes much of our content, including video calls and meetings, the only way to ensure no unwanted exposure from these videos is to have video turned off and initials or an alias added to the Zoom profile name whenever a call is being recorded. Zoom shows whether a call is being recorded at the top right of the video screen, and team members are always encouraged to ask if a video will be shared or not. For any GitLab livestreams through YouTube, a team member can watch and comment through YouTube instead of through the internal video call. Any questions can be sent directly to our People Ops and Legal teams.
### Proprietary and Confidential Information
......
......@@ -13,7 +13,7 @@ Welcome to the People Operations handbook! You should be able to find answers to
* [**Employment Issue Tracker**](https://gitlab.com/gitlab-com/people-ops/employment/issues): only Onboarding, Offboarding, and Interview Training Issues are held in this subproject and are created by People Ops.
- [**Chat channel**](https://gitlab.slack.com/archives/peopleops); please use the `#peopleops` chat channel for questions that don't seem appropriate for the issue tracker. With questions for our recruiting team, please use the mention `@recruitingteam`; for general People Operations questions, please use the mention `@peoplegeneral`.
- If you need to discuss something that is confidential/private, you can send an email to the People Operations group (see the "Email, Slack, and GitLab Groups and Aliases" Google doc for the alias).
- If you only feel comfortable speaking with one team member, you can ping an individual member of the People Operations team, as listed on our [Team page](/team/).
- If you only feel comfortable speaking with one team member, you can ping an individual member of the People Operations team, as listed on our [Team page](/company/team/).
- If you need help with any technical items, for example, 2FA, please reach out to Support via email or slack.
## Other pages related to People Operations
......
......@@ -122,4 +122,4 @@ That's up to the managers involved. It may be that the first step is to spend so
First step is to discuss this with your manager at your next 1:1. Come prepared with your proposal highlighting what skills you want to learn/enhance and the amount of time you think you will need. Remember, this should be of benefit to you and GitLab. You and your manager will need to collaborate on how you both can make this happen which may also involve discussing it further with the manager of the team you may be looking to transfer to. All discussions will be done transparently with you. Be mindful though that the business needs may mean a move can't happen immediately.
**How do I find a mentor?**
On the [team page](/team), you can see who is willing to be a mentor by looking at the associated [expertise](/team/structure/#expert) on their entry.
On the [team page](/team), you can see who is willing to be a mentor by looking at the associated [expertise](/company/team/structure/#expert) on their entry.
......@@ -1118,7 +1118,7 @@ provides a breakdown of the label types and how to choose the right label.
defined by our developers
1. Mention the different stakeholders in the body of your issue. In most product
related issues, we usually mention the product manager, the design, frontend, and backend managers as appropriate.
Some teams have [experts](/team/structure/#expert) or [liaisons](/job-families/liaison) that can be mentioned instead of the managers.
Some teams have [experts](/company/team/structure/#expert) or [liaisons](/job-families/liaison) that can be mentioned instead of the managers.
Mentioning the people in the body of the issue will trigger the notification mechanisms
chosen by the people who are mentioned - therefore there is no need to notify
people in another channel after the issue has been created (Slack, email).
......
......@@ -56,7 +56,7 @@ title: "Sales Handbook"
## Team Structure & Roles