giseldo/neodataset huggingface dataset:
Add more clarity around bold 600 decision

Its not clear from looking at pajamas what font weight we use for bold text. You have to inspect the text or find the variable in GitLab UI. 

We should include the variable name and it's value on the typography page. We can also include explanatory text that explains why we use 600 over 700

> It’s because some system fonts have a semi-bold, which would be mapped to 600, and that weight was preferred. For system fonts without a semi-bold it would be mapped to the 700 weight, which is why it could look extra bold in other OSs.

Story points: 1.0
Form help and error text should not be separate

## Problem

For our form elements, help text and error text are currently defined as two separate text items. This could be confusing as error text could be partially duplicative of the help text. Depending on how the help text is tied to the input for accessibility, this could also add confusion, or cause some info to be missed. Because the help text remains gray, it visually feels disconnected with an input in error state.

## Solution

Help text is a single, dynamic text block with the potential for multiple states.

* By default it is instructional and in a neutral palette
* When an error occurs the help text becomes more explanatory so that a user knows how to correct the error. The danger palette is used.

In this case there is inly one help text block for instruction and error prevention.

| **Before** | **After** |
| ------ | ------ |
| ![Frame_1](/uploads/bda6fdfcebb2d5ae11204f5af07e0451/Frame_1.png) | ![Frame_2](/uploads/cffdf4046b706318d38fbd325cdafc68/Frame_2.png) |

/cc @uhlexsis @tauriedavis @pedroms

Story points: 1.0
Combine contents of "Vue component" and "Design" tabs into a single page

There is often duplicated content between the tabs. For example: "Alerts allow the application to pass along relevant system information to the user without impeding their journey. Alerts are system generated and may or may not be derived by a user’s action." is the same in the following two places:

![Screen_Shot_2020-03-11_at_10.47.50_am](/uploads/00d1732ee0d8d26faf39f809d7f095fd/Screen_Shot_2020-03-11_at_10.47.50_am.png)

![Screen_Shot_2020-03-11_at_10.48.49_am](/uploads/4cf66e9fa152700f3a9fcc2527a60d97/Screen_Shot_2020-03-11_at_10.48.49_am.png)

Instead of a tab, we can add a "Component" section to the design tab (and then remove the tabs altogether)

Story points: 8.0
Figma component > Add Card

<!-- Start by making a copy of the component template to your own drafts.

In Figma:
1. Duplicate the component template https://www.figma.com/file/OmvFfWkqEsdGhXAND133ou/Component?node-id=0%3A1
2. Open the duplicate, then use the dropdown next to the file name to select “Move to Project…”
   and select your Drafts as the new location.
3. Update the template with your component name and start designing ;)
-->

<!--Add a short description of the component. If it’s helpful, add a checklist of variations
and states to the description so that a reviewer can be sure to cross reference everything
that has been completed.-->

<!--Use the Figma share feature and make sure that “anyone with the link” can view. Then, 
specifically invite the reviewer with “edit” permissions selected. Anyone can duplicate the 
file to their own drafts and edit from there, but the reviewer can directly edit and 
collaborate on the file. This will help maintain the integrity of the initial draft.-->

[View component in Figma →](https://www.figma.com/file/RbS6MpYuRWGvcdxRlUGxAD/Cards?node-id=1%3A496)

### Checklist

Make sure the following are completed before closing the issue:

1. [x] **Assignee**: Create component in your own draft file in Figma using the
[component template](https://www.figma.com/file/OmvFfWkqEsdGhXAND133ou/%5BComponent%5D),
including all variations and states.
1. [ ] **Assignee**: Ask another Figma Pilot Designer to review your component (make sure they have edit permissions).
1. [ ] **Reviewer**: Review and approve assignee’s addition. Ensure that component
matches Sketch specs, includes all current variations and states, and (if applicable)
is responsive.
1. [ ] **Assignee**: Add the component to the **Globals - beta** file, and view
the component in the Assets panel to ensure it aligns with what’s outlined in the
[Figma structure for library](https://gitlab.com/gitlab-org/gitlab-design/issues/791) issue.
1. [ ] **Assignee**: Publish the library changes along with a clear commit message.
1. [ ] **Assignee**: Update component link in the issue.
1. [ ] **Assignee**: Move your draft file to the **Component archive** Figma project.

Story points: 3.0
Fix fonts size of help text in radios/checkboxes

The following discussion from !1651 should be addressed:

- [ ] @pedroms started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/merge_requests/1651#note_271309985):  (+4 comments)

    > @jboyson unsure if related to this MR, the help text paragraph `p` has an odd font-size:
    > 
    > ![image](/uploads/d8ae5f82633b62712a852cf88c82b89f/image.png)

Story points: 1.0
Figma: Change GitLab logo in file thumbnails

Update the logo in file thumbnails (cover slides) starting with publicly shared files in the Pajamas UI kit and then the other cover template.

![CleanShot_2022-03-24_at_16.00.51_2x](/uploads/6314dcb6f940c178aa0e7bb2cbea8777/CleanShot_2022-03-24_at_16.00.51_2x.png)

![CleanShot_2022-03-24_at_16.02.21_2x](/uploads/73a4d1cb5b05d5ae294a83d97ef9c7e6/CleanShot_2022-03-24_at_16.02.21_2x.png)

Story points: 1.0
ViewComponents > Determine process and documentation

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82118 is our first MR that migrates a component helper to a ViewComponent. This could help with HAML/HTML components, but needs more exploration.

Docs: https://viewcomponent.org/

This issue is to help serve as discussion around View Components, how we might utilize and document them, and where that documentation should live.

Story points: 4.0
Define standards for edit icon

### Description

We do not consistently use the same icon to represent editing an object. This is based on this [slack thread](https://gitlab.slack.com/archives/CLW71KM96/p1646833267140679).

- [x] Audit edit icons (search for the pencil, pencil-square icon in the codebase)
   | pencil | pencil-square |
   | ------ | ------ |
   | ![Screen_Shot_2022-03-09_at_6.04.38_PM](/uploads/250840781259df86808b320dda78b0a7/Screen_Shot_2022-03-09_at_6.04.38_PM.png) | ![Screen_Shot_2022-03-09_at_6.04.26_PM](/uploads/3cba3b500aa2c8d7253060698c790479/Screen_Shot_2022-03-09_at_6.04.26_PM.png) |
- [x] Come up with a recommendation
   | pencil - use for edit |
   | ------ |
   | ![Screen_Shot_2022-03-09_at_6.04.38_PM](/uploads/250840781259df86808b320dda78b0a7/Screen_Shot_2022-03-09_at_6.04.38_PM.png) |
- [x] Update that icon to include `edit` definition in Figma
- [ ] Add this in Pajamas documentation - most likely [table actions](https://design.gitlab.com/components/table#additional-actions) - [MR](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2901)
- [ ] Replace pencil-square with pencil in GitLab UI - [MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89897)

<!-- Add a short description of the documentation addition or update. Remember to say why, not just what. -->

### Checklist

Make sure the following are completed before closing the issue:

1. [x] Assign the correct component label to this issue.
1. [x] Create an MR with the additions or updates needed.
1. [ ] When applicable, [create an issue using the `Figma update` issue template][pajamas-figma-update-template] to update the component in Figma, and mark it as related to this one. Bring the issue to your team planning session for prioritization and scheduling.
1. [ ] When applicable, [create an MR in GitLab UI][gitlab-ui-mr] to update the component. If you do not have capacity or are unable to update the component directly, [create a GitLab UI issue using the `Component` issue template][gitlab-ui-component-template]. Mark the new issue as related to this one. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [ ] When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
1. [ ] 🎉 Congrats, you made it! You can now close this issue.

<!--
### Resources

* [Component Lifecycle][component-lifecycle]
-->

[gitlab-ui-mr]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/new
[component-lifecycle]: https://design.gitlab.com/get-started/lifecycle
[pajamas-figma-update-template]: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/new?issuable_template=Figma%20update
[gitlab-ui-component-template]: https://gitlab.com/gitlab-org/gitlab-ui/-/issues/new?issuable_template=Component

Story points: 2.0
Update Figma file permissions to "Anyone with link can view"

## Problem

Figma links in the Pajamas component docs are set to `Anyone at GitLab can view`  permissions. It means that those outside of GitLab can't view the Figma files that we link to from the Pajamas docs.

It was discovered in [this MR thread.](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2719#note_838072427)

## Proposal

Update the Figma file permissions to be `Anyone with a link can view`.

Story points: 1.0
Provide guidelines for the usage of Drawers for consistent presentation of in-product Help information

### Description

Among other things, Drawers are used to present in-product contextual help information in GitLab. We need to provide guidelines for the usage of Drawers for Help information specifically to ensure consistent experience and a certain standard for the formatting and presentation of help info. 

#### Questions to consider

* What are the nuances of using a Drawer for Help information? How can we standardize the design of Help drawers in GitLab?
* What kind of content does / does not belong in the drawer?
* What is the order of types of content?
* Where does the content reside for best updating? Right now, it is hardcoded in the product.
* Requirement for TW to be involved in the Help window content creation (this type of content shouldn't extensively duplicate what is already available (potentially - need to think about this one); should not consist of mostly links; should answer very specific targeted questions, should follow our CTRT design guidelines). For example - the types of content in the CI/CD example are concept, task, tip, reference. Great content and the order is helpful.

<!-- Add a short description of the documentation addition or update. Remember to say why, not just what. -->

### Checklist

Make sure the following are completed before closing the issue:

1. [x] Assign the correct component label to this issue.
1. [x] Create an MR with the additions or updates needed.
1. [ ] When applicable, [create a new Pajamas issue using the "Figma update" issue template][pajamas-figma-update-template] to update the component in Figma. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [ ] When applicable, [create an MR in GitLab UI][gitlab-ui-mr] to update the component. If you do not have capacity or are unable to update the component directly, [create a new GitLab UI issue using the "Component"][gitlab-ui-component-template] issue template. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [ ] When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
1. [ ] 🎉 Congrats, you made it! You can now close this issue.

<!--
### Resources

* [Compontent Lifecycle][component-lifecycle]
-->

[gitlab-ui-mr]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/new
[component-lifecycle]: https://design.gitlab.com/get-started/lifecycle
[pajamas-figma-update-template]: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/new?issuable_template=Figma%20update
[gitlab-ui-component-template]: https://gitlab.com/gitlab-org/gitlab-ui/-/issues/new?issuable_template=Component

Story points: 3.0
Clarify drawer usage guidelines

### Description

This issue is to clarify several questions about the [Drawer component](https://design.gitlab.com/components/drawer/) usage guidelines as surfaced in [this audit. ](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/376#note_750204850)

#### Questions to answer

* Should we allow the drawer size to be changed?
* Should the drawer have white or gray background? We have both instances in the product.
* If drawer has a scrollbar, should the width be increased or the usable content area decreased? [Context](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73955)
* Do drawers have a "collapsed but still slightly visible" state? (like our right/left sidebars currently do). Or are they fully visible / fully hidden?
* Can drawers be on the left? Should our sidebars be flipped in RTL layouts (these are more broadly very broken)
* Can drawers be stacked (and overlap slightly)? Or there can be only one at a time. [Context](https://gitlab.com/gitlab-org/gitlab/-/issues/338718#note_752946251)

<!-- Add a short description of the documentation addition or update. Remember to say why, not just what. -->

### Checklist

Make sure the following are completed before closing the issue:

1. [x] Assign the correct component label to this issue.
1. [x] Create an MR with the additions or updates needed.
1. [-] When applicable, [create a new Pajamas issue using the "Figma update" issue template][pajamas-figma-update-template] to update the component in Figma. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [x] When applicable, [create an MR in GitLab UI][gitlab-ui-mr] to update the component. If you do not have capacity or are unable to update the component directly, [create a new GitLab UI issue using the "Component"][gitlab-ui-component-template] issue template. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [x] When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
1. [x] 🎉 Congrats, you made it! You can now close this issue.

<!--
### Resources

* [Compontent Lifecycle][component-lifecycle]
-->

[gitlab-ui-mr]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/new
[component-lifecycle]: https://design.gitlab.com/get-started/lifecycle
[pajamas-figma-update-template]: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/new?issuable_template=Figma%20update
[gitlab-ui-component-template]: https://gitlab.com/gitlab-org/gitlab-ui/-/issues/new?issuable_template=Component

Story points: 2.0
Pajamas UI Kit > Form component updates

## Purpose

Make updates to the way form components are constructed in the UI kit to reduce the number of component variants. [View the inspiration →](https://www.youtube.com/watch?v=9w0sOpsS90s)

Figma branch [#1235-form-exploration-JE →](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/branch/ubxFCR4pADM7ZfMJ7ZvyOU/Component-library?node-id=3050%3A0)

Story points: 3.0
Popover > Document close button usage

### Description

<!-- Add a short description of the documentation addition or update. Remember to say why, not just what. -->

As per https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/2630, we are introducing a close option to our popover component. We need to document its usage.  

### Checklist

Make sure the following are completed before closing the issue:

1. [x] Assign the correct component label to this issue.
1. [x] Create an MR with the additions or updates needed.
1. [x] When applicable, [create a new Pajamas issue using the "Figma update" issue template][pajamas-figma-update-template] to update the component in Figma. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [x] When applicable, [create an MR in GitLab UI][gitlab-ui-mr] to update the component. If you do not have capacity or are unable to update the component directly, [create a new GitLab UI issue using the "Component"][gitlab-ui-component-template] issue template. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [ ] When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
1. [x] 🎉 Congrats, you made it! You can now close this issue.

<!--
### Resources

* [Compontent Lifecycle][component-lifecycle]
-->

[gitlab-ui-mr]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/new
[component-lifecycle]: https://design.gitlab.com/get-started/lifecycle
[pajamas-figma-update-template]: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/new?issuable_template=Figma%20update
[gitlab-ui-component-template]: https://gitlab.com/gitlab-org/gitlab-ui/-/issues/new?issuable_template=Component

Story points: 1.0
Update Pajamas with information about the new iconography

### Description

<!-- Add a short description of the documentation addition or update. Remember to say why, not just what. -->

Updates to https://design.gitlab.com/product-foundations/iconography based on the work done https://about.gitlab.com/blog/2021/12/17/hey-icons-lighten-up/

As a designer trying to onboard I had to rely on external sources (and my memory) to read this section of the design system.

Related to #1202.

### Checklist

Make sure the following are completed before closing the issue:

1. [x] Assign the correct component label to this issue.
1. [x] Create an MR with the additions or updates needed.
1. [ ] When applicable, [create a new Pajamas issue using the "Figma update" issue template][pajamas-figma-update-template] to update the component in Figma. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [ ] When applicable, [create an MR in GitLab UI][gitlab-ui-mr] to update the component. If you do not have capacity or are unable to update the component directly, [create a new GitLab UI issue using the "Component"][gitlab-ui-component-template] issue template. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [ ] When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
1. [ ] 🎉 Congrats, you made it! You can now close this issue.

<!--
### Resources

* [Compontent Lifecycle][component-lifecycle]
-->

[gitlab-ui-mr]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/new
[component-lifecycle]: https://design.gitlab.com/get-started/lifecycle
[pajamas-figma-update-template]: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/new?issuable_template=Figma%20update
[gitlab-ui-component-template]: https://gitlab.com/gitlab-org/gitlab-ui/-/issues/new?issuable_template=Component

Story points: 3.0
UI kit > Update checkbox and radio components

## Purpose

- Update components to make better use of variants.
- Add indeterminate (checkboxes only and disabled states.

### Reference

There's an [existing Figma branch](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/branch/zuwBQHtdwn2KALwuKRuvvB/Component-library), but it's a bit far behind the main and there are some other approaches to explore so a new branch is preferred.

Here's an example of what's there though:

| **Checkbox** | **Radio** |
| ------ | ------ |
| ![CleanShot_2022-01-19_at_15.50.45_2x](/uploads/2a3f115b0190ba89dd60898c522d535f/CleanShot_2022-01-19_at_15.50.45_2x.png) | ![CleanShot_2022-01-19_at_15.50.57_2x](/uploads/2a13010b45f3539ad4acf4cd5f4f8f91/CleanShot_2022-01-19_at_15.50.57_2x.png) |

Story points: 2.0
Pajamas UI Kit > Add optional prop to form label

## Purpose

Form labels can have "(optional)" appended to them. It uses a different text style and would be useful to include as an option in Figma similar to how it is in GitLab UI. The text remains editable.

Toggling the optional property in GitLab UI:

![CleanShot_2021-12-29_at_10.40.11](/uploads/14cf536911a8729b2f193b32ad65df25/CleanShot_2021-12-29_at_10.40.11.gif)

[View the branch in Figma →](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/branch/QfyaK2zgr2FFlwtDKrdHQy/Component-library?node-id=425%3A10)

Here's a quick video demo:

![CleanShot_2021-12-30_at_08.09.23](/uploads/bce1238eb6953ed6fc96612549a82720/CleanShot_2021-12-30_at_08.09.23.mp4)

**Note**: This implementation doesn't account for text wrapping. If the label happened to be too long then you can either consider a shorter label, or detach the instance to format it in a design comp.

Story points: 1.0
Single stat documentation

### Description

<!-- Add a short description of the documentation addition or update. Remember to say why, not just what. -->

### Checklist

Make sure the following are completed before closing the issue:

1. [x] Assign the correct component label to this issue.
1. [ ] Create an MR with the additions or updates needed.
1. [ ] When applicable, [create a new Pajamas issue using the "Figma update" issue template][pajamas-figma-update-template] to update the component in Figma. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [ ] When applicable, [create an MR in GitLab UI][gitlab-ui-mr] to update the component. If you do not have capacity or are unable to update the component directly, [create a new GitLab UI issue using the "Component"][gitlab-ui-component-template] issue template. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [ ] When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
1. [ ] 🎉 Congrats, you made it! You can now close this issue.

<!--
### Resources

* [Compontent Lifecycle][component-lifecycle]
-->

[gitlab-ui-mr]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/new
[component-lifecycle]: https://design.gitlab.com/get-started/lifecycle
[pajamas-figma-update-template]: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/new?issuable_template=Figma%20update
[gitlab-ui-component-template]: https://gitlab.com/gitlab-org/gitlab-ui/-/issues/new?issuable_template=Component

Story points: 3.0
UI kit > Update components to light icons

## Purpose

With https://gitlab.com/gitlab-org/gitlab-svgs/-/issues/178 getting implemented in https://gitlab.com/gitlab-org/gitlab-svgs/-/merge_requests/739 we can update the icons in the Pajamas UI Kit.

The new icons will be maintained in a separate file from the component library for easier maintenance and sharing.

**Steps**

1. [x] Ensure all icons that weren't updated in the recent effort, but are still part of the library, are included in the new icon file. For example, pipeline, issue type, and brand icons.
1. [x] Publish the new icon library and add it to our community page.
1. [x] Replace the icons in the component library with the ones from the new icon library.
1. [x] Deprecate the old icons by removing them from the component library and placing into a separate file that will be archived.
1. [x] Publish an updated version of the component library.
1. [x] Mention the breaking change in the UX Weekly with directions on using the new library.
1. [x] Create a new MR to update the iconography guidelines in Pajamas.

Story points: 2.0