What does this MR do and why?

As a companion to gitlab-org/gitlab!227149, let's update the nav item to match the expanded title.

CC @oli.campeau

Merge request acceptance checklist

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

• I have evaluated the MR acceptance checklist for this merge request.
• If this MR changes how markdown is interpreted, share this MR in the #tech-docs-localization slack channel. The translation tooling might need to be updated, for example if new syntax is added or existing syntax rendering is changed.

Evan Read (bf41cc82) at 17 Mar 01:25

@gitlab-org/technical-writing/tw-docops I've gone ahead and added the content from this MR to the team wiki at: rumdl.

Not sure why I didn't think of that earlier, given that's the home for unofficial tips and tricks.

So no need to add here, so I'll close this.

What does this MR do?

For: gitlab-org/technical-writing/team-tasks#1598, let's document using rumdl as an option for documentation authors if they want. This MR doesn't require anyone to do anything, but might help folks add another tool to their toolkit for documentation authoring. This gives us documentation to point to if we feel that rumdl will solve any particular problem we see.

• Preview of new page: https://docs.gitlab.com/upstream-review-mr-ee-225806/development/documentation/testing/rumdl/

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

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.

@uchandran WDYT of this as a concept? It would have the effect the titles of the pages looking more like commands (like glab alias) and also have the added benefit of the titles escaping linting, much like code style in prose does now.

@kpaizee That's good wording. I've applied.

Evan Read (dfb3b6a1) at 17 Mar 01:02

@rdickenson Could you review this one?

Evan Read (0f2fc3e9) at 16 Mar 23:55

What does this MR do?

After running rumdl over docs (for gitlab-org/technical-writing/team-tasks#1598), I noticed some pages were inconsistent in how they treat italics.

This MR makes changes so that the pages consistently use _ if necessary to match the rest of the page.

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

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.

Evan Read (b7d7445c) at 16 Mar 23:50

Evan Read (72b75210) at 16 Mar 23:12

Evan Read (65bd6217) at 16 Mar 23:12

... and 1 more commit

What does this MR do and why?

This commit adds a new documentation to explain how to configure client retries for Gitaly client, in all three installation method:

• GDK
• Omnibus
• Helm

This is needed since client retries are now configurable when installing GitLab.

References:

• #591337

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Closes #591337

Evan Read (72b75210) at 16 Mar 22:59

... and 649 more commits

@oli.campeau I understand your perspective. I'm a bit the same. I like to "see where the sides are" (what options I have), then figure out what to put in those options.

I'd say the way we have it is broadly how we do things in this documentation suite. That is, we put the "what and why" before the "how".

So I'll merge, but it's a pretty easy two-way door decision.

@oli.campeau No worries! Let's get this merged.

What does this MR do and why?

This commit adds a new documentation to explain how to configure client retries for Gitaly client, in all three installation method:

• GDK
• Omnibus
• Helm

This is needed since client retries are now configurable when installing GitLab.

References:

• #591337

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Closes #591337