Address bullet point indentation formatting issues. (#1387)

* Address bullet point indentation formatting issues.

* Use minus consistently for bullets.

Author: shwoodard

aip/general/0193.md

@@ -90,8 +90,8 @@ Services must return a [`google.rpc.Status`][Status] message when an API
 error occurs. For each error the service **must** populate the `message`
 string in [`google.rpc.Status`][Status] as follows:
 
-+ present a developer-facing, human-readable "debug message"
-+ present the message in the service's native language to explain both
+- present a developer-facing, human-readable "debug message"
+- present the message in the service's native language to explain both
   the error and offer an actionable resolution to it ([citation][Error
   model])
 
@@ -102,14 +102,14 @@ bases, such as StackOverflow™.
 
 Important points:
 
-+ This `message` string is considered a problem description. It is
+- This `message` string is considered a problem description. It is
   intended for developers to understand the problem and is more
   detailed than [`ErrorInfo.reason`][ErrorInfo-reason], discussed in the
   next section.
-+ Use simple descriptive language that is easy to understand (without
+- Use simple descriptive language that is easy to understand (without
   technical jargon) to clearly state the problem that results in an
   error.
-+ For pre-existing (brownfield) APIs, the information in
+- For pre-existing (brownfield) APIs, the information in
   `google.rpc.Status` already exists and can’t be changed. In this
   case, do not edit anything in this `google.rpc.Status`, because some
   users might have automation running against the pre-existing content.
@@ -122,21 +122,21 @@ Important points:
 Details of this object are summarized in the following fields, field
 descriptions, and examples:
 
-+ `code int32`
-  + The status code, which **must** be an enum value of
+- `code int32`
+  - The status code, which **must** be an enum value of
     [`google.rpc.Code`][Code].
-  + *Example*: 8
-+ `message string`
-  + A developer-facing error message, which **should** be in English.
+  - *Example*: 8
+- `message string`
+  - A developer-facing error message, which **should** be in English.
     Any user-facing error message **should** be located in the
     LocalizedMessage payload.
-  + *Example message*: \"The zone \'us-east1-a\' does not have enough
+  - *Example message*: \"The zone \'us-east1-a\' does not have enough
     resources available to fulfill the request. Try a different zone, or
     try again later.\"
-+ `details Object (repeated)`
-  + Additional text details about the error, which includes
+- `details Object (repeated)`
+  - Additional text details about the error, which includes
     `ErrorInfo`,`LocalizedMessage`, and so on.
-  + *Example*: Described in the [ErrorDetails](#error-details) section.
+  - *Example*: Described in the [ErrorDetails](#error-details) section.
 
 #### [ErrorDetails][details]
 
@@ -183,16 +183,16 @@ exactly one `ErrorInfo`. It is required.
 Details of this object are summarized in the following fields, field
 descriptions, and examples:
 
-+ `reason string`
-  + A short snake_case description of why the error occurred. Error
+- `reason string`
+  - A short snake_case description of why the error occurred. Error
     reasons are unique within a particular domain of errors. The error
     reason **must** do the following:
-  + Be at most 63 characters and match a regular expression of
+  - Be at most 63 characters and match a regular expression of
     `/[A-Z][A-Z0-9_]+[A-Z0-9]/`, which represents UPPER_SNAKE_CASE.
-  + Be meaningful enough for a human reader to understand what the
+  - Be meaningful enough for a human reader to understand what the
     reason refers to.
-  + Be unique and consumable by machine actors for automation.
-  + *Example*:  CPU_AVAILABILITY<br>
+  - Be unique and consumable by machine actors for automation.
+  - *Example*:  CPU_AVAILABILITY<br>
     Distill your error message into its simplest form. For example, the
     `reason string` could be one of the following text examples in
     UPPER_SNAKE_CASE: `UNAVAILABLE`, `NO_STOCK`, `CHECKED_OUT`,
@@ -201,29 +201,31 @@ descriptions, and examples:
     > The Book, "The Great Gatsby", is unavailable at the Library,
     > "Garfield East". It is expected to be available again on 2199-05-13.
 
-  + In contrast, using either of the following reasons is not
+  - In contrast, using either of the following reasons is not
     recommended: `THE_BOOK_YOU_WANT_IS_NOT_AVAILABLE`, `ERROR`. And,
     using either of the following reasons breaches the required
     formatting and is not allowed: `librariesAreGreat`, `noBooks`.
-+ `domain string`
-  + The logical grouping to which the `reason` belongs. The error domain
+
+- `domain string`
+  - The logical grouping to which the `reason` belongs. The error domain
     is typically the registered service name of the tool or product that
     generated the error. The domain must be a globally unique value.
-  + *Example*:<br>`pubsub.googleapis.com`
-+ `metadata map`
-  + Additional structured details about this error, which **should**
+  - *Example*:<br>`pubsub.googleapis.com`
+
+- `metadata map`
+  - Additional structured details about this error, which **should**
     provide important context for customers to identify resolution
     steps.  Keys **should** match `/[a-z][a-zA-Z0-9-_]+/`, and be
     limited to 64 characters in length. When identifying the current
     value of an exceeded limit, the units **should** be contained in the
     key, not the value.
-  + *Example*:
-   ```
-   "vmType": "e2-medium",
-   "attachment": "local-ssd=3,nvidia-t4=2",
-   "zone": "us-east1-a"
-   ```
-  + For guidance on using the metadata map, see [Dynamic
+  - *Example*:
+    ```
+    "vmType": "e2-medium",
+    "attachment": "local-ssd=3,nvidia-t4=2",
+    "zone": "us-east1-a"
+    ```
+  - For guidance on using the metadata map, see [Dynamic
     Variables](#dynamic-variables).
 
 ##### Dynamic variables
@@ -301,18 +303,18 @@ will differ from the `message` string in `google.rpc.status`.
 Details of this object are summarized in the following fields, field
 descriptions, and examples:
 
-+ `locale string`
-  + The locale that follows the specification defined in [IETF
+- `locale string`
+  - The locale that follows the specification defined in [IETF
     bcp47](https://www.rfc-editor.org/rfc/bcp/bcp47.txt) (Tags for
     Identifying Languages).
-  + *Example*: **"en-US"**, **"fr-CH"**, **"es-MX"**
-+ `message string`
-  + The error message that the customer will receive through their
+  - *Example*: **"en-US"**, **"fr-CH"**, **"es-MX"**
+- `message string`
+  - The error message that the customer will receive through their
     chosen service, which **should** include a brief description of the
     error and a call to action to resolve the error. The message
     **should** include, where needed, data provided in other fields such
     as metadata.
-  + Give users clear and concise instructions for resolving the error,
+  - Give users clear and concise instructions for resolving the error,
     which **must** be explicit as possible; for example:
 
     > Consider trying your request in the <AVAILABLE-ZONE-1>,
@@ -321,11 +323,11 @@ descriptions, and examples:
     > again with a different VM hardware configuration or at a later
     > time.
 
-  + If the error resolution exceeds the number of characters supported in
+  - If the error resolution exceeds the number of characters supported in
     the problem description (`message` string of `google.rpc.Status`),
-    or requires multiple troubleshooting steps, include the most common
-    resolution in the message and use the `Help` payload to link to
-    relevant documentation.
+    or requires multiple troubleshooting steps, include the most
+    common resolution in the message and use the `Help` payload to
+    link to relevant documentation.
 
 ##### Help payload
 
@@ -353,7 +355,7 @@ descriptions, and examples:
   - The URL of the link. For error documentation this must follow the
     standardized format listed in the following example.
   - *Example*:
-    https://cloud.google.com/PRODUCT/docs/ERROR-REASON
+      https://cloud.google.com/PRODUCT/docs/ERROR-REASON
 
 ### Error messages
 
@@ -370,17 +372,17 @@ payload is present in the message.
 If the error message contains ErrorInfo payload (a machine-readable
 identifier):
 
-+ `Status.message` *string* and `LocalizedMessage.message` *string* can
+- `Status.message` *string* and `LocalizedMessage.message` *string* can
    change
-+ New metadata fields can be added
-+ However, existing metadata fields **must not** be removed and existing
+- New metadata fields can be added
+- However, existing metadata fields **must not** be removed and existing
   metadata field keys cannot be modified.
 
 If the error message does *not* contain ErrorInfo payload (usually for
 pre-existing APIs):
 
-+ The `LocalizedMessage.message` *string* can change
-+ However, the `Status.message` *string* **must** not be changed, as
+- The `LocalizedMessage.message` *string* can change
+- However, the `Status.message` *string* **must** not be changed, as
   this change is backward-incompatible.
 
 ##### Message alignment
@@ -469,17 +471,17 @@ message, which would be a backwards incompatible change.
 
 Reasons to present the same error message in both locations include the following:
 
-+ The service plans to localize either immediately or in the near future. See,
-"[Localization](#localization)".
-+ This practice enables clients to find an error message consistently in one
+- The service plans to localize either immediately or in the near future. See,
+  "[Localization](#localization)".
+- This practice enables clients to find an error message consistently in one
   location, `LocalizedMessaage.message`, across all methods of the API Service.
 
 Reasons to present an error message in `LocalizedMessage.message` that
 differs from `Status.message` include the following:
 
-+ The service requires an end-user-facing error message that differs
+- The service requires an end-user-facing error message that differs
   from the "debug message".
-+ Ongoing, iterative error message improvements are expected.
+- Ongoing, iterative error message improvements are expected.
 
 ### Updating Status.message
 
@@ -496,25 +498,25 @@ data instead.
 
 ## Further reading
 
-+ For which error codes to retry, see [AIP-194][aip-194].
-+ For how to retry errors in client libraries, see
+- For which error codes to retry, see [AIP-194][aip-194].
+- For how to retry errors in client libraries, see
   [AIP-4221][aip-4221].
 
 ## Changelog
 
-+ **2024-01-10**: Incorporate guidance for writing effective messages.
-+ **2023-05-17**: Change the recommended language for `Status.message` to be
+- **2024-01-10**: Incorporate guidance for writing effective messages.
+- **2023-05-17**: Change the recommended language for `Status.message` to be
   the service's native language rather than English.
-+ **2023-05-17**: Specify requirements for changing error messages.
-+ **2023-05-10**: Require [`ErrorInfo`][ErrorInfo] for all error responses.
-+ **2023-05-04**: Require uniqueness by message type for error details.
-+ **2022-11-04**: Added guidance around PERMISSION_DENIED errors previously
+- **2023-05-17**: Specify requirements for changing error messages.
+- **2023-05-10**: Require [`ErrorInfo`][ErrorInfo] for all error responses.
+- **2023-05-04**: Require uniqueness by message type for error details.
+- **2022-11-04**: Added guidance around PERMISSION_DENIED errors previously
   found in other AIPs.
-+ **2022-08-12**: Reworded/Simplified intro to add clarity to the intent.
-+ **2020-01-22**: Added a reference to the [`ErrorInfo`][ErrorInfo] message.
-+ **2019-10-14**: Added guidance restricting error message mutability to if
+- **2022-08-12**: Reworded/Simplified intro to add clarity to the intent.
+- **2020-01-22**: Added a reference to the [`ErrorInfo`][ErrorInfo] message.
+- **2019-10-14**: Added guidance restricting error message mutability to if
   there is a machine-readable identifier present.
-+ **2019-09-23**: Added guidance about error message strings being able to
+- **2019-09-23**: Added guidance about error message strings being able to
     change.
 
 <!-- prettier-ignore-start -->