Merge branch 'master' into 12126-globalsearch-jtbd

development/database/index.html.md.erb

@@ -41,7 +41,7 @@ The Database Maintainer role:
 * Adheres to the [review turnaround time](https://docs.gitlab.com/ee/development/code_review.html#review-turnaround-time) of 2 working days.
   * At the moment there's a low ratio of engineers per Database Maintainers, causing the Database Maintainer reviews to take more time. We're actively trying to [increase the number of Database Maintainers](https://gitlab.com/gitlab-org/gitlab-ce/issues/63790).
 
-If you're interested in participating in database reviews, please start from creating an issue with [this template](https://gitlab.com/gitlab-com/www-gitlab-com/issues/new?issuable_template=Trainee%20database%20maintainer).
+If you're interested in participating in database reviews, please start from creating an issue with [this template](https://gitlab.com/gitlab-com/www-gitlab-com/issues/new?issuable_template=trainee-database-maintainer).
 
 ## Recommended links and reference materials
 

development/dev/ecosystem/integrations/index.html.md.erb

@@ -35,6 +35,10 @@ For more urgent items, feel free to use the Slack Channel (internal): [#g_ecosys
 
 <%= direct_team(manager_role: 'Engineering Manager, Ecosystem:Integrations', role_regexp: /Frontend/) %>
 
+## Stable Counterparts
+
+<%= stable_counterparts(role_regexp: /(?!Integrations Engineer)(Integrations)/, direct_manager_role: 'Engineering Manager, Ecosystem:Integrations') %>
+
 ## OKRs
 
 Each quarter we have a series of Objectives and Key Results (OKRs) for our

development/dev/index.html.md.erb

@@ -21,7 +21,7 @@ We thrive for ownership of the things that we built by having a clear view on it
 The Dev sub-department is taking care of the first part of the DevSecOps Lifecycle with the following 3 stages and the specific groups:
 
 1. [Manage](/handbook/product/categories/#manage-stage)
-  * [Manage:Access BE](/handbook/engineering/development/dev/manage/)
+  * [Manage:Authentication and Authorization BE](/handbook/engineering/development/dev/manage/)
   * [Manage:Compliance BE](/handbook/engineering/development/dev/manage/)
   * [Manage:Import BE](/handbook/engineering/development/dev/manage/)
   * [Manage:Optimize BE](/handbook/engineering/development/dev/manage/)
@@ -47,11 +47,11 @@ The Dev sub-department is taking care of the first part of the DevSecOps Lifecyc
 
 ### Manage
 
-#### Manage:Access BE & Manage:Import BE
-<%= direct_team(manager_role: 'Backend Engineering Manager, Manage:Access & Manage:Import') %>
+#### Manage:Authentication and Authorization BE & Manage:Import BE
+<%= direct_team(manager_role: 'Backend Engineering Manager, Manage:Authentication and Authorization & Manage:Import') %>
 
-#### Manage:Access FE & Manage:Compliance FE & Manage:Workspace FE
-<%= direct_team(manager_role: 'Frontend Engineering Manager, Manage:Access & Manage:Compliance & Manage:Workspace') %>
+#### Manage:Authentication and Authorization FE & Manage:Compliance FE & Manage:Workspace FE
+<%= direct_team(manager_role: 'Frontend Engineering Manager, Manage:Authentication and Authorization & Manage:Compliance & Manage:Workspace') %>
 
 #### Manage:Compliance BE & Manage:Optimize BE
 <%= direct_team(manager_role: 'Backend Engineering Manager, Manage, Manage:Optimize & Manage:Compliance') %>

development/dev/manage/_workspace_processes.erb

+Workspace works on components of the application that have a far-reaching impact and many groups will be involved in migratig features over, the following process is needed:
+
+* Inradev and performance issues must be triaged by the EM and PM to determine their pririty based on the impace of the number of users efffected and how severe the problem is.
+* Large scale projects (over 3 months of work) and mid-size projects (spanning over 1 milestone of planned work) will be organized in epics with clear iteration plans.
+* The epic must be broken down by the engineers to enable external contributors from other team to easily identify what needs to be picked up.
+* S1 security issue will be picked up by team immediately (per [security process](https://about.gitlab.com/handbook/engineering/security/vulnerability_management/#remediation-slas)).
+* S2 security issues will be picked up in the closest milestone.

development/dev/manage/index.html.md.erb

@@ -28,7 +28,7 @@ In GitLab issues, questions should start by @ mentioning the relevant Product Ma
 * Everyone can contribute; no silos.
   * The goal is to have product give engineering and design the opportunity to be involved with direction and issue definition from the very beginning.
 * We do an optional, asynchronous daily stand-up in our respective group stand-up channels:
-  * Manage:Access [#g_manage_access_daily](https://gitlab.slack.com/archives/C01311Z0LDD)
+  * Manage:Authentication and Authorization [#g_manage_access_daily](https://gitlab.slack.com/archives/C01311Z0LDD)
   * Manage:Optimize [#g_manage_optimize_daily](https://gitlab.slack.com/archives/C012SB84TFU)
   * Manage:Compliance [#g_manage_compliance_daily](https://gitlab.slack.com/archives/C013E163FD0)
   * Manage:Import [#g_manage_import_daily](https://gitlab.slack.com/archives/C01099NRZ7B)
@@ -36,16 +36,42 @@ In GitLab issues, questions should start by @ mentioning the relevant Product Ma
 
 #### Hiring
 
-We use an [issue board](https://gitlab.com/gl-talent-acquisition/req-intake/-/boards/3479556?scope=all&label_name[]=devops%3A%3Amanage) to track open Development positions within the Manage stage. 
+We use an [issue board](https://gitlab.com/gl-talent-acquisition/req-intake/-/boards/3479556?scope=all&label_name[]=devops%3A%3Amanage) to track open Development positions within the Manage stage.
 
-1. When a new position is identified and approved, the hiring manager ("HM") will create a kickoff issue within the [req-intake project](https://gitlab.com/gl-talent-acquisition/req-intake) and assign it to themselves. This may result in duplicated kickoff issues if there are multiple hires approved. Due dates will be updated for the target hiring date so it's transparent when we are behind, and by how much. 
-1. New positions require a Greenhouse ID ("GHID") from Finance. If your position is still waiting on a GHID, use the ~"HM::Awaiting Greenhouse ID" label. If you already have the GHID for your position, add it to the issue description. 
-1. Before a position can be opened in Greenhouse, your recruiter will need some initial information about this position which is gathered inside a kickoff issue. You can fill this information out at any time between creation and receiving the GHID. 
+1. When a new position is identified and approved, the hiring manager ("HM") will create a kickoff issue within the [req-intake project](https://gitlab.com/gl-talent-acquisition/req-intake) and assign it to themselves. This may result in duplicated kickoff issues if there are multiple hires approved. Due dates will be updated for the target hiring date so it's transparent when we are behind, and by how much.
+1. New positions require a Greenhouse ID ("GHID") from Finance. If your position is still waiting on a GHID, use the ~"HM::Awaiting Greenhouse ID" label. If you already have the GHID for your position, add it to the issue description.
+1. Before a position can be opened in Greenhouse, your recruiter will need some initial information about this position which is gathered inside a kickoff issue. You can fill this information out at any time between creation and receiving the GHID.
 1. Sometimes there is a delay between completing the kickoff issue and creating the position in Greenhouse, while you and your recruiter align on requirements. Use the ~"HM::Completed Kickoff Issue" label to signify that the position is ready to go live in Greenhouse, and reassign it to the recruiter DRI.
 1. When the position is accepting candidates in Greenhouse and the hiring process begins (sourcing candidates, reviewing resumes, scheduling interviews), update the label with ~"HM::Interviewing". More granular information, such as the number of screening calls or technical/behavioral interviews scheduled, can be reported weekly in 1-1's or using the issue. While many people are involved in this process, hiring managers are still the DRI for a successful hire.
 1. Once you have selected a candidate for the position, you can use the ~"HM::Pending Offer" label to indicate the Justification and Offer process has been started.
 1. If you become blocked at any point during this process (unable to get the GHID, waiting too long between stages, etc), use the ~"blocked" label and add a note to the issue about the problem you're experiencing.
 
+##### DRIs & SLOs
+
+Note: SLO's are based on business hours
+
+| Stage | DRI | SLO | Description |
+| ------ | ------ | ------ | ------ |
+| [Create kickoff issue](https://gitlab.com/gl-talent-acquisition/req-intake/-/issues/new) | Hiring Manager | | |
+| Create requisition in Greenhouse | Recruiter | 48 hours | See [preparations](https://gitlab.com/gitlab-com/people-group/hiring-processes/-/issues/317#preparations) |
+| Review applications for qualified -> screening | Hiring manager | 36 hours | Hiring managers should determine new applications are qualified/rejected within 36 hours of submission |
+| Screen candidates | Hiring manager | 1 week | Screening calls should be scheduled within 1 week of moving a candidate to this stage |
+| Technical interviews | Hiring manager| 1 week | Technical interviews should be requested for scheduling within 1 week of moving a candidate to this stage. [Process defined here](https://gitlab.com/gitlab-com/people-group/hiring-processes/-/issues/317#team-interviews) |
+| Final round interviews | Recruiter | | |
+| Justification | Hiring manager | | |
+| Reference checks | Hiring manager | | |
+| Extend an offer | Recruiter | | |
+
+##### Escalation process
+
+Hiring managers should be checking the progress of their positions on a daily basis in order to understand when an escalation may be needed. To escalate a problem or candidate:
+1. Create a Slack channel under "hire-XXXX" where XXXX is either the candidates initials or the requisition ID
+1. Include your manager, `@urselak`, and `@leif`
+From here, we can pull in additional help to resolve the escalation and archive the channel.
+
+**_Reminder_**: Please do not use a candidate's full name in a public Slack channel.
+
+
 #### Direction
 
 The direction and strategy for Manage is documented on [https://about.gitlab.com/direction/manage/](https://about.gitlab.com/direction/manage/). This page (and the category direction
@@ -53,8 +79,6 @@ pages under the "Categories" header) is the single source of truth on where we'r
 * Direction pages should be reviewed regularly by Product. When updating these pages, please CC the relevant group to keep your teammates informed.
 * Product should make sure that their groups understand the direction and have an opportunity to contribute to it. Consider a monthly direction AMA for your group to field questions.
 
-
-
 #### Prioritization
 <!-- TODO: Would like to remove this and keep it on the group pages instead -->
 <%= partial("handbook/engineering/development/dev/manage/prioritization.erb") %>
@@ -101,10 +125,7 @@ It can be hard to understand how you're doing in your role, because feedback can
 | **(coaching)** | I'm trying to help you improve a behavior you are already exhibiting or change a behavior that you currently have | "The reports that you give me are very helpful, and in the future we can schedule them for the first of the month to be more consistent."
 | **(evaluation)** | Tells you where you stand according to existing standards or expectations | "My expectation was that our decision would be transparent. Since it was not, our team has forgotten the decision, so we must be sure and meet that expectation next time." |
 
-
-
-
-### Group Access - additional considerations
+### Group Authentication and Authorization - additional considerations
 
 <!-- TODO: Would like to remove this and keep it on the group pages instead -->
 <%= partial("handbook/engineering/development/dev/manage/access_processes.erb") %>
@@ -128,7 +149,7 @@ It can be hard to understand how you're doing in your role, because feedback can
 
 ### Group Workspace - additional considerations
 
-TBD - areas in Workspace are far-reaching and should have their own process outlined or require rollout plans for certain areas
+<%= partial("handbook/engineering/development/dev/manage/workspace_processes.erb") %>
 
 ## Meetings
 
@@ -165,7 +186,7 @@ The following people are permanent members of the Manage stage:
 
 <%= stable_counterparts(role_regexp: /[,&] Manage/, direct_manager_role: 'Backend Engineering Manager, Manage') %>
 
-## Dashboards 
+## Dashboards
 
 - Stage Metrics
   - [Stage Development Metrics](https://app.periscopedata.com/app/gitlab/855124/Manage:Development-Metrics)
@@ -174,7 +195,7 @@ The following people are permanent members of the Manage stage:
 - Import
   - [Backend overview](https://app.periscopedata.com/app/gitlab/698723/Manage::Import-Backend-Overview)
   - [North star metrics](https://app.periscopedata.com/app/gitlab/661967/Manage:Import-Dashboard)
-- Access
+- Authentication and Authorization
   - [SAML SSO Usage](https://app.periscopedata.com/app/gitlab/636494/Dev:-Manage:-Access-SAML-SSO-Usage)
   - [Backend overview](https://app.periscopedata.com/app/gitlab/695525/Manage::Access-Backend-Overview)
   - [Usage ping](https://app.periscopedata.com/app/gitlab/857665/Manage:Access---Usage-Ping)
@@ -189,7 +210,7 @@ The following people are permanent members of the Manage stage:
 
 As a globally distributed team who has not had an opportunity to interact face-to-face in quite some time due to the pandemic, we must find ways to be creative and come together as one unit!
 
-We will kick off the holiday season on November 22 by _optionally_ participating in a Secret Santa exchange - an exchange where a group of colleagues will exchange holiday presents anonymously with each member of the group being assigned to another member to provide a small gift. 
+We will kick off the holiday season on November 22 by _optionally_ participating in a Secret Santa exchange - an exchange where a group of colleagues will exchange holiday presents anonymously with each member of the group being assigned to another member to provide a small gift.
 1. The exchange amount will be $30 USD, including shipping and tax fees. This amount cannot be expensed and would need to be paid for out of pocket. Team members are not required to participate.
 1. A form will be provided on November 22 to sign up. This form will include ideal gift ideas for yourself, as well as your formatted mailing address, and local / online stores to choose your gift from.
 1. The form will close on December 8. At this time, your Secret Santa will be randomly selected and you will be given the name of a team member to buy a gift for, their ideal gift idea and local buying options if available.
@@ -201,7 +222,7 @@ We will kick off the holiday season on November 22 by _optionally_ participating
   * A number of our stage discussions and issues are located at [`gitlab-org/manage`](https://gitlab.com/gitlab-org/manage/)
 * Our Slack channels
   * Manage-wide [#s_manage](https://gitlab.slack.com/messages/CBFCUM0RX)
-  * Manage:Access [#g_manage_access](https://gitlab.slack.com/messages/CLM1D8QR0)
+  * Manage:Authentication and Authorization [#g_manage_access](https://gitlab.slack.com/messages/CLM1D8QR0)
   * Manage:Optimize [#g_manage_optimize](https://gitlab.slack.com/messages/CJZR6KPB4)
   * Manage:Compliance [#g_manage_compliance](https://gitlab.slack.com/messages/CN7C8029H)
   * Manage:Import [#g_manage_import](https://gitlab.slack.com/messages/CLX7WMSKW)

development/dev/manage/security-rota/index.html.md.erb

 ---
 layout: handbook-page-toc
-title: Manage::Access Security Rotation
+title: Manage::Authentication and Authorization Security Rotation
 ---
 
 ## On this page
@@ -9,7 +9,7 @@ title: Manage::Access Security Rotation
 - TOC
 {:toc .hidden-md .hidden-lg}
 
-### Manage::Access Security Rotation
+### Manage::Authentication and Authorization Security Rotation
 {: #welcome}
 
 The Access group are responsible for several product categories that attract a significant amount of scrutiny from a security perspective. An outcome of this is that we see a higher number of new security issues being created compared to other groups, which over time has caused the security backlog to grow. To help tackle the backlog, from milestone 13.3, we will assign 2 Backend Engineers per milestone to a security rota.
@@ -21,8 +21,8 @@ Schedule for security rota with names of the engineers assigned to the current m
 Engineers who are part of the rota should work from [this board](https://gitlab.com/groups/gitlab-org/-/boards/1816615).
 
 Another helpful boards:
- - [Board categorized by severity](https://gitlab.com/groups/gitlab-org/-/boards/1674442?&label_name[]=group%3A%3Aaccess&label_name[]=security)
- - [Board categorized by categories](https://gitlab.com/groups/gitlab-org/-/boards/1816633?&label_name[]=group%3A%3Aaccess&label_name[]=security)
+ - [Board categorized by severity](https://gitlab.com/groups/gitlab-org/-/boards/1674442?label_name[]=group::authentication+and+authorization&label_name[]=security)
+ - [Board categorized by categories](https://gitlab.com/groups/gitlab-org/-/boards/1816633?label_name[]=group::authentication+and+authorization&label_name[]=security)
 
 Process of working on security issue differs from the process of working on other features. All the details of security process are explained [here](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/developer.md). Usually we prioritize issues with higher severity and move to the issues with lower severity when there are no more actionable issues with higher severity.
 

development/dev/plan/_historical_capacity.md.erb

-Points of weight delivered by the team on the last three milestones, including
-rolling average. This allows for more accurate estimation of what we can deliver
-in future milestones. Full chart [here](https://app.periscopedata.com/app/gitlab/587512/Plan-stage-capacity-planning).
-
-<% chart_ids ||= [7693808, 7693825] %>
-<% chart_ids.each do |chart_id| %>
-  <embed width="<%= 99 / chart_ids.size.to_f %>%" height="300" src="<%= signed_periscope_url(dashboard: 587512, chart: chart_id, embed: 'v2', filters: [{name: 'Milestones', value: ["13.10", "13.11", "13.12"]}]) %>">
-<% end %>
+Points of weight delivered by the team in previous milestones, including a 3-month
+rolling average, are available in [this chart](https://app.periscopedata.com/app/gitlab/587512/Plan-stage-capacity-planning). 
+This allows for more accurate estimation of what we can deliver
+in future milestones.

development/dev/plan/_product_planning_dashboard.md.erb

@@ -3,13 +3,13 @@ track against some of the [Development Department KPIs][kpis], particularly
 those around merge request creation and acceptance. From that dashboard, the
 following chart shows [MR Rate].
 
-<%= tag(:embed, src: signed_periscope_url(dashboard: 561630, chart: 7421071, embed: 'v2'), width: '100%', height: '300') %>
+<%= tag(:embed, src: signed_periscope_url(dashboard: 681347, chart: 9159032, embed: 'v2', filters: [{ name: 'team_group' , value: ['product planning', 'certify'] }, { name: 'technology_group' , value: 'backend' }]), width: '100%', height: '300') %>
 
 The following chart shows the MR Rate of the Dev section as a whole, for the
 identification of trends:
 
-<%= tag(:embed, src: signed_periscope_url(dashboard: 561630, chart: 7305986, embed: 'v2'), width: '100%', height: '300') %>
+<%= tag(:embed, src: signed_periscope_url(dashboard: 681347, chart: 9159032, embed: 'v2', filters: [{ name: 'sub_department' , value: 'dev' }]), width: '100%', height: '300') %>
 
-[dashboard]: https://app.periscopedata.com/app/gitlab/561630/Dev-Sub-department-Overview-Dashboard
+[dashboard]: https://app.periscopedata.com/app/gitlab/681347/Development-Embedded-Dashboard
 [kpis]: /handbook/business-ops/data-team/metrics/#development-department-kpis
 [MR Rate]: /handbook/engineering/performance-indicators/#engineering-mr-rate

development/enablement/database/doc/root-namespace-sharding.html.md.erb

@@ -183,7 +183,7 @@ Identified complexities reside around the following topics:
 5. Scalability: Write bottlenecks for tables replicated from a single point (for non-shardable data)
 6. Product: Many product features have been identified to potentially become very slow/expensive or break with this approach. We would need to align the product thinking such that features are fully contained in a namespace. Ideally, this includes confining users into a single namespace, too - which seems like a huge undertaking and also quite limiting for the user experience.
 
-We expect to only need sharding capabilities for GitLab.com and don't expect this to be necessary for self-hosted installations. This further complicates implementation because it's likely we would have to implement some actions specific to GitLab.com.
+We expect to only need sharding capabilities for GitLab.com and don't expect this to be necessary for self-managed installations. This further complicates implementation because it's likely we would have to implement some actions specific to GitLab.com.
 
 ### Summary
 

development/enablement/database/doc/workload-analysis.html.md.erb

@@ -34,7 +34,7 @@ We've started to address this through manual invocations of [pg_repack](https://
 
 We came to realize that addressing index bloat is something we need to automate. This allows us to address this problem in a higher frequency, with no manual efforts and ultimately we maintain a healthy state of index bloat over time.
 
-We also expect larger self-hosted installations of GitLab to suffer from this problem. Therefore, we developed a reindexing feature that ships with GitLab. Currently, this is being rolled out to GitLab.com and once proven successful, the feature will be available and enabled in GitLab by default.
+We also expect larger self-managed installations of GitLab to suffer from this problem. Therefore, we developed a reindexing feature that ships with GitLab. Currently, this is being rolled out to GitLab.com and once proven successful, the feature will be available and enabled in GitLab by default.
 
 The reindexing implementation is based on the fact that a [majority of index bloat stems from regular (non unique) btree indexes](https://gitlab.com/gitlab-com/gl-infra/readiness/-/tree/master/library/database/postgres/bloat/#index-analysis). Those can be recreated relatively easily, without risk of prolonged locking situations:
 

development/enablement/geo/process.html.md

@@ -236,20 +236,24 @@ Expectations:
 
 #### Bug Triage Schedule
 
-| Month | Name |
-| ----- | ---- |
-| January 2021 | @mkozono |
-| December 2021 | [`@dbalexandre`](https://gitlab.com/dbalexandre) |
-| November 2021 | @vsizov |
-| October 2021 | @ibaum |
-| September 2021 | @aakriti.gupta |
-| August 2021 | @vsizov |
-| July 2021 | @mkozono |
-| June 2021 | @dbalexandre |
-| May 2021 | @mkozono |
-| April 2021 | @dbalexandre |
-| March 2021 | @mkozono |
-| February 2021 | @alexives |
+| Month     | Name |
+| -------   | ---- |
+| April     | @ibaum |
+| March     | @cat |
+| February  | @dbalexandre |
+| January   | @mkozono |
+| **2021**  |      |
+| December  | @dbalexandre |
+| November  | @vsizov |
+| October   | @ibaum |
+| September | @aakriti.gupta |
+| August    | @vsizov |
+| July      | @mkozono |
+| June      | @dbalexandre |
+| May       | @mkozono |
+| April     | @dbalexandre |
+| March     | @mkozono |
+| February  | @alexives |
 
 ## Retrospectives
 

development/enablement/geo/staging.html.md

@@ -96,8 +96,12 @@ The main goals for this rotation:
 
 | Month     | Name             |
 | -----     | ------           |
+| **2022**  | |
+| April     | [`@mkozono`](https://gitlab.com/mkozono) |
+| March     | [`@dbalexandre`](https://gitlab.com/dbalexandre) |
+| February  | [`@cat`](https://gitlab.com/cat) |
+| January   | [`@vsizov`](https://gitlab.com/vsizov) |
 | **2021**  | |
-| January   |  |
 | December  | [`@ibaum`](https://gitlab.com/ibaum) |
 | November  | [`@dbalexandre`](https://gitlab.com/dbalexandre) |
 | October   | [`@mkozono`](https://gitlab.com/mkozono) |

development/enablement/memory/knowledge.html.md.erb

@@ -69,7 +69,7 @@ We have a materials shared in our internal `Ruby on Rails Performance Training`
 - [How Linux Works: What Every Superuser Should Know by Brian Ward](https://www.goodreads.com/book/show/514432.How_Linux_Works)
 - [Ruby Performance Optimization: Why Ruby Is Slow, and How to Fix It by Alexander Dymo](https://www.goodreads.com/book/show/25276703-ruby-performance-optimization)
 - [Ruby Under a Microscope by Pat Shaughnessy](https://www.goodreads.com/book/show/16300795-ruby-under-a-microscope)
-- [Working with Ruby Threads by Jesse Storimer](https://www.goodreads.com/book/show/17826435-working-with-ruby-threads)
+- [Working with Ruby Threads by Jesse Storimer](https://workingwithruby.com/wwrt/intro)
 
 ### Podcasts
 - [Episode 372: Aaron Patterson on the Ruby Runtime : Software Engineering Radio](https://www.se-radio.net/2019/07/episode-372-aaron-patterson-on-the-ruby-runtime/)

development/enablement/search/index.html.md.erb

@@ -96,6 +96,10 @@ We use the Fibonacci rating system to assign weights to Search issues. Below are
 | 3      | Medium effort |
 | 5      | High effort |
 
+### Oncall escalation coverage
+
+As the Global Search Team requires special domain knowledge, such as Elasticsearch, we borrow team members with this domain knowledge from other teams to cover the oncall escalation when we are under staffing especially during the holiday seasons. In general, we will follow the [dev oncall](https://about.gitlab.com/handbook/engineering/development/processes/Infra-Dev-Escalation/process.html#escalation-process) process. The Elasticsearch domain experts, which can be identified by domain_expertise on their profile, may be contacted when SRE and dev oncall engineers cannot resolve the production incidents. We don't expect the domain experts to work outside of their normal working hours. In case of emergency, we will follow the set of rules and best practices outlined in our [Incident Management](https://about.gitlab.com/handbook/engineering/infrastructure/incident-management/) handbook. In order to assist team members to catch up the latest development status and resolve potential incidents, we have created a [Global Search Incident Management document](https://gitlab.com/gitlab-org/search-team/training-materials/-/tree/main/2021-12-14-production-incident-management) as a reference.
+
 ### Common Links
 
 * [Global Search Team Milestone Board](https://gitlab.com/groups/gitlab-org/-/boards/1339901?label_name[]=group%3A%3Aglobal%20search)

development/enablement/sharding/index.html.md.erb

@@ -62,10 +62,12 @@ The following members of other functional teams are our stable counterparts:
 ## Meetings
 Where we can we follow the GitLab values and communicate asynchronously.  However, there have a few important recurring meetings.  Please reach out to the [#g_sharding](https://gitlab.slack.com/archives/C01TQ838Y3T) Slack channel if you'd like to be invited.
 
-With the globally distributed nature of this team, it is unlikely that we will have a synchronous meeting where everyone will attend. When we have synchronous meetings we will record the meetings and share written summaries with the links to the recordings. Currently we have the following recurring meeting scheduled on Wednesdays.
+With the globally distributed nature of this team, it is unlikely that we will have a synchronous meeting where everyone will attend. When we have synchronous meetings we will record the meetings and share written summaries with the links to the recordings. Currently we have the following recurring meeting scheduled.
 
-- Sharding Group Sync (US/EMEA) 1:00PM UTC (6:OOAM PDT)
-- Sharding Group Sync (APAC) 9:30AM UTC (2:30AM PDT)
+- Alternating Wednesdays 
+  - Sharding Group Sync (EMEA/AMER) 1:00PM UTC (6:OOAM PDT)
+  - Sharding Group Sync (APAC/AMER) 10:00PM UTC (2:00PM PDT)
+- Weekly Monday/Wednesday - Sharding Group Sync (APAC/EMEA) 8:30AM UTC (2:30AM PDT)
 
 ## Work
 We follow the GitLab [engineering workflow](/handbook/engineering/workflow/) guidelines.  To bring an issue to our attention please add the `~"group::sharding"` label along with any other relevant labels.  If it is an urgent issue, please reach out to the Product Manager or Engineering Manager listed in the [Stable Counterparts](/handbook/engineering/development/enablement/sharding/#stable-counterparts) section above.
@@ -84,7 +86,7 @@ There are a few factors influencing some of our working agreements here. First,
 
 Currently we are asking team members to update their issues with:
 - Epic Start Date and Due Date entries - this will allow us to dogfood our [roadmap](https://gitlab.com/groups/gitlab-org/-/roadmap?state=opened&sort=end_date_asc&label_name%5B%5D=group%3A%3Asharding) functionality within GitLab
-- Add `~sharding::active` to issues that we know we will be working on in the near future. This helps us to keep our Sharding: Build](https://gitlab.com/groups/gitlab-org/-/boards/2594854?scope=all&utf8=%E2%9C%93&label_name[]=group%3A%3Asharding) tidy, especially the Open and Closed columns
+- Add `~sharding::active` to issues that we know we will be working on in the near future. This helps us to keep our [Sharding: Build](https://gitlab.com/groups/gitlab-org/-/boards/2594854?scope=all&utf8=%E2%9C%93&label_name[]=group%3A%3Asharding) tidy, especially the Open and Closed columns
 - At a minimum add a `weight=1` to all issues so that we can view epic progress at a glance on our [Group::Sharding Roadmap](https://gitlab.com/groups/gitlab-org/-/roadmap?state=opened&sort=end_date_asc&label_name%5B%5D=group%3A%3Asharding)
   - We have not decided on whether to use weights as a team, currently any weights outside of a minimum value of 1 is at the discretion of the assignee
 

development/enablement/sharding/issue-creation-workflow.html.md.erb

@@ -19,17 +19,18 @@ This diagram describes our issue creation workflow.
 graph TD
     Create[Create Issue] --> is_group{Will<br>Group::Sharding<br>own this issue};
     is_group -->|Yes| group_sharding[label group::sharding];
-    is_group -->|No| other_group[label appropriate group];
-    group_sharding --> is_active{To be completed<br> within 3 milestones}
-    is_active -->|Yes| active[label sharding::active]
-    is_active -->|No| sharding_blocker[label sharding-blocker]
-    active --> sharding_blocker
-    other_group --> sharding_blocker
-    sharding_blocker --> sharding_blocker_phase[label sharding-blocker::phaseX]
-    sharding_blocker_phase --> milestone[add appropriate milestone]
+    is_group -->|No| is_infra{Assigned to<br>infrastructure?};
+    is_infra -->|No| other_group[label appropriate group];
+    is_infra -->|Yes| at_mention_kenn[mention kwanyangu];
+    at_mention_kenn -->ci-decomposition
+    group_sharding --> active[label sharding::active]
+    active --> ci-decomposition
+    other_group --> ci-decomposition
+    ci-decomposition --> ci-decomposition_phase[label ci-decomposition::phaseX]
+    ci-decomposition_phase --> milestone[add appropriate milestone]
     milestone --> priority[add priority/severity labels]
     priority --> epic[add to appropriate epic]
-
+    classDef default fill:#fca326,color:#fff;
 ```
 Notes
 - Assign Priority/Severity based on the desired [Time To Resolve SLO](https://about.gitlab.com/handbook/engineering/quality/issue-triage/#availability) 

development/fulfillment/be-utilization/index.html.md.erb

@@ -12,7 +12,7 @@ description: "The Utilization Backend Team of the Fulfillment Sub-department at
 
 ## Overview
 
-The Utilization group often works at the interface between GitLab Core and Fulfillment applications. This includes components in the [Utilization category](/handbook/product/product-categories/#utilization-group) like consumables management (storage, CI minutes, seats, etc.), usage reporting, and usage notifications. Our customers use GitLab SaaS, GitLab Self-hosted, and internal tooling.
+The Utilization group often works at the interface between GitLab Core and Fulfillment applications. This includes components in the [Utilization category](/handbook/product/product-categories/#utilization-group) like consumables management (storage, CI minutes, seats, etc.), usage reporting, and usage notifications. Our customers use GitLab SaaS, GitLab self-managed, and internal tooling.
 
 ## Vision
 

development/growth/fast-boot/index.html.md.erb

@@ -94,8 +94,8 @@ Discussion led by Tim Hey, PM for Expansion. Topics covered:
     *   User Orientation - Users don’t know where to start
     *   Increase platform confidence and trust - I love my tools and am afraid to switch
 *   Internal opportunities
-    *   Self-hosted usage for upsell process and user workflow
-    *   Self-hosted True-up process and user workflow
+    *   Self-Managed usage for upsell process and user workflow
+    *   Self-Managed True-up process and user workflow
 
 [Video](https://www.youtube.com/watch?v=uodOO2RUIbo&feature=youtu.be)
 
@@ -141,7 +141,7 @@ Topics covered (which will also be added to the handbook)
 * SMAU -- what it is and how it's managed
 * Dashboards -- what they are, self-serve and how to request one
 * Data fields available for tracking and what to do if you need a new one
-* Tracking and instrumentation -- how to's for GitLab.com and Self-hosted
+* Tracking and instrumentation -- how to's for GitLab.com and Self-Managed
 * Technologies we use
 
 [MR under review](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/29940#23dfa14c4e3cd4e7facec62ed501fe5adc7bc0ef)
@@ -176,7 +176,7 @@ Acquisition
 * [Test simplified user registration page](https://gitlab.com/gitlab-org/growth/engineering/issues/20) + [Design progress](https://gitlab.com/gitlab-org/growth/engineering/issues/20/designs)
 * [Update .com paid signup process](https://gitlab.com/gitlab-org/growth/product/issues/87)
 * [Update trial signup process](https://gitlab.com/gitlab-org/growth/product/issues/88)
-* [Update self-hosted paid signup process](https://gitlab.com/gitlab-org/growth/product/issues/89)
+* [Update Self-Managed paid signup process](https://gitlab.com/gitlab-org/growth/product/issues/89)
 
 Expansion
 * [License Utilization by Host - Epic](https://gitlab.com/groups/gitlab-org/-/epics/1981)

development/growth/index.html.md.erb

@@ -92,12 +92,8 @@ The following people are permanent members of groups that belong to the Growth s
 
 #### Product intelligence
 
-##### Product Intelligence Backend
 <%= department_team(base_department: "Product Intelligence Team") %>
 
-##### Product Intelligence Frontend
-<%= department_team(base_department: "Product Intelligence FE Team") %>
-
 ### Business Continuity - Coverage and Escalation
 
 The following table shows who will provide cover if one or more of the Growth Engineering management team are unable to work for any reason.
@@ -128,7 +124,7 @@ The following members of other functional teams are our stable counterparts:
 role_regexp = /[,&] (Growth|Product Intelligence)/
 direct_manager_role = 'Director of Engineering, Growth, Fulfillment, and Applied ML'
 other_manager_roles = [
-  'Interim Fullstack Engineering Manager, Product Intelligence',
+  'Fullstack Engineering Manager, Product Intelligence',
   'Interim Senior Engineering Manager, Growth'
 ]
 stable_counterparts(role_regexp: role_regexp, direct_manager_role: direct_manager_role, other_manager_roles: other_manager_roles)