Verified Commit 692baa10 authored by Jamie Maynard's avatar Jamie Maynard
Browse files

Fix remain markdown errors in working-groups

parent 3f48b014

content/handbook/company/working-groups/administration.md

+3 −3
Original line number Diff line number Diff line
@@ -26,9 +26,9 @@ The maintenance and enhancement of GitLab Administration functions has been a sh 
### Exit Criteria



1. Owners of the items in the Admin Area of GitLab are identified, acknowledged, and documented in the handbook. => **DONE** The owner list is in [the issue](https://gitlab.com/gitlab-org/gitlab/-/issues/396707) description, we (GitLab as a whole) will continue seeking clarification for the remaining unowned areas. Meanwhile, continue following [Shared responsibility functionality](https://about.gitlab.com/handbook/product/categories/#shared-responsibility-functionality) for unowned areas.

2. Owners of things related to instance management (upgrade, backup and restore, metrics, performance) and configuration are identified, acknowledged, and documented in the handbook. => **SKIPPED** Didn't investigate due to other priorities.

3. A proposal for a new team in case there is a need for certain items of the GitLab Administrator features. There is a chance this is unnecessary if the above two items cover all features. => **SKIPPED** Didn't investigate due to other priorities.

4. A process of identifying Owners for future administration features is documented in the handbook. => **DONE** [Updated handbook page](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116711) with process of adding new admin section.

1. Owners of things related to instance management (upgrade, backup and restore, metrics, performance) and configuration are identified, acknowledged, and documented in the handbook. => **SKIPPED** Didn't investigate due to other priorities.

1. A proposal for a new team in case there is a need for certain items of the GitLab Administrator features. There is a chance this is unnecessary if the above two items cover all features. => **SKIPPED** Didn't investigate due to other priorities.

1. A process of identifying Owners for future administration features is documented in the handbook. => **DONE** [Updated handbook page](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116711) with process of adding new admin section.



## Roles and Responsibilities

content/handbook/company/working-groups/cloud-native-tool-strategy.md

+3 −3
Original line number Diff line number Diff line
@@ -9,10 +9,10 @@ description: "Learn more about how GitLab wants to adopt new technology to accel 
|-----------------|-----------------|

| Date Created    | May 7, 2021 |

| Target End Date | January 1, 2022 |

| Slack           | [#wg_cloud-native-tools]() (only accessible by GitLab team members) |

| Google Doc      | [Working Group Agenda]() (only accessible by GitLab team members) |

| Slack           | #wg_cloud-native-tools (only accessible by GitLab team members) |

| Google Doc      | Working Group Agenda (only accessible by GitLab team members) |

| Docs            | TBD |

| Epics/Issues    | [Main Epic]() / [Issue Board]() |

| Epics/Issues    | Main Epic / Issue Board |

| Label           | `` |

| Associated KPIs/OKRs | TBD |

| GitLab group for working group| `` |

content/handbook/company/working-groups/cross-functional-prioritization.md

+2 −2
Original line number Diff line number Diff line
@@ -92,11 +92,11 @@ Note: This does not preclude other stages beyond create to complete the exit cri 
| Member                | Cheryl Li                                            | Senior Engineering Manager, Verify |





# Cross-functional prioritization process

## Cross-functional prioritization process



The process is [documented](/handbook/engineering/cross-functional-prioritization/) in the handbook.



# Multi-modal communication

## Multi-modal communication



- Tag (at minimum) all potentially interested working group functional leads and when there is impact to product `gl-product-leadership` in all merge requests to solicit feedback.

- Wait two business days to gather and respond to feedback before submitting merge requests to the codeowners for review and merge.

content/handbook/company/working-groups/customer-use-case-adoption.md

+2 −2
Original line number Diff line number Diff line
@@ -23,7 +23,7 @@ This working group is charged with driving the necessary cross-functional alignm 
| Slack           | [#wg-customer-use-case-adoption](https://gitlab.slack.com/archives/C0584NEKSRJ) |

| Google Doc      | [Customer Use Case Adoption Scrum - Agenda](https://docs.google.com/document/d/1WtwXCK1r7hoco5O8oW5SIKiIWtXDr_WOLeWcIaDM7Nk/edit?usp=sharing)  |

| Epic            | [Use Case Adoption Measurement & Improvement](https://gitlab.com/groups/gitlab-com/-/epics/2190)

| Board           | _TBD_ |

| Board           | *TBD* |

| Overview & Status | See [Exit criteria](#exit-criteria) below |



## Exit criteria
@@ -48,6 +48,6 @@ Note that these goals are aspirational so we set a high bar (and potentially ach 
| Functional Lead: Customer Success Operations | Nishant Khanna                | Senior Customer Success Operations Analyst                 |

| Functional Lead: Digital Customer Success    | Michelle Harris               | Senior Program Manager, Customer Programs                  |

| Functional Lead: Data and Insights           | Amie Bright                   | VP of Data and Insights                                    |

| Functional Lead: Enterprise Sales            | _TBD_                         | _TBD_                                                      |

| Functional Lead: Enterprise Sales            | *TBD*                         | *TBD*                                                      |

| Functional Lead: Commercial Sales            | Julien Le Postec              | Area Sales Manager Mid Market South EMEA - Commercial Sales|

| Functional Lead: Developer Relations         | Michael Friedrich             | Senior Developer Evangelist                                |

content/handbook/company/working-groups/database-scalability/_index.md

+9 −9
Original line number Diff line number Diff line
@@ -147,20 +147,20 @@ It is important we settle on specific nomenclature. Currently, there is a fair a 
### Plan



1. Kick-off working group: handbook, agenda, meeting

2. Determine authoritative list of scaling patterns and determine a path for sharding to comprise the first iteration

1. Determine authoritative list of scaling patterns and determine a path for sharding to comprise the first iteration

   1. A blueprint per scaling pattern should be produced by an assigned DRI to:

      1. Describe the scaling pattern

      2. Applicable use cases in the database

      3. Analysis and evaluation of current use cases, their effects on the database

      4. A brief overview of the design

      1. Applicable use cases in the database

      1. Analysis and evaluation of current use cases, their effects on the database

      1. A brief overview of the design

   1. A blueprint for the path of how to shard the database

      1. Describe the goals of sharding

      2. Determine the sharding key

      3. Articulate required application and operation changes

3. Based on these scaling patterns, a blueprint about the Data Access Layer and caching considerations

4. First iteration implementation plan

      1. Determine the sharding key

      1. Articulate required application and operation changes

1. Based on these scaling patterns, a blueprint about the Data Access Layer and caching considerations

1. First iteration implementation plan

   1. Must include a plan to measure effects on both the database and the application

   2. Must include validation (testing) plan

   1. Must include validation (testing) plan

   1. Must complete Proof of Concepts (PoC) of sharding, determine a viable path, and produce building blocks from the PoC



### Work Streams and DRI