Convert headings to sentence case (#2056)

Co-authored-by: Marylia Gutierrez <[email protected]>

Author: Liudmila Molkova

CONTRIBUTING.md

@@ -12,7 +12,7 @@ requirements and recommendations.
 <!-- toc -->
 
 - [Sign the CLA](#sign-the-cla)
-- [How to Contribute](#how-to-contribute)
+- [How to contribute](#how-to-contribute)
   - [Which semantic conventions belong in this repo](#which-semantic-conventions-belong-in-this-repo)
   - [Suggesting conventions for a new area](#suggesting-conventions-for-a-new-area)
   - [Prerequisites](#prerequisites)
@@ -24,12 +24,12 @@ requirements and recommendations.
   - [3. Check new convention](#3-check-new-convention)
   - [4. Verify the changes before committing](#4-verify-the-changes-before-committing)
   - [5. Changelog](#5-changelog)
-    - [When to add a Changelog Entry](#when-to-add-a-changelog-entry)
+    - [When to add a changelog entry](#when-to-add-a-changelog-entry)
       - [Examples](#examples)
-    - [Adding a Changelog Entry](#adding-a-changelog-entry)
+    - [Adding a changelog entry](#adding-a-changelog-entry)
   - [5. Getting your PR merged](#5-getting-your-pr-merged)
 - [Automation](#automation)
-  - [Consistency Checks](#consistency-checks)
+  - [Consistency checks](#consistency-checks)
   - [Auto formatting](#auto-formatting)
   - [Markdown style](#markdown-style)
   - [Misspell check](#misspell-check)
@@ -46,7 +46,7 @@ requirements and recommendations.
 Before you can contribute, you will need to sign the [Contributor License
 Agreement](https://identity.linuxfoundation.org/projects/cncf).
 
-## How to Contribute
+## How to contribute
 
 When contributing to semantic conventions, it's important to understand a few
 key, but non-obvious, aspects:
@@ -248,7 +248,7 @@ Refer to the [Automation](#automation) section for more details.
 
 ### 5. Changelog
 
-#### When to add a Changelog Entry
+#### When to add a changelog entry
 
 Pull requests that contain user-facing changes will require a changelog entry.
 Keep in mind the following types of users (not limited to):
@@ -275,7 +275,7 @@ No changelog entry:
 - Refactorings with no meaningful change in functionality
 - Chores, such as enabling linters, updating dependencies
 
-#### Adding a Changelog Entry
+#### Adding a changelog entry
 
 The [CHANGELOG.md](./CHANGELOG.md) files in this repo is autogenerated
 from `.yaml` files in the [/.chloggen](/.chloggen) directory.
@@ -319,7 +319,7 @@ to merge**.
 
 Semantic Conventions provides a set of automated tools for general development.
 
-### Consistency Checks
+### Consistency checks
 
 The Specification has a number of tools it uses to check things like style,
 spelling and link validity.

docs/cloud-providers/aws-sdk.md

@@ -13,11 +13,11 @@ are found.
 
 Some descriptions are also provided for populating general OpenTelemetry semantic conventions based on these APIs.
 
-## Context Propagation
+## Context propagation
 
 See [compatibility](../non-normative/compatibility/aws.md#context-propagation).
 
-## Common Attributes
+## Common attributes
 
 The span name MUST be of the format `Service.Operation` as per the AWS HTTP API, e.g., `DynamoDB.GetItem`,
 `S3.ListBuckets`. This is equivalent to concatenating `rpc.service` and `rpc.method` with `.` and consistent

docs/database/database-metrics.md

@@ -11,7 +11,7 @@ linkTitle: Metrics
 - [Database operation](#database-operation)
   - [Metric: `db.client.operation.duration`](#metric-dbclientoperationduration)
 - [Development](#development)
-  - [Database Response](#database-response)
+  - [Database response](#database-response)
     - [Metric: `db.client.response.returned_rows`](#metric-dbclientresponsereturned_rows)
   - [Connection pools](#connection-pools)
     - [Metric: `db.client.connection.count`](#metric-dbclientconnectioncount)
@@ -228,7 +228,7 @@ Even though parameterized query text can potentially have sensitive data, by usi
 
 **Status**: [Development][DocumentStatus]
 
-### Database Response
+### Database response
 
 The following metric instruments describe database query response.
 

docs/database/database-spans.md

@@ -14,7 +14,7 @@ linkTitle: Spans
   - [Notes and well-known identifiers for `db.system.name`](#notes-and-well-known-identifiers-for-dbsystemname)
 - [Sanitization of `db.query.text`](#sanitization-of-dbquerytext)
 - [Generating a summary of the query text](#generating-a-summary-of-the-query-text)
-- [Semantic Conventions for specific database technologies](#semantic-conventions-for-specific-database-technologies)
+- [Semantic conventions for specific database technologies](#semantic-conventions-for-specific-database-technologies)
 
 <!-- tocstop -->
 
@@ -400,7 +400,7 @@ Semantic conventions for individual database systems or specialized instrumentat
 MAY specify a different `db.query.summary` format as long as produced summary remains
 relatively short and its cardinality remains low comparing to the `db.query.text`.
 
-## Semantic Conventions for specific database technologies
+## Semantic conventions for specific database technologies
 
 More specific Semantic Conventions are defined for the following database technologies:
 

docs/exceptions/exceptions-logs.md

@@ -12,13 +12,13 @@ emitted through the [Logger API](https://github.com/open-telemetry/opentelemetry
 
 <!-- toc -->
 
-- [Recording an Exception](#recording-an-exception)
+- [Recording an exception](#recording-an-exception)
 - [Attributes](#attributes)
-  - [Stacktrace Representation](#stacktrace-representation)
+  - [Stacktrace representation](#stacktrace-representation)
 
 <!-- tocstop -->
 
-## Recording an Exception
+## Recording an exception
 
 Exceptions SHOULD be recorded as attributes on the
 [LogRecord](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.43.0/specification/logs/data-model.md#log-and-event-record-definition) passed to the [Logger](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.43.0/specification/logs/api.md#logger) emit
@@ -57,7 +57,7 @@ The table below indicates which attributes should be added to the
 <!-- END AUTOGENERATED TEXT -->
 <!-- endsemconv -->
 
-### Stacktrace Representation
+### Stacktrace representation
 
 Same as [Trace Semantic Conventions for Exceptions - Stacktrace
 Representation](exceptions-spans.md#stacktrace-representation).

docs/exceptions/exceptions-spans.md

@@ -12,7 +12,7 @@ exceptions associated with spans.
 <!-- toc -->
 
 - [Exception event](#exception-event)
-  - [Stacktrace Representation](#stacktrace-representation)
+  - [Stacktrace representation](#stacktrace-representation)
 
 <!-- tocstop -->
 
@@ -47,7 +47,7 @@ This event describes a single exception.
 <!-- END AUTOGENERATED TEXT -->
 <!-- endsemconv -->
 
-### Stacktrace Representation
+### Stacktrace representation
 
 The table below, adapted from [Google Cloud][gcp-error-reporting], includes
 possible representations of stacktraces in various languages. The table is not

docs/faas/aws-lambda.md

@@ -12,13 +12,13 @@ use cases.
 <!-- toc -->
 
 - [All triggers](#all-triggers)
-  - [AWS X-Ray Active Tracing Considerations](#aws-x-ray-active-tracing-considerations)
-    - [`xray-lambda` Propagator Functionality](#xray-lambda-propagator-functionality)
+  - [AWS X-Ray active tracing considerations](#aws-x-ray-active-tracing-considerations)
+    - [`xray-lambda` propagator functionality](#xray-lambda-propagator-functionality)
     - [`xray-lambda` Propagator Configuration](#xray-lambda-propagator-configuration)
 - [API Gateway](#api-gateway)
 - [SQS](#sqs)
-  - [SQS Event](#sqs-event)
-  - [SQS Message](#sqs-message)
+  - [SQS event](#sqs-event)
+  - [SQS message](#sqs-message)
 - [Examples](#examples)
   - [API Gateway Request Proxy (Lambda tracing passive)](#api-gateway-request-proxy-lambda-tracing-passive)
   - [API Gateway Request Proxy (Lambda tracing active)](#api-gateway-request-proxy-lambda-tracing-active)
@@ -64,7 +64,7 @@ and the [cloud resource conventions][cloud]. The following AWS Lambda-specific a
 [faasres]: /docs/resource/faas.md (FaaS resource conventions)
 [cloud]: /docs/resource/cloud.md (Cloud resource conventions)
 
-### AWS X-Ray Active Tracing Considerations
+### AWS X-Ray active tracing considerations
 
 When [AWS X-Ray Active Tracing](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html) is enabled for a Lambda,
 the runtime will automatically generate a span based on configured sampling rates and propagate the span context
@@ -74,7 +74,7 @@ This span context is encoded using the [X-Ray Tracing Header Format](https://doc
 Users MUST be able to [configure the propagator](#xray-lambda-propagator-configuration) to prioritize propagating this X-Ray "Active Tracing" span context.
 (FYI: Users probably want this enabled if OpenTelemetry is configured to report spans to AWS X-Ray so their trace is linked together properly.)
 
-#### `xray-lambda` Propagator Functionality
+#### `xray-lambda` propagator functionality
 
 SDK's that have instrumentation for AWS Lambda SHOULD provide an additional propagator alongside the X-Ray propagator
 that can [be configured](#xray-lambda-propagator-configuration) via the `OTEL_PROPAGATORS` environment variable setting as `xray-lambda`.
@@ -153,7 +153,7 @@ for creating message processing spans within user code.
 
 The span kind for both types of SQS spans SHOULD be `CONSUMER`.
 
-### SQS Event
+### SQS event
 
 For the SQS event span, if all the messages in the event have the same event source, the name of the span MUST
 be `<event source> process`. If there are multiple sources in the batch, the name MUST be
@@ -169,7 +169,7 @@ See [compatibility](../non-normative/compatibility/aws.md#context-propagation) f
 - [`messaging.operation.type`](/docs/messaging/messaging-spans.md) MUST be set to `process`.
 - [`messaging.system`](/docs/messaging/messaging-spans.md) MUST be set to `aws_sqs`.
 
-### SQS Message
+### SQS message
 
 For the SQS message span, the name MUST be `<event source> process`.  The parent MUST be the `CONSUMER` span
 corresponding to the SQS event. The [message system attributes][] (not message attributes, which are provided by

docs/faas/faas-metrics.md

@@ -15,8 +15,8 @@ operations. By adding FaaS attributes to metric events it allows for finely tune
 
 <!-- toc -->
 
-- [Metric Instruments](#metric-instruments)
-  - [FaaS Instance](#faas-instance)
+- [Metric instruments](#metric-instruments)
+  - [FaaS instance](#faas-instance)
     - [Metric: `faas.invoke_duration`](#metric-faasinvoke_duration)
     - [Metric: `faas.init_duration`](#metric-faasinit_duration)
     - [Metric: `faas.coldstarts`](#metric-faascoldstarts)
@@ -27,15 +27,15 @@ operations. By adding FaaS attributes to metric events it allows for finely tune
     - [Metric: `faas.cpu_usage`](#metric-faascpu_usage)
     - [Metric: `faas.net_io`](#metric-faasnet_io)
 - [References](#references)
-  - [Metric References](#metric-references)
+  - [Metric references](#metric-references)
 
 <!-- tocstop -->
 
-## Metric Instruments
+## Metric instruments
 
 The following metric instruments describe FaaS operations.
 
-### FaaS Instance
+### FaaS instance
 
 The following metrics are recorded by the FaaS instance.
 
@@ -377,7 +377,7 @@ This metric is [recommended][MetricRecommended].
 
 ## References
 
-### Metric References
+### Metric references
 
 Below are links to documentation regarding metrics that are available with different
 FaaS providers. This list is not exhaustive.

docs/faas/faas-spans.md

@@ -13,14 +13,14 @@ See also the [additional instructions for instrumenting AWS Lambda](aws-lambda.m
 
 <!-- toc -->
 
-- [General Attributes](#general-attributes)
-  - [Function Name](#function-name)
+- [General attributes](#general-attributes)
+  - [Function name](#function-name)
   - [Difference between invocation and instance](#difference-between-invocation-and-instance)
-- [Incoming Invocations](#incoming-invocations)
-  - [Incoming FaaS Span attributes](#incoming-faas-span-attributes)
+- [Incoming invocations](#incoming-invocations)
+  - [Incoming FaaS span attributes](#incoming-faas-span-attributes)
   - [Resource attributes as incoming FaaS span attributes](#resource-attributes-as-incoming-faas-span-attributes)
-- [Outgoing Invocations](#outgoing-invocations)
-- [Function Trigger Type](#function-trigger-type)
+- [Outgoing invocations](#outgoing-invocations)
+- [Function trigger type](#function-trigger-type)
   - [Datasource](#datasource)
   - [HTTP](#http)
   - [PubSub](#pubsub)
@@ -30,7 +30,7 @@ See also the [additional instructions for instrumenting AWS Lambda](aws-lambda.m
 
 <!-- tocstop -->
 
-## General Attributes
+## General attributes
 
 Span `name` should be set to the function name being executed. Depending on the value of the `faas.trigger` attribute, additional attributes MUST be set. For example, an `http` trigger SHOULD follow the [HTTP Server semantic conventions](/docs/http/http-spans.md#http-server-semantic-conventions). For more information, refer to the [Function Trigger Type](#function-trigger-type) section.
 
@@ -96,7 +96,7 @@ call to invoke the lambda, which is often HTTP).
 <!-- END AUTOGENERATED TEXT -->
 <!-- endsemconv -->
 
-### Function Name
+### Function name
 
 There are 2 locations where the function's name can be recorded: the span name and the
 [`faas.name` Resource attribute](../resource/faas.md).
@@ -123,13 +123,13 @@ The span attribute `faas.invocation_id` differs from the [resource attribute][Fa
 [Azure functions]: https://docs.microsoft.com/azure/azure-functions/manage-connections#static-clients
 [Google functions]: https://cloud.google.com/functions/docs/concepts/execution-environment#scope
 
-## Incoming Invocations
+## Incoming invocations
 
 This section describes incoming FaaS invocations as they are reported by the FaaS instance itself.
 
 For incoming FaaS spans, the span kind SHOULD be `SERVER`.
 
-### Incoming FaaS Span attributes
+### Incoming FaaS span attributes
 
 <!-- semconv span.faas.server -->
 <!-- NOTE: THIS TEXT IS AUTOGENERATED. DO NOT EDIT BY HAND. -->
@@ -182,7 +182,7 @@ The `cloud.resource_id` and `cloud.account.id` attributes on AWS are some exampl
 In principle, the above considerations apply to any resource attribute that fulfills the criteria above
 (not being readily available without some extra effort that could be expensive).
 
-## Outgoing Invocations
+## Outgoing invocations
 
 This section describes outgoing FaaS invocations as they are reported by a client calling a FaaS instance.
 
@@ -233,7 +233,7 @@ which the invoked FaaS instance reports about itself, if it's instrumented.
 [FaaS resource attributes]: ../resource/faas.md
 [Cloud resource attributes]: ../resource/cloud.md
 
-## Function Trigger Type
+## Function trigger type
 
 This section describes how to handle the span creation and additional attributes based on the value of the attribute `faas.trigger`.
 

docs/feature-flags/feature-flags-logs.md

@@ -24,12 +24,12 @@ This can be used to determine the impact a feature has on a request, enabling en
 
 <!-- toc -->
 
-- [Recording an Evaluation](#recording-an-evaluation)
+- [Recording an evaluation](#recording-an-evaluation)
 - [Evaluation event](#evaluation-event)
 
 <!-- tocstop -->
 
-## Recording an Evaluation
+## Recording an evaluation
 
 Feature flag evaluations SHOULD be recorded as attributes on the
 [LogRecord](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.43.0/specification/logs/data-model.md#log-and-event-record-definition) passed to the [Logger](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.43.0/specification/logs/api.md#logger) emit