chore: summary bar cleanup

[sarahsanders-docker]

Description

• Updated "Contribute" guide to reference summary bars, added instructions for using them
• Removed introduced partial, this is now replaced by the summary bar requires value
• Updated all files using introduced partial to use summary bar, updated YAML file w/ feature name and info

Related issues or tickets

ENGDOCS-2392

Reviews

• Technical review
• Editorial review

[netlify]

✅ Deploy Preview for docsdocker ready!

Name	Link
🔨 Latest commit	fb65ae5
🔍 Latest deploy log	https://app.netlify.com/sites/docsdocker/deploys/679a63508dca1100089276f3
😎 Deploy Preview	https://deploy-preview-21887--docsdocker.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[aevesdocker]

I'm actually not sure about replacing the introduced partial with the summary bar 🤔 (sorry, I know you've gone to all that effort in removing and swapping them)
Visually, I'm immediately drawn to the summary bar, rather than reading the text. Also, it's quite useful to have the link to the release notes in these circumstances. I think it looks much stronger if we use the summary bar just for the top of the page (where appropriate) and then the introduced partial for in-page items, but keen to hear what the rest of the team thinks

[dvdksn]

I'd much rather have just one way of showing this data. I thought we ended up with a shortcode for the summary bar because it allows us the flexibility to put it on a section-level? If we only ever want to render this component at the top of a page, then it probably shouldn't even be a shortcode. Pretty sure we discussed this when reviewing the original PR.

[sarahsanders-docker]

I'd much rather have just one way of showing this data. I thought we ended up with a shortcode for the summary bar because it allows us the flexibility to put it on a section-level? If we only ever want to render this component at the top of a page, then it probably shouldn't even be a shortcode. Pretty sure we discussed this when reviewing the original PR.

I would also prefer to have one way of showing this data. I think if we introduce too many types of callouts or visual elements that represent a bunch of different things, we get into a territory that becomes difficult to maintain and be consistent with. Also as a user, the more consistent we are, the better I recognize and understand these elements over time.

For these visual elements, I would prefer keeping things limited to summary bars and callouts, and implementing them at the section level as needed. Also, these are implemented at the section level in other docs from the original PR.

@aevesdocker I can adjust the text shown in the Requires: section of the summary bar to include release notes. that is an easy fix and I can update the contribute guide to have that be standard when there are corresponding release notes

[sarahsanders-docker]

@aevesdocker @dvdksn I am able to add the release notes to the summary bar Requires: line by slightly adjusting the shortcode file. If this is a good compromise, I can push this change!

[aevesdocker]

Looks like I'm outnumbered! Adding the release notes link LGTM, thanks @sarahsanders-docker

[dvdksn]

You can also remove these, they were used by the introduced.html shortcode

• docs/i18n/en.yaml

  Lines 39 to 54 in ee59422

  	## component names
  	buildx:
  	other: Buildx
  	buildkit:
  	other: BuildKit
  	engine:
  	other: Docker Engine
  	api:
  	other: Engine API
  	desktop:
  	other: Docker Desktop
  	compose:
  	other: Docker Compose
  	scout:
  	other: Docker Scout

• docs/hugo.yaml

  Lines 130 to 139 in ee59422

  	# Minimum version thresholds (used together with the "introduced" shortcode
  	# See layouts/shortcodes/introduced.html
  	min_version_thresholds:
  	buildx: "0.10.0"
  	buildkit: "0.11.0"
  	engine: "24.0.0"
  	api: "1.41"
  	desktop: "4.20.0"
  	compose: "2.14.0"
  	scout: "1.0.0"