Merge pull request #35 from stakater/markdownupdates

Formatting updates
stakater · Jan 21, 2025 · 3f0716b · 3f0716b
2 parents d9daa6b + a24a3e5
commit 3f0716b
Show file tree

Hide file tree

Showing 2 changed files with 29 additions and 27 deletions.
diff --git a/.markdownlint.yaml b/.markdownlint.yaml
@@ -1,7 +1,9 @@
-{
-  "MD007": { "indent": 4 },
-  "MD013": false,
-  "MD024": false,
-  "MD029": { "style": one },
-  "MD046": false,
-}
+MD007:
+  indent: 4
+MD013: false
+MD024: false
+MD029:
+  style: one
+MD046: false
+MD055:
+  style: leading_and_trailing
diff --git a/content/index.md b/content/index.md
@@ -12,28 +12,28 @@ We are here to support you, not just until the problem is solved, but to ensure
 
 You as a customer can set the initial priority for a Request by specifying the appropriate priority: `Critical`, `High`, `Medium` or `Low`. The Engineer on Duty has the right to adjust it at their own discretion based on the rules below:
 
-Request Priority | Description of the Request Priority
---- | ---
-`Critical` |  Large-scale failure or complete unavailability of OpenShift or Customer's business application deployed on OpenShift. The `Critical` priority will be lowered to `High` if there is a workaround for the problem. Example: Router availability issues, synthetic monitoring availability issues.
-`High` | Partial degradation of OpenShift core functionality or Customer's business application functionality with potential adverse impact on long-term performance. The `High` priority will be lowered to `Medium` if there is a workaround for the problem. Example: Node Group and Control Plane availability problems.
-`Medium` | Partial, non-critical loss of functionality of OpenShift or the Customer's business application. This category also includes major bugs in OpenShift that affect some aspects of the Customer's operations and have no known solutions. The `Medium` priority will be lowered to `Low` if there is a workaround for the problem. This priority is assigned to Requests by default. If the Request does not have an priority set by the Customer, it will be assigned the default priority `Medium`. Example: Problems with the monitoring availability and Pod autoscaling.
-`Low` | This category includes: Requests for information and other matters, requests regarding extending the functionality of the Kubernetes Platform, performance issues that have no effect on functionality, Kubernetes platform flaws with known solutions or moderate impact on functionality. Example: Issues with extension availability.
+| Request Priority | Description of the Request Priority |
+| --- | --- |
+| `Critical` |  Large-scale failure or complete unavailability of OpenShift or Customer's business application deployed on OpenShift. The `Critical` priority will be lowered to `High` if there is a workaround for the problem. Example: Router availability issues, synthetic monitoring availability issues. |
+| `High` | Partial degradation of OpenShift core functionality or Customer's business application functionality with potential adverse impact on long-term performance. The `High` priority will be lowered to `Medium` if there is a workaround for the problem. Example: Node Group and Control Plane availability problems. |
+| `Medium` | Partial, non-critical loss of functionality of OpenShift or the Customer's business application. This category also includes major bugs in OpenShift that affect some aspects of the Customer's operations and have no known solutions. The `Medium` priority will be lowered to `Low` if there is a workaround for the problem. This priority is assigned to Requests by default. If the Request does not have an priority set by the Customer, it will be assigned the default priority `Medium`. Example: Problems with the monitoring availability and Pod autoscaling. |
+| `Low` | This category includes: Requests for information and other matters, requests regarding extending the functionality of the Kubernetes Platform, performance issues that have no effect on functionality, Kubernetes platform flaws with known solutions or moderate impact on functionality. Example: Issues with extension availability. |
 
 ## Support Tiers
 
 Stakater offers three levels of support tiers, as described in the table below.
 
-Feature | Essential | Advanced | Premium
---- | --- | --- | ---
-Use case | Basic minimum support | Development support | Production and critical workload support
-Support hours | 24x5x365 | 24x7x365 | 24x7x365
-Modes of support | Ticket | Ticket, Video | Ticket, Video, Chat, Phone
-Support response team | Regular | Specialized | Dedicated
-Recommendations for improvements | No | No | Yes
-Training and enablement sessions | No | No | Yes
-Technical Account Manager (TAM) | No | No | Yes
-Key Account Manager (KAM) | No | No | Yes
-Ticket response times - Critical | 12h | 2h | 1h
-Ticket response times - High | 12h | 4h | 2h
-Ticket response times - Medium | 24h | 8h | 4h
-Ticket response times - Low | 24h | 24h | 24h
+| | Essential | Advanced | Premium |
+| --- | --- | --- | --- |
+| Use case | Basic minimum support | Development support | Production and critical workload support |
+| Support hours | 24x5x365 | 24x7x365 | 24x7x365 |
+| Modes of support | Ticket | Ticket, Video | Ticket, Video, Chat, Phone |
+| Support response team | Regular | Specialized | Dedicated |
+| Recommendations for improvements | No | No | Yes |
+| Training and enablement sessions | No | No | Yes |
+| Technical Account Manager (TAM) | No | No | Yes |
+| Key Account Manager (KAM) | No | No | Yes |
+| Ticket response times - Critical | 12h | 2h | 1h |
+| Ticket response times - High | 12h | 4h | 2h |
+| Ticket response times - Medium | 24h | 8h | 4h |
+| Ticket response times - Low | 24h | 24h | 24h |