standardize capitalization of components (timescale#2064)

Author: charislam

.vscode/api-reference.code-snippets

@@ -10,7 +10,7 @@
 	 	"scope": "markdown",
 	 	"prefix": ["api"],
 	 	"body": [
-	 		"# ${1:api_call}() <tag type=\"$2\" content=\"$3\" />",
+	 		"# ${1:api_call}() <Tag type=\"$2\" content=\"$3\" />",
 			 "${4:<!--Single sentence description of the API call-->}",
              "```${5:sql}",
              "${6:FIXME: Syntax example}",

.vscode/highlight-blank.code-snippets

@@ -10,9 +10,9 @@
 	 	"scope": "markdown",
 	 	"prefix": ["hl"],
 	 	"body": [
-	 		"<highlight type=\"${1:note|important|warning|deprecated|cloud}\">",
+	 		"<Highlight type=\"${1:note|important|warning|deprecated|cloud}\">",
 			 "$2",
-			 "</highlight>"
+			 "</Highlight>"
 	 	],
 	 	"description": "Make a blank callout block"
 	 }

.vscode/highlight-callout.code-snippets

@@ -10,9 +10,9 @@
 	 	"scope": "markdown",
 	 	"prefix": ["high","callout"],
 	 	"body": [
-	 		"<highlight type=\"${1:note|important|warning|deprecated}\">",
+	 		"<Highlight type=\"${1:note|important|warning|deprecated}\">",
 			 "$TM_SELECTED_TEXT",
-			 "</highlight>"
+			 "</Highlight>"
 	 	],
 	 	"description": "Make the selected text a callout block"
 	 }

.vscode/markdownlint/highlight-line-break.js

@@ -21,8 +21,8 @@ const {
  */
 const checkHighlightLineBreak = (params, onError) => {
   const { lines } = params;
-  const openingPattern = "<highlight[^<]*>";
-  const closingPattern = "<\\/highlight>";
+  const openingPattern = "<Highlight[^<]*>";
+  const closingPattern = "<\\/Highlight>";
   const openingTags = findPatternInLines(lines, openingPattern);
   const closingTags = findPatternInLines(lines, closingPattern);
 

.vscode/markdownlint/highlight-type.js

@@ -22,7 +22,7 @@ const errorMessage = highlightTypes.reduce(
  */
 const checkHighlightType = (params, onError) => {
   const { lines } = params;
-  const highlightTags = findPatternInLines(lines, "<highlight[^<]*>");
+  const highlightTags = findPatternInLines(lines, "<Highlight[^<]*>");
 
   for (let tag of highlightTags) {
     const match = tag.line.match('type="([^"]+)"');

.vscode/markdownlint/procedure-tags-closed.js

@@ -13,8 +13,8 @@ const { checkTagsClosed, findPatternInLines } = require("./utils");
  */
 const checkProcedureTagsClosed = (params, onError) => {
   const { lines } = params;
-  const procedureOpeningTags = findPatternInLines(lines, "<procedure>");
-  const procedureClosingTags = findPatternInLines(lines, "<\\/procedure>");
+  const procedureOpeningTags = findPatternInLines(lines, "<Procedure>");
+  const procedureClosingTags = findPatternInLines(lines, "<\\/Procedure>");
   if (procedureOpeningTags.length === 0 && procedureClosingTags.length === 0)
     return;
   checkTagsClosed({

.vscode/markdownlint/terminal-indent.js

@@ -20,8 +20,8 @@ const {
 const checkTerminalIndent = (params, onError) => {
   // Find all terminal-related JSX tags
   const { lines } = params;
-  const terminalOpeningTags = findPatternInLines(lines, "<terminal>");
-  const terminalClosingTags = findPatternInLines(lines, "<\\/terminal>");
+  const terminalOpeningTags = findPatternInLines(lines, "<Terminal>");
+  const terminalClosingTags = findPatternInLines(lines, "<\\/Terminal>");
   const tabTags = findPatternInLines(lines, "<\\/?tab.*>");
   if (terminalOpeningTags.length === 0) return;
 

CONTRIBUTING.md

@@ -1,16 +1,19 @@
 # Introduction
+
 There are multiple ways to help make TimescaleDB better, including contributing
 to the documentation. All of our documentation is available to use and review
 with GitHub.
 
 ## First contribution
+
 You can make contributions to the documentation by creating a fork of the
 repository. However, if you have write access to the repository, use a branch
 instead. Some of our automation does not work correctly on forks.
 
-<procedure>
+<Procedure>
 
 ### Contributing using a fork
+
 1.  Make sure you have a [GitHub](https://github.com) account, and that
     you're signed in.
 1.  Navigate to the
@@ -20,73 +23,99 @@ instead. Some of our automation does not work correctly on forks.
 1.  Wait for GitHub to create your fork and redirect you.
 1.  Clone the repository to your local machine. To find this URL, click the green
     `Code` button and copy the HTTPS URL:
+
     ```bash
     git clone https://github.com/<username>/docs.git
     ```
+
 1.  List the current remote branches:
+
     ```bash
     git remote -v
     ```
+
     This command should list two remotes, both marked `origin`, like this:
+
     ```bash
     origin  https://github.com/<username>/docs.git (fetch)
     origin  https://github.com/<username>/docs.git (push)
     ```
+
     The `origin` remotes are your own fork, and you can do whatever you want
     here without changing the upstream repository.
 1.  Add the docs repo as an upstream:
+
     ```bash
     git remote add upstream https://github.com/timescale/docs.git
     ```
+
 1.  Check:
+
     ```bash
     git remote -v
     ```
+
     This command should now have the same two `origin` remotes as before, plus
     two more labelled `upstream`, like this:
+
     ```bash
     origin  https://github.com/<username>/docs.git (fetch)
     origin  https://github.com/<username>/docs.git (push)
     upstream  https://github.com/timescale/docs.git (fetch)
     upstream  https://github.com/timescale/docs.git (push)
     ```
+
 1.  Fetch the branches in the upstream repository:
+
     ```bash
     git fetch upstream
     ```
+
 1.  Merge the changes from the upstream `latest` branch, into your fork's
     `latest` branch:
+
     ```bash
     git merge upstream/latest
     ```
-1. Create a new branch for the work you want to do. Make sure you give it an
+
+1.  Create a new branch for the work you want to do. Make sure you give it an
     appropriate name, and include your username:
+
     ```bash
     git checkout -b update-readme-username
     ```
 
-</procedure>
+</Procedure>
 
-<procedure>
+<Procedure>
 
 ### Committing changes and creating a pull request
+
 1.  Make your changes.
 1.  Add the updated files to your commit:
+
     ```bash
     git add .
     ```
+
 1.  Commit your changes:
+
     ```bash
     git commit -m "Commit message here"
     ```
+
 1.  Push your changes:
+
     ```bash
     git push
     ```
+
     If git prompts you to set an upstream in order to push, use this command:
+
     ```bash
     git push --set-upstream origin <branchname>
     ```
+
 1.  Create a pull request (PR) by navigating to
     <https://github.com/timescale/docs> and clicking
     `Compare and Create Pull Request`. Write an informative commit message
@@ -97,70 +126,82 @@ instead. Some of our automation does not work correctly on forks.
     transparent about what you are working on, and making sure we all understand
     current progress.
 
-</procedure>
+</Procedure>
 
-<highlight type="important">
+<Highlight type="important">
 Choose your reviewers carefully! If you have made changes to the technical
 detail of the documentation, choose an appropriate subject matter expert (SME)
 to review those changes. Additionally, every change requires at least one
 documentation team member to approve. Ask the documentation team for a review by
 adding the `timescale/documentation` group as a reviewer.
-</highlight>
+</Highlight>
 
 ## Second contribution
+
 When you have checked out the repo, if you want to keep working on things, you
 need to make sure that your local copy of the repo stays up to date. If you
 don't do this, you *will* end up with merge conflicts.
 
-<procedure>
+<Procedure>
 
 ### Second contribution
+
 1.  Check out your fork's `latest` branch:
+
     ```bash
     git checkout latest
     ```
+
     You get a message like this:
+
     ```bash
     Switched to branch 'latest'
     Your branch is up to date with 'origin/latest'.
     ```
+
     BEWARE! This is usually a lie!
 1.  Fetch the branches in the upstream repository:
+
     ```bash
     git fetch upstream
     ```
+
 1.  Merge the changes from the upstream `latest` branch, into your fork's
     `latest` branch:
+
     ```bash
     git merge upstream/latest
     ```
+
 1.  If you are continuing work you began earlier, check out the branch that
     contains your work. For new work, create a new branch. Doing this regularly
     as you are working means you keep your local copies up to date and avoid
     conflicts. You should do it at least every day before you begin work, and
     again whenever you switch branches.
 
+</Procedure>
 
-</procedure>
-
-<highlight type="warning">
+<Highlight type="warning">
 Never leave branches lying around on your local system. Create your PR as soon
 as possible, and make good use of the Draft feature. Commit to your feature
 branch early and often! Update your local copy from latest whenever you switch
 branches.
-</highlight>
+</Highlight>
 
 ## Reviewing standards
+
 When you create a pull request, a member of the documentation team will review
 it for accuracy and adherance to our standards. You can see a list of the things
 that reviewers check for in the pull request template.
 
 ## Writing standards
+
 Timescale has comprehensive writing and style standards, that are constantly
 being updated and improved. For the current guidelines, see
 [contributing to documentation](https://docs.timescale.com/timescaledb/latest/contribute-to-docs/).
 
 ## The Timescale documentation team
+
 *   Lana Brindley <https://github.com/Loquacity>
 *   Rajakavitha Kodhandapani <https://github.com/Rajakavitha1>
 *   Charis Lam <https://github.com/charislam>

README.md

@@ -201,23 +201,23 @@ The `type` can currently support a value of `"note"`, `"warning"`,
 for content specifically referring to Timescale Cloud.
 
 ```html
-<highlight type="note">
+<Highlight type="note">
 Callout text goes here...
 
 Example link style would [look like this](http://example.com/)
-</highlight>
+</Highlight>
 ```
 
 ### Tags
 
 You can use tags to indicate links to downloadable files, or to indicate
 metadata about functions. Available tags:
 
-*   Download tags: `<tag type="download">Markdown link to download</tag>`
-*   Experimental tags: `<tag type="experimental" content="Experimental" />` or
-    `<tag type="experimental-toolkit" content="Experimental" />`
-*   Toolkit tag: `<tag type="toolkit" content="Toolkit" />`
-*   Community tag: `<tag type="community" content="Community" />`
+*   Download tags: `<Tag type="download">Markdown link to download</Tag>`
+*   Experimental tags: `<Tag type="experimental" content="Experimental" />` or
+    `<Tag type="experimental-toolkit" content="Experimental" />`
+*   Toolkit tag: `<Tag type="toolkit" content="Toolkit" />`
+*   Community tag: `<Tag type="community" content="Community" />`
 
 ### Procedures
 

_multi-code-block.md

@@ -1,5 +1,5 @@
 <!-- Note the spacing and labeling are very important! -->
-<terminal>
+<Terminal>
 
 <tab label='ruby'>
 
@@ -34,4 +34,4 @@ def different_python:
 
 </tab>
 
-</terminal>
+</Terminal>