diff --git a/docs/3-Contributing/1-Building-Fleet.md b/docs/3-Contributing/1-Building-Fleet.md index f7fd40c252..a6f67c43b6 100644 --- a/docs/3-Contributing/1-Building-Fleet.md +++ b/docs/3-Contributing/1-Building-Fleet.md @@ -47,7 +47,7 @@ npm install -g yarn Note: all packages default to the latest versions. To specify a version, place `--version ` after each package. You may also install all packages manually from their websites if you prefer. -After the packages have installed, you must use **Git Bash** to continue with the [next section](#clone-and-build). +After the packages have installed, you must use **Git Bash** to continue with the [next section](#clone-and-build). ### Clone and build @@ -71,7 +71,7 @@ To setup a working local development environment, you must install the following Once you have those minimum requirements, check out this [Loom video](https://www.loom.com/share/e7439f058eb44c45af872abe8f8de4a1) that walks through starting up a local development environment for Fleet. -For a text-based walkthrough, continue through the following steps: +For a text-based walkthrough, continue through the following steps: First, you will need to install Fleet's dependencies. @@ -154,7 +154,7 @@ To start the Fleet server backed by the Docker development infrastructure, run t ./build/fleet serve --dev ``` -The server is accessible by default at [https://localhost:8080](https://localhost:8080). +The server is accessible by default at [https://localhost:8080](https://localhost:8080). Note that `--dev` requires the use of `make generate-dev` as the server will not use bundled assets in this mode (you may see an error mentioning a template not found when visiting the website otherwise). By default, Fleet will try to connect to servers running on default ports on `localhost`. Depending on your browser's settings, you may have to click through a security warning. diff --git a/docs/3-Contributing/4-Committing-Changes.md b/docs/3-Contributing/4-Committing-Changes.md index 426c3002d2..ac99857ae9 100644 --- a/docs/3-Contributing/4-Committing-Changes.md +++ b/docs/3-Contributing/4-Committing-Changes.md @@ -35,7 +35,7 @@ There are two ways to write CHANGELOG files: 1. Having an individual responsible for writing the changes as part of the release process. 2. Writing the changelog collaborately and whoever creates the release just collects the text and organizes the information rather than generating it. -Fleet is currently doing 1. but if you are reading this it means we are already going with 2. In order to do so, we will start using the concept of changes files. +Fleet is doing 2, using the concept of changes files. #### What is it? @@ -55,7 +55,7 @@ As part of the release process, whoever is cutting the release will fold in the As it's shown in the example above, the exact contents of the file should follow as much as possible the format that the entry will have in the CHANGELOG file. So the job of the person tagging the release is just copy and paste. -All grammar checks and corrections should happen as part of the PR review. +All grammar checks and corrections should happen as part of the PR review. #### What does not need a changes file?