diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5d2be4e9bc..f4d565a424 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,202 +1,190 @@ -# Introduction +# Contribute to Timescale documentation -There are multiple ways to help make Timescale better, including contributing -to the documentation. All of our documentation is available to use and review -with GitHub. +Timescale documentation is open for contribution from all community members. The current source is in this repository. -## First contribution +This page explains the process and guidelines to follow when contributing to Timescale documentation. -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. +## Contribution process - +You can contribute to Timescale documentation in the following ways: -### Contributing using a fork +- [Create an issue][docs-issues] in this repository and describe the proposed change. Our doc team will take care of it. +- Update the docs yourself and have your change reviewed and published by our doc team. -1. Make sure you have a [GitHub](https://github.com) account, and that - you're signed in. -1. Navigate to the - [Timescale documentation repo](https://github.com/timescale/docs), - click the `Fork` button in the top-right corner, and select the account you - want to use. -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: +To make the contribution yourself: - ```bash - git clone https://github.com//docs.git - ``` +1. Get the documentation source: + + - No write access? [Fork this repository][github-fork]. + - Already have a write access? [Clone this repository][github-clone]. -1. List the current remote branches: +2. Create a branch from `latest`, make your changes, and raise a pull request back to `latest`. - ```bash - git remote -v - ``` +3. Sign a Contributor License Agreement (CLA). - This command should list two remotes, both marked `origin`, like this: + You have to sign the CLA only the first time you raise a PR. This helps to ensure that the community is free to use your contributions. + +4. Review your changes. - ```bash - origin https://github.com//docs.git (fetch) - origin https://github.com//docs.git (push) - ``` + The documentation site is generated in a separate private repository using [Gatsby][gatsby]. Once you raise a PR for any branch, GitHub will **automatically** generate a preview for your changes and attach the link in the comments. Any new commits will be visible at the same URL. If you don't see the latest changes, try an incognito browser window. Automated builds are not available for PRs from forked repositories. - 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: +## Language - ```bash - git remote add upstream https://github.com/timescale/docs.git - ``` +Aim to write in a clear, concise, and actionable manner. Timescale documentation uses the [Google Developer Documentation Style Guide][google-style] with the following exceptions: -1. Check: +- Do not capitalize the first word after a colon. +- Use code font (back ticks) for UI elements instead of bold. - ```bash - git remote -v - ``` +## Edit individual pages - This command should now have the same two `origin` remotes as before, plus - two more labelled `upstream`, like this: +Each major doc section has a dedicated directory with `.md` files inside, representing its child pages. This includes an `index.md` file that serves as a landing page for that doc section by default, unless specifically changed in the navigation tree. To edit a page, modify the corresponding `.md` file following these recommendations: - ```bash - origin https://github.com//docs.git (fetch) - origin https://github.com//docs.git (push) - upstream https://github.com/timescale/docs.git (fetch) - upstream https://github.com/timescale/docs.git (push) - ``` +- **Regular pages** should include: -1. Fetch the branches in the upstream repository: + - A short intro describing the main subject of the page. + - A visual illustrating the main concept, if relevant. + - Paragraphs with descriptive headers, organizing the content into logical sections. + - Procedures to describe the sequence of steps to reach a certain goal. For example, create a Timescale service. + - Other visual aids, if necessary. + - Links to other relevant resources. - ```bash - git fetch upstream - ``` +- **API pages** should include: -1. Merge the changes from the upstream `latest` branch, into your fork's - `latest` branch: + - The function name, with empty parentheses if it takes arguments. + - A brief, specific description of the function, including any possible warnings. + - One or two samples of the function being used to demonstrate argument syntax. + - An argument table with Name, Type, Default, Required, Description columns. + - A return table with Column, Type, and Description columns. - ```bash - git merge upstream/latest - ``` +- **Troubleshooting pages** are not written as whole Markdown files, but are programmatically assembled from individual files in the`_troubleshooting` folder. Each entry describes a single troubleshooting case and its solution, and contains the following front matter: + + |Key| Type |Required| Description | + |-|-------|-|--------------------------------------------------------------------------| + |`title`| string |✅| The title of the troubleshooting entry, displayed as a heading above it | + |`section`| The literal string `troubleshooting` |✅| Must be `troubleshooting`, used to identify troubleshooting entries during site build | + |`products` or `topics`| array of strings |✅ (can have either or both, but must have at least one)| The products or topics related to the entry. The entry will show up on the troubleshooting pages for the listed products and topics. | + |`errors`| object of form `{language: string, message: string}` |❌| The error, if any, related to the troubleshooting entry. Displayed as a code block right underneath the title. `language` is the programming language to use for syntax highlighting. | + |`keywords`| array of strings |❌| These are displayed at the bottom of every troubleshooting page. Each keyword links to a collection of all pages associated with that keyword. | + |`tags`| array of strings |❌| Concepts, actions, or things associated with the troubleshooting entry. These are not displayed in the UI, but they affect the calculation of related pages. | + + Beneath the front matter, describe the error and its solution in regular Markdown. You can also use any other components allowed within the docs site. + + The entry shows up on the troubleshooting pages for its associated products and topics. If the page doesn't already exist, add an entry for it in the page + index, setting `type` to `placeholder`. See [Navigation tree](#navigation-tree). -1. Create a new branch for the work you want to do. Make sure you give it an - appropriate name, and include your username: +## Edit the navigation hierarchy - ```bash - git checkout -b update-readme-username - ``` +The navigation hierarchy of a doc section is governed by `page-index/page-index.js` within the corresponding directory. For example: - +```js + { + title: "Timescale Cloud services", + href: "services", + excerpt: "About Timescale Cloud services", + children: [ + { + title: "Services overview", + href: "service-overview", + excerpt: "Timescale services overview", + }, + { + title: "Service explorer", + href: "service-explorer", + excerpt: "Timescale services explorer", + }, + { + title: "Troubleshooting Timescale services", + href: "troubleshooting", + type: "placeholder", + }, + ], + }, +``` - +See [Use Timescale section navigation][use-navigation] for reference. -### Committing changes and creating a pull request +To change the structure, add or delete pages in a section, modify the corresponding `page-index.js`. An entry in a `page-index.js` includes the following fields: -1. Make your changes. -1. Add the updated files to your commit: +| Key | Type | Required | Description | +|--------------------|-----------------------------------------------------------|----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `href` | string | ✅ | The URL segment to use for the page. If there is a corresponding Markdown file, `href` must match the name of the Markdown file, minus the file extension. | +| `title` | string | ✅ | The title of the page, used as the page name within the TOC on the left. Must be the same as the first header in the corresponding Markdown file. | +| `excerpt` | string | ❌ | The short description of the page, used for the page card if `pageComponents` is set to `featured-cards`. Should be up to 100 characters. See `pageComponents` for details. | +| `type` | One of `[directory, placeholder, redirect-to-child-page]` | ❌ | If no type is specified, the page is built as a regular webpage. The structure of its children, if present, is defined by `children` entries and the corresponding structure of subfolders. If the type is `directory`, the corresponding file becomes a directory. The difference of the directory page is that its child pages sit at the same level as the `directory` page. They only become children during the site build. If the type is `placeholder`, the corresponding page is produced programmatically upon site build. If not produced, the link in the navigation tree returns a 404. In particular, this is used for troubleshooting pages. If the type is `redirect-to-child-page`, no page is built and the link in the navigation tree goes directly to the first child. | +| `children` | Array of page entries | ❌ | Child pages of the current page. For regular pages, the children should be located in a directory with the same name as the parent. The parent is the `index.md` file in that directory. For`directory` pages, the children should be located in the same directory as the parent. | +| `pageComponents` | One of `[['featured-cards'], ['content-list']]` | ❌ | Any page that has child pages can list its children in either card or list style at the bottom of the page. Specify the desired style with this key. | +| `featuredChildren` | Array of URLs | ❌ | Similar to `pageComponents`, this displays the children of the current page, but only the selected ones. | +| `index` | string | ❌ | If a section landing page needs to be different from the `index.md` file in that directory, this field specifies the corresponding Markdown file name. | - ```bash - git add . - ``` +## Reuse text in multiple pages -1. Commit your changes: +Partials allow you to reuse snippets of content in multiple places. All partials +live in the `_partials` top-level directory. To make a new partial, create a new +`.md` file in this directory. The filename must start with an underscore. Then import it into the target page and reference in the relevant place. See [Formatting examples][formatting]. - ```bash - git commit -m "Commit message here" - ``` +## Formatting -1. Push your changes: +In addition to all the [regular Markdown formatting][markdown-syntax], the following elements are available for Timescale docs: - ```bash - git push - ``` +- Procedure blocks +- Highlight blocks +- Tabs +- Code blocks without line numbers and the copy button +- Multi-tab code blocks +- Tags + +See [Formatting examples][formatting] for how to use them. - If git prompts you to set an upstream in order to push, use this command: +## Variables + +Timescale documentation uses variables for its product names, features, and UI elements in Timescale Console with the following syntax: `$VARIABLE_NAME`. Variables do not work inside the following: + +- Front matter on each page +- HTML tables + +See the [full list of available variables][variables]. + +## Links + +- Internal page links: internal links do not need to include the domain name `https://docs.timescale.com`. Use the `:currentVersion:` variable instead of `latest` in the URL. +- External links: input external links as is. + +See [Formatting examples][formatting] for details. + +## Visuals + +When adding screenshots to the docs, aim for a full-screen view to provide better context. Reduce the size of your browser so there is as little wasted space as possible. + +Attach the image to your issue or PR, and the doc team will upload and insert it for you. + +## SEO optimization + +To make a documentation page more visible and clear for Google: + +- Include the `title` and `excerpt` meta tags at the top of the page. These represent meta title and description required for SEO optimization. - ```bash - git push --set-upstream origin - ``` + - `title`: up to 60 characters, a short description of the page contents. In most cases a variation of the page title. + - `excerpt`: under 200 characters, a longer description of the page contents. In most cases a variation of the page intro. -1. Create a pull request (PR) by navigating to - and clicking - `Compare and Create Pull Request`. Write an informative commit message - detailing your changes, choose reviewers, and save your PR. If you haven't - yet finished the work you want to do, make sure you create a draft PR by - selecting it from the drop down box in the GitHub web UI. This lets your - reviewers know that you haven't finished work yet, while still being - transparent about what you are working on, and making sure we all understand - current progress. +- Summarize the contents of each paragraph in the first sentence of that paragraph. +- Include main page keywords into the meta tags, page title, first header, and intro. These are usually the names of features described in the page. For example, for a page dedicated to creating hypertables, you can use the keyword **hypertable** in the following way: - + - Title: Create a hypertable in Timescale Cloud + - Description: Turn a regular PostgreSQL table into a hypertable in a few steps, using Timescale Console. + - First header: Create a hypertable - -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. - +## Docs for deprecated products -## 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. - - - -### 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. - - - - -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. - - -## 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/about/latest/contribute-to-docs/). +The previous documentation source is in the deprecated repository called [docs.timescale.com-content][legacy-source]. +[legacy-source]: https://github.com/timescale/docs.timescale.com-content +[docs-issues]: https://github.com/timescale/docs/issues +[github-fork]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo +[github-clone]: https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository +[gatsby]: https://www.gatsbyjs.com/ +[google-style]: https://developers.google.com/style +[markdown-syntax]: https://www.markdownguide.org/extended-syntax/ +[github-docs]: https://github.com/timescale/docs +[use-navigation]: use-timescale/page-index/page-index.js +[formatting]: _partials/_formatting_examples.md +[variables]: https://docs.timescale.com/variables-for-contributors/ \ No newline at end of file diff --git a/README.md b/README.md index 6148df9aca..3fc140ce91 100644 --- a/README.md +++ b/README.md @@ -196,23 +196,23 @@ Where you need the partial to display, insert it as a self-closing tag: To maintain consistency, please follow these general rules. * Maintain text editor width for paragraphs at 80 characters. We ask you to do -this to assist in reviewing documentation changes. When text is very wide, it -is difficult to visually see where text has changed within a paragraph and keeping -a narrow width on text assists in making PRs easier to review. **Most editors such -as Visual Studio Code have settings to do this visually.** + this to assist in reviewing documentation changes. When text is very wide, it + is difficult to visually see where text has changed within a paragraph and keeping + a narrow width on text assists in making PRs easier to review. **Most editors such + as Visual Studio Code have settings to do this visually.** * Most links should be reference-style links where the link address is at the -bottom of the page. The two exceptions are: + bottom of the page. The two exceptions are: * Links within highlight blocks (Note, Important, or Warning). These must be inline links for now * Links to anchors on the same page as the link itself. * All functions, commands and standalone function arguments (ex. `SELECT`, -`time_bucket`) should be set as inline code within backticks ("\`command\`"). + `time_bucket`) should be set as inline code within backticks ("\`command\`"). * Functions should not be written with parentheses unless the function is -being written with arguments within the parentheses. + being written with arguments within the parentheses. * "PostgreSQL" is the way to write the elephant database name, rather than -"Postgres." "TimescaleDB" refers to the database, "Timescale" refers to the -company. + "Postgres." "TimescaleDB" refers to the database, "Timescale" refers to the + company. * Use backticks when referring to the object of a user interface action. -For example: Click `Get started` to proceed with the tutorial. + For example: Click `Get started` to proceed with the tutorial. ### Callout and highlight blocks @@ -264,7 +264,7 @@ Used to indicate an optional step within a procedure. Syntax: `` Multi-code blocks are code blocks with a language or OS selector. For syntax, see [the multi-code-block example](./_multi-code-block.md). -### Tabs +### Tabs Tabs can be used to display content that differs based on a user selection. The syntax is: @@ -329,3 +329,7 @@ There is a specific format for the API section which consists of: * One or two literal examples of the function being used to demonstrate argument syntax. See the API file to get an idea. + + + + diff --git a/_multi-code-block.md b/_multi-code-block.md index fe2c36d061..d638a5123e 100644 --- a/_multi-code-block.md +++ b/_multi-code-block.md @@ -34,4 +34,4 @@ def different_python: - + \ No newline at end of file diff --git a/_partials/_deprecated.md b/_partials/_deprecated.md index c07cc2db29..53763784a1 100644 --- a/_partials/_deprecated.md +++ b/_partials/_deprecated.md @@ -1,5 +1,7 @@ + This section describes a feature that is deprecated on Timescale. We strongly recommend that you do not use this feature in a production environment. If you need more information, [contact us](https://www.timescale.com/contact/). + diff --git a/_partials/_formatting_examples.md b/_partials/_formatting_examples.md new file mode 100644 index 0000000000..2a8fc1eb4f --- /dev/null +++ b/_partials/_formatting_examples.md @@ -0,0 +1,170 @@ +# Formatting examples + +This page illustrates and provides examples of the formatting available for Timescale documentation. Note that for most elements, spacing is important. + +## Procedure + +Use for a logical sequence of steps to achieve a goal. For example, create a hypertable. + +![Procedure example](https://assets.timescale.com/docs/images/procedure-syntax.png) + +See a [use example][data-tiering] in the docs. + +## Highlight blocks + +Use sparingly and only if it's essential to attract the reader's attention. + +- Note + + ![Note highlight](https://assets.timescale.com/docs/images/highlight-note.png) + + See a [use example][disable-chunk-skipping] in the docs. + +- Important + + ![Important highlight](https://assets.timescale.com/docs/images/highlight-important.png) + + See a [use example][decompress-chunks] in the docs. + +- Warning + + ![Caution highlight](https://assets.timescale.com/docs/images/highlight-warning.png) + + See a [use example][alerting] in the docs. + +- Deprecation + + ![Deprecated highlight](https://assets.timescale.com/docs/images/highlight-deprecation.png) + + See a [use example][deprecation] in the docs. + +- Cloud + + ![Cloud highlight](https://assets.timescale.com/docs/images/highlight-cloud.png) + + Syntax example: + + ```text + + + A note dealing specifically with Timescale Cloud. + + + ``` + +## Tabs + +![Tabs](https://assets.timescale.com/docs/images/tabs-example.png) + +See a [use example][live-migration] in the docs. + +## Code blocks + +As a default, use [fenced Markdown code blocks][fenced-code-blocks]: + +![Regular code block](https://assets.timescale.com/docs/images/markdown-code-block.png) + +To remove line numbers and the copy button, use the `CodeBlock` component with `canCopy` and `showLineNumbers` set to `false`: + +![Custom code block](https://assets.timescale.com/docs/images/custom-code-block.png) + +See a [use example][aggregation] in the docs. + +## Multi-tab code blocks + +![Multi-tab code block](https://assets.timescale.com/docs/images/multi-tab-code.png) + +Syntax example: + + + + + + ```ruby + ruby code + ``` + + + + + + ```python + pyhon code + ``` + + + + + + ```go + different python code + ``` + + + + + +## Tags + +- Download + + ![Download tag](https://assets.timescale.com/docs/images/tag-download.png) + + See a [use example][time-series-data] in the docs. + +- Experimental + + ![Experimental tag](https://assets.timescale.com/docs/images/tag-experimental.png) + + See a [use example][time-bucket] in the docs. + +- Toolkit + + ![Tooklit tag](https://assets.timescale.com/docs/images/tag-toolkit.png) + + See a [use example][time-weighted-average] in the docs. + +- Community + + ![Community tag](https://assets.timescale.com/docs/images/tag-community.png) + + See a [use example][add-compression-policy] in the docs. + +- Hollow + + ![Hollow tag](https://assets.timescale.com/docs/images/hollow-tag.png) + + Syntax example: + + ```text + Text to display in a tag + ``` + +## Partials + +Import a partial from the `_partials` directory and then reference it in the relevant part of the page. See a [use example][live-migration] in the docs. + +## Links + +Links should be [reference-style Markdown links][reference-links]. For example: + +[A link to the data tiering section in docs][data-tiering] + +See [more examples][run-queries] in the docs. + +[data-tiering]: ../use-timescale/data-tiering/enabling-data-tiering.md +[disable-chunk-skipping]: ../api/disable_chunk_skipping.md +[decompress-chunks]: ../use-timescale/compression/decompress-chunks.md +[alerting]: ../use-timescale/alerting.md +[deprecation]: _partials/_deprecated.md +[live-migration]: ../migrate/live-migration.md +[fenced-code-blocks]: https://www.markdownguide.org/extended-syntax/#fenced-code-blocks +[aggregation]: ../getting-started/aggregation.md +[time-series-data]: ../getting-started/time-series-data.md +[time-bucket]: ../api/time_bucket_ng.md +[time-weighted-average]: ../api/time-weighted-averages.md +[add-compression-policy]: ../api/add_compression_policy.md +[reference-links]: https://www.markdownguide.org/basic-syntax/#reference-style-links +[run-queries]: ../getting-started/run-queires-from-console.md + + diff --git a/_procedure-block.md b/_procedure-block.md index 38921bc352..ef01fc2e8d 100644 --- a/_procedure-block.md +++ b/_procedure-block.md @@ -16,13 +16,13 @@ ``` 3. TimescaleDB is a time-series database, built on top of PostgreSQL. More than that, -however, it's a relational database for time-series. Developers who use TimescaleDB -get the benefit of a purpose-built time-series database, plus a classic relational -database (PostgreSQL), all in one, with full SQL support. + however, it's a relational database for time-series. Developers who use TimescaleDB + get the benefit of a purpose-built time-series database, plus a classic relational + database (PostgreSQL), all in one, with full SQL support. ```python def start: print('start') ``` - + \ No newline at end of file diff --git a/about/contribute-to-timescale.md b/about/contribute-to-timescale.md index f16c551331..9e320c666d 100644 --- a/about/contribute-to-timescale.md +++ b/about/contribute-to-timescale.md @@ -6,57 +6,37 @@ keywords: [contribute] tags: [github] --- -# Contributing to Timescale +# Contribute to Timescale -There are multiple ways to help make TimescaleDB better. All of the documentation -and source for the PostgreSQL extension are available to use and review on -GitHub. +TimescaleDB, pgai, pgvectorscale, TimescaleDB Toolkit, and the Timescale documentation are all open source. They are available in GitHub for you use, review and update. This page shows you the repositories where you can add to Timescale products. -## Contributing to Timescale documentation - -Timescale documentation is hosted in a [GitHub repository][github-docs] -and is open for contribution from all community members. If you -find errors or would like to add content to the docs, this tutorial -walks you through the process. - -### Making minor changes - -If you want to make only minor changes to docs, you can make corrections -and submit pull requests on the GitHub website. Go to the file you want to -correct and click the 'pencil' icon to edit. Once done, GitHub gives you -an option to submit a pull request at the bottom of the page. - -### Making larger contributions to docs +## Contribute to the code for Timescale products -In order to modify documentation, you should have a working knowledge -of [git][install-git] and [Markdown][markdown-tutorial]. You -also need to create a GitHub account. +Timescale appreciates any help the community can provide to make its products better! -Be sure to read the [Timescale docs contribution styleguide][timescale-docs-style]. -You'll see information about how we refer to aspects of Timescale, -how we format our docs, and special Markdown tags available to -you as you author your contribution. +There are multiple ways you can help: -Before we accept any contributions, Timescale contributors need to -sign the Contributor License Agreement (CLA). By signing a CLA, we -can ensure that the community is free and confident in its -ability to use your contributions. You are prompted to sign the -CLA during the pull request process. +* Open an issue with a bug report, build issue, feature request, suggestion, etc. +* Fork this repository and submit a pull request -## Contributing to TimescaleDB code +Head over to the Timescale source repositories to learn, review, and help improve our products! -Timescale appreciates any help the community can provide to make TimescaleDB better! +* [TimescaleDB][timescaledb]: an extension for PostgreSQL that enables time-series, events, and real-time analytics workloads, while increasing ingest, query, and storage performance. +* [pgai][pgai]: a suite of tools to develop RAG, semantic search, and other AI applications more easily with PostgreSQL. +* [pgvectorscale][pgvectorscale]: a complement to pgvector for higher performance embedding search and cost-efficient storage for AI applications. +* [TimescaleDB Toolkit][toolkit]: all things analytics when using TimescaleDB, with a particular focus on developer ergonomics and performance. -There are multiple ways you can help: +## Contributing to Timescale documentation -* Open an issue with a bug report, build issue, feature request, suggestion, etc. -* Fork this repository and submit a pull request +Timescale documentation is hosted in the [docs GitHub repository][github-docs] +and open for contribution from all community members. -[Head over to our GitHub repository][github-timescaledb] for TimescaleDB to learn -more about how you can help and to review our coding style guide! +See the [contribution guide][contribution-guide] for details. +[contribution-guide]: https://github.com/timescale/docs/blob/latest/CONTRIBUTING.md [github-docs]: https://github.com/timescale/docs -[github-timescaledb]: https://github.com/timescale/timescaledb/blob/master/CONTRIBUTING.md -[install-git]: https://git-scm.com/book/en/v2/Getting-Started-Installing-Git -[markdown-tutorial]: https://www.markdownguide.org/basic-syntax/ -[timescale-docs-style]: https://github.com/timescale/docs/blob/master/README.md +[timescaledb]: https://github.com/timescale/timescaledb/blob/main/CONTRIBUTING.md +[pgai]: https://github.com/timescale/pgai/blob/main/CONTRIBUTING.md +[pgvectorscale]: https://github.com/timescale/pgvectorscale/blob/main/CONTRIBUTING.md +[toolkit]: https://github.com/timescale/timescaledb-toolkit + diff --git a/use-timescale/alerting.md b/use-timescale/alerting.md index d90eccd7a9..d17c2590e1 100644 --- a/use-timescale/alerting.md +++ b/use-timescale/alerting.md @@ -33,7 +33,9 @@ it is designed to take advantage of the database's time-series capabilities. From there, proceed to your dashboard and set up alert rules as described above. + Alerting is only available in Grafana v4.0 and later. + ## Other alerting tools diff --git a/use-timescale/compression/decompress-chunks.md b/use-timescale/compression/decompress-chunks.md index dc09671ea6..838ba441a1 100644 --- a/use-timescale/compression/decompress-chunks.md +++ b/use-timescale/compression/decompress-chunks.md @@ -15,10 +15,12 @@ compressed chunk is more computationally expensive than inserting data into an uncompressed chunk. This adds up over a lot of rows. + When compressing your data, you can reduce the amount of storage space for your Timescale instance. But you should always leave some additional storage capacity. This gives you the flexibility to decompress chunks when necessary, for actions such as bulk inserts. + This section describes commands to use for decompressing chunks. You can filter