fixed linter warnings

developer/general/gsod.rst

@@ -57,8 +57,8 @@ Timeline
 ^^^^^^^^
 
 
-.. list-table:: 
-   :widths: 15 15 
+.. list-table::
+   :widths: 15 15
    :align: center
    :header-rows: 1
 
@@ -70,15 +70,14 @@ Timeline
      - Update & extend how-to guides
    * - December
      - Final project evaluation and case study
-   
 
 
 Project budget
 ^^^^^^^^^^^^^^
 
 
-.. list-table:: 
-   :widths: 32 32 
+.. list-table::
+   :widths: 32 32
    :align: center
    :header-rows: 1
 
@@ -88,7 +87,6 @@ Project budget
      - $12,000
    * - TOTAL
      - $12,000
-   
 
 
 Additional information

developer/general/how-to-edit-the-rst-documentation.rst

@@ -22,7 +22,7 @@ be downloaded from `doc.qubes-os.org <https://doc.qubes-os.org/en/latest/>`__:
 |epub-pdf|
 
 ..
-  TODO screenshots with main branch instead of rst when rst merged in main 
+  TODO screenshots with main branch instead of rst when rst merged in main
   TODO add draft pull request screenshot
 
 The documentation is a volunteer community effort. People like you are
@@ -74,8 +74,7 @@ button to edit the file (if you are already logged in in).
 
 If you are not logged in you can click on :guilabel:`Sign In`
 and you’ll be prompted to sign in with your GitHub username and password.
-You can also create a free account from
-here.
+You can also create a free account from here.
 
 |github-sign-in|
 
@@ -174,7 +173,7 @@ Tips & Tricks
 
    $ git merge upstream/main
 
-Keep your pull requests limited to a single issue, pull requests should be as atomic as possible. 
+Keep your pull requests limited to a single issue, pull requests should be as atomic as possible.
 
 .. _edit_doc_index:
 

developer/general/how-to-edit-the-website.rst

@@ -123,8 +123,8 @@ The main `qubesos.github.io <https://github.com/QubesOS/qubesos.github.io>`__ co
   └── pages         # ← Stand‑alone pages (donate, team, about, etc.)
     └── *.md/.html  # each file becomes a page at /<filename>/
 
-How to edit the website
------------------------
+Cheatsheet
+----------
 
 .. list-table::
    :header-rows: 1
@@ -139,7 +139,7 @@ How to edit the website
      - Update the key/value pair, then rebuild.
    * - Modify the look of all pages
      - ``_layouts/*.html`` and/or ``_sass/*.scss``
-     - Edit the HTML skeleton or SASS variables, then run ``jekyll serve`` to preview.
+     - Edit the HTML skeleton or SASS variables, then run preview.
    * - Insert a reusable component (e.g., a call‑out box)
      - ``_includes/*.html``
      - Create the snippet, then reference it with ``{% include snippet.html %}`` in any page or post.

developer/general/research.rst

@@ -8,7 +8,7 @@ posts related to Qubes OS.
 Secure Software Development
 ===========================
 
-- `Security challenges for the Qubes build process <https://blog.invisiblethings.org/2016/05/30/build-security.html>`__ by Joanna Rutkowska, May 2016 
+- `Security challenges for the Qubes build process <https://blog.invisiblethings.org/2016/05/30/build-security.html>`__ by Joanna Rutkowska, May 2016
 
 
 Towards Trusted Hardware

developer/general/rst-documentation-style-guide.rst

@@ -574,7 +574,7 @@ Core documentation resides in the `Qubes OS Project’s official repositories <h
 
 The main difference between **core** (or **official**) and **external** (or **community** or **unofficial**) documentation is whether it documents software that is officially written and maintained by the Qubes OS Project. The purpose of this distinction is to keep the core docs maintainable and high-quality by limiting them to the software output by the Qubes OS Project. In other words, we take responsibility for documenting all of the software we put out into the world, but it doesn’t make sense for us to take on the responsibility of documenting or maintaining documentation for anything else. For example, Qubes OS may use a popular Linux distribution for an official :doc:`TemplateVM </user/templates/templates>`. However, it would not make sense for a comparatively small project like ours, with modest funding and a lean workforce, to attempt to document software belonging to a large, richly-funded project with an army of paid and volunteer contributors, especially when they probably already have documentation of their own. This is particularly true when it comes to Linux in general. Although many users who are new to Qubes are also new to Linux, it makes absolutely no sense for our comparatively tiny project to try to document Linux in general when there is already a plethora of documentation out there.
 
-Many contributors do not realize that there is a significant amount of work involved in *maintaining* documentation after it has been written. They may wish to write documentation and submit it to the core docs, but they see only their own writing process and fail to consider that it will have to be kept up-to-date and consistent with the rest of the docs for years afterward. Submissions to the core docs also have to :ref:`undergo a review process <developer/general/how-to-edit-the-rst-documentation:security>`__ to ensure accuracy before being merged, which takes up valuable time from the team. We aim to maintain high quality standards for the core docs (style and mechanics, formatting), which also takes up a lot of time. If the documentation involves anything external to the Qubes OS Project (such as a website, platform, program, protocol, framework, practice, or even a reference to a version number), the documentation is likely to become outdated when that external thing changes. It’s also important to periodically review and update this documentation, especially when a new Qubes release comes out. Periodically, there may be technical or policy changes that affect all the core documentation. The more documentation there is relative to maintainers, the harder all of this will be. Since there are many more people who are willing to write documentation than to maintain it, these individually small incremental additions amount to a significant maintenance burden for the project.
+Many contributors do not realize that there is a significant amount of work involved in *maintaining* documentation after it has been written. They may wish to write documentation and submit it to the core docs, but they see only their own writing process and fail to consider that it will have to be kept up-to-date and consistent with the rest of the docs for years afterward. Submissions to the core docs also have to :ref:`undergo a review process <developer/general/how-to-edit-the-rst-documentation:security>` to ensure accuracy before being merged, which takes up valuable time from the team. We aim to maintain high quality standards for the core docs (style and mechanics, formatting), which also takes up a lot of time. If the documentation involves anything external to the Qubes OS Project (such as a website, platform, program, protocol, framework, practice, or even a reference to a version number), the documentation is likely to become outdated when that external thing changes. It’s also important to periodically review and update this documentation, especially when a new Qubes release comes out. Periodically, there may be technical or policy changes that affect all the core documentation. The more documentation there is relative to maintainers, the harder all of this will be. Since there are many more people who are willing to write documentation than to maintain it, these individually small incremental additions amount to a significant maintenance burden for the project.
 
 On the positive side, we consider the existence of community documentation to be a sign of a healthy ecosystem, and this is quite common in the software world. The community is better positioned to write and maintain documentation that applies, combines, and simplifies the official documentation, e.g., tutorials that explain how to install and use various programs in Qubes, how to create custom VM setups, and introductory tutorials that teach basic Linux concepts and commands in the context of Qubes. In addition, just because the Qubes OS Project has officially written and maintains some flexible framework, such as ``qrexec``, it does not make sense to include every tutorial that says “here’s how to do something cool with ``qrexec`` in the core docs. Such tutorials generally also belong in the community documentation.