Skip to content

Release post 13.5: add Package stage bugs

Tim Rizzi requested to merge trizzi-release-13-5-patch-63141 into release-13-5

/label release post release post item Technical Writing devopspackage ~"group::package" /milestone %13.5 /assign @trizzi

Engineer(s): @package-combined-group | Product Marketing: @parker_ennis | Tech Writer: @sselhorn | Engineering Manager: @jhampton

Links

This updates the list in bugs.yml and contains several links:

Review

When the above is complete and the content is ready for review, it should be reviewed by Product Marketing, Tech Writing, and the product director for this area.

  • (Required) Tech writer reviewed and approved
  • (Recommended) PMM 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 assigns to EM for merge

Tech writer review

Once assigned 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!

  • 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.
    • If a video is included make sure it uses the /embed/ YouTube URL path and not ?watch= parameter
  • Title:
    • Length limit: 7 words (not including articles or prepositions).
  • 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, Starter, 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. Leave style and messaging for the PM and PMM.
    • 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 unassign yourself while there's nothing immediate for you to do, but request to be assigned 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 unassign yourself. Your job is done!

PMM review

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

  • 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)
    • Check/copyedit features.yml

EM release post item checklist

  • Confirm that the feature made it into the release milestone and only then merge this merge request. If that's not the case and the deadline has passed, update this MR's milestone accordingly and leave this unchecked.
    • Please note that any MRs getting merged prior to 11:59PM PT on the 17th will target master. For any MRs needing to be merged after 11:59PM PT on the 17th, please coordinate with the PM to create a new MR, targeting the release-X-Y branch, which should then be assigned to the Release Post Manager to merge into final content assembly.
  • If the feature MR is in progress, set this Release Post MR as dependent on it, to prevent merging too early.
Edited by Tim Rizzi

Merge request reports