Adding 125 word guidance

It is recommended for the Release Post Manager to review all content for quality, including the marketing intro. But when reviewing content blocks in each release post item MRs, the RPM should look for the following:

1. Are the why (problem) and the what (solution) clearly stated? See [writing about features](/handbook/product/product-processes/#writing-about-features) as a guideline for what feature descriptions should contain.

2. Do the filenames follow the recommended file-naming convention? See **important note on naming files** under [Instructions](#release-post-item-instructions) for PM contributors.

1. Is the description fairly brief (no more than approximately 125 words)?

1. Do the filenames follow the recommended file-naming convention? See **important note on naming files** under [Instructions](#release-post-item-instructions) for PM contributors.

#### Tips for reviews

- All new and/or primary features are added to [`data/features.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/features.yml) *with a screenshot accompanying the feature (if the feature is visible in the UI)*.

  - All images are optimized according to the [image guidelines](#images) **and** smaller than 150KB.

  - Keep in mind the [`features.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/features.yml?ref_type=heads) is the SSOT for displaying features across `about.gitlab.com`.

- All features should have a clear value driver.

- All features should have a clear value driver and be fewer than approximately 125 words.

As noted in the [Release Post Item template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/.gitlab/merge_request_templates/Release-Post-Item.md):

- See [writing about features](/handbook/product/product-processes/#writing-about-features) as a guideline for what feature descriptions show have.

- Review the messaging for these features look for these 5 elements:

  - **problem/solution**: Does this describe the user pain points (problem) as well as how the new feature removes the paint points (solves the problem)?

  - **short/pithy**: Is this communicated clearly with the fewest words possible?

  - **short/pithy**: Is this communicated clearly with the fewest words possible (preferably 125 words or fewer)?

  - **tone clarify**: Is the language and sentence structure clear and grammatically correct? Is the text in the present tense, and is "you" used instead of "user."

  - **technical clarity**: Does the description of the feature make sense for various audiences, including folks who are not deeply familiar with GitLab?

  - **value driver**: Does the feature help our users Increase Operational Effectiveness, Deliver Better Products Faster, or Reduce Security and Compliance Risk?

        Describe how the new functionality is beneficial. Use phrases that start with, "In previous versions of GitLab, you couldn't... Now you can..."

        [Add another link](#link) if needed.

        [Add another link](#link) if needed. Use no more than 125 words for your description.

```

#### Description

  - Correct and working links for user information, issues, MRs, etc.

  - Correct spelling of names, organizations, product features, etc.

  - Correct [prounoun](/handbook/people-group/pronouns/) usage

- The write-up should be merged by the Tuesday of release week to the `data/release_posts/x_y/mvp.yml` file targeting the specific release branch

- The write-up should be merged by the Tuesday of release week to the `data/release_posts/x_y/mvp.yml` file targeting the specific release branch.

- The write-up should be fairly brief. It appears at the top of the release post in a prominent position. Try to keep it to fewer than 150 words.

You can use the sample message below when pinging the Notable Contributor winner and team members into the merge request: