Add hard line breaks to GitHub notes (#253)

## This PR - adds hard new lines to GitHub notes ### Notes GitHub does some magic behind the scenes that isn't part of the markdown standard. This causes some issues on our doc site. Explicitly adding a hard line break using double space helps us avoid this issue. ### Follow-up Tasks Update the docs to include this change. --------- Signed-off-by: Michael Beemer <[email protected]>
open-feature · Mar 25, 2024 · 8c4d67b · 8c4d67b
1 parent 5f262bd
commit 8c4d67b
Show file tree

Hide file tree

Showing 4 changed files with 8 additions and 8 deletions.
diff --git a/specification/README.md b/specification/README.md
@@ -75,5 +75,5 @@ Put simply:
 
 > These features are stable and battle-hardened.
 
-> [!NOTE]
+> [!NOTE]  
 > No explicit status = `Experimental`
diff --git a/specification/sections/01-flag-evaluation.md b/specification/sections/01-flag-evaluation.md
@@ -254,7 +254,7 @@ See [types](../types.md) for details.
 
 The _detailed evaluation_ functions behave similarly to the standard flag evaluation functions, but provide additional metadata useful for telemetry, troubleshooting, debugging, and advanced integrations.
 
-> [!NOTE]
+> [!NOTE]  
 > Metadata included in the `evaluation details` should be considered "best effort", since not all providers will be able to provide these details (such as the reason a flag resolved to a particular value).
 
 see: [evaluation details](../types.md#evaluation-details) type
@@ -439,7 +439,7 @@ stateDiagram-v2
 
 <span style={{ color: '#888' }}>█</span> only defined in static-context (client-side) paradigm
 
-> [!NOTE]
+> [!NOTE]  
 > Only SDKs implementing the [static context (client-side) paradigm](../glossary.md#static-context-paradigm) define `RECONCILING` to facilitate [context reconciliation](./02-providers.md#26-provider-context-reconciliation).
 
 #### Requirement 1.7.1

diff --git a/specification/sections/03-evaluation-context.md b/specification/sections/03-evaluation-context.md
@@ -16,8 +16,8 @@ The context might contain information about the end-user, the application, the h
 
 ### 3.1 Fields
 
-> [!NOTE]
-> Field casing is not specified, and should be chosen in accordance with language idioms.
+> [!NOTE]  
+> Field casing is not specified and should be chosen in accordance with language idioms.
 
 see: [types](../types.md)
 

diff --git a/specification/types.md b/specification/types.md
@@ -42,7 +42,7 @@ A structure representing the result of the [flag evaluation process](./glossary.
 - variant (string, optional)
 - flag metadata ([flag metadata](#flag-metadata))
 
-> [!NOTE]
+> [!NOTE]  
 > Some type systems feature useful constraints that can enhance the ergonomics of the `evaluation details` structure.
 > For example, in the case of an unsuccessful evaluation, `error code`, `reason`, and `error message` will be set, and variant will not.
 > If the type system of the implementation supports the expression of such constraints, consider defining them.
@@ -72,7 +72,7 @@ A set of pre-defined reasons is enumerated below:
 | STALE           | The resolved value is non-authoritative or possibly out of date                                                                  |
 | ERROR           | The resolved value was the result of an error.                                                                                   |
 
-> [!NOTE]
+> [!NOTE]  
 > The `reason` should not be limited to the reasons enumerated above. It can be any of the pre-defined reasons, or
 > any string value. Some type systems have features which can increase the ergonomics of `reason`, for instance a union
 > of pre-defined types with a string, or a rust-style enumeration which allows for enumerated values to have associated
@@ -172,7 +172,7 @@ An enumeration of provider events.
 | Event                          | Explanation                                                                                                         |
 | ------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
 | PROVIDER_READY                 | The provider is ready to perform flag evaluations.                                                                  |
-| PROVIDER_ERROR                 | The provider signalled an error.                                                                                    |
+| PROVIDER_ERROR                 | The provider signaled an error.                                                                                    |
 | PROVIDER_CONFIGURATION_CHANGED | A change was made to the backend flag configuration.                                                                |
 | PROVIDER_STALE                 | The provider's cached state is no longer valid and may not be up-to-date with the source of truth.                  |
 | PROVIDER_RECONCILING*          | The context associated with the provider has changed, and the provider has not yet reconciled its associated state. |