[chore] Standardize markdown

.github/lychee.toml

@@ -6,3 +6,5 @@ exclude  = [
     "^http(s)?://localhost",
     "^http(s)?://example.com"
 ]
+
+remap = ["https://github.com/(.*)#L[0-9]+(-L[0-9]+)? https://github.com/$1"]

.markdownlint.yaml

@@ -5,14 +5,11 @@
 default: true
 
 # Disabled rules (existing codebase has many violations)
-MD001: false  # heading increment
 MD004: false  # unordered list style
 MD007: false  # unordered list indentation
 MD009: false  # trailing spaces
 MD010: false  # hard tabs
-MD012: false  # multiple consecutive blank lines
 MD013: false  # line length
-MD014: false  # dollar signs in commands
 MD022: false  # blanks around headings
 MD024: false  # duplicate headings
 MD025: false  # multiple top-level headings

.markdownlintignore

@@ -4,3 +4,6 @@ CHANGELOG-API.md
 
 # GitHub templates (intentional structure/HTML)
 .github/
+
+# Test fixtures (managed by mdatagen tests)
+cmd/mdatagen/internal/testdata/

CONTRIBUTING.md

@@ -63,7 +63,7 @@ Components refer to connectors, exporters, extensions, processors, and receivers
 * Provide a configuration structure which defines the configuration of the component
 * Provide the implementation that performs the component operation
 
-For more details on components, see the [Donating New Components](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CONTRIBUTING.md#donating-new-components) document and the tutorial [Building a Trace Receiver](https://opentelemetry.io/docs/collector/trace-receiver/) which provides a detailed example of building a component.
+For more details on components, see the [Donating New Components](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/v0.147.0/docs/new-components.md) document and the tutorial [Building a Trace Receiver](https://opentelemetry.io/docs/collector/trace-receiver/) which provides a detailed example of building a component.
 
 When adding a new component to the OpenTelemetry Collector, ensure that any configuration structs used by the component include fields with the `configopaque.String` type for sensitive data. This ensures that the data is masked when serialized to prevent accidental exposure.
 
@@ -218,20 +218,20 @@ Working with the project sources requires the following tools:
 Fork the repo and checkout the upstream repo to your GOPATH by:
 
 ```
-$ git clone git@github.com:open-telemetry/opentelemetry-collector.git
+git clone git@github.com:open-telemetry/opentelemetry-collector.git
 ```
 
 Add your fork as an origin:
 
 ```shell
-$ cd opentelemetry-collector
-$ git remote add fork git@github.com:YOUR_GITHUB_USERNAME/opentelemetry-collector.git
+cd opentelemetry-collector
+git remote add fork git@github.com:YOUR_GITHUB_USERNAME/opentelemetry-collector.git
 ```
 
 Run tests, fmt, and lint:
 
 ```shell
-$ make
+make
 ```
 
 You can run `make markdownlint` to check Markdown formatting.

confmap/README.md

@@ -126,7 +126,6 @@ service:
   extensions: [ file_storage ]
 ```
 
-
 ```yaml
 # extra_extension.yaml
 extensions:

docs/coding-guidelines.md

@@ -171,7 +171,6 @@ To keep naming patterns consistent across the project, enumeration patterns are
   - `pcommon.ValueTypeStr` for `pcommon.ValueType`
   - `pmetric.MetricTypeGauge` for `pmetric.MetricType`
 
-
 ## Recommended Libraries / Defaults
 
 In order to simplify development within the project, we have made certain library recommendations that should be followed.
@@ -181,7 +180,6 @@ In order to simplify development within the project, we have made certain librar
 | Hashing  	 | ["hashing/fnv"](https://pkg.go.dev/hash/fnv) 	 | The project adopted this as the default hashing method due to the efficiency and is reasonable for non-cryptographic use 	 |
 | Testing  	 | Use `t.Parallel()` where possible            	 | Enabling more tests to be run in parallel will speed up the feedback process when working on the project.                 	 |
 
-
 Within the project, there are some packages that have yet to follow the recommendations and are being addressed. However, any new code should adhere to the recommendations.
 
 ## Default Configuration

docs/component-status.md

@@ -1,8 +1,8 @@
 # Component Status Reporting
 
-Component status reporting is a collector feature that allows components to report their status (aka health) via status events to extensions. In order for an extension receive these events it must implement the [StatusWatcher interface](https://github.com/open-telemetry/opentelemetry-collector/blob/f05f556780632d12ef7dbf0656534d771210aa1f/extension/extension.go#L54-L63).
+Component status reporting is a collector feature that allows components to report their status (aka health) via status events to extensions. In order for an extension receive these events it must implement the [Watcher interface](https://github.com/open-telemetry/opentelemetry-collector/blob/v0.147.0/component/componentstatus/status.go#L35).
 
-### Status Definitions
+## Status Definitions
 
 The system defines six statuses, listed in the table below:
 
@@ -29,18 +29,17 @@ Statuses can be categorized into two groups: lifecycle and runtime.
 - PermanentError
 - FatalError
 
-### Transitioning Between Statuses
+## Transitioning Between Statuses
 
 There is a finite state machine underlying the status reporting API that governs the allowable state transitions. See the state diagram below:
 
-
 ![State Diagram](img/component-status-state-diagram.png)
 
 The finite state machine ensures that components progress through the lifecycle properly and it manages transitions through runtime states so that components do not need to track their state internally. Only changes in status result in new events being generated; repeat reports of the same status are ignored. PermanentError is a permanent runtime state. A component in a PermanentError state cannot transition to OK or RecoverableError, but it can transition to Stopping. FatalError is a final state. A component in a FatalError state cannot make any further state transitions.
 
 ![Status Event Generation](img/component-status-event-generation.png)
 
-### Automation
+## Automation
 
 The collector's service implementation is responsible for starting and stopping components. Since it knows when these events occur and their outcomes, it can automate status reporting of lifecycle events for components.
 
@@ -52,7 +51,7 @@ The collector will report a Starting event when starting a component. If an erro
 
 The collector will report a Stopping event when shutting down a component. If Shutdown returns an error, the collector will report a PermanentError event. If Shutdown completes without an error, the collector will report a Stopped event.
 
-### Best Practices
+## Best Practices
 
 **Start**
 
@@ -70,7 +69,7 @@ We intend to define guidelines to help component authors distinguish between rec
 
 A component should never have to report explicit status during shutdown. Automated status reporting should handle all cases. To recap, the collector will report Stopping before Shutdown is called. If a component returns an error from shutdown the collector will report a PermanentError and it will report Stopped if Shutdown returns without an error.
 
-### Implementation Details
+## Implementation Details
 
 There are a couple of implementation details that are worth discussing for those who work on or wish to understand the collector internals.
 
@@ -84,4 +83,4 @@ The service gets a slightly different TelemetrySettings object, a servicetelemet
 
 **sharedcomponent**
 
-The collector has the concept of a shared component. A shared component is represented as a single component to the collector, but represents multiple logical components elsewhere. The most common usage of this is the OTLP receiver, where a single shared component represents a logical instance for each signal: traces, metrics, and logs (although this can vary based on configuration). When a shared component reports status it must report an event for each of the logical instances it represents. In the current implementation, shared component reports status for all its logical instances during [Start](https://github.com/open-telemetry/opentelemetry-collector/blob/31ac3336d956d93abede6db76453730613e1f076/internal/sharedcomponent/sharedcomponent.go#L89-L98) and [Shutdown](https://github.com/open-telemetry/opentelemetry-collector/blob/31ac3336d956d93abede6db76453730613e1f076/internal/sharedcomponent/sharedcomponent.go#L105-L117). It also [modifies the ReportStatus method](https://github.com/open-telemetry/opentelemetry-collector/blob/31ac3336d956d93abede6db76453730613e1f076/internal/sharedcomponent/sharedcomponent.go#L34-L44) on component.TelemetrySettings to report status for each logical instance when called.
+The collector has the concept of a shared component. A shared component is represented as a single component to the collector, but represents multiple logical components elsewhere. The most common usage of this is the OTLP receiver, where a single shared component represents a logical instance for each signal: traces, metrics, and logs (although this can vary based on configuration). When a shared component reports status it must report an event for each of the logical instances it represents. In the current implementation, shared component reports status for all its logical instances during [Start](https://github.com/open-telemetry/opentelemetry-collector/blob/v0.147.0/internal/sharedcomponent/sharedcomponent.go#L89-L98) and [Shutdown](https://github.com/open-telemetry/opentelemetry-collector/blob/v0.147.0/internal/sharedcomponent/sharedcomponent.go#L105-L117). It also [wraps the host's Report method](https://github.com/open-telemetry/opentelemetry-collector/blob/v0.147.0/internal/sharedcomponent/sharedcomponent.go#L34-L44) to report status for each logical instance when called.

docs/release.md

@@ -4,9 +4,9 @@ Collector build and testing is currently fully automated. However there are stil
 
 We release both core and contrib collectors with the same versions where the contrib release uses the core release as a dependency. We’ve divided this process into three sections. Each section is assigned to an approver or maintainer of the corresponding repository. The sections are:
 
-1. The [Core](#releasing-opentelemetry-collector) collector, including the collector builder CLI tool.
-2. The [Contrib](#releasing-opentelemetry-collector-contrib) collector repository, containing Collector components.
-3. The [artifacts](#producing-the-artifacts)
+1. The [Core](https://github.com/open-telemetry/opentelemetry-collector/blob/v0.147.0/docs/release.md#releasing-opentelemetry-collector-core-release-manager) collector, including the collector builder CLI tool.
+2. The [Contrib](https://github.com/open-telemetry/opentelemetry-collector/blob/v0.147.0/docs/release.md#releasing-opentelemetry-collector-contrib-contrib-release-manager) collector repository, containing Collector components.
+3. The [artifacts](https://github.com/open-telemetry/opentelemetry-collector/blob/v0.147.0/docs/release.md#producing-the-artifacts-releases-release-manager)
 
 **Important Note:** You’ll need to be able to sign git commits/tags in order to be able to release a collector version. Follow [this guide](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) to set it up.
 
@@ -77,7 +77,6 @@ releases and add new schedules to the bottom of the list. To update the release
    1. If the core release manager is also eligible as a contrib and 'releases' release manager, assign them to all roles they can perform.
    2. Otherwise, pick a contrib/'releases' approver/maintainer that is not a core approver/maintainer, rotating through the list of eligible people. The contrib approvers/maintainers are all members of the [@collector-contrib-approvers](https://github.com/orgs/open-telemetry/teams/collector-contrib-approvers) team, and the 'releases' approvers/maintainers are all members of the [@collector-releases-approvers](https://github.com/orgs/open-telemetry/teams/collector-releases-approvers) team.
 
-
 ## Troubleshooting
 
 1. `unknown revision internal/coreinternal/v0.85.0` -- This is typically an indication that there's a dependency on a new module. You can fix it by adding a new `replaces` entry to the `go.mod` for the affected module.

docs/rfcs/component-status-reporting.md

@@ -95,7 +95,6 @@ For each listed deviation, the solution for unblocking component 1.0 is:
 - `Should component health reporting be an opt-in for component.Host implementations?` :white_check_mark:: Yes. A `component.Host` implementation is not required to provide a component status reporting feature. They may do so via an additional interface, such as `componentstatus.Reporter`.
 - `Component TelemetrySettings Requirements` :white_check_mark:: `component.TelemetrySettings.ReportStatus` has been removed. Instead, component status reporting is expected to be provided via an additional interface that `component.Host` implements. Components can check if the `component.Host` implements the desired interface, such as `componentstatus.Reporter` to access component status reporting features.
 
-
 ## Reference
 - Remove FatalError? Looking for opinions either way: https://github.com/open-telemetry/opentelemetry-collector/issues/9823
 - In order to prioritize lifecycle events over runtime events for status reporting, allow a component to transition from PermanentError -> Stopping: https://github.com/open-telemetry/opentelemetry-collector/issues/10058
@@ -113,7 +112,3 @@ For each listed deviation, the solution for unblocking component 1.0 is:
     - https://github.com/open-telemetry/opentelemetry-collector/pull/6560
   - Merged
     - https://github.com/open-telemetry/opentelemetry-collector/pull/8169
-
-
-
-

docs/rfcs/configuration-merging-strategy.md

@@ -151,7 +151,6 @@ service:
 
 2. _Merge all the lists under the `service::*` section_:
 
-
 ```yaml
 #main.yaml
 receivers:
@@ -244,7 +243,6 @@ otelcol \
     - Merged extension(s) from `extra_extension.yaml`
     - Merged receiver(s) from `extra_receiver.yaml`
 
-
 3. _Prepend processors_:
 ```bash
 otelcol --config=main.yaml --config=extra_processor.yaml?merge_mode=prepend&merge_paths=service::**::processors --feature-gates=confmap.enableMergeAppendOption

docs/rfcs/processing.md

@@ -221,7 +221,6 @@ traces:
   group_by(trace_id, 2m)
 ```
 
-
 Update a spans ID
 
 ```

extension/memorylimiterextension/README.md

@@ -13,8 +13,7 @@ The memory limiter extension is used to prevent out of memory situations on
 the collector. The extension will potentially replace the Memory Limiter Processor. 
 It provides better guarantees from running out of memory as it will be used by the 
 receivers to reject requests before converting them into OTLP. All the configurations 
-are the same as Memory Limiter Processor. 
-
+are the same as Memory Limiter Processor.
 
 This extension can be used as an extension for all HTTP and gRPC receivers that
 are configured through the standard `confighttp` and `configgrpc` libraries. For

processor/README.md

@@ -110,4 +110,3 @@ order in which each processor is applied.
 ## Creating Custom Processors
 
 To create a custom processor for the OpenTelemetry Collector, you need to implement the processor interface, define the processor's configuration, and register it with the Collector. The process typically involves creating a factory, implementing the required processing logic, and handling configuration options. For a practical example and guidance, refer to the [`processorhelper`](https://pkg.go.dev/go.opentelemetry.io/collector/processor/processorhelper) package, which provides utilities and patterns to simplify processor development.
-