Release Post: Redesigned Login Page

Team members for review and approval: Engineer(s): @jannik_lehmann | Product Marketing: @PMM | Tech Writer: @eread | Product Designer(s): @emilybauman

Engineering Manager to merge when the feature is deployed and enabled: @m_gill

Links

• Feature Issue (required): gitlab-org&8557 (closed)
• Pricing theme MR (required for primary features in Premium or Ultimate only):
• Feature MR (optional):
• Feature Flag Issue (optional): gitlab-org/gitlab#368387 (closed)
• External Comms Relating to this Release Post: gitlab-org/gitlab#372487 (closed)

Key dates

• By the 10th: PMs should draft/submit for review ALL release post item content, whether they are feature or recurring blocks, earlier and no later than the 10th of the month.
• By the 16th: All required TW reviews as well as any optional PMM and PM Director/Group Manager reviews and resulting revisions should get done no later than the 16th of the month.
• By the 17th: Release post items need to be marked with the Ready label in order to be merged for the current release post.
• By end of day 17th: EMs will merge RP items with the Ready label by the end of day 11:59PM PT on the 17th. Any MRs merged into master after 11:59PM PDT will not make the release post and need to follow this process:

If you need to make a change or addition to a release post item after 11:59PM PT on the 17th, open a new MR targeting the release-X-Y branch and assign to the Release Post Manager, with @mention of the lead Tech Writer and PMM. Please do not re-target the existing MR. It is important you follow the instructions on how to create a new MR to the release X-Y branch in Adding, editing, or removing merged content blocks after the 18th and before the 22nd. It's highly recommended the PM connect with the release post manager to make sure content can still be added prior to creating the new MR.

Notes: Drafting release post content well in advance of the 10th is highly recommended, so reviews/revisions can happen in a rolling fashion and not bottleneck against the 17th merge due date.

Getting ready for merge

Reminder: Make sure any feature flags have been enabled or removed!

Once all content is reviewed and complete, add the Ready label and set the Engineering Manager (EM) as the Assignee. The EM is responsible for merging as soon as the implementing feature is deployed to GitLab.com, after which this content will appear on the GitLab.com Release page and can be included in the next release post. All release post items must be merged on or before the 17th of the month. If a feature is not ready by the 17th due date, the EM should push the release post item to the next milestone.

PM release post item checklist

Expand for Details

Please only mark a section as completed once you performed all individual checks!

• Set yourself as the Assignee.
• Why? – The benefit of this feature to the user is clearly explained
  • What is the problem we are solving for the user, and how is the situation improved?
  • Be specific about the problem, using examples so that the reader can recall the last time they had that problem.
  • Be specific about the solution, using examples so that the reader can quickly understand the improvement.
  • Describe the benefits in terms of outcomes like productivity, efficiency, velocity, communication.
  • Avoid feature language, like removing a limitation, that focusses on the product and not our users.
  • Avoid assumed knowledge, assume a customer or prospect will be linked this description without context.
• Title:
  • Length limit: 7 words (not including articles or prepositions). Exceptions may be allowed by the Release Post Manager or the Messaging Lead.
• Content:
  • Make it clear if it is a new feature, or an improvement to an existing feature.
  • If your item is a deprecation, upgrade or removal reference the appropriate section in the release-posts handbook page for guidance. Please also see communication guidelines for breaking changes.
  • Make sure your content is reasonably aligned with guidance in Writing about features
  • Check title is in sentence case, and feature and product names are in capital case.
  • Run the content through an automated spelling and grammar check.
  • Validate all links are functional and have meaningful text for SEO (e.g., "click here" is bad link text).
• Images and Video:
  • Screenshot or video is included (required for all changes with a visible UI component). Consider preferring a speed run video since this will showcase your feature better, and also serve as a functional test to validate that it actually works as expected.
  • Check that the image follows the image guidelines. It should be less than 150kb, and minimizes empty space. You may need to make your browser window smaller before taking the screenshot to bring UI elements closer together, or crop the image afterwards.
  • Check if the image shadow is applied correctly. Add image_noshadow: true when an image already has a shadow.
  • Ensure the videos added to the frontmatter use /embed, not /watch, URLs (e.g. https://www.youtube-nocookie.com/embed/eH-GuoqlweM) more info here.
  • Ensure that the YouTube link points to the https://www.youtube-nocookie.com domain as this will allow the video to render in the review app correctly.
  • Ensure videos and iframes added within the feature description are wrapped in <figure class="video_container"> tags (for responsiveness).
  • Clean up video captions; auto-generated captions often mangle technical terms.
  • Ensure screenshots have realistic looking data. Avoid screenshots that say "test", "demo", "example".
  • Remove any remaining instructions (comments).
• Frontmatter:
  • Check feature availability frontmatter (available_in:) is correct: (Core, Premium, Ultimate). Make sure to set gitlab_com: false when the feature isn't available for GitLab.com users. Settings are also available for features only available for GitLab.com users.
  • Check documentation link points to the latest docs (documentation_link:), and includes the anchor to the relevant section on the page if possible. If documentation is not yet available/merged for the feature in question, you may use a placeholder or use the link where the documentation will be added (often the engineer and tech writer know this ahead of time). Be sure to update this placeholder prior to publication if you do not use the final link.
  • Check that documentation is updated, very clearly talks about the feature (mentions it by the same name consistently in all resources).
  • Check that all links to about.gitlab.com content are relative URLs.
• For any top or primary features:
  • Be sure to include or revise the features.yml file as needed, as described in the Handbook
  • Be sure to label your MR release post itemprimary to help the Messaging Lead find and review it for the release post. (Note that if your MR was auto-generated through your feature issue, you can skip this step)
• Review Alpha, Beta, Limited, and General Availability guidelines
• Add Reviewers: Once the above are complete, add the Tech Writer, PMM, and Group Manager or Director as Reviewers.

Pricing theme updates for Premium and Ultimate primary features

This is required as part of the release post workflow. However, since review/alignment on this may take longer than the release post allows, please use a separate MR to de-couple timeline dependencies.

Expand for Details

• In the bottom right corner of this screen, copy the name of the "Source branch"
• Create a new branch
• Paste the name of this branch into the name and append it with "-pricing-theme"
• Select this branch name as the source from the "Create from" field

• Click "Create Branch"
• Click the "Create merge request" button that appears near the top of the UI
• Choose the Pricing Theme template in the new MR and follow the steps in the template

Review

When the above is complete and the content is ready for review, it must be reviewed by Tech Writing. It can also be reviewed by Product Marketing, Product Design, and the Product Leader for this area.

Use the Reviewers for Merge Requests feature in GitLab when adding team members for content reviews. Reviewers will then approve the MR and remove themselves from Reviewers when their review is complete.

Tip: Try using the Review App in this MR to see exactly how the release post item is rendered. This can help you catch issues that are harder to spot in YAML. Once this MR is merged, you can also see it on the release preview page prior to content assembly.

• (Required) Tech Writer reviewed and approved
• (Recommended) PMM reviewed and approved
• (Optional) Product Designer reviewed and approved
• (Optional) Group Manager or Director reviewed and approved (ensuring the why is clearly explained: what is the problem we are solving for the user, and what value are we delivering.)
• PM adds Ready label and sets EM as Assignee for merge

Tech writer review

Expand for Details

Once added as a Reviewer to this merge request, the technical writer designated to the corresponding DevOps stage/group will perform their review according to the criteria described below.

Please only mark a section as completed once you performed all individual checks! When your review is complete, please approve this MR and remove yourself from Reviewers.

• Feature:
  • If the feature is listed as top or primary (not secondary), as described in the Handbook, review changes (as needed) to features.yml. Make sure it's associated with the appropriate stage and group.
• Image:
  • All top and primary features require an image (png, jpg, or gif format).
  • Make sure the image (png, jpg, or gif) is smaller than 150 KB, if included.
• Video:
  • Use the /embed/ YouTube URL path and not ?watch= parameter.
  • Ensure the PM has reviewed the captions for clarity.
• Title:
  • Length limit: 7 words (not including articles or prepositions).
  • Capitalization: ensure the title is sentence cased.
• Consistency:
  • Ensure that all resources (docs, release post, features.yml when applicable, etc.) refer to the feature with the same term / feature name.
  • Review feature availability frontmatter (available_in:) for consistency with the documentation: (Core, Premium, Ultimate), and features.yml if applicable.
• Documentation and Content:
  • Review the post and documentation for consistency. If the post says "we've added feature X", the documentation should describe something about feature X.
  • Review the content. Make sure it accurately describes the feature based on your understanding. Look for typos or grammar mistakes. Work with PM and PMM to ensure a consistent GitLab style and tone for messaging, based on other features and release posts.
  • Review use of whitespace and bullet lists. Will the release post item be easily scannable when published? Consider adding line breaks or breaking content into bullets if you have more than a few sentences.
  • Make sure there aren't acronyms readers may not understand per https://about.gitlab.com/handbook/communication/#writing-style-guidelines
    • Note: if you are unsure whether the docs were updated, check the file history looking for a recent update. If you don't find any, check with the PM. If the docs are missing (or unclear, confusing), ask the PM to request the dev who shipped the feature for an MR updating it asap and make sure to review it. If required docs changes are minor, you can choose to do it yourself to speed things up.
• Links:
  • Make sure the linked issue_url is correct.
  • Ensure the documentation_link links to the correct document and anchor, and is wrapped in single quotes.
  • Verify that all links and anchors work as intended. Do not link to the H1 (top) anchor on a docs page. Links should not redirect. Links to pages within about.gitlab.com are given by the relative path, not absolute.
  • documentation_link: 'https://docs.gitlab.com/ee/#amazing' is wrapped in single quotes and name: "Lorem ipsum" wrapped in double quotes.
• Code. Make sure any included code is wrapped in code blocks.
• Capitalization. Make sure to capitalize feature names. Stay consistent with the Documentation Style Guidance on Capitalization.
• Blank spaces. Remove unnecessary spaces (end of line spaces, double spaces, extra blank lines, and lines with only spaces).
• Notes:
  • The documentation is part of GitLab's DoD. A feature is not consider done while there's no documentation for it.
  • If there's something missing from the checklist above, you can request further action for PMs or other team members before approving this MR. You can remove yourself from Reviewers while there's nothing immediate for you to do, but request to be added as a Reviewer once the missing tasks are done so you can double-check and approve the MR.
  • Once all your review items have been checked, approve the merge request, check your checkbox in the review checklist above, and remove yourself from Reviewers. Your job is done!

PMM review

PMM Review is Optional

Expand for Details

Please only mark this section as completed once you performed all individual checks! When your review is complete, please approve this MR and remove yourself from Reviewers.

• PMM review
  • 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?
  • tone clarify: Is the language and sentence structure clear and grammatically correct?
  • technical clarity: Does the description of the feature make sense for various audiences, including folks who are not deeply familiar with GitLab?
  • Check/copyedit all your content blocks (including links/images)
  • If you think any features should change from primary to secondary, add a suggestion to the release post item and ping the PM owner to review.
  • Check/copyedit features.yml

EM release post item checklist

Expand for Details

• Set at least one code MR as a blocker for this MR by going to Edit > Merge request dependencies. Setting a code blocker improves clarity, and prevents premature merge. If no feature MR exists, go to the most relevant issue and click "Create merge request" to create an empty merge request. Use the [feature flag rollout issue(https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Roll%20Out) if one exists.
• When this MR is labeled as Ready and assigned to you:
  • Confirm the feature is in the release. Be aware that merging code to master "does not guarantee that the feature will be in the m release" (source). If in doubt, you should confirm the feature commits are in the x-y-stable-ee branch (for example, 13-12-stable-ee). If the code is not in the release or the deadline has passed, update this merge request's milestone accordingly and leave this unchecked.
  • If the feature has a feature flag, verify it is enabled by default.
  • If before 11:59PM PT on the 17th, merge this merge request to the master branch. If after that time, but you believe this should be merged late, follow the process for late additions and be sure to inform the release post manager.

.gitlab/merge_request_templates/Release-Post.md

@@ -61,6 +61,10 @@ _People:_
 | --- | --- | --- | --- | --- | --- | --- |
 | `@release_post_manager` | `@tw_lead` | `@tech_advisor` | DRI: `@wspillane` & `@social` for Slack Checklist item | `@pmm_lead` | `@fseifoddini` | `@release_post_manager_shadow` |
+_Response time SLA:_
+
+To accommodate the tight timelines of tasks during the 18th-22nd of the month, members of the release post team are asked to commit to one-hour response times in Slack during their working hours on those dates.
+
 ---
 ### Release post kickoff (`@release_post_manager`) due by the 7th
@@ -121,9 +125,7 @@ _People:_
   - **Please note a sync standup is always required for major releases**
 13. [ ] Review  the release post major due dates in the [standup agenda](https://docs.google.com/document/d/1LhAEBgZmSq8gs7Dm60RwqU60EZK5cafvILgQUoiakBM/edit) you created. If any fall on a weekend, Family and Friends day or other holiday, flag this to your release post team in Slack prep channel for awareness and to initiate any necessary planning to ensure smooth handoffs/completion of tasks over weekends, etc.
 14. [ ] In the `#release-post` Slack channel, remind Product Managers that all [content blocks (features, recurring, bugs, etc.)](#content-blocks) should be drafted and under review by the 10th. All direction items and notable community contributions should be included in the release post.
-15. [ ] Confirm your local dev environment is running a current version of Ruby. See Handbook section [Local dev environment setup to run content assembly script](https://about.gitlab.com/handbook/marketing/blog/release-posts/#local-dev-environment-setup-to-run-content-assembly-script). Ask the Technical Advisor for help.
-  - If you have any difficulty installing dependencies, reach out to your Technical Advisor.
-16. [ ] Remind the Technical Writer in Slack prep channel to not to merge in changes from `master` to the release post branch. See the `Release post branch ownership` section above for more details.
+15. [ ] Remind the Technical Writer in Slack prep channel to not to merge in changes from `master` to the release post branch. See the `Release post branch ownership` section above for more details.
 ### Release post item creation reminders (`@release_post_manager`) due by the 10th
@@ -268,42 +270,42 @@ To assist managers in determining whether a release contains a feature. The foll
  **Due date: YYYY-MM-17**
+
+1. [ ] In the `#x-y-release-post-prep` channel, remind the team that from the 18th-22nd, release post team members are asked to maintain a one-hour response time in Slack during their working hours. This is to ensure the smooth progression of time-sensitive tasks during this window.
 1. [ ] In the `#release-post` channel remind all PMs that it's the 17th, so they need to either have their EMs merge their release post item MRs or bump the milestone if they know it won't make it.
 1. [ ] Mention the [Distribution PM](https://about.gitlab.com/handbook/product/categories/#distribution-group) in the `#release-post` channel, reminding them to add any relevant [upgrade warnings](https://about.gitlab.com/handbook/marketing/blog/release-posts/#important-notes-on-upgrading) by doing an [upgrade MR](https://about.gitlab.com/handbook/marketing/blog/release-posts/#upgrades).
 1. [ ] Finalize your [MVP](https://about.gitlab.com/handbook/marketing/blog/release-posts/#mvp) selection and work with the person that nominated the MVP to write the MVP section in `data/release_posts/X_Y/mvp.yml` on the `release-X-Y` branch.
   1. [ ] On the `release-X-Y` branch, add the MVP's name and other profile info to `data/mvps.yml`.
 - Use `/rebase` on the release post MR. If you receive an error that the rebase cannot be scheduled, resolve any conflicts appear in the merge request widget. If no conflicts appear, consult with the Tech Advisor to resolve them locally.
 1. [ ] Merge [Bug](BUG_MR_LINK) [Usability improvements](USABILITY_MR_LINK) and [Performance Improvement](PERFORMANCE_MR_LINK) MRs
-1. [ ] Perform a dry-run of the content assembly **without pushing to master** by completing the following commands:
-
-```bash
-  git checkout master
-  git pull
-  git checkout release-x-y
-  git pull
-  git merge master
-  bin/release-post-assemble
-```
-
-- You should get a list of changed files. If no errors have been detected, use `git reset --hard` to return back to your last commit.
-- If you get any errors, reach out to the Technical advisor for support and keep product operations and your TW lead informed as needed
-
-### Content assembly (`@release_post_manager`) due on the 18th
-
-**Due date: YYYY-MM-18** (18th at 8 AM PT and NO earlier)
-
 1. [ ] Ping Product Operations `@brhea` to [generate the deprecations and removals indexes](https://about.gitlab.com/handbook/marketing/blog/release-posts/index.html#adding-deprecations-and-removals-index-to-www-gitlab-com).
   1. The release post manager will proceed with their tasks as this task will be completed by `@brhea` asyncrhonously prior to the publication date.
   1. However, if `@brhea` will be unavailable from the 18th through the 20th, collaborate with your technical advisor to complete the following steps yourself:
     1. [ ] Run `bin/rake gitlab:docs:write_deprecations` in the `gitlab` repo `@brhea`
     1. [ ] Run `bin/rake gitlab:docs:write_removals` in the `gitlab` repo `@brhea`
     1. [ ] Copy and paste the output files to the `data` directory in this repo `@brhea`
-1. [ ] Post in Slack `#release-post` notifying the team content assembly has begun and any un-merged MRs should no longer be merged to `master`. Point them to this link for info on how to merge MRs after content assembly has begun `https://about.gitlab.com/handbook/marketing/blog/release-posts/#adding-editing-or-removing-merged-content-blocks-after-the-18th-and-before-the-22nd`
-  1. [ ] Perform **final content assembly** by pulling all content block MRs merged to `master` into the release post branch [following these instructions in the handbook](https://about.gitlab.com/handbook/marketing/blog/release-posts/#content-assembly-merging-release-post-items-content-blocks-to-your-branch).
-1. [ ] Do a visual check of the `release-X-Y` content block and image folders to make sure paths and names are correct
-1. [ ] Make sure the **View App** button shows up in the MR as expected
+1. [ ] Paste the following message in `#release-post`
+  ```md
+  @product-team 📣 Content assembly 📣
+
+  1. Content assembly will happen via automation on the 18th at 4 pm UTC (11 am ET / 8 am PT)
+  1. Any un-merged MRs after that time should no longer target `master`
+  1. Follow the steps here if you need to merge your items after the automation has run: `https://about.gitlab.com/handbook/marketing/blog/release-posts/#adding-editing-or-removing-merged-content-blocks-after-the-18th-and-before-the-22nd`
+
+  cc: @fseifoddini @brhea
+  ```
+
+### Content assembly (`@release_post_manager`) due on the 18th
+
+**Due date: YYYY-MM-18** at **4 pm UTC (11 am ET / 8 am PT)** and NO earlier
+
+1. [ ] Verify the presence of .yml files in the `X_Y` data directory: `data/release_posts/X_Y/`
+1. [ ] Verify the absence .yml files in the `unreleased` data directory: `data/release_posts/unreleased/`
+1. [ ] Verify the presence of image files in the `X_Y` image directory: `source/images/X_Y/`
+1. [ ] Verify the absence of image files in the `unreleased` image directory: `source/images/unreleased/`
 1. [ ] Do a visual check of the blog post and ordering of content blocks for secondary items to confirm they are grouped by stage in descending alphabetical order.
+  - If any of the steps above cannot be verified, content assembly may have failed. Mention `@brhea` and `@tech_advisor` in a comment on this MR and in `#x-y-release-post-prep` and proceed with the steps below. Optionally, you may choose to move the files manually by following the [steps outlined here](https://about.gitlab.com/handbook/marketing/blog/release-posts/manual-release-post-kickoff/#if-the-content-assembly-bot-fails).
 1. [ ] Update the release post intro in the `sites/uncategorized/source/releases/posts/YYYY-MM-DD-gitlab-X-Y-released.html.md` with 4 primary features to highlight. To do this:
   1. [ ] Make sure to remove the backticks around the features
   1. [ ] Link the release post items mentioned in the intro to the item blocks within the release post. For example, for a feature named `"Define test cases in GitLab"`, the link from the introduction should point to `#define-test-cases-in-gitlab`.
@@ -328,12 +330,11 @@ You will be updating the contents of the `card` block that has `event_type: "Rel
   1. [ ] Ping `@mpreuss22` or `@justin.vetter` in `#digital-experience-team` on Slack to review the changes, with a [link to your MR](BUYER_EXPERIENCE_LINK).
 1. [ ] Ensure that the social media sharing text for the click to tweet button on the bottom of the release post page is available in the introduction of the release post page.
-1. [ ] Notify the PM team in the `#release-post` channel that final content assembly has happened and all work must now shift from `master` to the release post branch via coordination with the release post manager.
-  1. Include a link to how to merge MRs after the 18th `https://about.gitlab.com/handbook/marketing/blog/release-posts/#adding-editing-or-removing-merged-content-blocks-after-the-18th-and-before-the-22nd`
-  1. Include a link to the review app (**View App**) page, asking them to make sure all their content is showing up as expected with correct image/video links, etc.
 ### Hand off for TW review (`@release_post_manager`) due on the 18th
+TW review cannot proceed if content assembly is incomplete. Only perform these steps if the content assembly verification you performed above has passed.
+
 **Due date: YYYY-MM-18**
 1. [ ] Label this MR: ~"blog post" ~release
@@ -374,7 +375,7 @@ In the run-up to publishing the release post on the 22nd, some release post mana
   1. [ ] Post the following message in `#backend_maintainers` on Slack:
     > I am the release post manager for XX.Y and will need help merging in the "What's new" notification following the publication of the release post. This will be a time-sensitive MR on the 22nd. Could I please request a volunteer or two to be ready and available to help merge the MR when I have it ready to go? Thanks! cc: @a_akgun
   1. [ ] The RPM will create and finalize the MR draft by 11:59 PDT on the 21st.
-  1. [ ] The RPM will tag in What's New DRIs Product Operations `@fseifoddini` and `@brhea` as Reviewers, to review and Approve.
+  1. [ ] The RPM will tag in What's New DRIs Product Operations `@fseifoddini` and `@brhea` and VP of Product `@david` as Reviewers, to review and Approve.
   1. [ ] The RPM will tag in any maintainers who respond to the above message in `#backend_maintainers` as Reviewers, to review and Approve.
   1. [ ] The RPM will merge the MR after the release post is live on the 22nd and images have been checked to load correctly locally.