OWASP 2017 - postponing deprecation date to %18.0

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

• Deprecation Issue: #458835

This MR updates the OWASP Grouping Deprecation from %17.6 to %18.0. Given the discussions on breaking change exceptions in gitlab-com/Product#13657 (closed) where we did not get approval for the exception, we will likely only be able to ship this on the next major milestone, which is why I've selected %18.0 instead of another 17.x milestone.

The content of the update has not changed - only the deprecation milestone. I don't think we need to change any of the content right now.

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.
• Confirm this MR is labeled release post itemdeprecation
• Follow the process to create a deprecation YAML file.
• Add reviewers by the 10th.
• Add scoped devops:: and group:: labels as necessary.
• Add the appropriate milestone to this MR.
• If the changes modify log format(addition/deletion/modification) of product feature, tag @gitlab-com/gl-security/engineering-and-research/security-logging team over the GitLab issue/MR.
• When ready to be merged (and no later than the 15th) @mention 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 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.

Expand for Details

• Title:
  • Length limit: 7 words (not including articles or prepositions).
  • Capitalization: ensure the title is sentence cased.
• Consistency:
  • Ensure that all resources (docs, deprecation, etc.) refer to the feature with the same term / feature name.
• Content:
  • Make sure the deprecation is accurate 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 deprecations.
  • Review use of whitespace and bullet lists. Will the deprecation 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 our Writing style guidelines.
• Links:
  • All links must be full URLs, as the deprecation YAML files are used in two different projects. Do not use relative links. The generated doc is an exception to the relative link rule and currently uses absolute links only.
  • Make sure all links and anchors are correct. Do not link to the H1 (top) anchor on a docs page.
• 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).

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 merge request to auto-merge, or if the pipeline is already complete, merge.

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