Small fixes all across the docs (#529)

Signed-off-by: Thomas Staudinger <[email protected]>

docs/packaging/creating-a-new-package.md

@@ -50,7 +50,7 @@ To create a skeleton `package.yml` file, use the `go-task new` command.
 
 This command takes two arguments, in the following order:
 
-1. package name
+1. Package name
 2. Source URL
 
 ```bash
@@ -168,7 +168,7 @@ git commit
 
 There should be a summary line (with the package name), a blank line, and then the rest of the commit message.
 
-- There should at the minimum be a summary and Test Plan.
+- There should at the minimum be a Summary and Test Plan.
 - Bullet point lists should start with a dash.
 
 Here is an example in our standard format (make sure to check the box in the checklist):

docs/packaging/monitoring.yml.md

@@ -19,7 +19,7 @@ Checking for security advisories ([CVEs](https://en.wikipedia.org/wiki/Common_Vu
 
 ## Adding monitoring.yml to an existing package
 
-To add a monitoring.yml file to an existing package you can use the following `go-task` command to add a template file, starting from within the directory containing the `package.yml` for a given package:
+To add a `monitoring.yml` file to an existing package you can use the following `go-task` command to add a template file, starting from within the directory containing the `package.yml` for a given package:
 
 ```bash
 go-task add-monitoring
@@ -36,7 +36,7 @@ security:
   cpe: ~
 ```
 
-You must, at minimum, fill out `id` and check if the package has a CPE name. `rss` should be deleted if no feed is available.
+You must, at minimum, fill out `id` and check if the package has a [CPE name](#what-is-a-cpe-name). `rss` should be deleted if no feed is available.
 
 ## systemd as an example
 
@@ -80,7 +80,7 @@ Fields used to monitor for new versions.
 | -------- | --------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `id`     | integer                     | Yes                     | Anitya ID from [release-monitoring.org](https://release-monitoring.org/)                                                                                                                                                                                 |
 | `ignore` | list of regular expressions | No                      | List of regular expressions enclosed in quotes matching versions to ignore. Include a comment explaining the ignored versions.                                                                                                                           |
-| `rss`    | URL                         | No, strongly encouraged | URL for a releases RSS feed. If the only RSS feed you can find for a project is a general "news" feed, don't include the field. For GitHub projects, You can use the "tags" or "releases" feed: `https://github.com/USER/REPOSITORY/tagsORreleases.atom` |
+| `rss`    | URL                         | No, strongly encouraged | URL for a releases RSS feed. If the only RSS feed you can find for a project is a general "news" feed, don't include the field. For GitHub projects, you can use the "tags" or "releases" feed: `https://github.com/USER/REPOSITORY/tagsORreleases.atom` |
 
 ### Finding the Anitya ID
 

docs/packaging/package.yml.md

@@ -240,7 +240,7 @@ BOLT is a post-link optimizer developed to speed up large applications. You will
 | **%ARCH%**                   | Indicates the current build architecture.                                                                                                         |
 | **%CC%**                     | C compiler.                                                                                                                                       |
 | **%CFLAGS%**                 | cflags as set in `eopkg.conf`.                                                                                                                    |
-| **%CONFOPTS%**               | Flags / options for configuration, such as `--prefix=%PREFIX%`. [Full List.](https://github.com/getsolus/ypkg/blob/master/ypkg2/rc.yml#L403-L415) |
+| **%CONFOPTS%**               | Flags / options for configuration, such as `--prefix=%PREFIX%`. [Full List.](https://github.com/getsolus/ypkg/blob/master/ypkg2/rc.yml#L431-L443) |
 | **%CXX%**                    | C++ compiler.                                                                                                                                     |
 | **%CXXFLAGS%**               | cxxflags as set in `eopkg.conf`.                                                                                                                  |
 | **%JOBS%**                   | jobs, as set in `eopkg.conf`.                                                                                                                     |

docs/packaging/prepare-for-packaging.md

@@ -8,7 +8,7 @@ sidebar_position: 1
 
 ## Switch to the Unstable repository
 
-Packages need to be built and tested against the "unstable" repository. If you don't want to switch your primary system to unstable, you can do your packaging work in a VM. We have Virtual Machine Manager in the repos.
+Packages need to be built and tested against the "unstable" repository. If you don't want to switch your primary system to unstable, you can do your packaging work in a VM. We have Virtual Machine Manager and other similar tools in the Solus repository.
 
 Refer to [Repository Management](/docs/user/package-management/repo-management) to see how to add and switch to unstable.
 
@@ -35,7 +35,7 @@ We need to install a few things in order to get started with packaging:
 - `git` is used for version control of the Solus sources
 - `github-cli` is used to make working with GitHub easier
 - `go-task` is used by our build tools for scripting
-- `jq` is used by our optional Helper Functions
+- `jq` is used by our optional [Helper Functions](#set-up-repository-helper-functions-optional)
 - `solbuild` is a lightweight container environment for building packages repeatably
 - `solbuild-config-unstable` sets up solbuild for working with the `unstable` repository
 - `ypkg` is the program that actually builds packages
@@ -47,11 +47,11 @@ sudo eopkg it git github-cli go-task jq solbuild solbuild-config-unstable ypkg y
 
 ## Setting up a GitHub account and Git
 
-The Solus source repositories for the package repository currently reside on [github.com/getsolus/packages](https://github.com/getsolus/packages). You will need a GitHub account to submit patches and file issues. You can create a GitHub account [here](https://github.com/signup). Note that you will also need to set up [2FA](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa) (two factor authentication) for your account.
+The Solus source repositories for the package repository currently reside on [github.com/getsolus/packages](https://github.com/getsolus/packages). You will need a GitHub account to submit patches and file issues. You can create a GitHub account [here](https://github.com/signup). Note that you will also need to set up [2FA](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa) (two-factor authentication) for your account.
 
 ### Configure `github-cli`.
 
-Once you have a GitHub account, you need to configure `github-cli` to work with it. At minimum, you need to run `gh auth login`. Have your GitHub credentials and 2FA (two factor authentication) mechanism at hand.
+Once you have a GitHub account, you need to configure `github-cli` to work with it. At minimum, you need to run `gh auth login`. Have your GitHub credentials and 2FA (two-factor authentication) mechanism at hand.
 
 See the [GitHub CLI quickstart](https://docs.github.com/en/github-cli/github-cli/quickstart) for some common uses of the tool.
 
@@ -150,10 +150,10 @@ You should now have the following available from your shell:
 | Function          | Description                                                                                                                                   | Usage                          |
 | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
 | **cpesearch**     | Search for CPE Names for packages. For use when writing the [`monitoring.yml`](/docs/packaging/monitoring.yml.md) file for a package          | `cpesearch search-term`        |
-| **goroot**        | When in the solus monorepo, change directory to the root directory of the git repository.                                                     | `goroot`                       |
-| **gotopkg**       | Change directory to any solus package. You can type part of the package name then double press `Tab` to get autocompletion for this function. | `gotopkg firefox`              |
-| **gotosoluspkgs** | Change directory to the solus monorepo from anywhere on the filesystem.                                                                       | `gotosoluspkgs`                |
-| **whatprovides**  | Find out what package provides a library by reading the `abi_libs` files.                                                                     | `whatprovides libfoobar.so.1.` |
+| **goroot**        | When in the Solus packages repository, change directory to the root directory.                                                     | `goroot`                       |
+| **gotopkg**       | Change directory to any Solus package. You can type part of the package name then double press `Tab` to get autocompletion for this function. | `gotopkg firefox`              |
+| **gotosoluspkgs** | Change directory to the Solus packages repository from anywhere on the filesystem.                                                                       | `gotosoluspkgs`                |
+| **whatprovides**  | Find out what package provides a library by reading the `abi_libs` files.                                                                     | `whatprovides libfoobar.so.1` |
 | **whatuses**      | Find out what packages use a library by reading the `abi_used_libs` files.                                                                    | `whatuses libfoobar.so.1`      |
 
 ## Building packages

docs/packaging/procedures/release-processes.md

@@ -36,8 +36,8 @@ Follow these steps to submit a package for deprecation:
 1. Fork and clone the `solus-sc` repo [on GitHub](https://github.com/getsolus/solus-sc), and/or create a new branch
 2. Edit `repo_data/distribution.xml.in`
 3. Add the package you wish to deprecate at the end of the `<Obsoletes>` section
-4. Change directory `cd merged_repos.sh` and from there run the `merged_repos.sh` script
-5. Commit and push your changes to your repo/branch
+4. Run the `merged_repos.sh` script
+5. Commit and push your changes to your repository/branch
 6. Open a Pull Request on GitHub
 
 If a deprecation depends on a packaging change landing before it can be properly deprecated without undesirable side effects on user systems, the GitHub deprecation Pull Request MUST link to the packaging change and declare it as a dependency for deprecation.

docs/packaging/submitting-a-pull-request.mdx

@@ -15,7 +15,7 @@ Please refrain from submitting a pull request for the following instances:
 
 - For a package that is yet to be accepted for inclusion by a member of the Solus Staff team. Search [open package requests](https://github.com/getsolus/packages/issues?q=label%3A%22Package+Request%22) to see if there is an open request for the package.
   We welcome you to politely reach out via the package request issue or our Support room on [Matrix](/docs/user/contributing/getting-involved#matrix-chat) if you deem the review of the request to be time-sensitive in nature.
-- If your pull request is a Work In Progress / WIP. Pull requests that are completed or are marked as _request for comments_ (RFC) are accepted. For RFC request please ensure your patch title contains `[RFC]` and is marked as 'draft'. WIP patches clutter the issue tracker and make patch review by Solus Staff more time consuming and introduces unnecessary work.
+- If your pull request is a Work In Progress / WIP. Pull requests that are completed or are marked as _request for comments_ (RFC) are accepted. For RFC request please ensure your patch title contains `[RFC]` and is marked as 'draft'. WIP patches clutter the issue tracker, make patch review by Solus Staff more time consuming, and introduce unnecessary work.
 
 ## Final Branch Review
 
@@ -27,6 +27,7 @@ At minimum, your pull request will include changes for the following files:
 It may also include these files:
 
 - `MAINTAINERS.md`
+- `monitoring.yml`
 
 Double check the `package.yml` to make sure the builddeps are in the right order, and that it otherwise adheres to the [standards](package.yml.md) Solus has set.
 
@@ -66,7 +67,7 @@ There are multiple ways to create a Pull Request with GitHub, either from the we
     3. Link any relevant issues:
        - If you want to link this pull request to an existing issue, simply mention it in the PR summary: `The inclusion of <somepackage> fixes #123`.
        - If you need a change to depend on another change, mention it in the PR summary too: `Depends on #234`.
-    4. Double check everything
+    4. Double-check everything.
     5. Create the pull request!
     </p>
 

docs/packaging/testing-a-package.md

@@ -6,9 +6,9 @@ sidebar_position: 5
 
 # Testing a Package
 
-After building a package, it must be tested against the unstable repo before a pull request can be submitted. Each pull request requires you to explain how you tested the package to make sure things work as expected.
+After building a package, it must be tested against the unstable repository before a pull request can be submitted. Each pull request requires you to explain how you tested the package to make sure things work as expected.
 
-You will use the .eopkg file(s) created by the build process for testing.
+You will use the `.eopkg` file(s) created by the build process for testing.
 
 ## Install the `.eopkg` Files
 
@@ -24,7 +24,7 @@ For example, if you were updating a text editor, you would want to make sure you
 
 ## For Updated Packages: Return to the Repository Version
 
-It is a good idea to uninstall the package you built, and return to the repository version, once you are done testing. To do this, run the following command on the main application. For example, if you just built `tree`:
+It is a good idea to uninstall the package you built, and return to the repository version, once you are done testing. To do this, run the following command on the main application. For example, if you just built and tested `tree`:
 
 ```bash
 sudo eopkg it --reinstall tree

docs/packaging/update-dev-environment.md

@@ -8,7 +8,7 @@ sidebar_position: 2
 
 Always make sure your development environment and system are up to date before beginning work on a package
 
-1. Update your fork of the getsolus/packages Repository.
+1. Update your fork of the [getsolus/packages](https://github.com/getsolus/packages) repository.
 2. Update your local clone of your fork.
 3. Update the solbuild base image `sudo solbuild update`
 4. Update the system.

docs/packaging/updating-an-existing-package.md

@@ -133,7 +133,9 @@ The following guidelines apply to the commit message body:
 `git commit` on [an initialized repository](prepare-for-packaging.md#initialize-git-hooks) will automatically open your editor with the correct template.
 Note that lines starting with a `#` will be ignored by Git and do not need to be removed.
 
-_Important_: Do not include issue numbers in changelogs. This will incorrectly link your issue to another one in our repository. Ex:
+_Important_: Do not include issue numbers in changelogs. This will incorrectly link your issue to another one in our repository.
+
+Example:
 
 ```
 - #123 fixed a thing

docs/user/software/command-line/index.md

@@ -11,13 +11,13 @@ When using a terminal session to perform command-line activities, a Unix shell i
 
 Solus makes available other shells via our repository, with a full list available in `/usr/share/defaults/etc/shells`. Common shells, aside from Bash, are:
 
-- [Dash](https://gondor.apana.org.au/~herbert/dash/)
-- [Fish](https://fishshell.com/)
-- [Zsh](https://zsh.sourceforge.io/)
+- [DASH](http://gondor.apana.org.au/~herbert/dash/)
+- [fish](https://fishshell.com/)
+- [zsh](https://zsh.sourceforge.io/)
 
 ### Installation
 
-In order to use a shell different from Bash, you may need to install the respective package for the shell to be able to work. You will find those packages in the Software-Center within the _System utilities_ category, or via the command-line with `sudo eopkg install <Name of the Shell>`.
+In order to use a shell different from Bash, you may need to install the respective package for the shell to be able to work. You will find those packages in the Software Center within the _System utilities_ category, or via the command-line with `sudo eopkg install <Name of the Shell>`.
 
 Example:
 
@@ -31,19 +31,19 @@ To switch to another shell, first install the appropriate package, followed by t
 
 Example:
 
-- For Zsh: `chsh -s /bin/zsh`
+- For zsh: `chsh -s /bin/zsh`
 
-- For Fish: `chsh -s /usr/bin/fish`
+- For fish: `chsh -s /usr/bin/fish`
 
 ### Troubleshooting
 
 If the default shell is not changed, you must add the shell to `/etc/shells` via the command `sh` with `sudo`.
 
 Example:
 
-- For Zsh: `echo "/bin/zsh" | sudo tee -a /etc/shells`
+- For zsh: `echo "/bin/zsh" | sudo tee -a /etc/shells`
 
-- For Fish: `echo "/usr/bin/fish" | sudo tee -a /etc/shells`
+- For fish: `echo "/usr/bin/fish" | sudo tee -a /etc/shells`
 
 ## fzf