giseldo/neodataset huggingface dataset:
Bug with mobile menu on events template

This template is for filing a bug report related to the logged out marketing website https://about.gitlab.com/ and 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.

#### What is/are the relevant URL(s)

`https://about.gitlab.com/events/commit/`

#### Briefly describe the bug

Example: A link is broken and when hovering over it the color is the wrong color and poorly aligned.

`The mobile menu on the event page feels broken since the menu doesn’t collapse upon selecting a link.`

#### If possible, please specify how to reproduce the bug

`On a mobile device (small display), open the hamburger menu and click on a link.`

#### Please provide any relevant screenshots or screencasts

How to take a screenshot: https://www.howtogeek.com/205375/how-to-take-screenshots-on-almost-any-device/

![Greenshot_2020-08-24_10.46.11](/uploads/4aecd993211b8a54f7b56915b9cd0015/Greenshot_2020-08-24_10.46.11.png)

#### What is your window size, browser, operating system, and versions

Please use the following website to determine your browser specifications and provide a link developers can follow:

What is my browser https://www.whatsmybrowser.org

`https://www.whatsmybrowser.org/b/QV0IN`

#### What computing device are you using?

Please list the brand and model (Example: Samsung Galaxy S 10 Plus)

`Mobile phone`

#### Have you tried a fresh incognito window? Could this be related to cookies or account type/state?

- [x] I tried a fresh incognito window & it had no impact.
- [ ] The problem goes away when using an incognito window.
- [ ] The problem only happens when certain cookies are set to a specific value (please specify below).

#### Please list any browser plugins you have enabled

Why do we ask for this? Certain website bugs may be caused by plugins. For example: Adblock, noscript, ghostery, safe browsing.

`N/A`

#### What is your geographic location

Why do we ask for this? Certain bugs may be geographically related. For example, if you're in the European Union, it could be related to GDPR policy and cookies.

`N/A`

#### What type of network are you connected to?

**Type**

- [ ] Wired
- [ ] Wifi
- [x] Cellular (4G, 5G, etc)
- [ ] Satellite
- [ ] Other

`Insert details here if applicable`

**Location**

- [x] Home
- [ ] Workplace
- [ ] Travel facility (hotel, airport, conference center, etc)
- [ ] Public venue (restaurant, library, cafe, etc)
- [ ] VPN
- [ ] Other

`Insert details here if applicable`

**Hardware**

- [ ] I am behind a network security appliance such as a firewall
- [ ] I am using a pi-hole or other hardware-based traffic blocker
- [ ] Other

`Insert details here if applicable`

<!-- These labels will be automatically applied unless you edit or delete the following section -->

Story points: 1.0
DevSecOps survey - CI insights – 2020-10-22

<!-- PLEASE READ: See https://about.gitlab.com/handbook/marketing/blog/ for details on the blog process. Unless you are just suggesting a blog post idea, you will need to create the formatted merge request for your blog post in order for it to be reviewed and published. -->

### Proposal

Need to go over the DevSecOps survey and find some CI or CI/CD-related content and talk about it.

Then I need to recommend some other CI-content.

Awareness-level



### 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/#process-for-time-sensitive-posts)
  - [ ] Add ~"Blog: Priority" label and supplied rationale in description
  - [ ] Mention `@rebecca` to give her a heads up ASAP
- [ ] If wide-spread customer impacting or sensitive, mention `@nwoods` to give her a heads up ASAP, apply the ~"sensitive" label, and check the [PR handbook](https://about.gitlab.com/handbook/marketing/corporate-marketing/#requests-for-announcements) in case you need to open an announcement request instead of a blog post issue
- [ ] If the post is about one of GitLab's Technology Partners, including integration partners, mention `@TinaS`,  apply the ~"Partner Marketing" label, and see the [blog handbook for more on third-party posts](https://about.gitlab.com/handbook/marketing/blog/index.html#third-party-posts)
- [ ] If the post is about one of GitLab's customers, mention `@KimLock` and `@FionaOKeeffe`, apply the ~"Customer Reference Program" label, 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
How to get started with GitLab's pipeline templates - 2020-09-23

<!-- PLEASE READ: See https://about.gitlab.com/handbook/marketing/blog/ for details on the blog process. Unless you are just suggesting a blog post idea, you will need to create the formatted merge request for your blog post in order for it to be reviewed and published. -->

### Proposal

There has been some confusion in the past on Auto DevOps and that the term means. I think a blog discussing Auto DevOps in the context of pipeline templates would be helpful. I think a tutorial-type of blog post showing how to use these templates, how to customize them, and how to use them to get started quickly with GitLab CI would helpful for developers.

### [Link to draft](https://docs.google.com/document/d/1ccPqcd2CrSM-r5wLriRtTt7TmTndNWJ6XQJzaTFffv8/edit?usp=sharing)

### Checklist

- [x] If you have a specific publish date in mind (please allow 3 weeks' lead time)
  - [x] Include it in the issue title
  - [x] 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/#process-for-time-sensitive-posts)
  - [ ] Add ~"Blog: Priority" label and supplied rationale in description
  - [ ] Mention `@rebecca` to give her a heads up ASAP
- [ ] If wide-spread customer impacting or sensitive, mention `@nwoods` to give her a heads up ASAP, apply the ~"sensitive" label, and check the [PR handbook](https://about.gitlab.com/handbook/marketing/corporate-marketing/#requests-for-announcements) in case you need to open an announcement request instead of a blog post issue
- [ ] If the post is about one of GitLab's Technology Partners, including integration partners, mention `@TinaS`,  apply the ~"Partner Marketing" label, and see the [blog handbook for more on third-party posts](https://about.gitlab.com/handbook/marketing/blog/index.html#third-party-posts)
- [ ] If the post is about one of GitLab's customers, mention `@KimLock` and `@FionaOKeeffe`, apply the ~"Customer Reference Program" label, 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: 2.0
How to get the most out of your YAML configs - 2020-10-01

<!-- PLEASE READ: See https://about.gitlab.com/handbook/marketing/blog/ for details on the blog process. Unless you are just suggesting a blog post idea, you will need to create the formatted merge request for your blog post in order for it to be reviewed and published. -->

### Proposal

This is a best practices blog post specifically designed for optimizing YAML rather than just pipelines or other CI-related terms. Other platforms discuss YAML and I think it would be helpful for us to talk about this as well.



### 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/#process-for-time-sensitive-posts)
  - [ ] Add ~"Blog: Priority" label and supplied rationale in description
  - [ ] Mention `@rebecca` to give her a heads up ASAP
- [ ] If wide-spread customer impacting or sensitive, mention `@nwoods` to give her a heads up ASAP, apply the ~"sensitive" label, and check the [PR handbook](https://about.gitlab.com/handbook/marketing/corporate-marketing/#requests-for-announcements) in case you need to open an announcement request instead of a blog post issue
- [ ] If the post is about one of GitLab's Technology Partners, including integration partners, mention `@TinaS`,  apply the ~"Partner Marketing" label, and see the [blog handbook for more on third-party posts](https://about.gitlab.com/handbook/marketing/blog/index.html#third-party-posts)
- [ ] If the post is about one of GitLab's customers, mention `@KimLock` and `@FionaOKeeffe`, apply the ~"Customer Reference Program" label, 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: 2.0
Community contribution pipelines fail

There is a new recurring issue with community contributions to `www-gitlab-com` over the past few weeks. When they create/change an MR, the pipelines fail. When a GitLab team member clicks the “Run Pipeline” button, the pipelines pass - despite making no changes.

Here is an example:
- https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/59977/pipelines.

Here is an another example:
- https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/59503

Why is this happening and can it be resolved?

CC @dmurph @johncoghlan  @cwoolley-gitlab

Story points: 2.0
Reapply redirects in pipeline for testing manually

## Question

Can we reapply redirects manually from a pipeline to a branch after redirects deploy for a newer branch?

## Scenario

Occasionally there will be multiple redirect updates in different branches and we might need to test redirects in an older MR. Right now, redirects are applied to the latest MR with changes to `redirects.yml`. Can we apply redirects manually to older MRs for testing if needed?

@laurenbarker you asked for me to ask this in another MR but I don't have a branch to ask so I created this issue. I'm assigning to you for now, let me know if I can help with any part of it

Story points: 2.0
Add a visual element on Handbook pages to differentiate it from Marketing pages

### Proposal
Add a visual element on the Handbook pages to help differentiate it from Marketing pages. 

### What problem is this solving?
At the moment we have enabled editing with the static site editor on Handbook pages. However some marketing pages look like Handbook pages and it is confusing users why they can't use the static site editor.

An example of this is with the Direction page (https://about.gitlab.com/direction/)

One approach to solving this problem is moving the content to the Handbook. This approach may take a while to coordinate across teams so we are considering a smaller more immediate change on the Handbook side to help users quickly recognise that they are on the Handbook.

| Handbook Page | Non-handbook Page |
| ------ | ------ |
| ![CleanShot_2020-08-21_at_08.43.45_2x](/uploads/4b4be81909dd742fefbdb97e242d257c/CleanShot_2020-08-21_at_08.43.45_2x.png) | ![CleanShot_2020-08-21_at_08.43.32_2x](/uploads/7ed331fff28e3f1f6e753ca7777a65bc/CleanShot_2020-08-21_at_08.43.32_2x.png) |

_example of two pages looking very similar, however, are in different areas of the site_

### Suggestion
We are considering changing the background image of the header area of the Handbook.

This would be an extension of what we are already doing with the favicon in the browser for Handbook page
![Screen_Shot_2020-08-21_at_11.45.00_am](/uploads/94040e40ae063650d8227cc99cd4cae5/Screen_Shot_2020-08-21_at_11.45.00_am.png)

### Extra information

The current background image is constructed of a left and a right svg (226x400 px)
- https://about.gitlab.com/images/home/icons-pattern-left.svg
- https://about.gitlab.com/images/home/icons-pattern-right.svg 

~"group::static site editor" ~"devops::create" ~"category::static site editor"

Story points: 1.0
Add A beginner's guide to GitOps ebook to topics page

Please select a template from the top left dropdown before continuing.

This repository primarily relates to the logged out marketing website
https://about.gitlab.com/ 
and 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.

If you do not select an appropriate template then your issue might get lost. For more information about our workflows, please reference the handbook for the marketing website
https://about.gitlab.com/handbook/marketing/website/
or reference your team documentation.

### FAQ:

Q: Which template should I use?

A: Most people will use the "-website-bug-report" or "-handbook-update" issue templates. To request updates to existing pages or new content, please visit https://about.gitlab.com/handbook/marketing/growth-marketing/#requesting-support

There are also templates for writing various kinds of blog posts including the unfiltered category. Please see the blog handbook for instructions before you open an issue: https://about.gitlab.com/handbook/marketing/blog/#publishing-process 

The rest of the templates are likely specific to team, role, or special occasion.

Q: When will you get to this issue?

A: Your issue will be refined and then prioritized relative to other issues. Marketing's website development team is currently an impacted resource.

Q: How do I link to an issue template?

A: https://gitlab.com/gitlab-com/www-gitlab-com/issues/new?issuable_template=name-of-template

Q: How do I edit this FAQ? I have another question.

A: Submit an issue
https://gitlab.com/gitlab-com/www-gitlab-com/issues/new 
with FAQ in the title and assign it to @ brandon_lyon or another member of the website team
https://about.gitlab.com/handbook/marketing/website/

Story points: 1.0
Phase 2 Website Update - stages-devops-lifecycle/

```

BL notes to self:

* The parts left for me are outlined in a comment near the bottom
  https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/8738#note_422873185


```

This template if for the Marketing Growth Team for their Phase 2 Webpage updates

Title this issue: Phase 2 Website Update - (Page Name) 

[Phase 2 Epic](https://gitlab.com/groups/gitlab-com/marketing/growth-marketing/-/epics/23)

## Metadata for page
- **Intent:** 
- **Goal:** 
- **Who is code owner:**  
- **SME Group:** 

## Adjustments to be made:
These adjustments are from this audit round

- [x] Add metadata
- [x] Swapping content or content links
- [ ] Adding pathfactory link 
- [ ] Adjusting SEO 
- [ ] Adding CTA buttons
- [x] Adjusting copy on CTA buttons
- [x] Adjusting old/erroneous messaging
- [ ] Improve mobile optimization
- [ ] Clean up alignment
- [ ] Adjust color schemes
- [x] Swap out old assets

## Roles and Responsibilities

| Role | DRI |
| ------ | ------ |
| Project DRI | @rreich  |
| Marketing Analytics | @shanerice  |
| Content/Messaging | @erica|
| Web Dev | @skarpeles  |
| Brand/Design  | @luke |
| GM Stakeholder | @dmor  |
| PMM approver (copy updates) | @williamchia |

## Production
**Project DRI**
- [x] Add design to design tab
- [ ] Decide on audit items and check-off
- [ ] Assign to relevant Team Leads for visibility 
- [ ] Make relevant WIP MRs
- [ ] Add this issue to the page epic description 
- [ ] Close issue once set of MRs is complete 

**Team Leads**
You may make comments in the design tab for tracking, but conversations on updates should be kept to the relevant MRs

Story points: 3.0
Document how to investigate Release Stage error budget in handbook

### Overview

This issue tracks the effort to document how to investigate drops in the [error budget](https://dashboards.gitlab.net/d/stage-groups-detail-release/stage-groups-release-group-error-budget-detail?orgId=1).

The aim here is ensure new joiners and other engineers can follow a clear process to investigate such issues moving forward.

### Proposal

- Add a new section in the [Release Group](https://about.gitlab.com/handbook/engineering/development/ops/release) handbook page.
- Under the new section, document the steps one could follow to investigate issues with the [error budget](https://dashboards.gitlab.net/d/stage-groups-detail-release/stage-groups-release-group-error-budget-detail?orgId=1).

Story points: 1.0
Evaluate Cube.dev as read abstraction layer for  ClickHouse and PostgreSQL

## Background

One of the exit criteria for [ClickHouse Working group](https://about.gitlab.com/company/team/structure/working-groups/clickhouse-datastore/#exit-criteria) states

> Consider an abstraction layer to interaction with ClickHouse or alternatives

With motivation behind it being the fact that ClickHouse requires significant resources to be run, and for smaller installations of GitLab it might not return investment with provided performance improvement. That in result creates a risk that ClickHouse might not be globally available for all installations and all features would need to account for the fact that there might be different data stores available. In order to avoid placing burned of detecting and handling multiple data stores on each feature implementation an abstraction layer is considered that will abstract specific data store from feature code

## Goal

Build prof of concept prototype that would follow outlined later exercise scenario and provide summary that is going to rate prospect solution agains following criteria:

1. Can all requirements from exercise scenario be completed: (Yes/No)
1. Can database engine specific functions like ([percentile_disc](https://www.postgresql.org/docs/9.4/functions-aggregate.html)) being used: (Yes/No/After additional work):
1. Measure execution time for each of the exercise scenarios
1. Have you encountered any performance issues and/or excessive hardware resources consumption
 
On scale 1 to 5 (1 - very easy, 5 - very hard):
1. How complex was to write request to realise outlined scenarios
1. How complex would be to configure add new table to each of the engines
1. How complex would be to apply changes to schema of each relations described in the exercise scenario section

## Exercise scenario

Proof of concept prototype with [cube.dev](https://cube.dev/docs/getting-started/docker) must retrieve following information for each of data engines:

1. Total number of clients for each country  
1. Get 75 [percentile](https://en.wikipedia.org/wiki/Percentile) for total price of orders
2. Find `order_id` of the order that have the biggest total price

Data engines schema details are: 

### PostgreSQL

1. Create 4 tables `Clients (id, name, country)`, `Orders(id, client_id, created_at)`, `LineItems(id, item_id, order_id, created_at)` and  `Items(id, name, created_at, price)` 
2. Seed tables with 100 clients records
3. Seed 100 items records
4. Seed 1000 000 orders, where 250000 orders contain 1 line item, 250000 orders contain 2 lines items, 250000 orders contain 3 lines items, and finally 250000 orders contain 4 lines items

# Clickhouse

1. Create single table `LineItemAddToOrderEvent(id, client_name, client_country, order_id, item_name, item_price, created_at)`
2. Seed it with 2 500 000 rows

Story points: 5.0
Collect list of prospect ClickHouse and PostgreSQL abstraction layer solutions

## Background

One of the exit criteria for [ClickHouse Working group](https://about.gitlab.com/company/team/structure/working-groups/clickhouse-datastore/#exit-criteria) states

> Consider an abstraction layer to interaction with ClickHouse or alternatives

With motivation behind it being the fact that ClickHouse requires significant resources to be run, and for smaller installations of GitLab it might not return investment with provided performance improvement. That in result creates a risk that ClickHouse might not be globally available for all installations and all features would need to account for the fact that there might be different data stores available. In order to avoid placing burned of detecting and handling multiple data stores on each feature implementation an abstraction layer is considered that will abstract specific data store from feature code

## Goal

Collect list of available solutions including both open source ones like cube.dev and option to build one in house. When looking at solution it is not expected to provide in detail evaluation against criteria defined at https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/14402 but rather have them in mind as next steps, and discard solutions that from the first glance seems to not suffice requirements

Story points: 3.0
Stop Proposal: Stop maintaining the PPS data on the "Features by Theme" page

## Start pointing to the Post purchase survey (PPS) Dashboard

We currently update the `pps_*` values in `features.yml` in order to populate the [Features by Theme page](https://about.gitlab.com/features/by-theme/).

We should discontinue maintaining those values and instead direct the audience to the [PPS Dashboard](https://app.periscopedata.com/app/gitlab:safe-dashboard/1007759/PPS-Dashboard).

## What was the initial objective?

https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/66574 created `features/by-theme` in order to create:

> a page that represents the key features by capability and cleanups some of the listed features for those capabilities. The cleanup mostly involved removing features that seemed duplicative when listed alongside others in the same capability.

https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84577 added the PPS data to the page ...

But there isn't any additional context on the intent in the MR. 

## Are we achieving the objective?

I'm not sure, but updating the pps values to populate that page is an inefficient, time-consuming process.

Now that all of the PPS data is available in Sisense we should utilize it as the primary destination for this type of data.

If grouping the results by pricing theme is valuable to team members, we could explore a way to provide that visualization in Sisense.

## Proposal

1. Remove the PPS values from the table and return the page to its initial design:

![image](/uploads/900302d80812eba8a6ffba625d71c6be/image.png)

_Wayback machine_

2. Add a link to the page pointing visitors to the PPS Dashboard if they are looking for PPS data for a given feature.

3. Optionally, delete the page entirely if "Features by Theme" is no longer used by team members in strategic decision making.

## Traffic

Is there an audience for this page?

The page had 711 visits in calendar year 2022. 509 if you remove that strange spike at the end of August.

![image](/uploads/53c78617dd9d52e994224c89d749e3e1/image.png)

The vast majority are from Google, but I'm not sure what to make of that.

It's an internal-facing page, so the low traffic may not be particularly instructive.

Story points: 1.0