giseldo/neodataset huggingface dataset:
Create FID/CLS charts in Sisense

Create FID and CLS PIs in handbook

### Grafana dashboard
https://dashboards.gitlab.net/d/000000043/sitespeed-page-summary?orgId=1&from=now-7d&to=now&var-base=sitespeed_io&var-path=desktop&var-group=gitlab_com&var-page=_explore&var-browser=chrome&var-connectivity=cable&var-function=median

### Sisense dashboard
* CLS: https://app.periscopedata.com/app/gitlab/888743/Cumulative-Layout-Shift-(CLS)-at-P90
* FID: https://app.periscopedata.com/app/gitlab/888749/First-Input-Delay-(FID)-at-P90

Story points: 3.0
Pricing page should mention that CC is required for CI minutes

#### What is/are the relevant URL(s)

- https://about.gitlab.com/pricing/

#### Briefly describe the bug

I am seeing this page and we say `No credit card required`. While that is true, according to https://about.gitlab.com/blog/2021/05/17/prevent-crypto-mining-abuse/ new *free* accounts require a CC before utilizing CI. So I was wondering whether we should call this out, e.g.

#### If possible, please specify how to reproduce the bug

Go to the page.

#### Please provide any relevant screenshots or screencasts

![Screenshot_2021-05-19_at_09.19.53](/uploads/1da6bbfcf2bce8f56ed9a8b581761be3/Screenshot_2021-05-19_at_09.19.53.png)

#### EXPECTATION

I would expect that e.g. 

>  Get 400 CI/CD minutes per month

is changed to 

>  Get 400 CI/CD minutes per month¹

where `¹` is linked to the FAQ section (https://about.gitlab.com/pricing#faq) and we add something to the Pipelines Section like:

> Why do I need to enter Credit Card details for free pipeline minutes?

> In order to combat crypto yada-yada link to blogpost: https://about.gitlab.com/blog/2021/05/17/prevent-crypto-mining-abuse/

#### What is your window size, browser, operating system, and versions

N/A

#### What computing device are you using?

N/A

### What type of input are you attempting to use?

N/A

#### Have you tried a fresh incognito window? Could this be related to cookies or account type/state?

N/A

#### Please list any browser plugins you have enabled

N/A

#### Are you blocking javascript or any other resources?

N/A

#### What is your geographic location

N/A

#### What type of network are you connected to?

N/A

**Hardware**

N/A

<!-- Please do not remove the items below, they are needed to automatically notify the relevant entities -->
/cc @gl-website

<!-- These labels will be automatically applied unless you edit or delete the following section -->

Story points: 1.0
Create promotion rate PI for all department

Current promotion rate charts are on this dashboard: https://app.periscopedata.com/app/gitlab/756370/Promotion_Rate

We want to push this to all departments at the PI level.


## Reviews
- [ ] Review Completed for `Engineering Division` https://gitlab.com/gitlab-org/security/www-gitlab-com/-/merge_requests/54
- [ ] Review Completed for ~"Customer Support Department"
- [ ] Review Completed for ~"Development Department"
- [ ] Review Completed for ~"Infrastructure Department"
- [ ] Review Completed for ~"Quality Department"
- [ ] Review Completed for ~"UX Department"
- [ ] Review Completed for ~"Security Department"

Story points: 5.0
Update the HB install script to first detect if the working directory is a git directory

<!--

This template is for requesting work related to the [company handbook](https://about.gitlab.com/handbook/).

This is not the correct repository for requests related to docs.gitlab.com, the GitLab product, or other items.

You may link to this issue template using the following URL: https://gitlab.com/gitlab-com/www-gitlab-com/issues/new?issuable_template=-handbook-update

-->

#### Briefly describe the update
The handbook install script tries to establish whereabouts on your system the `www-gitlab-com` repo is located. We should first check the working directory to see if it's a git repo and use it if that's the case. Suggested by @cwoolley-gitlab [here](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/81524#note_570269519)
<!--
Example: Updating team documentation regarding project workflow.
-->



<!-- These labels will be automatically applied unless you edit or delete the following section -->

Story points: 2.0
Follow-up from "Add 2021 DecSecOps Survey page"

The following discussion from !81287 should be addressed:

- [ ] @jgarc started a [discussion](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/81287#note_566610206):  (+1 comment)

    > Need to follow up on fixing past developer-survey assets for 2020!

Story points: 1.0
Optional DRI Attribute to PIs

In Infra, we have unofficially had DRIs for specific sections of metrics for awhile.

As an example, I would handle cost metrics, Director of infra, reliability handles incident related metrics, and senior manager, delivery & scalability would handle MTTP and other metrics around deployments/scaling.
Ultimately the metrics still have department head as DRI for the page overall in case someone is out or update missed.

I think this has worked out pretty well for us, and we were talking about making this kind of delegation of PIs official in the page and document what that DRI would be responsible for.

This change would be:
- adding DRI attribute to PI pages
- handbook documentation on what denoted DRI, department head, CTO (or applicable position above department heads), and analysts are responsible for in relation to the PI pages

Idea of documented division of responsibility would break down into:
- listed DRI would be responsible for updating health & health reasons of KPI before each key meeting and answering any related questions in the meeting as well. These DRIs would typically be Directors or Managers who are closest to the metrics if they are delegated this responsibility by their department head.
- Analysts are responsible for maintaining shared PIs charts in Sisense across departments (Inherited PIs) and supporting DRIs with creation of their department specific PI charts in Sisense.
- Department heads are responsible for their PI page overall, so covering for any PIs without delegated DRI and in case someone is out.
- CTO is responsible for defining the division level PIs that are shared across departments and working with department heads on setting targets for these

https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/85436

cc @meks @lmai1

Story points: 5.0
Change Request: Support Department MR Rate

<!---
This issue is for visualization related issues within our BI tool.
---->

#### What is the original Periscope dashboard/link? 

https://app.periscopedata.com/shared/fc54cf54-e5f9-4708-9dfe-9e4c921ac79e?

#### Please link to where this (or these) performance indicator/s are defined in the handbook. 

https://about.gitlab.com/handbook/support/performance-indicators/#support-department-mr-rate

#### What are your requested changes?

Two changes:

1. Target is defined at 5 MRs per month, but target line shows at 10. Should be corrected.
1. (Like to have, not required) Add a table that would show in dashboard (but not in handbook embed) of number of MRs by Gitlab username. Sorted descending by total MRs.

#### What is the business question you are trying to answer? 

For change 2, which ICs may need help to complete contributions?

#### What is the impact of this question and how will it help the company?

Identification of individuals who may need additional assistance would encourage them to contribute and increase results in KPI.

#### What time frames are crucial here? 

Should be total for entire time frame (year) of dashboard. ICs who make even a small number of contributions in a year likely do not need additional help.

#### What is the visualization you are trying to create?

Include any links or screenshots, if appropriate. As a rule of the thumb, the analytics team uses 12 visualization types. They are:

1. Simple Text

| GitLab username | Total number of MRs |
| ------ | ------ |
| cynthia | 5 |
| jcolyer | 2 |

#### What is the source of data behind the visualization?

GitLab. Hopefully the same source as already used in the dashboard.

#### What interactions/drill downs are required?

No filters required.

#### Any caveats or details that may be helpful?

Story points: 1.0
Create Vacancy Time to Fill KPI

Part of overall review of division level PIs: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/11463

If we are keeping PI at department level, tasks involved with review are:

- if chart update is needed, agree on what format going forward will be
- changing formatting to match standards in Sisense charts
- check target matches in handbook and sisense
- make sure handbook definition and other details are updated and link to parent is not broken

## Reviews
- [x] Review Completed for `Engineering Division`
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84142
- [x] Review Completed for ~"Customer Support Department"
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84127
- [x] Review Completed for ~"Development Department"
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84129
- [x] Review Completed for ~"Infrastructure Department"
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/83163
- [x] Review Completed for ~"Quality Department"
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84131
- [x] Review Completed for ~"Security Department"
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84134
- [x] Review Completed for ~"UX Department"
  - https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84133

Story points: 3.0
Blog post: Loading large requests on the frontend in increasingly larger batches

<!-- PLEASE READ: See https://about.gitlab.com/handbook/marketing/blog/unfiltered for details on the Unfiltered blog process.-->

### Proposal

<!-- What do you want to blog about? Add your description here -->

#### Potential Titles

* Loading large requests on the frontend in increasingly larger batches
* Loading increasingly large batches to render large MRs faster
* Batch Diff loading with increasing payloads
* Incrementally loading large merge request diffs in batches
* ....

#### Goal 

Go over the journey of shipping batch diffs and tweaking them for better performance in large Merge Requests

#### Outline

* Establish the previously shipped batch diffs. Pain points of lots of requests/iterations for large MRs
* Slow start of TCP/IP
* Actual implementation with minimum (1st request fast), growing up to a point (beware of BE load)
* Results
* Future work: parallelisation. (problem: how to handle order?)

Story points: 2.0
Consolidate labels for marking issues that are open for community contributions

### Problem

The ~"Accepting merge requests" label which is mostly used for making it easier to [contribute](https://about.gitlab.com/community/contribute/) by marking issues that are open for community contributions.

This is interfered, most probably unintentionally, by similar labels like the [Accepting Merge Requests](https://gitlab.com/gitlab-org/omnibus-gitlab/-/labels?utf8=%E2%9C%93&subscribed=&search=Accepting) label in the [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab) project (see  related [issues](https://gitlab.com/gitlab-org/omnibus-gitlab/issues?label_name%5B%5D=Accepting+Merge+Requests)) and the [Accepting community contributions](https://gitlab.com/gitlab-org/design.gitlab.com/-/labels?utf8=✓&subscribed=&search=Accepting) label in the [`design.gitlab.com`](https://gitlab.com/gitlab-org/design.gitlab.com) project (see related [issues](https://gitlab.com/gitlab-org/design.gitlab.com/issues?label_name%5B%5D=Accepting+community+contributions)).


### Proposal

1. Delete the [Accepting Merge Requests](https://gitlab.com/gitlab-org/omnibus-gitlab/-/labels?utf8=%E2%9C%93&subscribed=&search=Accepting) project label in `omnibus-gitlab` and replace it, on the related [issues](https://gitlab.com/gitlab-org/omnibus-gitlab/issues?label_name%5B%5D=Accepting+Merge+Requests), with the `gitlab-org` group label ~"Accepting merge requests". /cc @ibaum @marin @twk3
1. Delete the [Accepting community contributions](https://gitlab.com/gitlab-org/design.gitlab.com/-/labels?utf8=✓&subscribed=&search=Accepting) project label in `design.gitlab.com` and replace it, on the related [issues](https://gitlab.com/gitlab-org/design.gitlab.com/issues?label_name%5B%5D=Accepting+community+contributions), with the `gitlab-org` group label ~"Accepting merge requests". /cc @pedroms @tauriedavis

Story points: 1.0
Remove "~Accepting merge requests" label on all merge requests

### Problem

The ~"Accepting merge requests" label is usually attached to issues that are marked as open for community contributions.
However, it's also attached to [merged requests](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Accepting%20merge%20requests) opened directly from the issue using the [dropdown option](https://docs.gitlab.com/ee/user/project/issues/issue_data_and_actions.html#22-create-merge-request) or using the [quick actions](https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-and-merge-requests). The label is also sometimes added manually on merge requests.

### Proposal

1. Remove the ~"Accepting merge requests" label from _all_ merge requests.
2. Add a policy rule for the @gitlab-bot to auto remove this label from future merge requests that will continue to attach that label due to current UX. There is probably no need to change the current UX since auto removing the automatically attached ~"Accepting merge requests" label would be unnecessarily too specific, right?

Story points: 2.0
Add report for unscheduled customer bugs in Group level triage package 3.0

This is the help with `Key result`: Triage all existing customer ~S1 ~S2 ~bug and have them scheduled with a milestone.

* All existing ~customer ~S1 and ~S2 without a scheduled milestone. 
* Put the information in CE and EE.

This is done: https://gitlab.com/gitlab-org/gitlab-ce/issues/63136

We need to evaluate including this in the weekly triage packages

Story points: 2.0
Apply Control and Framework labels to Manage issues

Manage is going to split into [two groups](https://about.gitlab.com/handbook/product/categories/#manage-stage), Control and Framework. We'd love some help to get the many Manage issues correctly labeled so these groups can prepare for a successful split. :slight\_smile: 

The [label breakdown between the two groups](https://about.gitlab.com/handbook/product/categories/#other-functionality-in-manage):

~"group:control" 

* ~"user management" 
* ~"user profile" 
* ~permissions 
* ~"audit events" 
* ~"spam fighting" 
* ~"admin dashboard" 
* ~ldap 
* ~saml 
* ~authentication 
* ~authorization 
* ~oauth 
* ~group 
* ~groups 
* ~2FA 
* ~"group templates" 
* ~subgroups 

~"group:framework" 

* ~analytics 
* ~"cycle analytics" 
* ~convdev 
* ~project 
* ~"project export"
* ~"project import" 
* ~"project templates" 
* ~"gitlab.com" 
* ~navigation 
* ~internationalization 
* ~importers 
* ~import 

### Proposal

* [ ]  Apply the ~"group:control" label to all issues with both the ~Manage label OR the ~"devops:manage" AND one of the ~"group:control" subject labels above.
* [ ]  Apply the ~"group:framework" label to all issues with both the ~Manage label OR the ~"devops:manage" AND one of the ~"group:framework" subject labels above.

Story points: 2.0
Group triage packages to use stage label instead of Group label

It’s valid to have several group labels but only one stage label :thinking_face: Right now these issues will appear in both groups’ triage package but may not be relevant to both groups… (example: https://gitlab.com/gitlab-org/gitlab-ee/issues/9216). Maybe we should find group issues based on the stage label instead? Because we recommend only one of those be added to any issue at one time

Story points: 2.0
Autolabel group label on MRs based on author group information from team.yml

We need to start enforcing a high-level data hygiene on throughputs. 

> let's use this issue to implement the team member mapping to group labels. Also let's stop using the word "team" we need to be clear on the terminology.

Let's reuse the mechanism from enforcing stage labels. 

## Proposal
* Singularity on **Stages** and **Groups** will be built-in with scoped labels.
  * **Stages** ~"devops::plan", ~"devops::create", etc.
  * **Groups** ~"group::source code" ~"group::knowledge" ~"group::editor", etc.
* Improving the hygiene accounting on `group::xxx` labels
  * For un-labeled MRs we should be able to infer from a team member mapping in `team.yml` at that point in time to the `group::xxx`. This would also solve the case when engineers move from group to group since the label preserves that mapping at that point in time.
  * We will not auto label things that are corrected by a human or if the label is already present. 
  * If data is not present in `team.yml` we should introduce a structure there
* Improving the hygiene accounting to `devops:xxx` labels
  * If there is category label, map to the stage of category label.
  * If there is only group label, we will not auto label, as the group label could belong to an MR author who is working outside of their stage 
  * We will not auto label things that are corrected by a human or if the label is already present. 
* Stretch: Auto add specialty label and either ~frontend / ~backend 

## Solution

First we attempt to add **group label** based on the MR author in `pre-hygiene` stage. This would set the stage for `stage-and-group-labels-hygiene` whereby most MRs would have **group label** set either manually or inferred from the MR author.

The next `stage-and-group-labels-hygiene` job will then attempt to infer the remaining labels based on this table:

| # | has_stage_label? | has_group_label? | has_category_labels? | group_is_part_of_stage? | inference_strategy|
| -- | ------ | ------ | ----- | ------ | ------ |
| 1 | true | true | true | N.A | Not needed |
| 2 | true | true | false | true | infer category from group |
| 3 | true | true | false | false | do not infer category - too many categories per stage to infer reliably | 
| 4 | true | false | true | N.A | infer group from category or stage | 
| 5 | false | true | true | N.A | infer stage from category | 
| 6 | false | true | false | N.A | do not infer stage and category | 
| 7 | false | false | false | N.A | Not possible to infer | 

## Work to do
- [x] Create a new entry point for MR label inference based on above
- [x] Create new job in `pre-hygiene` to add group label based on MR author
- [ ] Use new entry point in MR label inference

Story points: 5.0
Add ~"Community contributor" across the gitlab-org group

For now we have a [special schedule for runner](https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/11219/edit) which sets ~"Community contribution"

We can escalate this to be gitlab-org group level after having https://gitlab.com/gitlab-org/gitlab-triage/merge_requests/89

/cc @markglenfletcher @meks

Story points: 1.0
Create a new rule to add ~"Community contribution" for core members (`gitlab-core-team`)

Because they're part of `@gitlab-org` and the current rules will not add the labels for core members.

----

The following discussion from !49 should be addressed:

- [ ] @gtsiolis started a [discussion](https://gitlab.com/gitlab-org/quality/triage-ops/merge_requests/49#note_116834216):  (+3 comments)

    > @gitlab-org/triage do you think contributions from the core team members should have the ~"Community contribution" label or not? If yes, I think we could a) add a new policy to add ~"Community contribution" label for members of `@gitlab-core-team`, b) update this rule to include a second `condition` which I don't think it's currently possible, or c) introduce a new label like *Core Team Contribution*.

Story points: 2.0
Remove `no-severity` and `no-priority` labels from issues with S/P labels

When asking a team member to help with adding S/P labels. We ensure that the prompt does not happen again by adding a ~"no\-severity" or ~"no\-priority" label.

Once the S/P labels have been applied, we could walk through and remove the ~"no\-priority" and ~"no\-severity" labels.

This makes the issues look cleaner and the remaining presence of this label could potentially impact other rules later. But I don't think this is essential right now

Story points: 2.0
Think of a way to create the labels for a new milestone automatically

We now have a lot of labels which corresponds to a particular milestone. We're creating them manually, but I think it's really easily to forget it or create it too early or too late. Too early, we might misuse them. Too late, it's inconvenient when we want to use them.

Example of milestone labels:

* ~"missed:11.2" and ~"Pick into 11.2" We only need them passing 11.2 freeze date
* ~"regression:11.2" We only need this after 11.2 is released

Could we make the bot create them automatically? We already know when ~"missed:11.2" should be applied, and for ~"regression:11.2" it's probably after the end of that milestone (i.e. 23th)

What we're missing is probably just a way to create the label in https://gitlab.com/gitlab-org/gitlab-triage

/cc @meks @markglenfletcher

Story points: 3.0
Audit the current group definition for group triage reports

Now who should be assigned and mentioned were defined at [lib/group_definition.rb](https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/lib/group_definition.rb), and some groups were outdated from the information written on [Product sections, stages, groups, and categories](https://about.gitlab.com/handbook/product/categories/).

One example mentioned at https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/483#note_334640221 that ~"group::threat management"  was renamed to ~"group::threat insights", and we need to reflect that.

I'll go over it and also split engineering managers so we can reuse better for https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/483

For example, change this:

``` ruby
def group_analytics
  {
    mentions: %w[@dennis @djensen @npost @jshackelford @wortschi],
    assignees: %w[@dennis @djensen @jshackelford @wortschi],
    labels: ['group::analytics']
  }
end
```

To this:

``` ruby
def group_analytics
  {
    pm: %w[@jshackelford],
    em: %w[@wortschi @djensen],
    product_design: %w[@npost],
    labels: ['group::analytics']
  }
end
```

I am confused if `@dennis` is a frontend engineering manager for this group, so I think I might need to ask a lot of people for confirming the new list...

/cc @gl-quality/eng-prod

Story points: 5.0