Additional small fixes across the repo (#530)

Change all remaining headers to sentence case as demanded by style guide

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

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

@@ -30,19 +30,19 @@ git switch main
 git pull
 ```
 
-## Create a New Branch
+## Create a new branch
 
 It's always a good idea to switch to a new git branch before beginning packaging work. This helps to separate your work from any new changes made to the package repository, which will allow you to more easily rebase any changes if needed. To do so run:
 
 ```bash
 git switch -c your-branch
 ```
 
-## Create The `MAINTAINERS.md` File
+## Create the `MAINTAINERS.md` file
 
 You must add a file called `MAINTAINERS.md` using the template in [Maintainership](procedures/maintainership.md). Solus uses this to track the primary maintainer(s) for each package.
 
-## Create the `package.yml` File
+## Create the `package.yml` file
 
 You will need a link to the most recent source tarball for this from the software's website.
 
@@ -124,7 +124,7 @@ To read more about finding and including dependencies and other parts of `packag
 
 Understanding how to translate source code into a good `package.yml` file is the heart of packaging. If you are stumped, or have questions, **ask for help in our Solus Packaging room on [Matrix](/docs/user/contributing/getting-involved#matrix-chat).**
 
-## Build the Package
+## Build the package
 
 Build the package using `go-task`. The default task will build the package against the Unstable repository, so you don't have to specify a task here.
 
@@ -146,7 +146,7 @@ All these files _except_ the `*eopkg` file(s) should be included in your pull re
 
 Once your package has built successfully, you will need to [test it](testing-a-package).
 
-## Commit your Changes
+## Commit your changes
 
 Check the [changes in your files](git-basics#check-the-changes-in-your-files).
 

docs/packaging/index.md

@@ -8,20 +8,20 @@ sidebar_position: 0
 
 This is the overall workflow for creating or updating a package.
 
-## Development Environment Preparation
+## Development environment preparation
 
 1. [Prepare for Packaging](prepare-for-packaging.md)
 2. Review the [requirements for the package.yml file](docs/packaging/package.yml.md).
 3. Also review our [Packaging Practices](docs/packaging/packaging-practices.md).
 
-## Prior to Building a Package
+## Prior to building a package
 
 Please check the following:
 
 - Search [open package requests](https://github.com/getsolus/packages/issues?q=label%3A%22Package+Request%22) to see if there is one for the package. If there isn't an existing issue, go ahead and submit your pull request. If there is already a pull request, please check its status to avoid duplicating work.
 - If you are submitting a pull request for the inclusion of software in the repo, the package has a corresponding package request that is **accepted for inclusion** or is a dependency of a package that has been accepted into the repository.
 
-## Building Packages
+## Building packages
 
 1. [Update your development environment](update-dev-environment.md)
 2. Prepare the package directory and build the package

docs/packaging/prepare-for-packaging.md

@@ -88,11 +88,11 @@ To update solbuild, run:
 sudo solbuild update
 ```
 
-## Fork the getsolus/packages Repository
+## Fork the getsolus/packages repository
 
 Create your own fork of [getsolus/packages](https://github.com/getsolus/packages) using the GitHub web UI or [`gh` cli tool](https://cli.github.com/manual/gh_repo_fork) from the `github-cli` package. It will be forked to `github.com/yourgithubaccount/packages`.
 
-## Clone Your forked package repository
+## Clone your forked package repository
 
 Create a local clone of the package repository you just forked. Here we are using the name `solus-packages` and cloning it into our home directoy. The rest of the documentation will presume this structure. You can choose a different name and path but will have to make sure to replace it in every command that refers to the `solus-packages` directory.
 
@@ -114,7 +114,7 @@ go-task -d ~/solus-packages init
 
 This makes it easy to create commits in the correct format, and will warn you about issues with changes you commit.
 
-## Set up repository helper functions (Optional)
+## Set up repository helper functions (optional)
 
 The helper functions are a collection of shell scripts that help you navigate the packages repository more quickly, and perform some specialized searches.
 
@@ -147,14 +147,14 @@ ln -s ~/solus-packages/common/Scripts/helpers.zsh ~/.zshrc.d/solus-monorepo-help
 
 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 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`                |
+| 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 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`      |
+| **whatuses**      | Find out what packages use a library by reading the `abi_used_libs` files.                                                                    | `whatuses libfoobar.so.1`     |
 
 ## Building packages
 

docs/packaging/procedures/maintainership.md

@@ -19,11 +19,11 @@ On the Solus side however, the community must not forget that maintainers are vo
 
 The Solus Staff have the right to enforce certain practices, even when in contrast with maintainers' vision. It also has the right to ultimately accept or reject a patch.
 
-## Stepping In
+## Stepping in
 
 To officially step in as the maintainer of a package, a `MAINTAINERS.md` file must be provided for accepted packages that are not yet included in the repository, or if the package predates the policy of requiring one. Instead, if a previously maintained package is marked by Solus Staff as needing a new maintainer, the `MAINTAINERS.md` file must be updated.
 
-## Updating a Maintained Package
+## Updating a maintained package
 
 The procedure varies depending on whether or not the individual is the maintainer.
 
@@ -35,7 +35,7 @@ Maintainers are free to [update a package](/docs/packaging/updating-an-existing-
 
 If a package is actively maintained, modifications should not occur and the individual should exercise patience when it comes to updates. In some cases, a maintainer may intentionally be holding back a package, or has simply not updated yet. If pertinent, the individual should file a [package update request](/docs/packaging/procedures/request-a-package-update). Alternatively, the individual can reach the maintainers or Solus Staff via the Solus Packaging room on [Matrix](/docs/user/contributing/getting-involved#matrix-chat) and ask permission to update the package. It is also possible to submit an update and attach a message to it clarifying the intention of updating the package, although this is a special case reserved to e.g. security updates.
 
-## Template for the `MAINTAINERS.md` File
+## Template for the `MAINTAINERS.md` file
 
 Presented here is the `MAINTAINERS.md` file. This file must be provided verbatim alongside the other patch contents, and filled in with the maintainers' personal information. A [Matrix](/docs/user/contributing/getting-involved#matrix-chat) contact is optional but recommended, while an email address is mandatory. Similar to the `.solus/packager` file used for packaging, the maintainers listed in `MAINTAINERS.md` must use their real first and last name(s) for accountability purposes.
 

docs/packaging/procedures/package-inclusion.md

@@ -9,33 +9,33 @@ This policy sets forth the criteria for a package to be accepted for inclusion i
 
 ## Criteria
 
-### Explicitly Redistributable
+### Explicitly redistributable
 
 - Software under a free software or open source software license, or license text which explicitly states that it is **permissible** to redistribute the software. We use the [SPDX License List](https://spdx.org/licenses/).
 - For anything that cannot be redistributed by Solus, there is the possibility for them to be provided as a Flatpak, for Third Party repository inclusion, however the Solus project is not responsible for flatpak or snap implementation of these items. These items should then fetch only at installation time, and not contain non distributable components.
 - Solus supports both VCS (currently only git, this will expand) and traditional software sources (such as tarballs) for packages, equally.
 - Unless **absolutely unavoidable**, the sources for a package should be source, and not **binary, prebuilt** sources. Exceptions may be made in rare cases, such as stage1 bootstrap for a compiler, or requires custom components otherwise impossible to provide in Solus (patched libraries, etc.)
 
-### Server Software
+### Server software
 
 - Mail servers such as Postfix, Dovecot, etc, are **not** eligible for inclusion. Solus does not provide a server operating system.
 - Web servers and database daemons **are** eligible for inclusion, as they facilitate web developers to work locally.
 - Anything outside of these may be catered to by the usage of Docker, or other container technology. Thus, container technology must be supported by Solus to support access to ancillary cases.
 
-### Software Age
+### Software age
 
 - DOA (dead-on-arrival) packages are generally rejected from Solus. However, they may be included at the discretion of the project, if they provide unique functionality.
 - Projects with no tags/tarballs which lack traction, may be frozen until a suitable release is made. Tagging releases is an indicator for good release engineering practices.
 - Typically, we prefer **stable** tagged releases. However, this may be waived if:
   - The software has significant traction (i.e. prerelease)
   - A bug fix only exists beyond the latest stable release for a git source
 
-### Stack Complexity
+### Stack complexity
 
 - Certain requests may tick all the boxes, but introduce a level of complexity or require a level of engagement not possible to balance for Solus Staff. Under certain situations, a request will be frozen until it has a dedicated maintainer.
 - This extends to requests for full desktop environments. However, this does not extend to minor components like drop-in window managers or panels separate of a dependent stack (i.e. Awesome WM, tint2, etc.)
 
-### Value Add
+### Value-add
 
 - A web wrapper which **adds value**, such as Discord, with the global push-to-talk shortcut, is eligible for inclusion.
 - A web page wrapper, that adds **no further value** other than “convenient desktop shortcut” or “tray icon”, are **not** eligible for inclusion. Web browsers already support desktop notifications.

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

@@ -17,7 +17,7 @@ Please refrain from submitting a pull request for the following instances:
   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, make patch review by Solus Staff more time consuming, and introduce unnecessary work.
 
-## Final Branch Review
+## Final branch review
 
 At minimum, your pull request will include changes for the following files:
 
@@ -41,9 +41,9 @@ Take a final look over your commit message to make sure it has all the necessary
 git log -1
 ```
 
-## Creating the Pull Request
+## Creating the pull request
 
-There are multiple ways to create a Pull Request with GitHub, either from the website, or from the command line.
+There are multiple ways to create a pull request with GitHub, either from the website, or from the command line.
 
 <Tabs groupId="opening-prs">
   <TabItem value="website" label="Website">
@@ -91,7 +91,7 @@ There are multiple ways to create a Pull Request with GitHub, either from the we
   </TabItem>
 </Tabs>
 
-## Amending a Pull Request
+## Amending a pull request
 
 There may be times you need to make minor changes after submitting the pull request. For instance, you see something that needs correcting. To do this, you will need to amend your commit.
 
@@ -108,7 +108,7 @@ We want amended commits because of the way our tooling works. It expects that th
 
 :::
 
-### Amending a Pull Request with multiple commits
+### Amending a pull request with multiple commits
 
 Sometimes, you may be submitting multiple packages in a single pull request, and one of them might need changes. The process is very similar to the above steps, but with a couple of additions.
 
@@ -122,13 +122,13 @@ Sometimes, you may be submitting multiple packages in a single pull request, and
 8. Repeat steps 4 through 7 for all commits you wish to edit
 9. Push the amended stack: `git push --force`
 
-## Updating a Pull Request That Has Changes Requested
+## Updating a pull request that has changes requested
 
 Your pull request will be reviewed, and changes may be requested. This is normal. It's to ensure the quality of the packages in our repository and to make sure each PR adheres to our standards.
 
 If you need to make changes in response to a review, follow the steps in the [section above](#amending-a-pull-request).
 
-## After the Pull Request is Accepted
+## After the pull request is accepted
 
 Once your pull request is accepted and merged, someone on the Solus Team will issue a build. Your new / updated package will be published to the unstable repos.
 

docs/packaging/testing-a-package.md

@@ -10,7 +10,7 @@ After building a package, it must be tested against the unstable repository befo
 
 You will use the `.eopkg` file(s) created by the build process for testing.
 
-## Install the `.eopkg` Files
+## Install the `.eopkg` files
 
 To install your new package, run the following command in the directory where you built the package. Include **all** `.eopkg` files that were built.
 
@@ -22,15 +22,15 @@ Testing need not be very complicated. The goal is to ensure the package will rel
 
 For example, if you were updating a text editor, you would want to make sure you can open, create and save files. If you know of issues the package has had in the past, it's a good idea to test that as well to make sure there are no regressions. There are plenty of historical pull requests to review if you want more detail.
 
-## For Updated Packages: Return to the Repository Version
+## 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 and tested `tree`:
 
 ```bash
 sudo eopkg it --reinstall tree
 ```
 
-## Remove the `.eopkg` Files
+## Remove the `.eopkg` files
 
 Before you can submit your pull request, you need to remove the `.eopkg` files. All repository packages are built by a dedicated build server from the source files provided in your pull request.
 

docs/packaging/update-dev-environment.md

@@ -13,11 +13,11 @@ Always make sure your development environment and system are up to date before b
 3. Update the solbuild base image `sudo solbuild update`
 4. Update the system.
 
-## Update Your Fork of the getsolus/packages Repository
+## Update your fork of the getsolus/packages repository
 
 If you already have a fork of [getsolus/packages](https://github.com/getsolus/packages) in GitHub, log into GitHub. Make sure you're looking at the `main` branch. Check to see that your fork is up to date with the main repository it was forked from. If your fork indicates it is behind, use the "Sync fork" button to bring it up to date.
 
-## Update Your Local Clone of Your Fork
+## Update your local clone of your fork
 
 If you already have a local clone, you need to bring it up to date. To do so run:
 
@@ -27,7 +27,7 @@ git switch main
 git pull
 ```
 
-## Update `solbuild` and the System
+## Update `solbuild` and the system
 
 ```bash
 sudo solbuild update