Status/2024Q1: grammar fixes

4 files changed, 4 insertions, 4 deletions

diff --git a/website/content/en/status/report-2024-01-2024-03/cloud-init.adoc b/website/content/en/status/report-2024-01-2024-03/cloud-init.adoc
index 3a49bb4bff..1410966cf0 100644
--- a/website/content/en/status/report-2024-01-2024-03/cloud-init.adoc
+++ b/website/content/en/status/report-2024-01-2024-03/cloud-init.adoc
@@ -29,6 +29,6 @@ The work to come, in broad strokes:
 - Port lxd-agent's dependencies to FreeBSD.
 - Port lxd-agent to FreeBSD.
 
-That work will be interspersed with more improvments to cloud-init on BSDs, and more tests on different cloud providers.
+That work will be interspersed with more improvements to cloud-init on BSDs, and more tests on different cloud providers.
 
 Sponsor: The FreeBSD Foundation
diff --git a/website/content/en/status/report-2024-01-2024-03/gcc.adoc b/website/content/en/status/report-2024-01-2024-03/gcc.adoc
index 9fdecb0f40..1f39cb172e 100644
--- a/website/content/en/status/report-2024-01-2024-03/gcc.adoc
+++ b/website/content/en/status/report-2024-01-2024-03/gcc.adoc
@@ -17,7 +17,7 @@ Some work on existing bugs has already started.
 
 In particular, package:lang/gcc14-devel[] has long stayed out of date due to some issues with building the port without any BOOTSTRAP option.
 Thanks to the help of other developers and contributors (a special thank to Mark Millard), I noticed that according to the official documentation link:https://gcc.gnu.org/install/prerequisites.html[building GCC without bootstrap requires a working GCC binary] and thus I switched package:lang/gcc14-devel[] to require that a BOOTSTRAP option is set.
-However it has later been stated that bootstraping GCC using clang and libc++ is link:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632[officially supported].
+However it has later been stated that bootstrapping GCC using clang and libc++ is link:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632[officially supported].
 But it has also been stated that this is not a high priority.
 
 At the moment package:lang/gcc14-devel[] is the only GCC port requiring a BOOTSTRAP option to be set.
diff --git a/website/content/en/status/report-2024-01-2024-03/ten64-whle-honeycomb.adoc b/website/content/en/status/report-2024-01-2024-03/ten64-whle-honeycomb.adoc
index 368e9a851b..2cd21e9767 100644
--- a/website/content/en/status/report-2024-01-2024-03/ten64-whle-honeycomb.adoc
+++ b/website/content/en/status/report-2024-01-2024-03/ten64-whle-honeycomb.adoc
@@ -16,7 +16,7 @@ For DPAA2 I have local changes which will need review (or further discussion):
 * Improve Dmitry Salychev's (dsl) initial SFF/SFP code, prototyping a bus similar to MII for SFP with the hope that with more work it can grow into a larger, general FreeBSD framework and hooked it up to DPMAC.
 * With this, minimal support (still fairly hacked up) for "managed" SFP+ mode (using the Ten64 terminology) is usable on FDT-based systems using DAC and fiber cables.
 * Add more sysctl statistics to DPMAC and NI.
-In short, I mostly cleaned up some of the mess I contributed to during the initial bringup.
+In short, I mostly cleaned up some of the mess I contributed to during the initial bring-up.
 
 For the LS1088a based WHLE-LS1 systems changes include:
 * device-tree file updates.
diff --git a/website/content/en/status/report-2024-01-2024-03/wireless.adoc b/website/content/en/status/report-2024-01-2024-03/wireless.adoc
index 9fc1ec6102..0f77129009 100644
--- a/website/content/en/status/report-2024-01-2024-03/wireless.adoc
+++ b/website/content/en/status/report-2024-01-2024-03/wireless.adoc
@@ -6,7 +6,7 @@ link:https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_res
 Contact: Bjoern A. Zeeb <bz@FreeBSD.org> +
 Contact: The FreeBSD wireless mailing list <wireless@FreeBSD.org>
 
-In the first weeks of 2024 focus was on stability for 13.3-RELEASE to finally make man:iwlwifi[4] useable.
+In the first weeks of 2024 focus was on stability for 13.3-RELEASE to finally make man:iwlwifi[4] usable.
 The upcoming 14.1-RELEASE will benefit from this work too.
 The response has since generally been positive and man:iwlwifi[4] supporting chipsets up to BE200 seems mostly stable, yet still slow.