BUG - Remove links to changelog

docs/contributing.md

@@ -196,7 +196,7 @@ Choose the `<version>` number. It should follow [Semantic
 Versioning](https://semver.org/) and the established pattern of
 `v<x>.<y>.<z>`.
 
-Ensure that `CHANGELOG.md` is up to date with all the changes since
+Ensure that [`CHANGELOG.md`](https://github.com/conda-incubator/conda-store/blob/main/CHANGELOG.md) is up-to-date with all the changes since
 the last release following the template provided within the markdown
 file.
 

docusaurus-docs/community/contribute/contribute-code.md

@@ -14,8 +14,8 @@ This page is in active development, content may be inaccurate and incomplete.
 
 Install the following dependencies before developing on conda-store.
 
-- [docker](https://docs.docker.com/engine/install/)
-- [docker-compose](https://docs.docker.com/compose/install/)
+- [Docker](https://docs.docker.com/engine/install/)
+- [ocker-compose](https://docs.docker.com/compose/install/)
 
 To deploy `conda-store` run the following command
 
@@ -26,8 +26,8 @@ docker-compose up --build -d
 :::important
 Many of the conda-store docker images are built/tested for amd64(x86-64)
 there will be a performance impact when building and running on
-arm architectures. Otherwise this workflow has been shown to run and build on OSX.
-Notice the `architecture: amd64` whithin the docker-compose.yaml files.
+arm architectures. Otherwise, this workflow has been shown to run and build on OSX.
+Notice the `architecture: amd64` within the `docker-compose.yaml` files.
 :::
 
 The following resources will be available:
@@ -43,7 +43,7 @@ The following resources will be available:
 On a fast machine this deployment should only take 10 or so seconds
 assuming the docker images have been partially built before.
 
-If you are making and changes to conda-store-server and would like to see
+If you are making any changes to `conda-store-server` and would like to see
 those changes in the deployment, run:
 
 ```shell
@@ -55,7 +55,7 @@ docker-compose up --build
 
 1. Install the following dependencies before developing on conda-store:
 
-- [conda](https://docs.conda.io/projects/conda/en/latest/user-guide/install/linux.html)
+   - [conda](https://docs.conda.io/projects/conda/en/latest/user-guide/install/linux.html)
 
 2. Install the development dependencies and activate the environment:
 
@@ -69,32 +69,32 @@ conda activate conda-store-server-dev
 3. Running `conda-store` in `--standalone` mode launches celery as a
 subprocess of the web server.
 
-```
-python -m conda_store_server.server --standalone
-```
+    ```bash
+    python -m conda_store_server.server --standalone
+   ```
 
-4. Visit [localhost:8080](http://localhost:8080/)
+1. Visit [localhost:8080](http://localhost:8080/)
 
 ## Set up development environment -- conda-store-ui
 
 To get started with conda-store-ui development, there are a couple of options. This guide will help you to set up your local development environment.
 
 ### Prerequisites
 
-Before setting up conda-store ui, you must prepare your environment.
+Before setting up conda-store-ui, you must prepare your environment.
 
 We use [Docker Compose](https://docs.docker.com/compose/) to set up the infrastructure before starting ensure that you have docker-compose installed. If you need to install docker-compose, please see their [installation documentation](https://docs.docker.com/compose/install/)
 
 1. Clone the [conda-store-ui](https://github.com/conda-incubator/conda-store-ui.git) repository.
-2. Copy `.env.example` to `.env`. All default settings should work, but if you want to test against a differenct version of conda-store-server, you can specify if in the `.env` file by setting the `CONDA_STORE_SERVER_VERSION` variable to the desired version
+2. Copy `.env.example` to `.env`. All default settings should work, but if you want to test against a different version of conda-store-server, you can specify it in the `.env` file by setting the `CONDA_STORE_SERVER_VERSION` variable to the desired version
 
 ### Local Development with conda-store-ui running in Docker
 
-Running conda-store-ui in Docker is the simplest way to setup your local development environment.
+Running conda-store-ui in Docker is the simplest way to set up your local development environment.
 
 1. Run `yarn run start:docker` to start the entire development stack.
-2. Open you local browser and go to [http://localhost:8000](http://localhost:8000) so see conda-store-ui.
-3. You can then login using the default username of `username` and default password of `password`.
+Open your local browser and go to [http://localhost:8000](http://localhost:8000) so see conda-store-ui.
+3. You can then log in using the default username of `username` and default password of `password`.
 
 **Note:** Hot reloading is enabled, so when you make changes to source files, your browser will reload and reflect the changes.
 
@@ -113,8 +113,8 @@ This project uses [Conda](https://conda.io) for package management. To set up Co
 #### Run the application
 
 1. Run `yarn run start` and wait for the application to finish starting up
-2. Open you local browser and go to [http://localhost:8000](http://localhost:8000) so see conda-store-ui.
-3. You can then login using the default username of `username` and default password of `password`.
+Open your local browser and go to [http://localhost:8000](http://localhost:8000) so see conda-store-ui.
+3. You can then log in using the default username of `username` and default password of `password`.
 
 **Note:** Hot reloading is enabled, so when you make changes to source files, your browser will reload and reflect the changes.
 

docusaurus-docs/community/contribute/contribute-docs.md

@@ -12,15 +12,15 @@ The new conda-store documentation website is built using [Docusaurus 2](https://
 ### Pre-requisites
 
 1. Fork and clone the conda-store repository: `git clone https://github.com/<your-username>/conda-store.git`
-2. Install [Node.js](https://nodejs.org/en), and verify installation with: `node -v`
+2. Install [Node.js](https://nodejs.org/en), and verify the installation with `node -`v`
 
 ### Local development
 
 :::note
 You can also create an isolated environment for development.
 :::
 
-Navigate to `docusaurus-docs` repository, and run:
+Navigate to the  `/docusaurus-docs` directory, and run:
 
 ```bash
 npm install

docusaurus-docs/community/contribute/issues.md

@@ -4,7 +4,7 @@ description: Best practices for opening issues
 
 # Create and improve issues
 
-## Submit bug report or feature request
+## Submit a bug report or feature request
 
 The conda-store issue trackers are the preferred channel for bug reports, documentation requests, and submitting pull requests.
 
@@ -32,7 +32,7 @@ A few more tips:
 
 - **Getting info about your conda-store installation and environment**: You can use the command line interface to print details and even format them as Markdown to copy-paste into GitHub issues.
 
-- **Sharing long blocks of code or logs**: If you need to include long code, logs or trace backs, you can wrap them in `<details>` and `</details>`.
+- **Sharing long blocks of code or logs**: If you need to include long code, logs or tracebacks, you can wrap them in `<details>` and `</details>`.
   This collapses the content, so it only becomes visible on click, making the issue easier to read and follow.
 
 :::tip
@@ -46,10 +46,10 @@ If an issue is affecting you, start at the top of this list and complete as many
 1. Check the issue tracker, if there is an open issue for this same problem, add a reaction or more details to the issue
    to indicate that it’s affecting you (tip: make sure to also check the open pull requests for ongoing work).
 2. If there is an open issue, and you can add more detail, write a comment describing how the problem is affecting you (tip: learn to improve issues in the next section),
-   OR if you can, write up a work-around or improvement for the issue.
+   OR if you can, write up a workaround or improvement for the issue.
 3. If there is not an issue, write the most complete description of what’s happening including reproduction steps.
-4. [Optional] - Offer to help fix the issue (and it is totally expected that you ask for help; open-source maintainers want to help contributors).
-5. [Optional] - If you decide to help to fix the issue, deliver a well-crafted, tested PR.
+4. [Optional] - Offer to help fix the issue (and it is expected that you ask for help; open-source maintainers want to help contributors).
+5. [Optional] - If you decide to help fix the issue, deliver a well-crafted, tested PR.
 
 ## Improve existing issues
 
@@ -60,7 +60,7 @@ The following actions are typically useful:
 - Add missing elements that are blocking progress such as code samples to reproduce the problem.
 - Suggest better use of code formatting.
 - Suggest reformulating the title and description to make them more explicit about the problem to be solved.
-- Link to related issues or discussions while briefly describing how they are related, for instance “See also #xyz for a similar attempt at this” or “See also #xyz where the same thing happened in another cloud provider" provides context and helps the discussion.
+- Link to related issues or discussions while briefly describing how they are related, for instance, “See also #xyz for a similar attempt at this” or “See also #xyz where the same thing happened in another cloud provider" provides context and helps the discussion.
 - Summarize long discussions on issues to help new and existing contributors quickly understand the background, current status, and course of action for the issue.
 
 You can further [contribute to triaging efforts with these guidelines][triage].

docusaurus-docs/community/contribute/testing.md

@@ -46,7 +46,7 @@ $ cd conda-store-server
 $ hatch env run -e dev lint
 ```
 
-Checking that package builds
+Checking that the package builds
 
 ```shell
 $ cd conda-store-server

docusaurus-docs/community/maintenance/github-conventions.md

@@ -64,15 +64,15 @@ Here are a few guidelines for how to categorize impact across a few major types
   Is of particular importance to a key community.
 - `impact: med`: Useful to many users but not an overwhelming amount. Will be a less-obvious improvement.
   Most issues should be in this category.
-- `impact: low`: Useful but not a critical part of workflows. Is a niche use-case that only a few users may need.
+- `impact: low`: Useful but not a critical part of workflows. Is a niche use case that only a few users may need.
 
 **Bugs**
 
 - `impact: high`: Disruptive to nearly all users, or critically disruptive to many users or key communities
   (for example, instances won't work at all).
 - `impact: med`: Disruptive to some users, but not in a critical way. Only noticeable under circumstances that aren't very common.
   Most issues should be in this category.
-- `impact: low`: Minimally disruptive or cosmetic, or only affects a few users or niche use-cases.
+- `impact: low`: Minimally disruptive or cosmetic, or only affects a few users or niche use cases.
   Note that `accessibility` related issues should be `impact: high` as these are never purely cosmetic changes.
 
 ### Area tag
@@ -110,28 +110,28 @@ A few labels exist to denote particular situations:
 
 - `Close?`: to denote an issue that might need closing, either because the discussion has dried out or there are no concrete follow-up actions
 - `DO-NOT-MERGE`: to denote a PR that should not be merged yet
-- `good first issue`: these issues represents self-contained work that would make a good introduction to project development for a new contributor
+- `good first issue`: these issues represent self-contained work that would make a good introduction to project development for a new contributor
 - `Roadmap 🚀`: this issue is part of the project roadmap
 
 ## Pull requests
 
-Pull requests are usually associated with or linked to issues. The natural path is to start with an issue and move onto a pull request for resolution.
+Pull requests are usually associated with or linked to issues. The natural path is to start with an issue and move on to a pull request for resolution.
 But sometimes a new pull request is created without an associated issue.
-In such cases a new issue should be created for that pull request to engage people in a general discussion, not the technical review which is performed in the pull request itself.
+In such cases, a new issue should be created for that pull request to engage people in a general discussion, not the technical review which is performed in the pull request itself.
 
 If the PR does not need a discussion (trivial fixes, tasks, and so on), the opening of an associated issue may be skipped, but the pull request must be labeled accordingly.
 
 We use mutually exclusive GitHub labels with the prefix`status:` to classify PR's.
 
 - `status: abandoned 🗑`: this pull request has not seen activity in a while (at least a month)
-- `status: stale 🥖`: a "stale" pull request is one that is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project.
+- `status: stale 🥖`: a "stale" pull request is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project.
 - `status: in progress 🏗`: this PR is currently being worked on
 - `status: in review 👀`: this PR is currently being reviewed by the team
 - `status: declined 🙅🏻‍♀️`: this PR has been reviewed and declined for merged
 - `status: approved 💪🏾`: this PR has been reviewed and approved for merge
 - `status: blocked ⛔️`: this PR is blocked by another PR or issue
 
-GitHub notifies team member when labels are changed, so it is useful to keep the status of each pull request as close as possible with the reality.
+GitHub notifies team members when labels are changed, so it is useful to keep the status of each pull request as close as possible to reality.
 For example, if you realize that your PR needs more work after a first pass review, then change the label to `status: in progress 🏗`.
 
 **All PR's must be tagged with a status at all times**

docusaurus-docs/community/maintenance/release.md

@@ -56,7 +56,7 @@ For the release tag, there should be **NO** prepended `v`.
 Create an issue and copy & paste the steps below to release a new conda-store version. Close the issue when it is done.
 
 :::caution
-There are two packages the [conda-store](https://github.com/conda-incubator/conda-store) repository; [`conda-store`](https://github.com/conda-incubator/conda-store/tree/main/conda-store) and [`conda-store-server`](https://github.com/conda-incubator/conda-store/tree/main/conda-store-server). Make sure to update both packages when releasing a new version.
+There are two packages: the [conda-store](https://github.com/conda-incubator/conda-store) repository; [`conda-store`](https://github.com/conda-incubator/conda-store/tree/main/conda-store) and [`conda-store-server`](https://github.com/conda-incubator/conda-store/tree/main/conda-store-server). Make sure to update both packages when releasing a new version.
 :::
 
 ```md
@@ -82,7 +82,7 @@ Release captain responsible - <@gh_username>
 - [ ] Bump `conda-store` version in [`conda-store/conda-store/__init__.py`](https://github.com/conda-incubator/conda-store/blob/main/conda-store/conda_store/__init__.py)
 - [ ] Bump `conda-store-server` version in [`conda-store-server/conda-store-server/__init__.py`](https://github.com/conda-incubator/conda-store/blob/main/conda-store/conda_store/__init__.py)
 - [ ] Update the `conda-store-ui` version users in `conda-store-server` [`conda-store-server/hatch_build.py`](https://github.com/conda-incubator/conda-store/blob/main/conda-store-server/hatch_build.py)
-- [ ] Update the [CHANGELOG.md](./CHANGELOG.md) file with the new version, release date, and relevant changes[^github-activity].
+- [ ] Update the [CHANGELOG.md](https://github.com/conda-incubator/conda-store/blob/main/CHANGELOG.md) file with the new version, release date, and relevant changes[^github-activity].
 - [ ] Check the version locally with `hatch version`
 - [ ] Build and test locally
   - [ ] For `conda-store` and `conda-store-server`:
@@ -105,7 +105,7 @@ Release captain responsible - <@gh_username>
   - Call the release the current version, e.g. `2023.9.1`
   - In the **`Choose a Tag:`** dropdown, type in the release name (e.g., `2023.9.1`) and click "Create new tag"
   - In the **`Target:`** dropdown, pin it to the release commit that you've recently pushed.
-  - Add release notes in the field below[^github-activity], you can copy/paste the changelog from the [CHANGELOG.md](./CHANGELOG.md) file.
+  - Add release notes in the field below[^github-activity], you can copy/paste the changelog from the [CHANGELOG.md](https://github.com/conda-incubator/conda-store/blob/main/CHANGELOG.md) file.
 - [ ] Confirm that the release completed
   - [The `release` GitHub action job](https://github.com/conda-incubator/conda-store/blob/main/.github/workflows/release.yaml) has completed successfully in the [actions tab](https://github.com/pydata/pydata-sphinx-theme/actions).
   - [The `conda-store` PyPI version is updated](https://pypi.org/project/conda-store/)