chore: 🔀 minor improvements (#161)

## Description

Some small fixes and minor improvements. See commit list for
descriptions.

<!-- Please delete as appropriate: -->
This PR needs a quick review.

why-REST/_index.qmd → why-REST/index.qmd

@@ -3,7 +3,7 @@ title: "Why RESTful API"
 description: |
   REST is a widely used design style for developing APIs.
 date: "2023-03-22"
-draft: true
+previous: true
 categories:
   - api
   - software-architecture

why-atomic-commits-and-prs/index.qmd

@@ -3,6 +3,9 @@ title: "Why atomic commits"
 description: "Our reasons for using atomic commits in our projects instead of squashing commits and ...? rebase? "
 date: "2024-05-14"
 categories:
+- git
+- collaborate
+- communicate
 ---
 
 ::: content-hidden
@@ -17,11 +20,11 @@ State the context and some background on the issue, then write a
 statement in the form of a question for the problem.
 :::
 
-A software project like Seedcase needs an easy way to manage and track changes in the codebase. 
+A software project like Seedcase needs an easy way to manage and track changes in the codebase.
 This includes making sure that changes are well documented, easy to understand, and can be reverted if necessary.
 We use Git as our version control system, and the GitHub flow as our branching strategy. We then need to decide the best approach for managing commits and PRs in our projects.
 
-The question then becomes: 
+The question then becomes:
 
 > Which strategy should we use in our projects in regards to commit and PR content and frequency to ensure a clear project history and efficient collaboration?
 
@@ -73,7 +76,7 @@ When you create branches for one specific purpose, it benefits your (and your co
 1. It enables you to give the branch a short, descriptive name that clearly communicates to your collaborators what work has been done on this particular branch.
 2. Smaller changes allows for a faster reviewing and merging to the `main` branch, since it is easier for your collaborators to get an overview of the work you have done.
 
-As an example, a branch could cover a fix to a particular bug or [issue](issues.md) (i.e., a problem in the current code or documentation that has been reported in the repository in GitHub) or add a new feature, such as a new plot, like in the figure above showing parallel development.
+As an example, a branch could cover a fix to a particular bug or issue (i.e., a problem in the current code or documentation that has been reported in the repository in GitHub) or add a new feature, such as a new plot, like in the figure above showing parallel development.
 
 
 

why-changelog-with-commitizen/index.qmd

@@ -140,7 +140,7 @@ Release](https://semantic-release.gitbook.io/semantic-release/) tool.
     for linting our commit messages and version bumps.
 -   A bit difficult to get started with: As detailed in the [Semantic
     release
-    post](../why-semantic-release-with-commitizen/index.qmd#python-semantic-release),
+    post](/why-semantic-release-with-commitizen/index.qmd#python-semantic-release),
     their website doesn't include any tutorials or "getting started"
     guides.
 :::

why-containers/index.qmd

@@ -8,7 +8,7 @@ previous: true
 categories:
   - container
   - installation
-  - deploying
+  - deploy
 ---
 
 <!-- TODO: Update this to match style of other posts -->

why-conventional-branches/index.qmd

@@ -4,8 +4,8 @@ description: "Our reasons for using conventional branch names."
 date: "2024-06-08"
 categories:
 - git
-- communication
-- collaboration
+- communicate
+- collaborate
 - workflow
 ---
 
@@ -24,9 +24,9 @@ statement in the form of a question for the problem.
 For the Seedcase Project, we aim to follow best practices and have
 explicit and clear structures for how we work together. This includes
 workflows on how we work with Git and GitHub (see the decision posts
-[Why GitHub flow](why-github-flow.qmd), [Why atomic commits and
-PRs](why-atomic-commits-and-prs.qmd), and [Why conventional
-commits](why-conventional-commits.qmd)).
+[Why GitHub flow](/why-github-flow/index.qmd), [Why atomic commits and
+PRs](/why-atomic-commits-and-prs/index.qmd), and [Why conventional
+commits](/why-conventional-commits/index.qmd)).
 
 Since we follow the GitHub flow, we need a structure for how we name our
 branches, since branch naming is important for keeping a project
@@ -73,7 +73,7 @@ When researching for branch naming conventions, most of the described
 best practices involve a naming scheme that follows a structure similar
 to Conventional Commits, which works very well for the Seedcase core
 team, since we follow this convention for our commit messages (see the
-[Why conventional commits](why-conventional-commits.qmd) decision post
+[Why conventional commits](/why-conventional-commits/index.qmd) decision post
 for why we follow this convention).
 
 In general, these naming schemes involves a prefix describing the
@@ -104,12 +104,12 @@ will be fleshed out below.
 When especially larger teams work on a project, they tend to have some
 kind of project management system, with tickets or items for each
 developer to work on. The Seedcase core team uses GitHub projects (see
-the [Why GitHub projects](why-github-projects.qmd) post), which includes
+the [Why GitHub projects](/why-github-projects/index.qmd) post), which includes
 numbering of issues across repositories.
 
 This information can easily be added to a branch name like so:
 
-```         
+```
 feat/issue-123-short-description
 ```
 
@@ -192,7 +192,7 @@ REASONS."
 
 We decided to follow the following naming scheme:
 
-```         
+```
 <type>/short-description
 ```
 

why-conventional-commits/index.qmd

@@ -4,8 +4,8 @@ description: "Our reasons for using conventional commits (with optional emojis f
 date: "2024-05-14"
 categories:
 - git
-- communication
-- collaboration
+- communicate
+- collaborate
 - workflow
 ---
 
@@ -32,7 +32,7 @@ working in a team-based and open source setting.
 Note that the benefits described above are tightly coupled to a clear,
 consistent workflow on commit frequency and content (see the decision
 post on why we aim to make [atomic commits and
-PRs](why-atomic-commits.qmd)).
+PRs](/why-atomic-commits-and-prs/index.qmd)).
 :::
 
 Since commit message conventions are not enforced by Git itself, but
@@ -53,7 +53,7 @@ transparency and collaboration. Therefore, it is essential to have a
 clear and consistent commit message convention to maintain these
 principles, both within the team and across external contributions.
 
-Since we follow the [GitHub flow](why-github-flow.qmd), changes are made
+Since we follow the [GitHub flow](/why-github-flow/index.qmd), changes are made
 on topic branches and reviewed before merging into the main branch.
 Having a clear commit message convention can ease the review process, as
 the context and purpose of changes will be clearer for reviewers.
@@ -116,7 +116,7 @@ the history of the project more understandable and easier to track.
 A conventional commit includes a **header**, an optional **body**, and
 an optional **footer** in each commit message, like shown below:
 
-```         
+```
 <type>[optional scope]: <description>
 
 [optional body]
@@ -172,7 +172,7 @@ explanations of the meaning of each emoji. Each commit message consists
 of an **intention** (an emoji), an optional **scope**, and a
 **message**, like shown below:
 
-```         
+```
 <intention>(<scope>): <message>
 ```
 
@@ -249,5 +249,5 @@ Note that following a commit message convention alone doesn't ensure a
 clear project history. Following a commit convention that includes
 commit content and frequency is as essential as a commit message
 convention. See the [Why atomic commits and
-PRs](why-atomic-commits-and-prs.qmd) decision post for a discussion of
+PRs](/why-atomic-commits-and-prs/index.qmd) decision post for a discussion of
 such conventions.

why-discord/index.qmd

@@ -3,8 +3,8 @@ title: "Why Discord"
 description: "Our reasons for using Discord as our communication platform."
 date: "2023-06-25"
 categories:
-  - communication
-  - collaboration
+  - communicate
+  - collaborate
 ---
 
 ::: content-hidden

why-django/index.qmd

@@ -6,7 +6,7 @@ date: "2023-03-22"
 date-modified: "2024-05-16"
 previous: true
 categories:
-  - development
+  - develop
   - framework
 ---
 
@@ -48,7 +48,7 @@ List some reasons for why we need to make this decision and what things
 have arisen that impact work.
 :::
 
-We are developing Seedcase in Python (see [Why Python](why-python.qmd)
+We are developing Seedcase in Python (see [Why Python](/why-python/index.qmd)
 for more information about this decision), so we only consider web
 frameworks for Python. The core part of Seedcase software is or will be
 a relatively complex web application with a front end, an API and a data
@@ -107,7 +107,7 @@ pattern.
     away much of the database logic and allows developers to work with
     database models in a Pythonic way.
 -   Supports all major databases (including PostgreSQL - see our [Why
-    PostgreSQL](why-postgres.qmd) decision post) and has a migration
+    PostgreSQL](/why-postgres/index.qmd) decision post) and has a migration
     mechanism, making it easy to evolve the database schema over time.
 -   Has good file storage support, making it easier to work with raw
     data and image files.

why-docker/index.qmd

@@ -7,7 +7,7 @@ date: "2022-12-14"
 previous: true
 categories:
   - container
-  - deploying
+  - deploy
   - installation
   - dependencies
 ---
@@ -23,7 +23,7 @@ use cases. Even though all have a similar concept of images and
 containers, there are some technical differences worth noting.
 
 As to why we have chosen containerization, see the page [Why choose
-containerization technology](why-containers.qmd).
+containerization technology](/why-containers/index.qmd).
 
 ## Comparison of technologies
 

why-figjam/index.qmd

@@ -3,7 +3,7 @@ title: "Why FigJam for retrospectives"
 description: "Our reasons for using FigJam for our retrospectives."
 date: "2024-10-25"
 categories:
-  - collaboration
+  - collaborate
   - retrospectives
 ---
 
@@ -180,7 +180,7 @@ account.
 :::
 
 ```{=html}
-<!-- https://scrumlr.io/board/8b5ca88c-f97e-438d-898d-cf1c19e7aac8 
+<!-- https://scrumlr.io/board/8b5ca88c-f97e-438d-898d-cf1c19e7aac8
 board created on the 1st November 2024-->
 ```
 

why-fly/index.qmd

@@ -6,8 +6,8 @@ description: |
 date: "2023-12-08"
 previous: true
 categories:
-  - development
-  - deploying
+  - develop
+  - deploy
 ---
 
 ## Context and problem statement

why-frictionless-data/index.qmd

@@ -4,8 +4,8 @@ description: "Why we choose to use the Frictionless Data standard for structurin
 date: "2024-07-15"
 categories:
 - framework
-- standardize
-- organize
+- standardise
+- organise
 - manage
 ---
 
@@ -61,7 +61,7 @@ requirements like being open source and not being commercial solutions.
 Some are listed
 [here](https://atlan.com/open-source-data-catalog-tools/) and
 [here](https://github.com/opendatadiscovery/awesome-data-catalogs). Many
-of the tools that exist are strongly focused on corporate needs and on 
+of the tools that exist are strongly focused on corporate needs and on
 providing an extensively featured platform for sharing data and
 metadata, without a clear structure to the data or metadata itself.
 There are some "data catalog" tools, but many don't fit our
@@ -132,8 +132,8 @@ REASONS."
 While there are no real alternatives to Frictionless Data that fit our
 requirements, there are many strong reasons to use it as is described
 above. For instance, the principles and values align closely with ours
-and this standard is owned and developed by the non-profit Open 
-Knowledge Foundation, who do work in other areas that also align 
+and this standard is owned and developed by the non-profit Open
+Knowledge Foundation, who do work in other areas that also align
 with our values and principles.
 
 ## Resources used for this post

why-github-projects/index.qmd

@@ -3,10 +3,10 @@ title: "Why GitHub Projects"
 description: "As a project grows, it becomes both more important and more difficult to keep track of where the project is at.  This can be helped by using visualisation and project management tools like GitHub Projects."
 date: "2023-11-23"
 categories:
-  - documentation
-  - collaboration
-  - management
-  - organization
+  - document
+  - collaborate
+  - manage
+  - organise
 ---
 
 <!--TODO #36 docs: Update 'Why GitHub Projects' with Benefits and Drawbacks -->
@@ -19,7 +19,7 @@ The larger a team is, the more important it becomes to keep track of who is doin
 
 ## Decision drivers
 
-As a team we have been struggling to keep track of who is completing which tasks, and how far along that work is. We have therefore agreed, that we will try to communicate this better internally within the team, not only with frequent commits and reviews, but also utilising the new project tools that GitHub have rolling out. 
+As a team we have been struggling to keep track of who is completing which tasks, and how far along that work is. We have therefore agreed, that we will try to communicate this better internally within the team, not only with frequent commits and reviews, but also utilising the new project tools that GitHub have rolling out.
 
 ## Considered options
 

why-mit-license/index.qmd

@@ -5,7 +5,7 @@ description: |
 date: "2023-04-01"
 date-modified: last-modified
 categories:
-- licensing
+- license
 ---
 
 <!--TODO #38 docs: Update 'Why MIT license with benefits and drawbacks -->

why-poetry/index.qmd

@@ -4,7 +4,7 @@ description: "Our reasons for using Poetry for managing Python package dependenc
 date: "2024-01-29"
 categories:
 - dependencies
-- development
+- develop
 - workflow
 ---
 
@@ -77,7 +77,7 @@ management.
 #### Drawbacks
 
 - Design is a bit older and not as intuitive/clear to use
-- Documentation is a bit too verbose/technical
+- document is a bit too verbose/technical
 - Package caching doesn't seem to be well designed/robust, so packages could get unnecessarily re-installed
 - Only handles package dependency management, which means we need another tool to develop software (like a Python package)
 

why-polyrepo/index.qmd

@@ -3,8 +3,8 @@ title: "Why poly-repo"
 description: "Our reasons for structuring projects (both software and websites) in a poly-repo rather than mono-repo style."
 date: "2023-12-05"
 categories:
-  - organization
-  - management
+  - organise
+  - manage
 ---
 
 ## Context and problem statement
@@ -119,7 +119,7 @@ mono-repo approach to developing their software products. This approach
 looks a bit like this, where each project is a folder under the main
 repo:
 
-```         
+```
 main/
 ├── .git/
 ├── project1/
@@ -205,7 +205,7 @@ dozens of packages, and their teams are quite small.
 
 This structure looks a bit like:
 
-```         
+```
 project1/
 ├── .git/
 ├── tests/

why-postgres/index.qmd

@@ -27,7 +27,7 @@ defined by
 [DB-Engines](https://db-engines.com/en/ranking/relational+dbms) in
 November 2022): MySQL, PostgreSQL, and SQLite.
 
-As we are planning to use [container technology](why-containers.qmd) to
+As we are planning to use [container technology](/why-containers/index.qmd) to
 run the database it is not as important which operating systems the
 database will run on. Having said that, of the three systems that we are
 looking at, MySQL and PostgreSQL will run on multiple operating systems

why-python/index.qmd

@@ -6,7 +6,7 @@ description: |
 date: "2023-03-22"
 date-modified: "2024-05-10"
 categories:
-  - development
+  - develop
 ---
 
 ::: content-hidden