label release post release post item Technical Writing ~devops:: groupcontainer registry release post itemdeprecation label typemaintenance milestone %15.8 assign @trizzi (choose the DRI; remove backticks here, and below)

Be sure to link this MR to the relevant deprecation issue(s).

• Deprecation Issue: container-registry#842 (closed)

If there is no relevant deprecation issue, hit pause and:

• Review the process for deprecating and removing features.
• Connect with the Product Manager DRI.

Deprecation announcements can and should be created and merged into Docs at any time, to optimize user awareness and planning. We encourage confirmed deprecations to be merged as soon as the required reviews are complete, even if weeks ahead of the target milestone's release post. For the announcement to be included in a specific release post and that release's documentation packages, this MR must be reviewed/merged per the due dates below:

By the 10th: Assign this MR to these team members as Reviewer and for Approval (optional unless noted as required):

• Product Marketing: @PMM
• Product Designer(s): @ProductDesigners
• Product Group Manager or Director: @jreporter - Required
• Engineering Manager: @michelletorres - Required
• Technical writer: @claytoncornell - Required

By 11:59 AM PDT 15th: EM/PM assigns this MR to the TW reviewer for final review and merge: @EM/PM

By 11:59 PM PDT 17th: TW Reviewer updates Docs by merging this MR to master: @TW

Please review:

• The definitions of "Deprecation", "End of Support", and "Removal".
• The guidelines for deprecations.
• The process for creating a deprecation entry.

They are frequently updated, and everyone should make sure they are aware of the current standards (PM, PMM, EM, and TW).

EM/PM release post item checklist

• Set yourself as the Assignee, meaning you are the DRI.
• If the deprecation is a breaking change, add label breaking change.
• Follow the process to create a deprecation YAML file.
• Make sure that the milestone dates are based on the dates in Product milestone creation.
• Add reviewers by the 10th.
• When ready to be merged and not later than the 15th, add the ~ready label and @ message the TW for final review and merge.

Reviewers

When the content is ready for review, it must be reviewed by a Technical Writer and Engineering Manager, but can also be reviewed by Product Marketing, Product Design, and the Product Leaders for this area. Please use the Reviewers for Merge Requests feature for all reviews. Reviewers will then approve the MR and remove themselves from Reviewers when their review is complete.

• (Recommended) PMM
• (Optional) Product Designer
• (Optional) Group Manager or Director
• Required review and approval: Technical Writer designated to the corresponding DevOps stage/group.

Tech writer review

After being added as a Reviewer to this merge request, the TW performs their review according to the criteria described below.

Review deprecation MRs with a similar process as regular docs MRs. Add suggestions as needed, @ message the PM to inform them the first review is complete, and remove yourself as a reviewer if it's not ready for merge yet.

When the PM indicates it is ready for merge and all issues have been addressed, start the merge process.

Technical writer merge process

The deprecations doc's .md file must be updated before this MR is merged:

1. Check out the MR's branch (in the gitlab-org/gitlab project).
2. From the command line (in the branch), run bin/rake gitlab:docs:compile_deprecations. If you want to double check that it worked, you can run bin/rake gitlab:docs:check_deprecations to verify that the doc is up to date.
3. Commit the updated file and push the changes.
4. Set the MR to merge when the pipeline succeeds (or merge if the pipeline is already complete).

If you have trouble running the Rake task, check the troubleshooting steps.