giseldo/neodataset huggingface dataset:
Propose new IA for Brand and Digital Handbook

## Goals
Propose new IA for Brand and Digital Handbook content, including existing content and foreseeable content updates. May require migrating Brand and Digital content currently spread across other team pages to a new, centralized [Brand and Digital Handbook location](https://about.gitlab.com/handbook/marketing/brand-and-digital-design/). 

* Some content will apply to entire Brand and Digital team, such as shared labels, whereas other content will be specific to Brand or Design
* Embrace Handbook IA conventions and only stray with strategic intent
* Solve for integration with other handbook sections and pages (i.e. cross-links)
* Make it easy for users looking for content in old locations to find that content in its new location (i.e. cross-links)
* Optimize IA and content for stakeholders AND our team 
* Avoid duplicate content wherever possible
* Announce change via appropriate channels

## Proposed tasks
* [x] Team - Identify existing Brand and Digital content
* [x] Shane & TBD Partner - Facilitate collaborative IA exercise in Mural or Figma, using digital post-its to represent existing and foreseeable content simply, and then organizing that content into a site map with arrows representing cross-links. 
* [x] @skarpeles - create a spreadsheet of which topics each person should handle
* [x] Team review
* [x] Implement in follow-on Issues/MRs

## How to contribute

If you have additional ideas or comments about what's mentioned in this description, please add them to this issue!
* Start a new thread for your idea/topic
* Keep comments relevant to the thread they're in
* As these discussions evolve, the brand team will review and add approved suggestions to the description and mark the thread with a :white_check_mark: 

## Mural Board

Link to Mural board of visual page hierarchy: https://app.mural.co/t/gitlab2474/m/gitlab2474/1579534915496/530305c8bd3e3e1831f08ad402b46926283f805c

## Spreadsheet of Pages
Spreadsheet of pages to complete, and who is responsible for each: https://docs.google.com/spreadsheets/d/1_QCkndT-6mR0wfuGxiLrFeWHG5RyTN6rYdR3cJHOEsw/edit#gid=0

## Google Doc of Content Migration
https://docs.google.com/document/d/1Tt9kODKAcecCvXsc6msu5j4yr448c0S8I3Mgffp4NNE/edit

@luke @brandon_lyon @skarpeles @monica_galletto @vicbell 

Story points: 1.0
Cache `node_modules` for www-gitlab-com pipelines

# UPDATE NOTE: This MR will not be implemented.  After looking at the initial numbers, the amount of additional time taken by the additional cache push/pull (~18500 files in `node_modules`, about ~8 seconds to push and ~8 seconds to pull) would eat up most of the gains caused by eliminating the `yarn install` (which takes ~20 seconds).  This seems to indicate that the Yarn/NPM network download time is normally very fast (probably due to CDN/etc, and yarn optimizations), almost as fast as downloading and unzipping the files from disk.  https://gitlab.com/gitlab-com/www-gitlab-com/issues/6358 still offers opportunities to do this caching via docker, though.

We currently don't put the downloaded node_modules in the cache, like we do for the bundler vendor directory containing gems.  This would probably be an easy and quick win to save 20-30 seconds, and also reduce the possibility of flaky builds (if the download happens to fail for network/etc issues - I'm not sure if we are using a local pass-through caching proxy or not)

POTENTIAL IMPROVEMENT: Small, probably 20-30 seconds for jobs which need this.

PROS:
* Easy to implement, low risk, same as we are already doing for gems

Story points: 1.0
Disable unnecessary jobs in pipeline when merging to master

As discussed in https://gitlab.com/gitlab-com/www-gitlab-com/issues/5983#note_267627509 we currently run the code_quality and dependency_scanning jobs for both MRs and merges to master.

Since no direct commits to master is allowed and MRs can't be merged until the pipeline passes it is sufficient to only run these two jobs on the MR pipeline.

This will [improve pipeline speed](https://app.periscopedata.com/app/gitlab/561277) by eliminating jobs on master which only need to run once for each commit, and should have already been run as part of a merge request.

See also more similar follow-on work in https://gitlab.com/gitlab-com/www-gitlab-com/issues/6190

Story points: 1.0
Propose an A/B Testing Framework for about.gitlab.com (Spike)

## Goals
Propose an A/B testing framework for testing conversion MVCs on about.gitlab.com so we can iterate, learn and increase conversions faster - and with more apples to apples data than comparing time periods.

## Requirements
* **Collaborate with appropriate stakeholders on MVC A/B test solution**

## Proposed Tasks
* Collaborate to identify potential requirements
* Set MVC requirements
* Collaborate on brainstorming technology solutions (consider build vs. buy)
* Propose a solution

## Follow-on Issue
Create an A/B testing framework for testing conversion MVCs on about.gitlab.com so we can iterate, learn and increase conversions faster - and with more apples to apples data than comparing time periods.
* Co-design, develop and test solution on conversion MVC

@brandon_lyon @laurenbarker 
@shanerice @jjcordz 
@s_awezec @jackib

Story points: 3.0
Demo Landing Page Conversion MVC


## Goals
Increase Demo landing page conversion rate on about.gitlab.com with collaborative, data-driven MVC.

## Requirements

Must Have
* **Co-design an improved and compliant solution** - Co-design a conversion-driven MVC that meets or exceeds the design and usability the current state solution. The MVC should be informed by conversion best practices, marketing strategy and brand and website standards. Consider page speed, content and form optimization.
* **Set KPIs** - Set MVC KPIs in order to test the positive and negative impacts of your change - especially marketing KPIs. How might your changes negatively affect experiences and metrics?
* **Validate performance** If testing proves the MVC is positive change, share demonstrable data, merge, and ensure health monitoring and reporting.
* **Share change events** - Document and share change events and results with relevant GitLab teams.

Should Have

Could Have

Wont Have
*  **Non-cohesive demo experience** - Ensure the new landing page experience is aligned to the overall demo workflow (i.e. continuous content and design experience).

## KPIs
Design KR: Increase Demo landing page conversion rate by 50%. 

Current State Benchmark: Conversion rate is 9.5% (23,821 unique pageviews QTD; 2,272 unique submit events)


## Proposed Tasks
* [ ] WIP: Conversion audit & recommendations (Shane)
* [x] KPI's
* [ ] Planning
* [ ] MVC Requirements 
* [x] Iterative Co-Design 
* [x] Build the page @skarpeles 
* [x] Test 
* [ ] If success: Merge, monitor and report
* [ ] Create follow-on issues, as needed.

@brandon_lyon @skarpeles 
@shanerice @jjcordz 

<!-- Please leave the label below on this issue -->

Story points: 4.0
Home Page Conversion MVC


## Goals
Increase Home page conversion rate on about.gitlab.com with collaborative, data-driven MVC.

## Requirements

* **Co-design an informed solution** - Co-design a conversion-driven MVC that meets or exceeds the design and usability the current state solution. The MVC should be informed by conversion best practices, marketing strategy and brand and website standards.
* **Set KPIs** - Set MVC KPIs in order to test the positive and negative impacts of your change - especially marketing KPIs. How might your changes negatively affect experiences and metrics?
* **Validate performance** If testing proves the MVC is positive change, share demonstrable data, merge, and ensure health monitoring and reporting.
* **Share change events** - Document and share change events and results with relevant GitLab teams.

Should Have


## Proposed Tasks
* [x] @sbouchard1 Conversion audit & recommendations
* [ ] @shanerice KPI's
* [ ] Planning
* [ ] MVC Requirements 
* [ ] Iterative Co-Design 
* [ ] Development @skarpeles 
* [ ] Test 
* [ ] If success: Merge, monitor and report
* [ ] Create follow-on issues, as needed.

@brandon_lyon @skarpeles 
@shanerice @jjcordz 

<!-- Please leave the label below on this issue -->

Story points: 4.0
GitHub and Azure DevOps links should go to sections on comparison pages

### Acceptance Criteria:

The logos on https://about.gitlab.com/devops-tools/ should link to related tabs on the resulting page.

- [x] Clicking on the "Azure devops" logo under the "create" column should link to `https://about.gitlab.com/devops-tools/azure-devops-vs-gitlab.html#create`
- [x] URL hashes should be manually navigable, ie typing in the URL manually links to that spot.

For now this will only apply to two rows: GitHub and Azure.

### Problem Statement:

```
via @tbarr

The GitHub and Azure DevOps logos link to this page: https://about.gitlab.com/devops-tools/github-vs-gitlab.html or this page: https://about.gitlab.com/devops-tools/azure-devops-vs-gitlab.html

The logos in the Comparison chart should deep-link into the section that is relevant. For example, if you click on the GitHub logo under PACKAGE, it should take you to: https://about.gitlab.com/devops-tools/github-vs-gitlab.html#package

There also seems to be a problem that even if you paste that link, it doesn't take you to package until you click.

cc @mskumar
```

Story points: 2.0
Add CTA to Global Website Nav

## Goals
Increase online conversions by adding a call-to-action (CTA) element to the about.gitlab.com global nav.

## Requirements

Must have
* **Stand out CTA element** - Next to the GitLab logo, the CTA is a stand out element on the global nav.
* **Co-design an informed solution** - Co-design a conversion-driven MVC that meets or exceeds the design and usability the current state solution. The MVC should be informed by conversion best practices, marketing strategy, and brand and website standards. 
* **Stand out CTA element** - Pick CTA to try (will impact KPIs)
* **Set KPIs** - Set MVC KPIs in order to test the positive and negative impacts of your change - especially marketing KPIs. For example, if changing other elements is required to fit the new CTA, how might that negatively impact other experiences and metrics?
* **Validate performance** If testing proves the MVC is positive change, share demonstrable data, merge, and implement health monitoring and reporting.
* **Share change events** - Document and share change events and results with relevant GitLab teams.

Should have
* **Ability to opt-out of CTA** - For example, an important content funnel where the primary goal is the content download.

## Tasks
*  [x] @shanerice KPIs (add 5,600 `/free-trial/` pageviews per month)
*  [x] WIP: Co-design
*  [x] Dev
*  [ ] @shanerice @brandon_lyon Test


@s_awezec @matejlatin 
@brandon_lyon @shanerice @jjcordz @skarpeles

Story points: 4.0
Remove use of alt-link and ensure homepage displays appropriate category links

From [scaling agenda](https://docs.google.com/document/d/1nMJzrDfG7C14WP5v7P226oPFuXkwqIk7bdIT8ai0DNU/edit#bookmark=id.yqcc4osgu9vm):


> KENNY EricB Sid: Can we ensure that every shipped feature in the table on https://about.gitlab.com/ links to the docs? Usability testing linked to https://about.gitlab.com/direction/verify/usability_testing/ so please test others.
> EricB: I’ll take this one for the team and get a MR out today
> Here’s the MR: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/35049
> EricB: I’ve asked Todd B to merge as it changes our homepage
> Reverted in https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/36826
> Kenny: We need to adjust the logic for how the link is selected on the homepage to select Product link first, then docs, then vision based on availability and remove the use of the alt-link.
> Also give error if it is no longer planned but there is no docs link.
> Kenny: Thumbs up, I’ll add the lint.

## Tasks
* [x] Banish Alt_Link - https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/36915
* [x] Add CI Check on categories.yml file - https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/37335

Story points: 1.0
Add tweet button when highlighting text in the handbook

### Problem to solve

In order to increase reach of the GitLab handbook, we should make it easy to tweet out highlighted text.

### Proposal

When a user highlights text, let's pop up a twitter button. When a user clicks that button it takes them to a separate page to tweet out the quote with a link back to the handbook page where the text was. [Medium](https://medium.com/darklang/how-dark-deploys-code-in-50ms-771c6dd60671) has a similar feature.

![image](/uploads/2bc4afa929f2ff19479ad66ccd1cc1a3/image.png)

### Implementation details

The share link to use is, `https://twitter.com/intent/tweet?url=$URL&text=$text&hashtags=$tags`, where:
1. `$url` is a URI encoded string of the handbook page the user is currently on
1. `$text` is a URI encoded string of the text the user has selected
1. `$tags` is a comma separated list of the hashtags to add to the tweet. Propose defaulting to `gitlab,handbook`

Story points: 3.0
AUP Layout change and minor update

### Description

Currently section 3 of the [Gitlab Website Terms of Service](https://about.gitlab.com/terms/#gitlab_com) is not formatted in a way that is easy to read and does not include the term `Spam`. 

Checklist when modifying an existing page:

- [ ] What is the goal of changing the page?
- [ ] What metrics are we trying to affect?
- [ ] How will we decide if the change was successful or not?
- [ ] Would we revert the changes if we decided that it was not a success?
- [ ] Make sure events are reflected in Google Analytics/Marketo if the page is changed
- [ ] Make sure redirection is done if we change the page so email newsletters do not contain dead link

### Proposal
Update the AUP to make it easier to read and include the term `Spam`.

Proposed change/format below:

### Acceptable Use of Your Account and the Website 

By accepting this Agreement you agree not to use, encourage, promote, or facilitate others to use the Website or your account in a way that is harmful or disruptive to others ("Acceptable Use"). 

Examples of harmful or disruptive use include, but are not limited to: 
* engaging in illegal or fraudulent activities.
* infringing upon others' intellectual property rights.
* distributing harmful or offensive content that is defamatory, obscene, abusive, an invasion of privacy or harassing.
* the distribution of malicious/commercial Spam 
* violating the security or integrity of any computer, network or communications system.
* taxing Gitlab resources with activities such as cryptocurrency mining. 
* conducting [external scans](https://about.gitlab.com/security/#external-testing) of any kind against GitLab.com infrastructure without written permission from GitLab. 

Furthermore, account name squatting is prohibited by GitLab. Account names on GitLab are administered to users on a first-come, first-serve basis. Accordingly, account names cannot be held or remain inactive for future use. Any attempts to purchase, solicit, or sell account names in any form may result in the permanent suspension of the account. GitLab reserves the right to remove, rename, or close inactive accounts at its discretion. 

If you believe that an account is in violation of these terms, please visit our [Abuse Reports](https://docs.gitlab.com/ee/user/abuse_reports.html) page for reporting instructions. 
### Links / references

https://about.gitlab.com/terms/#gitlab_com

cc @gl-website
cc @jhurewitz @cciresi

Story points: 1.0
Wide tables are causing page display issues for the about.gitlab.com on mobile

<!--Bug Report-->
<!--Please remember this are suggestions. Any extra information you provide is beneficial.-->
<!-- Edit this file at : https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/.gitlab/issue_templates/Bug-Report.md -->
<!-- Template code owner: @brandon_lyon, marketing web designer/developer -->

### What is/are the relevant URLs or emails?

Any page with a table wider than a mobile device, e.g.:

* https://about.gitlab.com/handbook/engineering/security/vulnerability_management/
* https://about.gitlab.com/handbook/product/product-management/#product-management-career-development-framework
* https://about.gitlab.com/devops-tools/azure_devops/azure-devops-overview/

### Briefly describe the bug

Pages with wide tables cause the responsive mobile view to be wider than the header, and thus scroll horizontally

### What are the steps to reproduce the bug

* Use a on a narrow mobile device, e.g. iPhone X.
* Go to a page which has a wide table.  E.g. one of URLs above

### What is the observed behavior? Be specific.

* Zoom out/scroll to the right, see grey area
* Scroll down to table, and see that it is the cause of the too-wide behavior

### What is the expected behavior? Be specific.

* Table is sized to device width, and page is not scrollable horizontally.

### Please provide any relevant screenshots

![mobile_rendering](/uploads/2442980a31d45f72e0e0019c71ab7959/mobile_rendering.png)

For reference - here is what Desktop looks like:

![Screen_Shot_2019-10-18_at_12.31.10_PM](/uploads/1a3b73f049fa857af705d3abff4e4891/Screen_Shot_2019-10-18_at_12.31.10_PM.png)

### What is your window size, browser, operating system, and versions

Safari 13, iOS 13.1 414px by 896px

Also tested on an Android device

### What device are you using

* iPhone 11 pro max
* iPhone X in Chrome developer tools responsive emulator

Story points: 2.0
Add Periscope Charts to Engineering Productivity PIs

We should add Periscope charts to the Engineering Productivity team KPIs

The following was added with https://gitlab.com/gitlab-com/www-gitlab-com/commit/f192317d7669dd70fc9b70b4d8219245af4472b7

```
periscope_data:
    chart: 6114177
    dashboard: 463858
    embed: v2
```

Story points: 1.0
Add External Pipeline for Marketing Site

### Problem to solve

Local development of this repo is slow and cumbersome. Production build times for Middleman are also slow. 

### Proposal

Let's move frontend asset builds out of Middleman and into an `external_pipeline`. This will allow Middleman to do what it does best - compile the HTML.

For our `external_pipeline`, lets have it complete the following tasks:
- preprocess scss
- minify css
- minify js
- bundle js
- sourcemaps
- copy web fonts, icons
- image resizing and processing* (depending on speed)
- browser reload (local dev)
 (local dev)

### What does success look like, and how can we measure that?

Faster local development for developers.

Faster deployment times. Reduced publishing time for blog, handbook, and marketing webpages. 

### Iterative Approach
1. Process Stylsheets with Webpack first, introducing build to system
1. Monitor and fix edgecases
1. Add javascript bundling to Webpack second
1. Monitor and fix egecases
1. Migrate rollup to Webpack for vue component bundles
1. Monitor and fix edgecases
1. Add image process to Webpack


cc @gl-website

Story points: 8.0
Add a Collapse All / Expand all button to the company org chart

Add a button at the top of the org chart that allows the user to toggle between collapsing/expanding all the nodes by clicking on the button.

Default org chart state should be to be fully expanded.

Button text:
- If all nodes are expanded: Collapse all
- If any node is collapsed: Expand all 

Reference: https://gitlab.slack.com/archives/C3MAZRM8W/p1568416800345400?thread_ts=1568366463.339100&cid=C3MAZRM8W

Story points: 1.0
What is accessibility testing and why is no one doing it?



### Proposal

Assigned to @skassabian as this was the jumping off point for her survey on accessibility. I'm on unclear on time frame but put June 2020 as a placeholder.

### Checklist

- [ ] If you have a specific publish date in mind (please allow 3 weeks' lead time)
  - [ ] Include it in the issue title
  - [ ] Give the issue a due date of a minimum of 2 working days prior
  - [ ] If your post is likely to be >2,000 words, give a due date of a minimum of 4 working days prior
- [ ] If [time sensitive](https://about.gitlab.com/handbook/marketing/blog/#time-sensitive-posts-official-announcements-company-updates-breaking-changes-and-news)
  - [ ] Added ~"priority" label and supplied rationale in description
  - [ ] Mentioned `@rebecca` to give her a heads up ASAP
- [ ] If wide-spread customer impacting or sensitive
  - [ ] Add ~"sensitive" label
  - [ ] Mention `@nwoods` to give her a heads up ASAP
- [ ] If the post is about one of GitLab's Technology Partners, including integration partners, mention `@TinaS` and see the [blog handbook for more on third-party posts](https://about.gitlab.com/handbook/marketing/blog/index.html#third-party-posts)
- [ ] Indicate if supporting an event or campaign
- [ ] Indicate if this post requires additional approval from internal or external parties before publishing (please provide details in a comment)

Story points: 3.0
Encode devops stages parent/child structure in either categories.yml or stages.yml

With the process of building our dashboards and label migration. We should store the single source of truth on devops stage parent-child structure in the handbook project.

Context: 

* https://gitlab.com/gitlab-org/quality/triage-ops/issues/172#mapping
* https://quality-dashboard.gitlap.com/groups/gitlab-org/stages

Comments from the dev metrics meeting.

> Jason: Idea is to encode this in data in the handbook. => Lyle: isn’t it categories.yml and stages.yml. => Jason: There is no label field. We should extend it.

Story points: 3.0
Quality Engineering KPI - Build bug first triage (with stage/group and severity) metric into Periscope

### Overview 

Measure our speed to triage new issues. We currently have ~400 new issues every week in CE/EE. We need to go through all of them and identify valid issues and high severity bugs. 

## Measurement definition

The duration from issue creation to partial triage time for all gitlab-org/quality/team-tasks~2278648 issues in `gitlab-org/gitlab`. This will be visualized as a Time Series chart showing the average duration by month. 

Next steps:
- [x] Define an automated mechanism to detect first triage of a GitLab team member. - starting with description in https://gitlab.com/gitlab-org/quality/team-tasks/issues/136#note_211116724 
- [ ] Define measure mechanism and establish threshold.  
- [ ] Fan-out triaging to all of engineering. First triage is mostly on the Quality Dept Eng Prod team.
- [ ] Expand this into first scheduled milestone.

We need to build this in Periscope and respect/update https://about.gitlab.com/handbook/engineering/quality/performance-indicators/.

Once finalized, the chart should go into https://app.periscopedata.com/app/gitlab/516343/Quality-KPIs.

Story points: 3.0
Geo blog post: what we've learned about FDW

We could write a nice technical blog post about how we use FDW, how we set it up, which challenges we encountered, and what we did to improve performance. Also writing about our ActiveRecord model could be interesting.

But since we seem to be moving away from it, it might be better to just list the lessons we've learned from it.

cc `@geo-team`

Story points: 3.0