` in Qubes code.)
+
+
+
+
diff --git a/developer/general/developing-gui-applications.md b/developer/general/developing-gui-applications.md
deleted file mode 100644
index 19e60a1c..00000000
--- a/developer/general/developing-gui-applications.md
+++ /dev/null
@@ -1,102 +0,0 @@
----
-lang: en
-layout: doc
-permalink: /doc/developing-gui-applications/
-ref: 333
-title: Developing Qubes OS GUI tools
----
-
-In order to avoid installing Qubes OS frontend tools you are working on in your own `dom0` or just to test them with less problems, you can use the mock Qubes object from the `qubesadmin` package.
-
-## Running programs using mock Qubes object
-
-Where you would normally provide the Qubes object, use the `qubesadmin.tests.mock_app` package and one of the mock Qubes objects from it.
-
-For example, the following code can be used to run the `qui-domains` tool using the mock Qubes object (this code would replace the initial part of the main function):
-
-```python
-def main():
- ''' main function '''
- # qapp = qubesadmin.Qubes()
- # dispatcher = qubesadmin.events.EventsDispatcher(qapp)
- # stats_dispatcher = qubesadmin.events.EventsDispatcher(qapp, api_method='admin.vm.Stats')
-
- import qubesadmin.tests.mock_app as mock_app
- qapp = mock_app.MockQubesComplete()
- dispatcher = mock_app.MockDispatcher(qapp)
- stats_dispatcher = mock_app.MockDispatcher(
- qapp, api_method='admin.vm.Stats')
-
- # continue as normal
-```
-
-To run a mocked program without installing it in a qube, remember to extend PYTHONPATH appropriately, for example:
-
-```bash
-~/qubes-sources/manager $ PYTHONPATH=../core-admin-client:. python3 qui/tray/domains.py
-```
-
-The mock object does not provide events (yet).
-
-Note: in order to see all qubes-relevant icons (like VM icons), install the `qubes-artwork` package.
-
-## How does it actually work
-
-The mock Qubes object has a collection of expected Qubes RPC calls and the responses that a real system would provide. Writing these calls manually is a bit tedious, given that most frontend tools query a lot of qube properties. For example, on a medium-sized system, initializing Qube Manager involves about 300 separate RPC calls.
-
-If you need more calls, you can add them to the mock object using the following syntax (the following example adds listing available vm kernels):
-
-```python
- mock_app.expected_calls[('dom0', 'admin.pool.volume.List', 'linux-kernel', None)] = \
- b'0\x006.1.57-1.fc37\n6.1.43-1.fc37\ncustom_kernel\n'
-
-```
-
-If error should be thrown, you need to provide the error code and name, for example:
-
-```python
- mock_app.expected_calls[("vmname", "admin.vm.property.Get", "property_name", None)] = \
- b'2\x00QubesNoSuchPropertyError\x00\x00No such property\x00'
-```
-
-For details of particular calls, you can use [Extending the mock Qubes object](#extending-the-mock-qubes-object).
-
-
-## Available mocks
-
-Three mocks are available in the `mock_app` file:
-
-* MockQubes, an extremely bare-bones Qubes testing instance, with just dom0, sys-net, and one template (fedora-36).
-* MockQubesComplete, a more complex setup [](/attachment/doc/doc-mock-app-ex1.png)
-* MockQubesWhonix, the setup above extended with several Whonix-related qubes
-
-
-## Extending the mock Qubes object
-
-To collect information to modify this script, you can use the wrapper function to wrap and output all qubesd calls used by a program running on a live qubes instance.
-
-```python
- qapp = qubesadmin.Qubes()
- import qubesadmin.tests.mock_app as mock_app
- qapp.qubesd_call = mock_app.wrapper(qapp.qubesd_call)
- qapp._parse_qubesd_response = mock_app.wrapper(qapp._parse_qubesd_response)
-```
-
-## Writing tests
-
-The same mock Qubes can also be used to write tests. You can use the wrappers above to check which calls are made when certain actions are performed, and add them to the mock objects in the following way:
-
-```python
-# this is an excerpt from tests for Qubes Global Config tool
- clockvm_combo.set_active_id('test-blue')
-
- mock_qapp.expected_calls[('dom0', 'admin.property.Set',
- 'clockvm', b'test-blue')] = b'0\x00'
- basics_handler.save()
-
-```
-
-If the call is made correctly, the test will continue successfully; if an unexpected call is made, the test will fail.
-
-Caution: the mock Qubes object does not react to changes like a normal Qubes object does. Further queries to the test object will continue to return initial values.
-
diff --git a/developer/general/developing-gui-applications.rst b/developer/general/developing-gui-applications.rst
new file mode 100644
index 00000000..81a7e256
--- /dev/null
+++ b/developer/general/developing-gui-applications.rst
@@ -0,0 +1,117 @@
+=============================
+Developing Qubes OS GUI tools
+=============================
+
+
+In order to avoid installing Qubes OS frontend tools you are working on in your own ``dom0`` or just to test them with less problems, you can use the mock Qubes object from the ``qubesadmin`` package.
+
+Running programs using mock Qubes object
+----------------------------------------
+
+
+Where you would normally provide the Qubes object, use the ``qubesadmin.tests.mock_app`` package and one of the mock Qubes objects from it.
+
+For example, the following code can be used to run the ``qui-domains`` tool using the mock Qubes object (this code would replace the initial part of the main function):
+
+.. code:: python
+
+ def main():
+ ''' main function '''
+ # qapp = qubesadmin.Qubes()
+ # dispatcher = qubesadmin.events.EventsDispatcher(qapp)
+ # stats_dispatcher = qubesadmin.events.EventsDispatcher(qapp, api_method='admin.vm.Stats')
+
+ import qubesadmin.tests.mock_app as mock_app
+ qapp = mock_app.MockQubesComplete()
+ dispatcher = mock_app.MockDispatcher(qapp)
+ stats_dispatcher = mock_app.MockDispatcher(
+ qapp, api_method='admin.vm.Stats')
+
+ # continue as normal
+
+
+To run a mocked program without installing it in a qube, remember to extend PYTHONPATH appropriately, for example:
+
+.. code:: bash
+
+ ~/qubes-sources/manager $ PYTHONPATH=../core-admin-client:. python3 qui/tray/domains.py
+
+
+The mock object does not provide events (yet).
+
+**Note:** in order to see all qubes-relevant icons (like VM icons), install the ``qubes-artwork`` package.
+
+How does it actually work
+-------------------------
+
+
+The mock Qubes object has a collection of expected Qubes RPC calls and the responses that a real system would provide. Writing these calls manually is a bit tedious, given that most frontend tools query a lot of qube properties. For example, on a medium-sized system, initializing Qube Manager involves about 300 separate RPC calls.
+
+If you need more calls, you can add them to the mock object using the following syntax (the following example adds listing available vm kernels):
+
+.. code:: python
+
+ mock_app.expected_calls[('dom0', 'admin.pool.volume.List', 'linux-kernel', None)] = \
+ b'0\x006.1.57-1.fc37\n6.1.43-1.fc37\ncustom_kernel\n'
+
+
+If error should be thrown, you need to provide the error code and name, for example:
+
+.. code:: python
+
+ mock_app.expected_calls[("vmname", "admin.vm.property.Get", "property_name", None)] = \
+ b'2\x00QubesNoSuchPropertyError\x00\x00No such property\x00'
+
+
+For details of particular calls, you can use `Extending the mock Qubes object <#extending-the-mock-qubes-object>`__.
+
+Available mocks
+---------------
+
+
+Three mocks are available in the ``mock_app`` file:
+
+- MockQubes, an extremely bare-bones Qubes testing instance, with just dom0, sys-net, and one template (fedora-36).
+
+- MockQubesComplete, a more complex setup |Qubes Manager running MockQubesComplete|
+
+- MockQubesWhonix, the setup above extended with several Whonix-related qubes
+
+
+
+Extending the mock Qubes object
+-------------------------------
+
+
+To collect information to modify this script, you can use the wrapper function to wrap and output all qubesd calls used by a program running on a live qubes instance.
+
+.. code:: python
+
+ qapp = qubesadmin.Qubes()
+ import qubesadmin.tests.mock_app as mock_app
+ qapp.qubesd_call = mock_app.wrapper(qapp.qubesd_call)
+ qapp._parse_qubesd_response = mock_app.wrapper(qapp._parse_qubesd_response)
+
+
+Writing tests
+-------------
+
+
+The same mock Qubes can also be used to write tests. You can use the wrappers above to check which calls are made when certain actions are performed, and add them to the mock objects in the following way:
+
+.. code:: python
+
+ # this is an excerpt from tests for Qubes Global Config tool
+ clockvm_combo.set_active_id('test-blue')
+
+ mock_qapp.expected_calls[('dom0', 'admin.property.Set',
+ 'clockvm', b'test-blue')] = b'0\x00'
+ basics_handler.save()
+
+
+If the call is made correctly, the test will continue successfully; if an unexpected call is made, the test will fail.
+
+Caution: the mock Qubes object does not react to changes like a normal Qubes object does. Further queries to the test object will continue to return initial values.
+
+.. |Qubes Manager running MockQubesComplete| image:: /attachment/doc/doc-mock-app-ex1.png
+
diff --git a/developer/general/documentation-style-guide.md b/developer/general/documentation-style-guide.md
deleted file mode 100644
index 79146d96..00000000
--- a/developer/general/documentation-style-guide.md
+++ /dev/null
@@ -1,355 +0,0 @@
----
-lang: en
-layout: doc
-permalink: /doc/documentation-style-guide/
-redirect_from:
-- /doc/doc-guidelines/
-- /en/doc/doc-guidelines/
-- /wiki/DocStyle/
-- /doc/DocStyle/
-ref: 30
-title: Documentation style guide
----
-
-_Also see [how to edit the documentation](/doc/how-to-edit-the-documentation/)._
-
-Qubes OS documentation pages are stored as plain text Markdown files in the [qubes-doc](https://github.com/QubesOS/qubes-doc) repository. By cloning and regularly pulling from this repo, users can maintain their own up-to-date offline copy of all Qubes documentation rather than relying solely on the web.
-
-The documentation is a volunteer community effort. People like you are constantly working to make it better. If you notice something that can be fixed or improved, please [edit the documentation](/doc/how-to-edit-the-documentation/)!
-
-This page explains the standards we follow for writing, formatting, and organizing the documentation. Please follow these guidelines and conventions when editing the documentation. For the standards governing the website as a whole, please see the [website style guide](/doc/website-style-guide).
-
-## Markdown conventions
-
-All the documentation is written in Markdown for maximum accessibility. When making contributions, please observe the following style conventions. If you're not familiar with Markdown syntax, [this](https://daringfireball.net/projects/markdown/) is a great resource.
-
-### Hyperlink syntax
-
-Use non-reference-style links like `[website](https://example.com/)`. Do *not* use reference-style links like `[website][example]`, `[website][]` or `[website]`. This facilitates the localization process.
-
-### Relative vs. absolute links
-
-Always use relative rather than absolute paths for internal website links. For example, use `/doc/documentation-style-guide/` instead of `https://www.qubes-os.org/doc/documentation-style-guide/`.
-
-You may use absolute URLs in the following cases:
-
-- External links
-- URLs that appear inside code blocks (e.g., in comments and document templates, and the plain text reproductions of [QSBs](/security/qsb/) and [Canaries](/security/canary/)), since they're not hyperlinks
-- Git repo files like `README.md` and `CONTRIBUTING.md`, since they're not part of the website itself but rather of the auxiliary infrastructure supporting the website
-
-This rule is important because using absolute URLs for internal website links breaks:
-
-- Serving the website offline
-- Website localization
-- Generating offline documentation
-- Automatically redirecting Tor Browser visitors to the correct page on the onion service mirror
-
-### Image linking
-
-See [how to add images](/doc/how-to-edit-the-documentation/#how-to-add-images) for the required syntax. This will make the image a hyperlink to the image file, allowing the reader to click on the image in order to view the full image by itself. This is important. Following best practices, our website has a responsive design, which allows the website to render appropriately across all screen sizes. When viewing this page on a smaller screen, such as on a mobile device, the image will automatically shrink down to fit the screen. If visitors cannot click on the image to view it in full size, then, depending on their device, they may have no way see the details in the image clearly.
-
-In addition, make sure to link only to images in the [qubes-attachment](https://github.com/QubesOS/qubes-attachment) repository. Do not attempt to link to images hosted on other websites.
-
-### HTML and CSS
-
-Do not write HTML inside Markdown documents (except in rare, unavoidable cases, such as [alerts](#alerts)). In particular, never include HTML or CSS for styling, formatting, or white space control. That belongs in the (S)CSS files instead.
-
-### Headings
-
-Do not use `h1` headings (single `#` or `======` underline). These are automatically generated from the `title:` line in the YAML front matter.
-
-Use Atx-style syntax for headings: `##h2`, `### h3`, etc. Do not use underlining syntax (`-----`).
-
-### Indentation
-
-Use spaces instead of tabs. Use hanging indentations where appropriate.
-
-### Lists
-
-If appropriate, make numerals in numbered lists match between Markdown source and HTML output. Some users read the Markdown source directly, and this makes numbered lists easier to follow.
-
-### Code blocks
-
-When writing code blocks, use [syntax highlighting](https://github.github.com/gfm/#info-string) where possible (see [here](https://github.com/jneen/rouge/wiki/List-of-supported-languages-and-lexers) for a list of supported languages). Use `[...]` for anything omitted.
-
-### Line wrapping
-
-Do not hard wrap text, except where necessary (e.g., inside code blocks).
-
-### Do not use Markdown syntax for styling
-
-For example, there is a common temptation to use block quotations (created by beginning lines with the `>` character) in order to stylistically distinguish some portion of text from the rest of the document, e.g.:
-
-```
-> Note: This is an important note!
-```
-
-This renders as:
-
-> Note: This is an important note!
-
-There are two problems with this:
-
-1. It is a violation of the [separation of content and presentation](https://en.wikipedia.org/wiki/Separation_of_content_and_presentation), since it abuses markup syntax in order to achieve unintended stylistic results. The Markdown (and HTML, if any) should embody the *content* of the documentation, while the *presentation* is handled by (S)CSS.
-
-2. It is an abuse of quotation syntax for text that is not actually a quotation. (You are not quoting anyone here. You're just telling the reader to note something and trying to draw their attention to your note visually.)
-
-Instead, an example of an appropriate way to stylistically distinguish a portion of text is by using [alerts](#alerts). Consider also that extra styling and visual distinction may not even be necessary. In most cases, traditional writing methods are perfectly sufficient, e.g.,:
-
-```
-**Note:** This is an important note.
-```
-
-This renders as:
-
-**Note:** This is an important note.
-
-### Alerts
-
-Alerts are sections of HTML used to draw the reader's attention to important information, such as warnings, and for stylistic purposes. They are typically styled as colored text boxes, usually accompanied by icons. Alerts should generally be used somewhat sparingly, so as not to cause [alert fatigue](https://en.wikipedia.org/wiki/Alarm_fatigue) and since they must be written in HTML instead of Markdown, which makes the source less readable and more difficult to work with for localization and automation purposes. Here are examples of several types of alerts and their recommended icons:
-
-```
-
-
- Did you know? The Qubes OS installer is completely offline. It doesn't
- even load any networking drivers, so there is no possibility of
- internet-based data leaks or attacks during the installation process.
-
-
-
-
-
Note: Using Rufus to create the installation medium means that you
won't be able
- to choose the "Test this media and install Qubes OS" option mentioned in the
- example below. Instead, choose the "Install Qubes OS" option.
-
-
- Note: Qubes OS is not meant to be installed inside a virtual machine
- as a guest hypervisor. In other words, nested virtualization is not
- supported. In order for a strict compartmentalization to be enforced, Qubes
- OS needs to be able to manage the hardware directly.
-
-
-
-
-
Warning: Qubes has no control over what happens on your computer
- before you install it. No software can provide security if it is installed on
- compromised hardware. Do not install Qubes on a computer you don't trust. See
-
installation security for more
- information.
-
-
- Did you know? The Qubes OS installer is completely offline. It doesn't
- even load any networking drivers, so there is no possibility of
- internet-based data leaks or attacks during the installation process.
-
-
-
-
-
Note: Using Rufus to create the installation medium means that you
won't be able
- to choose the "Test this media and install Qubes OS" option mentioned in the
- example below. Instead, choose the "Install Qubes OS" option.
-
-
- Note: Qubes OS is not meant to be installed inside a virtual machine
- as a guest hypervisor. In other words, nested virtualization is not
- supported. In order for a strict compartmentalization to be enforced, Qubes
- OS needs to be able to manage the hardware directly.
-
-
-
-
-
Warning: Qubes has no control over what happens on your computer
- before you install it. No software can provide security if it is installed on
- compromised hardware. Do not install Qubes on a computer you don't trust. See
-
installation security for more
- information.
-