Skip to content

Change Reviews H1 to prevent duplicate linking

Amy Qualls requested to merge 395729-aqualls-fix-h1 into master

What does this MR do?

@mohamed.zumair spotted an interesting edge case on https://docs.gitlab.com/ee/user/project/merge_requests/reviews/ - the title of the page (the H1) and an H2 subheading were exactly the same. The Technical Writing team uses two linters (Vale for grammar, Markdownlint for structure) for checks, but this edge case slips past with our current settings.

Markdownlint rule MD024 (Multiple headings with the same content) has two possible options: allow_different_nesting and siblings_only. We are using allow_different_nesting. What was spotted in #395729 (closed) demonstrates the problem nicely: any time you have ANY duplicate headings, you'll end up with anchor links that are problematic.

In this case, it's easy to miss. (@eread, @marcel.amirault, and @sselhorn will find this edge case interesting!) Typically, when you have duplicate headings, a number gets appended to the end of the anchor. A prime example is https://docs.gitlab.com/ee/api/graphql/reference/index.html where you end up with anchors like #arguments-36. However, with our current Markdownlint settings, the title on this page gets #review-a-merge-request, but that anchor isn't included when checking the subheadings. Otherwise, that H2 would be #review-a-merge-request-1 … and we would have spotted it. (At least, I hope we would have.)

So let's extricate ourselves from this problem. The subheading task Review a merge request is in correct form: present tense. It's safe to assume that inbound links containing #review-a-merge-request were intended for the H2. We break fewer things if we rename the H1, because links shouldn't depend on it.

This merge request changes the H1 from Review a merge request to Merge request reviews. The page was already an ambiguous combination of the two anyway (noun vs verb) and this approach fixes the identified problem with minimal disruption.

I still wish we had a way to disambiguate the two, but I'll settle for clearing out this bug. @mohamed.zumair, this issue was sneaky. Good eye, and thank you for reporting it.

Related issues

Closes Docs feedback: Update heading of Review a merge... (#395729 - closed).

Author's checklist

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

  • ~"frontend"
  • ~"backend"
  • ~"type::bug"
  • ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

  • If the content requires it, ensure the information is reviewed by a subject matter expert.
  • Technical writer review items:
    • Ensure docs metadata is present and up-to-date.
    • Ensure the appropriate labels are added to this MR.
    • Ensure a release milestone is set.
    • If relevant to this MR, ensure content topic type principles are in use, including:
      • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
      • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
      • Any task steps should be written as a numbered list.
      • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
  • Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.
Edited by Amy Qualls

Merge request reports