Docs: Refactor inconsistent unordered lists (grafana#27826)

* Docs: Refactor inconsistent unordered lists

* add requested changes

* Update docs/sources/linking/data-link-variables.md

Co-authored-by: Diana Payton <[email protected]>

* Update docs/sources/http_api/_index.md

Co-authored-by: Diana Payton <[email protected]>

* Update docs/sources/guides/whats-new-in-v6-0.md

Co-authored-by: Diana Payton <[email protected]>

* Update docs/sources/auth/auth-proxy.md

Co-authored-by: Diana Payton <[email protected]>

* resolve weird line breaks

* revert unintentional change

* Update docs/sources/auth/auth-proxy.md

Co-authored-by: Diana Payton <[email protected]>

* Update docs/sources/auth/auth-proxy.md

Co-authored-by: Diana Payton <[email protected]>

* Update docs/sources/auth/auth-proxy.md

Co-authored-by: Diana Payton <[email protected]>

Co-authored-by: Diana Payton <[email protected]>

.github/ISSUE_TEMPLATE/1-bug_report.md

@@ -9,9 +9,9 @@ Please use this template to create your bug report. By providing as much info as
 
 PROTIP: record your screen and attach it as a gif to showcase the issue.
 
-* Questions should be posted to: https://community.grafana.com
-* Use query inspector to troubleshoot issues: https://bit.ly/2XNF6YS
-* How to record and attach gif: https://bit.ly/2Mi8T6K
+- Questions should be posted to: https://community.grafana.com
+- Use query inspector to troubleshoot issues: https://bit.ly/2XNF6YS
+- How to record and attach gif: https://bit.ly/2Mi8T6K
 -->
 
 **What happened**:

.github/PULL_REQUEST_TEMPLATE.md

@@ -22,7 +22,7 @@ Thank you for sending a pull request! Here are some tips:
 
 <!--
 
-* Automatically closes linked issue when the Pull Request is merged.
+- Automatically closes linked issue when the Pull Request is merged.
 
 Usage: "Fixes #<issue number>", or "Fixes (paste link of issue)"
 

CODE_OF_CONDUCT.md

@@ -8,19 +8,19 @@ In the interest of fostering an open and welcoming environment, we as contributo
 
 Examples of behavior that contributes to creating a positive environment include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a professional setting
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
 
 ## Our Responsibilities
 

ISSUE_TRIAGE.md

@@ -8,10 +8,10 @@ The core maintainers of the Grafana project are responsible for categorizing all
 
 Triage helps ensure issues resolve quickly by:
 
-* Ensuring the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for an issue to explain how an end user experiences a problem and what actions they took.
-* Giving a contributor the information they need before they commit to resolving an issue.
-* Lowering the issue count by preventing duplicate issues.
-* Streamlining the development process by preventing duplicate discussions.
+- Ensuring the issue's intent and purpose is conveyed precisely. This is necessary because it can be difficult for an issue to explain how an end user experiences a problem and what actions they took.
+- Giving a contributor the information they need before they commit to resolving an issue.
+- Lowering the issue count by preventing duplicate issues.
+- Streamlining the development process by preventing duplicate discussions.
 
 If you don't have the knowledge or time to code, consider helping with triage. The community will thank you for saving them time by spending some of yours.
 
@@ -112,9 +112,9 @@ In general, if the issue description and title is perceived as a question no mor
 
 To make it easier for everyone to understand and find issues they're searching for it's suggested as a general rule of thumbs to:
 
-* Make sure that issue titles are named to explain the subject of the issue, has a correct spelling and doesn't include irrelevant information and/or sensitive information.
-* Make sure that issue descriptions doesn't include irrelevant information, information from template that haven't been filled out and/or sensitive information.
-* Do your best effort to change title and description or request suggested changes by adding a comment.
+- Make sure that issue titles are named to explain the subject of the issue, has a correct spelling and doesn't include irrelevant information and/or sensitive information.
+- Make sure that issue descriptions doesn't include irrelevant information, information from template that haven't been filled out and/or sensitive information.
+- Do your best effort to change title and description or request suggested changes by adding a comment.
 
 > **Note:** Above rules is applicable to both new and existing issues of the Grafana project.
 
@@ -335,6 +335,6 @@ This will give you a structure of labels in the sidebar similar to the following
   - Grafana
 ```
 
-* All notifications you’ll need to read/take action on show up as unread in GitHub (mine) and its sub-labels.
-* All other notifications you don’t need to take action on show up as unread in GitHub (other) and its sub-labels
-  * This is convenient for issue triage and to follow the activity in the Grafana project.
+- All notifications you’ll need to read/take action on show up as unread in GitHub (mine) and its sub-labels.
+- All other notifications you don’t need to take action on show up as unread in GitHub (other) and its sub-labels
+  - This is convenient for issue triage and to follow the activity in the Grafana project.

MAINTAINERS.md

@@ -1,8 +1,8 @@
 @torkelo is the main/default maintainer, some parts of the codebase have other maintainers:
 
-* Backend:
-  * @bergquist
-* Plugins:
-  * @ryantxu
-* UX/UI:
-  * @davkal
+- Backend:
+  - @bergquist
+- Plugins:
+  - @ryantxu
+- UX/UI:
+  - @davkal

WORKFLOW.md

@@ -13,28 +13,28 @@ Team members and their access to repositories is maintained through [GitHub team
 ## Proposing changes
 
 Examples of proposed changes are overarching architecture, component design, and specific code or graphical elements. Proposed changes SHOULD cover the big picture and intention, but individual parts SHOULD be split into the smallest possible changes. Changes SHOULD be based on and target the master branch. Depending on size of the proposed change, each change SHOULD be discussed, in increasing order of change size and complexity:
-* Directly in a RR (Pull Request) - this MAY be done, but SHOULD not be the common case.
-* Issue
-* Developer mailing list
-* Design document, shared via Google Docs, accessible to at least all team members.
+- Directly in a RR (Pull Request) - this MAY be done, but SHOULD not be the common case.
+- Issue
+- Developer mailing list
+- Design document, shared via Google Docs, accessible to at least all team members.
 
 Significant changes MUST be discussed and agreed upon with the relevant subsystem maintainers.
 
 ## Merging PRs (Pull Requests)
 
 Depending on the size and complexity of a PR, different requirements MUST be applied. Any team member contributing substantially to a PR MUST NOT count against review requirements.
 Commits MUST be merged into master using PRs. They MUST NOT be merged into master directly.
-* Every merge MUST be approved by at least one team member.
-* Non-trivial changes MUST be approved by at least
-  * two team members, or
-  * one subsystem maintainer.
-* Significant changes MUST be approved by at least
-  * two team members, AND
-  * the relevant subsystem maintainer.
+- Every merge MUST be approved by at least one team member.
+- Non-trivial changes MUST be approved by at least
+  - two team members, or
+  - one subsystem maintainer.
+- Significant changes MUST be approved by at least
+  - two team members, AND
+  - the relevant subsystem maintainer.
 
 PRs MUST be [reviewed](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/reviewing-changes-in-pull-requests) and [approved](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/approving-a-pull-request-with-required-reviews) via GitHub’s review system.
-* Reviewers MAY write comments if approving
-* Reviewers MUST write comments if rejecting a PR or if requesting changes.
+- Reviewers MAY write comments if approving
+- Reviewers MUST write comments if rejecting a PR or if requesting changes.
 
 Once a PR is approved as per above, any team member MAY merge the PR.
 
@@ -45,28 +45,28 @@ Once a PR is approved as per above, any team member MAY merge the PR.
 Grafana uses trunk-based development.
 
 In particular, we found that the following principles match how we work:
-* Master and release branches MUST always build without failure.
-* Branches SHOULD be merged often. Larger changes SHOULD be activated with feature flags until they are ready. Long-lived development branches SHOULD be avoided.
-* Changes MAY be enabled by default once they are in a complete state
-* Changes which span multiple PRs MUST be described in an overarching issue or Google Doc.
+- Master and release branches MUST always build without failure.
+- Branches SHOULD be merged often. Larger changes SHOULD be activated with feature flags until they are ready. Long-lived development branches SHOULD be avoided.
+- Changes MAY be enabled by default once they are in a complete state
+- Changes which span multiple PRs MUST be described in an overarching issue or Google Doc.
 
 ## Releases
 
 Releases MUST follow [Semantic Versioning](https://semver.org/) in naming and SHOULD follow Semantic Versioning as closely as reasonably possible for non-library software.
 
 Release branches MUST be split from the following branches.
-* MAJOR release branches MUST be based on master.
-* MINOR release branches MUST be based on master.
-* PATCH release branches MUST be split from the relevant MINOR release branch’s most current PATCH
+- MAJOR release branches MUST be based on master.
+- MINOR release branches MUST be based on master.
+- PATCH release branches MUST be split from the relevant MINOR release branch’s most current PATCH
 
 Security releases follow the same process but MUST be prepared in secret. Security releases MUST NOT include changes which are not related to the security fix. Normal release processes MUST accommodate the security release process. SECURITY.md MUST be followed.
 
 PRs intended for inclusion in the next PATCH release MUST be labeled with `cherry-pick-needed` so they can be picked up by automated release tooling.
 
 Releases follow the following cadence
-* MAJOR: Yearly
-* MINOR: Every 4-6 weeks
-* PATCH: As needed
+- MAJOR: Yearly
+- MINOR: Every 4-6 weeks
+- PATCH: As needed
 
 Releases SHOULD NOT be delayed by pending changes.
 

contribute/developer-guide.md

@@ -211,8 +211,8 @@ Another alternative is to limit the files being watched. The directories that ar
 
 To retain your `ulimit` configuration, i.e. so it will be remembered for future sessions, you need to commit it to your command line shell initialization file. Which file this will be depends on the shell you are using, here are some examples:
 
-* zsh -> ~/.zshrc
-* bash -> ~/.bashrc
+- zsh -> ~/.zshrc
+- bash -> ~/.bashrc
 
 Commit your ulimit configuration to your shell initialization file as follows ($LIMIT being your chosen limit and $INIT_FILE being the initialization file for your shell):
 

contribute/style-guides/documentation-markdown-guide.md

@@ -1,30 +1,26 @@
 # Markdown style guide
 
-This guide for Markdown style helps keep contributions consistent across all documentation
-created for Grafana products. Refer to the guide and update its sections as needed when a
-Subject Matter Expert answers a question on Markdown style, or a decision is made about
-how to apply Markdown.
+This guide for Markdown style helps keep contributions consistent across all documentation created for Grafana products. Refer to the guide and update its sections as needed when a Subject Matter Expert answers a question on Markdown style, or a decision is made about how to apply Markdown.
 
 ## Headers
 
-In Markdown, the number of "#" symbols creates different heading levels, similar to
-HTML heading levels:
+In Markdown, the number of "#" symbols creates different heading levels, similar to HTML heading levels:
 
 **Example**
 
-* \# is \<h1>.
-* \#\# is \<h2>.
-* \#\#\# is \<h3>.
+- \# is \<h1>.
+- \#\# is \<h2>.
+- \#\#\# is \<h3>.
 
 Start your document with a single ``#`` for the title of the page. Add the sub-headings with two ``##``.
 
 ## Bold and emphasis
 
-* Make text **bold** using two asterisks.
+- Make text **bold** using two asterisks.
 
-**Example:** It is ``**important**`` to use GitHub Flavored Markdown emoji consistently.
+**Example:** It is ``**important**`` to use GitHub-flavored Markdown emoji consistently.
 
-* Make text ``_emphasized_`` using single `` _underscores_``. Do not use the single asterisk, it can be easily confused with bold.
+- Make text ``_emphasized_`` using single `` _underscores_``. Do not use the single asterisk, it can be easily confused with bold.
 
 **Example:** GitHub-flavored markdown emoji should _only_ appear in specific cases.
 
@@ -35,7 +31,7 @@ Create links to other website by wrapping the display text in square brackets, a
 
 \[text to display](www.website.com)
 
-**Example:** For more information on including emoji in GitHub flavored Markdown, refer to the [webfx page on emoji](https://www.webfx.com/tools/emoji-cheat-sheet/) for a list of emoji.
+**Example:** For more information on including emoji in GitHub-flavored markdown, refer to the [webfx page on emoji](https://www.webfx.com/tools/emoji-cheat-sheet/) for a list of emoji.
 
 ## Block quotes
 
@@ -49,8 +45,7 @@ Include block quotes inside text using right-facing arrows:
 
 ## Code blocks
 
-Code blocks written with markdown can show off syntax highlighting specific
-to different languages. Use three back tics to create a code block:
+Code blocks written with markdown can show off syntax highlighting specific to different languages. Use three back tics to create a code block:
 
 ```
 function testNum(a) {
@@ -62,8 +57,7 @@ function testNum(a) {
 }
 ```
 
-Write the name of the language after the first set of back tics, no spaces,
-to show specific syntax highlighting. For example; "\```javascript" produces the following:
+Write the name of the language after the first set of back tics, no spaces, to show specific syntax highlighting. For example; "\```javascript" produces the following:
 
 ```javascript
 function testNum(a) {
@@ -76,10 +70,7 @@ function testNum(a) {
 ```
 ## Tables
 
-Construct a table by typing the table headings, and separating them with
-a "|" character. Then, add a second line of dashes ("-") separated by
-another "|" character. When constructing the table cells, separate each cell data with another
-"|".
+Construct a table by typing the table headings, and separating them with a "|" character. Then, add a second line of dashes ("-") separated by another "|" character. When constructing the table cells, separate each cell data with another "|".
 
 **Example**
 
@@ -115,8 +106,7 @@ The list above will always display as:
 
 ### Unordered lists
 
-Build a list of points - an unordered or unnumbered list - by
-using "\-" (hyphen) characters.
+Build a list of points - an unordered or unnumbered list - by using "\-" (hyphen) characters.
 
 **Example**