Adding more detail to the pajamas best practices section

1. `aria-label=` This text can be the same as the `fig caption`.

1. `img class=` This formats the image's display size. `img-50` scales the width down to 50% of the page. `gl-p-5` scales to the full width of the page.

1. `src=` This correspond's with the image's location. This should match the file name that corresponds with what you've uploaded to the `static` > `img` > `brand` folder.

   1. If you are working with a .png, use `light src=` or `dark src=` to create a fixed, solid white or black background so that the image shows up consistently in light and dark mode.

1. `alt=` This is alternate text that displays in the case that the media does not populate on the page; this should be more descriptive and unique from the `aria-label` and `fig caption`.

   1. This can be left blank if enough detail is provided on the page already: `alt=""`

1. `fig caption` This is the descriptive text displayed below the graphic.

#### Pushing your merge request

Smaller commits make collaboration easier. To keep things organized, only make the smallest changes necessary within a single merge request. For instance, if you need to make updates to both the Typography and the Brand Motion pages, break up the changes into two MRs.

1. Use [conventional commits](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/doc/commits.md#pajamas-commit-conventions). The commit message needs to start with a capital letter and be under 72 characters in length; the merge request description is where you can add more details.

1. Use [conventional commits](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/doc/commits.md#pajamas-commit-conventions). The commit message needs to be under 72 characters in length; the merge request description is where you can add more details.

   1. **Commit example:** `Feat(BrandMotion): embed video samples`.

      1. '*Feat*' indicates the '*type*' of commit.

      1. '*Feat*' indicates the '*type*' of commit. Make sure to capitalize the *F*.

      1. '*BrandMotion*' identifies the site page the changes were made to.

      1. '*embed video samples*' describes the changes that were made.

1. `push` your commit to a `new branch`. Then select `create MR`.

   1. `type:feature:` Effort to deliver new features, feature changes & improvements.

   1. `type:maintenance:` Up-keeping efforts & catch-up corrective improvements that are not Features nor Bugs.

   1. `type:bug:` Defects in shipped code and fixes for those defects.

1. Attach the [milestone](/handbook/engineering/releases/monthly-releases/#monthly-release-schedule) that matches up with your desired timeline.

1. Under `Merge options`, select the box for *Squash commits when merge request is accepted.*

1. Attach the [milestone](/handbook/engineering/releases/monthly-releases/#monthly-release-schedule) that matches up with your desired timeline. For our purposes, default to the most current GitLab launch. Example: `18.11`

1. Under `Merge options`, select the box for `Squash commits when merge request is accepted.`

1. Select `create merge request`.

1. Wait for the pipeline to complete, then assign either Jeremy or Taurie as the `reviewer`.

1. Once the pipeline has passed, check out the `review app` to preview changes.

1. Make any edits or fixes if needed. For larger edits, go to the `Changes` page in the Merge Request, click the three stacked dots, and select `Edit in Web IDE`. This will allow you to push another commit with your changes. Alternatively, for smaller content edits you can simply go to a line of code on the `Changes` page, click the comment icon, click the `Insert suggestion` icon in the comment toolbar, and make your changes directly to the highlighted green text. You can then batch multiple suggestions at a time and select `Apply suggestion(s)` to have these edits automatically added to your MR.

1. The GitLab Duo chat feature can help you identify what changes need to be made if your pipeline fails. You can also go to the job page and select `Troubleshoot pipeline` to identify the fixes.

1. The `Reviewer` must give their approval by hitting the green check mark by their name. Check out the `review app` to preview the changes made.

1. Once the pipeline has successfully passed and approval(s) from our team have been given, assign either Jeremy or Taurie from the Product team as a `reviewer`.