From 964926c3a3aea8ab52c5d8b3a65e2f77a9e9403f Mon Sep 17 00:00:00 2001 From: Sam Date: Thu, 23 May 2024 18:34:04 +0300 Subject: [PATCH] Tighten up and refactor the tutorial WIP (#11316) * Tighten up and refactor the tutorial * Second half of the doc edits * Apply suggestions from code review Co-authored-by: Anthony * Refactor conf options * Less Python version maintenance * Use ref for links * Or just say next * Use ref for link to hading * Cleanup bullets * Fix whitespace, thanks pre-commit * Update docs/user/tutorial/index.rst * Condense email shenanigans * Apply suggestions from code review Co-authored-by: Anthony --------- Co-authored-by: Anthony --- docs/user/tutorial/index.rst | 545 +++++++++++++++-------------------- 1 file changed, 226 insertions(+), 319 deletions(-) diff --git a/docs/user/tutorial/index.rst b/docs/user/tutorial/index.rst index f4fcf889900..bfdb5d1e433 100644 --- a/docs/user/tutorial/index.rst +++ b/docs/user/tutorial/index.rst @@ -1,61 +1,52 @@ Read the Docs tutorial ====================== -In this tutorial you will create a documentation project on Read the Docs -by importing a Sphinx project from a GitHub repository, -tailor its configuration, and explore several useful features of the platform. - -The tutorial is aimed at people interested in learning -how to use Read the Docs to host their documentation projects. -You will fork a fictional software library -similar to the one developed in the :doc:`official Sphinx tutorial `. -No prior experience with Sphinx is required -and you can follow this tutorial without having done the Sphinx one. - -The only things you will need are -a web browser, an Internet connection, and a GitHub account -(you can `register for a free account `_ if you don't have one). -You will use Read the Docs Community, which means that the project will be public. - -Getting started ---------------- - -Preparing your project on GitHub -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To start, `sign in to GitHub `_ -and navigate to `the tutorial GitHub template `_, -where you will see a green :guilabel:`Use this template` button. -Click it to open a new page that will ask you for some details: - -* Leave the default "Owner", or change it to something better for a tutorial project. -* Introduce an appropriate "Repository name", for example ``rtd-tutorial``. -* Make sure the project is "Public", rather than "Private". - -After that, click on the green :guilabel:`Create repository from template` button, -which will generate a new repository on your personal account -(or the one of your choosing). -This is the repository you will import on Read the Docs, -and it contains the following files: - -``.readthedocs.yaml`` - Read the Docs configuration file. - Required to setup the documentation build process. - -``README.rst`` - Basic description of the repository, you will leave it untouched. - -``pyproject.toml`` - Python project metadata that makes it installable. - Useful for automatic documentation generation from sources. - -``lumache.py`` - Source code of the fictional Python library. - -``docs/`` - Directory holding all the Sphinx documentation sources, - including the Sphinx configuration ``docs/source/conf.py`` - and the root document ``docs/source/index.rst`` written in reStructuredText. +In this tutorial you will learn how to host a public documentation project on Read the Docs Community. + +.. note:: + + Find out the `differences between Read the Docs Community and Read the Docs for Business `_. + +In the tutorial we will: + +1. Import a Sphinx project from a GitHub repository (no prior experience with Sphinx is required). +2. Tailor the project's configuration. +3. Explore other useful Read the Docs features. + +If you don't have a GitHub account, you'll need to `register for a free account `_ before you start. + +Preparing your repository on GitHub +----------------------------------- + +#. `Sign in to GitHub `_ and navigate to the `tutorial GitHub template `_. + +#. Click the green :guilabel:`Use this template` button, then click :guilabel:`Create a new Repository`. On the new page: + + Owner + Leave the default, or change it to something suitable for a tutorial project. + Repository name + Something memorable and appropriate, for example ``rtd-tutorial``. + Visibility + Make sure the project is "Public", rather than "Private". + +#. Click the green :guilabel:`Create repository` button to create a public repository that you will use in this Read the Docs tutorial, containing following files: + + ``.readthedocs.yaml`` + Read the Docs configuration file. Required. + + ``README.rst`` + Description of the repository. + + ``pyproject.toml`` + Python project metadata that makes it installable. + Useful for automatic documentation generation from sources. + + ``lumache.py`` + Source code of the fictional Python library. + + ``docs/`` + Directory holding all the fictional Python library documentation in reStructuredText, the Sphinx configuration ``docs/source/conf.py`` + and the root document ``docs/source/index.rst``. .. figure:: /_static/images/tutorial/github-template.png :width: 80% @@ -64,10 +55,10 @@ and it contains the following files: GitHub template for the tutorial -Sign up for Read the Docs -~~~~~~~~~~~~~~~~~~~~~~~~~ +Creating a Read the Docs account +-------------------------------- -To sign up for a Read the Docs account, +To create a Read the Docs account: navigate to the `Sign Up page `_ and choose the option :guilabel:`Sign up with GitHub`. On the authorization page, click the green :guilabel:`Authorize readthedocs` button. @@ -87,74 +78,49 @@ On the authorization page, click the green :guilabel:`Authorize readthedocs` but If you want to learn more, check out :ref:`guides/setup/git-repo-automatic:permissions for connected accounts`. -After that, you will be redirected to Read the Docs, -where you will need to confirm your e-mail and username. -Clicking the :guilabel:`Sign Up »` button will create your account -and redirect you to your :term:`dashboard`. - -By now, you should have two email notifications: +After that, you will be redirected to Read the Docs to confirm your e-mail and username. Click the :guilabel:`Sign Up »` button to create your account and +open your :term:`dashboard`. -* One from GitHub, telling you that "A third-party OAuth application ... - was recently authorized to access your account". You don't need to do - anything about it. -* Another one from Read the Docs, prompting you to "verify your email - address". Click on the link to finalize the process. - -Once done, your Read the Docs account is created -and ready to import your first project. - -Welcome! +When you have clicked the link in your emaill from Read the Docs to "verify your email address" and finalize the process, your Read the Docs account will be ready to create your first project. .. figure:: /_static/images/tutorial/rtd-empty-dashboard.png :width: 80% :align: center :alt: Read the Docs empty dashboard - Read the Docs empty dashboard + Welcome to your Read the Docs dashboard! -.. note:: +Importing the project to Read the Docs +-------------------------------------- - Our commercial site offers some extra features, - like support for private projects. - You can learn more about :doc:`our two different sites `. +To import your GitHub project to Read the Docs: -First steps ------------ +#. Click the :guilabel:`Import a Project` button on your `dashboard `_. -Importing the project to Read the Docs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +#. Click the |:heavy_plus_sign:| button to the right of your ``rtd-tutorial`` project. If the list of repositories is empty, click the |:arrows_counterclockwise:| button. -To import your GitHub project to Read the Docs, -first click on the :guilabel:`Import a Project` button on your dashboard -(or browse to `the import page `_ directly). -You should see your GitHub account under the "Filter repositories" list on the right. -If the list of repositories is empty, click the |:arrows_counterclockwise:| button, -and after that all your repositories will appear on the center. + .. figure:: /_static/images/tutorial/rtd-import-projects.gif + :width: 80% + :align: center + :alt: Import projects workflow -.. figure:: /_static/images/tutorial/rtd-import-projects.gif - :width: 80% - :align: center - :alt: Import projects workflow + Import projects workflow - Import projects workflow +#. Enter some details about your Read the Docs project: -Locate your ``rtd-tutorial`` project -(possibly clicking :guilabel:`next ››` at the bottom if you have several pages of projects), -and then click on the |:heavy_plus_sign:| button to the right of the name. -The next page will ask you to fill some details about your Read the Docs project: + Name + The name of the project, used to create a unique subdomain for each project. + so it is better if you prepend your username, + for example ``{username}-rtd-tutorial``. -Name - The name of the project. It has to be unique across all the service, - so it is better if you prepend your username, - for example ``{username}-rtd-tutorial``. + Repository URL + The URL that contains the documentation source. Leave the automatically filled value. -Repository URL - The URL that contains the sources. Leave the automatically filled value. + Default branch + Name of the default branch of the project, leave it as ``main``. -Default branch - Name of the default branch of the project, leave it as ``main``. + Then click the :guilabel:`Next` button to create the poject and open the :term:`project home`. -After hitting the :guilabel:`Next` button, you will be redirected to the :term:`project home`. You just created your first project on Read the Docs! |:tada:| .. figure:: /_static/images/tutorial/rtd-project-home.png @@ -165,30 +131,25 @@ You just created your first project on Read the Docs! |:tada:| Project home Checking the first build -~~~~~~~~~~~~~~~~~~~~~~~~ +------------------------ -Read the Docs will try to build the documentation of your project -right after you create it. -To see the build logs, -click on the :guilabel:`Your documentation is building` link on the :term:`project home`, -or alternatively navigate to the "Builds" page, -then open the one on top (the most recent one). +Read the Docs will build your project documentation right after you create it. -If the build has not finished yet by the time you open it, -you will see a spinner next to a "Installing" or "Building" indicator, -meaning that it is still in progress. +To see the build logs: -.. figure:: /_static/images/tutorial/rtd-first-successful-build.png - :width: 80% - :align: center - :alt: First successful documentation build +#. Click the :guilabel:`Your documentation is building` link on the :term:`project home`. + + - If the build has not finished by the time you open it, you will see a spinner next to a "Installing" or "Building" indicator, meaning that it is still in progress. + - If the build has finished, you'll see a green "Build completed" indicator, the completion date, the elapsed time, and a link to the generated documentation. - First successful documentation build + .. figure:: /_static/images/tutorial/rtd-first-successful-build.png + :width: 80% + :align: center + :alt: First successful documentation build -When the build finishes, you will see a green "Build completed" indicator, -the completion date, the elapsed time, -and a link to see the corresponding documentation. -If you now click on :guilabel:`View docs`, you will see your documentation live! + First successful documentation build + +#. Click on :guilabel:`View docs` to see your documentation live! .. figure:: /_static/images/tutorial/rtd-first-light.png :width: 80% @@ -209,111 +170,84 @@ If you now click on :guilabel:`View docs`, you will see your documentation live! and tries to be as unobstrusive as possible, so we would like to kindly ask you to :doc:`not block us ` |:heart:| -Basic configuration changes -~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Configuring the project +----------------------- + +To update the project description and configure the notification settings: -You can now proceed to make some basic configuration adjustments. -Navigate back to the :term:`project page` -and click on the :guilabel:`⚙ Admin` button, which will open the Settings page. +#. Navigate back to the :term:`project page` and click the :guilabel:`⚙ Admin` button,to open the Settings page. -First of all, add the following text in the description: +#. Update the project description by adding the following text: Lumache (/lu'make/) is a Python library for cooks and food lovers that creates recipes mixing random ingredients. -Then set the project homepage to ``https://world.openfoodfacts.org/``, -and write ``food, python`` in the list of tags. -All this information will be shown on your project home. +#. Set the project homepage to ``https://world.openfoodfacts.org/``, and add ``food, python`` to the list of public project tags. -After that, configure your email so you get a notification if the build fails. -To do so, click on the :guilabel:`Notifications` link on the left, -type the email where you would like to get the notification, -and click the :guilabel:`Add` button. -After that, your email will be shown under "Existing Notifications". +#. To get a notification if the build fails, click the :guilabel:`Email Notifications` link on the left, add your email address, and click the :guilabel:`Add` button. -Trigger a build from a pull request -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Triggering builds from pull requests +------------------------------------ -Read the Docs allows you to :doc:`trigger builds from GitHub pull requests ` -and gives you a preview of how the documentation would look like with those changes. +Read the Docs can :doc:`trigger builds from GitHub pull requests ` +and show you a preview of the documentation with those changes. -To enable that functionality, first click on the :guilabel:`Settings` link on the left -under the :guilabel:`⚙ Admin` menu, check the "Build pull requests for this project" checkbox, -and click the :guilabel:`Save` button at the bottom of the page. +To trigger builds from pull requests: -Next, navigate to your GitHub repository, locate the file ``docs/source/index.rst``, -and click on the |:pencil2:| icon on the top-right with the tooltip "Edit this file" -to open a web editor (more information `on their documentation`__). +#. Click the :guilabel:`Settings` link on the left under the :guilabel:`⚙ Admin` menu, check the "Build pull requests for this project" checkbox, and click the :guilabel:`Save` button at the bottom of the page. -__ https://docs.github.com/en/github/managing-files-in-a-repository/managing-files-on-github/editing-files-in-your-repository +#. Make some changes to your documentation: -.. figure:: /_static/images/tutorial/gh-edit.png - :width: 80% - :align: center - :alt: File view on GitHub before launching the editor + #. Navigate to your GitHub repository, locating the file ``docs/source/index.rst``, and clicking on the |:pencil2:| icon on the top-right with the tooltip "Edit this file" to open a web editor (more information `on their documentation`__). - File view on GitHub before launching the editor + __ https://docs.github.com/en/github/managing-files-in-a-repository/managing-files-on-github/editing-files-in-your-repository -In the editor, add the following sentence to the file: + .. figure:: /_static/images/tutorial/gh-edit.png + :width: 80% + :align: center + :alt: File view on GitHub before launching the editor -.. code-block:: rst - :caption: docs/source/index.rst + File view on GitHub before launching the editor - Lumache has its documentation hosted on Read the Docs. + #. In the editor, add the following sentence to the file: -Write an appropriate commit message, -and choose the "Create a **new branch** for this commit and start a pull request" option, -typing a name for the new branch. -When you are done, click the green :guilabel:`Propose changes` button, -which will take you to the new pull request page, -and there click the :guilabel:`Create pull request` button below the description. + .. code-block:: rst + :caption: docs/source/index.rst -.. figure:: /_static/images/tutorial/gh-pr-build.png - :width: 80% - :align: center - :alt: Read the Docs building the pull request from GitHub + Lumache hosts its documentation on Read the Docs. + + #. Write an appropriate commit message, choose the "Create a **new branch** for this commit and start a pull request" option. + + #. Click the green :guilabel:`Propose changes` button to open the new pull request page, then click the :guilabel:`Create pull request` button below the description. + + .. figure:: /_static/images/tutorial/gh-pr-build.png + :width: 80% + :align: center + :alt: Read the Docs building the pull request from GitHub - Read the Docs building the pull request from GitHub + Read the Docs building the pull request from GitHub After opening the pull request, a Read the Docs check will appear indicating that it is building the documentation for that pull request. -If you click on the :guilabel:`Details` link while it is building, -you will access the build logs, -otherwise it will take you directly to the documentation. -When you are satisfied, you can merge the pull request! +If you click the :guilabel:`Details` link while your project is building +the build log will be opened. After building this link opens the documentation directly. Adding a configuration file --------------------------- -The Admin tab of the :term:`project home` allows you -to change some *global* configuration values of your project. -In addition, you can further customize the building process -using the ``.readthedocs.yaml`` :doc:`configuration file `. -This has several advantages: +The Admin tab of the :term:`project home` has some *global* configuration settings for your project. -- The configuration lives next to your code and documentation, tracked by version control. -- It can be different for every version (more on versioning in the next section). -- Some configurations are only available using the config file. - -This configuration file should be part of your Git repository. -It should be located in the base folder of the repository and be named ``.readthedocs.yaml``. +Build process configuration settings are in ``.readthedocs.yaml`` :doc:`configuration file `, in your Git repository, which means it can be different for every version or branch of your project (more on `versioning <#versioning-documentation>`_). .. TODO: We are adding a how-to that we need to include in this tutorial. .. Maybe by reference or maybe as full-featured content. -In this section, we will show you some examples of what a configuration file should contain. - -.. tip:: +.. TODO there is a bit of handwaving about whether you're commiting and merging branches here, we might need to be a bit more explicit. Or at least add a mention at this level that wherever we talk about editing, we mean on main and pushing to GH. - Settings that apply to the entire project are controlled in the web dashboard, - while settings that are version or build specific are better in the YAML file. +Using different Python versions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Changing the Python version -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -For example, to explicitly use Python 3.8 to build your project, -navigate to your GitHub repository, click on ``.readthedocs.yaml`` file and then in the pencil icon ✏️ to edit the file -and change the Python version as follows: +To build your project with Python 3.8 instead of the latest Python version, edit the ``.readthedocs.yaml`` file and change the Python version to 3.8 like this: .. code-block:: yaml :caption: .readthedocs.yaml @@ -333,26 +267,26 @@ and change the Python version as follows: sphinx: configuration: docs/source/conf.py -The purpose of each key is: +The :doc:`purpose of each key ` in the ``.readthedocs.yaml`` configuration file is: ``version`` - Mandatory, specifies :doc:`version 2 of the configuration file `. + Required, specifies :doc:`version 2 of the configuration file `. ``build.os`` - Required to specify the Python version, + Required, specifies the Docker image used to build the documentation. :ref:`states the name of the base image `. ``build.tools.python`` - Declares the Python version to be used. + Specifies the :ref:`Python version `. ``python.install.requirements`` - Specifies the Python dependencies to install required to build the documentation. + Specifies what :ref:`Python dependencies ` to install. After you commit these changes, go back to your project home, navigate to the "Builds" page, and open the new build that just started. You will notice that one of the lines contains ``python -mvirtualenv``: if you click on it, you will see the full output of the corresponding command, -stating that it used Python 3.8.6 to create the virtual environment. +stating that it used Python 3.8.6, the latest version of Python 3.8, to create the virtual environment. .. figure:: /_static/images/tutorial/build-python3.8.png :width: 80% @@ -361,8 +295,8 @@ stating that it used Python 3.8.6 to create the virtual environment. Read the Docs build using Python 3.8 -Making warnings more visible -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Making build warnings more visible +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you navigate to your HTML documentation, you will notice that the index page looks correct @@ -383,10 +317,10 @@ and you will see several warnings: WARNING: autodoc: failed to import exception 'InvalidKindError' from module 'lumache'; the following exception was raised: No module named 'lumache' -To spot these warnings more easily and allow you to address them, -you can add the ``sphinx.fail_on_warning`` option to your Read the Docs configuration file. -For that, navigate to GitHub, locate the ``.readthedocs.yaml`` file you created earlier, -click on the |:pencil2:| icon, and add these contents: +To spot these warnings more easily and help you to address them, + add the ``sphinx.fail_on_warning`` option to your Read the Docs configuration file. + +To fail on warnings to your Read the Docs project, edit the ``.readthedocs.yaml`` file in your project, add the three lines of ``sphinx`` configuration below, and commit the file: .. code-block:: yaml :caption: .readthedocs.yaml @@ -407,18 +341,19 @@ click on the |:pencil2:| icon, and add these contents: configuration: docs/source/conf.py fail_on_warning: true -At this point, if you navigate back to your "Builds" page, -you will see a ``Failed`` build, which is exactly the intended result: -the Sphinx project is not properly configured yet, -and instead of rendering an empty API page, now the build fails. +If you navigate to your "Builds" page, you will see a ``Failed`` build, which is expected because we've configured Sphinx to fail on warnings and several warnings were encountered during the build. + +To learn how to fix these warnings, see the next section. + +Installing Python dependencies +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The reason :py:mod:`sphinx:sphinx.ext.autosummary` and :py:mod:`sphinx:sphinx.ext.autodoc` fail to import the :ref:`tutorial/index:making build warnings more visible`, is because the ``lumache`` module is not installed. -The reason :py:mod:`sphinx:sphinx.ext.autosummary` and :py:mod:`sphinx:sphinx.ext.autodoc` -fail to import the code is because it is not installed. -Luckily, the ``.readthedocs.yaml`` also allows you to specify -which requirements to install. +You will need to specify those installation requirements in ``.readthedocs.yaml``. -To install the library code of your project, -go back to editing ``.readthedocs.yaml`` on GitHub and modify it as follows: +To install your project dependencies and make your code available to Sphinx, +edit ``.readthedocs.yaml``, add the ``python.install`` section and commit it: .. code-block:: yaml :caption: .readthedocs.yaml @@ -431,10 +366,10 @@ go back to editing ``.readthedocs.yaml`` on GitHub and modify it as follows: - method: pip path: . -With this change, Read the Docs will install the Python code +Now, Read the Docs installs the Python code before starting the Sphinx build, which will finish seamlessly. If you go now to the API page of your HTML documentation, -you will see the ``lumache`` summary! +you will see the ``lumache`` summary! :tada: Enabling PDF and EPUB builds ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -443,7 +378,7 @@ Sphinx can build several other formats in addition to HTML, such as PDF and EPUB You might want to enable these formats for your project so your users can read the documentation offline. -To do so, add this extra content to your ``.readthedocs.yaml``: +To do so, add the following ``formats`` to your ``.readthedocs.yaml``: .. code-block:: yaml :caption: .readthedocs.yaml @@ -470,29 +405,29 @@ as well as the :term:`flyout menu`. Versioning documentation ------------------------ -Read the Docs allows you to have :doc:`several versions of your documentation `, +Read the Docs supports having :doc:`several versions of your documentation `, in the same way that you have several versions of your code. By default, it creates a ``latest`` version that points to the default branch of your version control system (``main`` in the case of this tutorial), and that's why the URLs of your HTML documentation contain the string ``/latest/``. -Creating a new version -~~~~~~~~~~~~~~~~~~~~~~ +Creating a new version of your documentation +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Let's say you want to create a ``1.0`` version of your code, -with a corresponding ``1.0`` version of the documentation. -For that, first navigate to your GitHub repository, click on the branch selector, -type ``1.0.x``, and click on "Create branch: 1.0.x from 'main'" -(more information `on their documentation`__). +Read the Docs automatically creates documentation versions from GitHub branches and tags that :ref:`follows some rules ` about looking like version numbers, such as ``1.0``, ``2.0.3`` or ``4.x``. -__ https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository +To create version ``1.0`` of your code, and consequently of your documentation: + +#. Navigate to your GitHub repository, click the branch selector, type ``1.0.x``, and click "Create branch: 1.0.x from 'main'" (more information `in the GitHub documentation`__). + +#. Check that you now have version ``1.0.x`` in your :term:`project home`, click on the :guilabel:`Versions` button, and under "Active Versions" you will see two entries: -Next, go to your :term:`project home`, click on the :guilabel:`Versions` button, -and under "Active Versions" you will see two entries: + - The ``latest`` version, pointing to the ``main`` branch. + - A new ``stable`` version, pointing to the ``origin/1.0.x`` branch. + +__ https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository -- The ``latest`` version, pointing to the ``main`` branch. -- A new ``stable`` version, pointing to the ``origin/1.0.x`` branch. .. figure:: /_static/images/tutorial/active-versions.png :width: 80% @@ -501,30 +436,18 @@ and under "Active Versions" you will see two entries: List of active versions of the project -Right after you created your branch, -Read the Docs created a new special version called ``stable`` pointing to it, -and started building it. When the build finishes, -the ``stable`` version will be listed in the :term:`flyout menu` -and your readers will be able to choose it. +When you created your branch, +Read the Docs created a new special version called ``stable`` pointing to it. When it's built it will be listed in the :term:`flyout menu`. -.. note:: - - Read the Docs :ref:`follows some rules ` - to decide whether to create a ``stable`` version pointing to your new branch or tag. - To simplify, it will check if the name resembles a version number - like ``1.0``, ``2.0.3`` or ``4.x``. +Setting stable as the default +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Now you might want to set ``stable`` as the *default version*, +To set ``stable`` as the *default version*, rather than ``latest``, so that users see the ``stable`` documentation -when they visit the :term:`root URL` of your documentation -(while still being able to change the version in the flyout menu). +when they visit the :term:`root URL` of your documentation: -For that, go to the :guilabel:`Settings` link -under the :guilabel:`⚙ Admin` menu of your project home, -choose ``stable`` in the "Default version*" dropdown, -and hit :guilabel:`Save` at the bottom. -Done! +#. In the the :guilabel:`⚙ Admin` menu of your project home, go to the :guilabel:`Settings` link, choose ``stable`` in the "Default version*" dropdown, and hit :guilabel:`Save` at the bottom. Modifying versions ~~~~~~~~~~~~~~~~~~ @@ -541,20 +464,15 @@ version, which will always point to the ``1.0.x`` branch of your repository. List of inactive versions of the project -Let's activate the ``1.0.x`` version. -For that, go to the "Versions" on your :term:`project home`, -locate ``1.0.x`` under "Activate a version", -and click on the :guilabel:`Activate` button. -This will take you to a new page with two checkboxes, -"Active" and "Hidden". Check only "Active", -and click :guilabel:`Save`. +To activate the ``1.0.x`` version: -After you do this, ``1.0.x`` will appear on the "Active Versions" section, -and a new build will be triggered for it. +#. On your :term:`project home`, go to the "Versions", locate ``1.0.x`` under "Activate a version", and click the :guilabel:`Activate` button. + +#. On the "Activate" page with "Active" and "Hidden" checkboxes, check only "Active" and click :guilabel:`Save`. .. note:: - You can read more about :ref:`hidden versions ` + Read more about :ref:`hidden versions ` in our documentation. .. "Show a warning for old versions" feature is not available anymore. @@ -592,32 +510,31 @@ and a new build will be triggered for it. Warning for old versions -Getting insights from your projects ------------------------------------ +Getting project insights +------------------------ Once your project is up and running, you will probably want to understand how readers are using your documentation, addressing some common questions like: -- what pages are the most visited pages? -- what search terms are the most frequently used? -- are readers finding what they look for? +- what are the most visited pages? +- what are the most frequently used search terms? +- are readers finding what they are looking for? + +Read the Docs has traffic and search analytics tools to help you find answers to these questions. -Read the Docs offers you some analytics tools to find out the answers. +Understanding traffic analytics +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Browsing traffic analytics -~~~~~~~~~~~~~~~~~~~~~~~~~~ +The Traffic Analytics view gives you a simple overview of how your readers browse your documentation. It respects visitor privacy by not storing identifying information about your them. The :doc:`/analytics` view shows the top viewed documentation pages of the past 30 days, plus a visualization of the daily views during that period. -To generate some artificial views on your newly created project, -you can first click around the different pages of your project, -which will be accounted immediately for the current day statistics. To see the Traffic Analytics view, go back the :term:`project page` again, -click on the :guilabel:`⚙ Admin` button, -and then click on the :guilabel:`Traffic Analytics` section. +click the :guilabel:`⚙ Admin` button, +and then click the :guilabel:`Traffic Analytics` section. You will see the list of pages in descending order of visits, -as well as a plot similar to the one below. +and a similar visualization to this one: .. figure:: /_static/images/tutorial/traffic-analytics-plot.png :width: 80% @@ -626,32 +543,24 @@ as well as a plot similar to the one below. Traffic Analytics plot +You can also download this data in :abbr:`CSV (Comma-Separated Values)` format for closer inspection. +To do that, scroll to the bottom of the page +and click the :guilabel:`Download all data` button. + .. note:: - The Traffic Analytics view explained above gives you a simple overview - of how your readers browse your documentation. It has the advantage that - it stores no identifying information about your visitors, - and therefore it respects their privacy. - However, you might want to get more detailed data by + You can get more detailed traffic data by :ref:`enabling Google Analytics `. - Notice though that we take some extra measures to :ref:`respect user + Notice though that Read the Docs takes extra measures to :ref:`respect user privacy ` when they visit projects that have Google Analytics enabled, - and this might reduce the number of visits counted. + which might reduce the number of visits counted. -Finally, you can also download this data for closer inspection. -To do that, scroll to the bottom of the page -and click on the :guilabel:`Download all data` button. -That will prompt you to download a :abbr:`CSV (Comma-Separated Values)` file -that you can process any way you want. - -Browsing search analytics -~~~~~~~~~~~~~~~~~~~~~~~~~ +Understanding search analytics +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Apart from traffic analytics, Read the Docs also offers the possibility -to inspect :doc:`what search terms your readers use ` -on your documentation. -This can inform decisions on what areas to reinforce, +As well as traffic analytics, Read the Docs shows :doc:`what terms your readers are searching for `. +This can inform decisions on what areas to focus on, or what parts of your project are less understood or more difficult to find. To generate some artificial search statistics on the project, @@ -660,7 +569,7 @@ type ``ingredients``, and press the :kbd:`Enter` key. You will be redirected to the search results page, which will show two entries. Next, go back to the :guilabel:`⚙ Admin` section of your project page, -and then click on the :guilabel:`Search Analytics` section. +and then click the :guilabel:`Search Analytics` section. You will see a table with the most searched queries (including the ``ingredients`` one you just typed), how many results did each query return, and how many times it was searched. @@ -680,30 +589,28 @@ by clicking on the :guilabel:`Download all data` button. Where to go from here --------------------- -This is the end of the tutorial. You started by forking a GitHub repository -and importing it on Read the Docs, building its HTML documentation, -and then went through a series of steps to customize the build process, -tweak the project configuration, and add new versions. +This is the end of the tutorial. You have accomplished a lot: + +#. Forked a GitHub repository. +#. Connected it to Read the Docs. +#. Built its HTML documentation. +#. Customized the build process. +#. Added new documentation versions. +#. Browsed the project analytics. + +Nice work! -Here you have some resources to continue learning about documentation +Here are some resources to help you continue learning about documentation and Read the Docs: -- You can learn more about the functionality of the platform - by going over our :doc:`features ` page. -- To make the most of the documentation generators that are supported, - you can read the :doc:`Sphinx tutorial ` - or the `MkDocs User Guide `_. -- Display example projects and read the source code in :doc:`/examples`. -- Whether you are a documentation author, a project administrator, a developer, or a designer, - you can follow our how-to guides that cover specific tasks, - available under :doc:`/guides/index`. -- For private project support and other enterprise features, - you can use :doc:`our commercial service ` - (and if in doubt, check out :doc:`/choosing-a-site`). -- Do you want to join a global community of fellow `documentarians `? - Check out `Write the Docs `_ and +- Learn more about the platform :doc:`features `. +- Learn about other supported documentation generators in the :doc:`Sphinx tutorial ` or the `MkDocs User Guide `_. +- See a list of Read the Docs :doc:`/examples`. +- Learn how to do specific tasks in the :doc:`/guides/index`. +- Learn about private project support and other enterprise features + in :doc:`our commercial service ` and :doc:`/choosing-a-site` guide. +- Join a global community of fellow `documentarians ` in `Write the Docs `_ and :doc:`its Slack workspace `. -- Do you want to contribute to Read the Docs? - We greatly appreciate it! Check out :doc:`rtd-dev:contribute`. +- Contribute to Read the Docs in :doc:`rtd-dev:contribute`, we appreciate it! Happy documenting!