Skip to content

Deprecate modifying notes confidentiality on APIs

Felipe Artur requested to merge issue_350670-deprecate_notes_confidential_attribute_on_apis into master

What does this MR do and why?

Update notes confidentiality will no longer be allowed. We need to deprecate confidential attributes on update endpoints for REST and GraphQL APIs.

The model validation will be added with #356670 (closed).

Related to #350670 (closed)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Deprecation process

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.
  • 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.

Tech writer review

  • Title:
    • Length limit: 7 words (not including articles or prepositions).
    • Capitalization: ensure the title is sentence cased.
    • Rewrite to exclude the words deprecation, deprecate, removal, and remove if necessary.
  • 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 https://about.gitlab.com/handbook/communication/#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.

Edited by Marcin Sedlak-Jakubowski

Merge request reports