Skip to content

Test for subheadings that are too long

Amy Qualls requested to merge aqualls-subheading-length into master

What does this MR do?

Based on this Slack thread from April 2024, now aged out, proposes a warning-level test that captures subheadings longer than 100 characters. This value is larger than the 70-character maximum length for subheadings in troubleshooting sections. I'll get into why in a moment.

(Note: this MR description has been heavily revised over the past few months.)

Much of the discussion in this merge request revolved around trying to make a custom Vale rule work. After some flailing about, and some testing on @rdickenson and @marcel.amirault's part, it became clear that a markdownlint rule was the better choice, even though it came with caveats. Russell and Marcel wanted to know if we should flag at 70 characters, as the rule says, or to be more lenient to focus on catching the subheadings of truly egregious length.

Caveats

The Vale rule was pretty janky, and we couldn't get it to work the way we liked. The Vale rule was a raw-scoped rule, which we know is tougher to disable, so we focused on markdownlint rule MD013 (line-length). The problem: MD013 also enforces line lengths in some cases that we don't care about, like tables and code blocks. We settled on these parameters:

  • headers of > 100 characters
  • a general line length of > 800 characters
  • checking the length on as few types of lines as possible
  line-length:                # MD013
    code_blocks: false
    tables: false
    headings: true
    heading_line_length: 100
    line_length: 800

Findings:

Thanks to carefully chosen values, some cleanup (see MRs attached to #467298 (closed)), and the move of doc/architecture out of the gitlab repo, this test passes! (Which is good because we break pipelines on markdownlint findings…)

markdownlint-cli2 --config .markdownlint-cli2.yaml 'doc/**/*.md'
  • 100 characters for subheadings had only 3 results remaining. (I'd already cleaned most of them.) This merge request fixes them.
  • 800 characters for general line length had only 1 fix remaining. (I'd already cleaned most of them.) This merge request fixes that line.

Setting the heading length to 90 characters (instead of 100) results in about 30 findings, which is totally doable in a follow-up or two. Iteration toward 70 was Russell's original suggestion, and I think he's right.

show me the results if we did 90 / 800

4 of these will go away after this merge request lands, because they are fixed in this merge request.

$ markdownlint-cli2 --config .markdownlint-cli2.yaml 'doc/**/*.md'

markdownlint-cli2 v0.12.1 (markdownlint v0.33.0)
Finding: doc/**/*.md
Linting: 2307 file(s)
Summary: 37 error(s)
doc/administration/geo/replication/faq.md:72:91 MD013/line-length Line length [Expected: 90; Actual: 96]
doc/administration/geo/replication/security_review.md:238:91 MD013/line-length Line length [Expected: 90; Actual: 100]
doc/administration/postgresql/replication_and_failover_troubleshooting.md:196:91 MD013/line-length Line length [Expected: 90; Actual: 105]
doc/ci/docker/using_docker_build.md:745:91 MD013/line-length Line length [Expected: 90; Actual: 101]
doc/ci/docker/using_docker_build.md:787:91 MD013/line-length Line length [Expected: 90; Actual: 103]
doc/ci/environments/index.md:1031:91 MD013/line-length Line length [Expected: 90; Actual: 108]
doc/ci/environments/protected_environments.md:277:91 MD013/line-length Line length [Expected: 90; Actual: 99]
doc/ci/pipelines/compute_minutes.md:229:91 MD013/line-length Line length [Expected: 90; Actual: 98]
doc/ci/yaml/includes.md:604:91 MD013/line-length Line length [Expected: 90; Actual: 106]
doc/development/ai_features/duo_chat.md:35:91 MD013/line-length Line length [Expected: 90; Actual: 114]
doc/development/backend/ruby_style_guide.md:135:91 MD013/line-length Line length [Expected: 90; Actual: 101]
doc/development/data_seeder.md:350:91 MD013/line-length Line length [Expected: 90; Actual: 98]
doc/development/documentation/topic_types/index.md:46:48 MD044/proper-names Proper names should have the correct capitalization [Expected: markdownlint; Actual: Markdownlint]
doc/development/fe_guide/troubleshooting.md:72:91 MD013/line-length Line length [Expected: 90; Actual: 105]
doc/development/git_object_deduplication.md:175:91 MD013/line-length Line length [Expected: 90; Actual: 99]
doc/install/installation.md:1184:91 MD013/line-length Line length [Expected: 90; Actual: 98]
doc/integration/advanced_search/elasticsearch_troubleshooting.md:239:91 MD013/line-length Line length [Expected: 90; Actual: 94]
doc/integration/advanced_search/elasticsearch_troubleshooting.md:269:91 MD013/line-length Line length [Expected: 90; Actual: 108]
doc/solutions/cloud/aws/gitlab_aws_integration.md:108:91 MD013/line-length Line length [Expected: 90; Actual: 103]
doc/subscriptions/gitlab_com/index.md:522:91 MD013/line-length Line length [Expected: 90; Actual: 97]
doc/subscriptions/self_managed/index.md:506:91 MD013/line-length Line length [Expected: 90; Actual: 97]
doc/topics/git/troubleshooting_git.md:246:91 MD013/line-length Line length [Expected: 90; Actual: 96]
doc/update/deprecations.md:2020:91 MD013/line-length Line length [Expected: 90; Actual: 114]
doc/update/package/package_troubleshooting.md:125:91 MD013/line-length Line length [Expected: 90; Actual: 103]
doc/user/application_security/api_fuzzing/troubleshooting.md:42:91 MD013/line-length Line length [Expected: 90; Actual: 107]
doc/user/application_security/api_fuzzing/troubleshooting.md:79:91 MD013/line-length Line length [Expected: 90; Actual: 98]
doc/user/application_security/api_security_testing/troubleshooting.md:55:91 MD013/line-length Line length [Expected: 90; Actual: 106]
doc/user/application_security/container_scanning/index.md:804:91 MD013/line-length Line length [Expected: 90; Actual: 97]
doc/user/application_security/container_scanning/index.md:819:91 MD013/line-length Line length [Expected: 90; Actual: 106]
--> doc/user/application_security/continuous_vulnerability_scanning/index.md:76:801 MD013/line-length Line length [Expected: 800; Actual: 887]
doc/user/application_security/dependency_scanning/troubleshooting_dependency_scanning.md:80:91 MD013/line-length Line length [Expected: 90; Actual: 101]
doc/user/application_security/dependency_scanning/troubleshooting_dependency_scanning.md:167:91 MD013/line-length Line length [Expected: 90; Actual: 99]
doc/user/application_security/dependency_scanning/troubleshooting_dependency_scanning.md:253:91 MD013/line-length Line length [Expected: 90; Actual: 94]
doc/user/compliance/license_approval_policies.md:59:91 MD013/line-length Line length [Expected: 90; Actual: 102]
doc/user/group/saml_sso/troubleshooting.md:212:91 MD013/line-length Line length [Expected: 90; Actual: 105]
doc/user/group/saml_sso/troubleshooting.md:262:91 MD013/line-length Line length [Expected: 90; Actual: 109]
doc/user/infrastructure/iac/troubleshooting.md:91:91 MD013/line-length Line length [Expected: 90; Actual: 96]

Related items

Related to Track subheading length improvements (#467298 - closed) where I'll track the work to get this rule turned on.

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