diff --git a/docs/en/debug/asset_tracking.md b/docs/en/debug/asset_tracking.md
index e933596944..57a962c552 100644
--- a/docs/en/debug/asset_tracking.md
+++ b/docs/en/debug/asset_tracking.md
@@ -1,6 +1,6 @@
# Asset Tracking
-
+
PX4 can track and log detailed information about external hardware devices connected to the flight controller.
This enables unique identification of vehicle parts throughout their operational lifetime using device IDs, serial numbers, and version information.
diff --git a/docs/en/middleware/uxrce_dds.md b/docs/en/middleware/uxrce_dds.md
index dd8bf2af52..f273efb476 100644
--- a/docs/en/middleware/uxrce_dds.md
+++ b/docs/en/middleware/uxrce_dds.md
@@ -324,7 +324,7 @@ The configuration can be done using the [UXRCE-DDS parameters](../advanced_confi
- [UXRCE_DDS_NS_IDX](../advanced_config/parameter_reference.md#UXRCE_DDS_NS_IDX) : Index-based namespace definition.
Setting this parameter to any value other than `-1` creates a namespace with the prefix `uav_` and the specified value, e.g. `uav_0`, `uav_1`, etc.
See [namespace](#customizing-the-namespace) for methods to define richer or arbitrary namespaces.
- - [`UXRCE_DDS_FLCTRL`](../advanced_config/parameter_reference.md#UXRCE_DDS_FLCTRL) : Serial port hardware flow control enable.
+ - [`UXRCE_DDS_FLCTRL`](../advanced_config/parameter_reference.md#UXRCE_DDS_FLCTRL) : Serial port hardware flow control enable.
To use hardware flow control, a custom MicroXRCE Agent needs to be adopted. Please refer to [this PR](https://github.com/eProsima/Micro-XRCE-DDS-Agent/pull/407) for the required changes, cherry-pick them on top of the [agent version](#build-run-within-ros-2-workspace) you need to use and then run the agent with the additional `--flow-control` option.
::: info
@@ -542,7 +542,7 @@ Each (`topic`,`type`) pairs defines:
4. The message type (`VehicleOdometry`, `VehicleStatus`, `OffboardControlMode`, etc.) and the ROS 2 package (`px4_msgs`) that is expected to provide the message definition.
5. **(Optional)**: An additional `rate_limit` field (only for publication entries), which specifies the maximum rate (Hz) at which messages will be published on this topic by PX4 to ROS 2.
If left unspecified, the maximum publication rate limit is set to 100 Hz.
-6. **(Optional)**: An additional `instance` field (only for publication entries), which lets you select which instance of a [multi-instance topic](./uorb.md#multi-instance) you want to be published to ROS 2.
+6. **(Optional)**: An additional `instance` field (only for publication entries), which lets you select which instance of a [multi-instance topic](./uorb.md#multi-instance) you want to be published to ROS 2.
If provided, this option changes the ROS 2 topic name of the advertised uORB topic appending the instance number: `fmu/out/[uorb topic name][instance]` (plus eventual namespace and message version).
In the example above the final topic name would be `/fmu/out/vehicle_imu1`.
@@ -566,7 +566,7 @@ Add a topic to the `subscriptions_multi` section to:
- Without `route_field`, this guarantees separation between PX4 and ROS 2 publishers, but not among multiple ROS 2 publishers. In that scenario, their messages will still be routed to the same instance.
- This is the desired behavior, for example, when you want PX4 to log the readings of two equal sensors; they will both publish on the same topic, but one will use instance 0 and the other will use instance 1.
- Optionally, add `route_field` and `max_instances` to demultiplex a single ROS 2 topic into multiple uORB instances based on a message field value:
+ Optionally, add `route_field` and `max_instances` to demultiplex a single ROS 2 topic into multiple uORB instances based on a message field value:
- Each unique value of `route_field` is dynamically assigned to a separate uORB instance on first arrival, up to `max_instances`.
For example, a single `/fmu/in/aux_global_position` ROS 2 topic can be demultiplexed to up to 4 separate uORB instances of `aux_global_position`, with each unique `id` value mapped to its own instance.
diff --git a/docs/en/middleware/zenoh.md b/docs/en/middleware/zenoh.md
index a152e0edf7..e4ef2c9976 100644
--- a/docs/en/middleware/zenoh.md
+++ b/docs/en/middleware/zenoh.md
@@ -1,6 +1,6 @@
# Zenoh (PX4 ROS 2 rmw_zenoh)
-
+
:::warning Experimental
At the time of writing, PX4 Zenoh-pico is experimental, and hence subject to change.
diff --git a/docs/en/neural_networks/raptor.md b/docs/en/neural_networks/raptor.md
index c82b78ad6c..d8ab4ee98b 100644
--- a/docs/en/neural_networks/raptor.md
+++ b/docs/en/neural_networks/raptor.md
@@ -1,6 +1,6 @@
# RAPTOR: A Neural Network Module for Adaptive Quadrotor Control
-
+
::: warning
This is an experimental module.
diff --git a/docs/en/releases/1.17.md b/docs/en/releases/1.17.md
index 2115e92400..5e04b9f0ea 100644
--- a/docs/en/releases/1.17.md
+++ b/docs/en/releases/1.17.md
@@ -13,7 +13,7 @@ const { site } = useData();
-This contains changes to PX4 planned for PX4 v1.17 (since the last major release [PX v1.16](../releases/1.16.md)).
+This contains changes in PX4 v1.17 (since the last major release [PX v1.16](../releases/1.16.md)).
::: warning
PX4 v1.17 is in alpha/beta testing.
diff --git a/docs/en/releases/index.md b/docs/en/releases/index.md
index cb00c401d5..229e0d3b80 100644
--- a/docs/en/releases/index.md
+++ b/docs/en/releases/index.md
@@ -3,7 +3,7 @@
A list of PX4 release notes, they contain a list of the changes that went into each release, explaining the included features, bug fixes, deprecations and updates in detail.
- [main](../releases/main.md) (changes planned for v1.18 or later)
-- [v1.17](../releases/1.17.md) (changes planned for v1.17, since v1.16)
+- [v1.17](../releases/1.17.md) (changes in v1.17, since v1.16)
- [v1.16](../releases/1.16.md)
- [v1.15](../releases/1.15.md)
- [v1.14](../releases/1.14.md)
diff --git a/docs/en/releases/release_process.md b/docs/en/releases/release_process.md
index beda62e000..230af4fb9b 100644
--- a/docs/en/releases/release_process.md
+++ b/docs/en/releases/release_process.md
@@ -45,7 +45,11 @@ Release notes are built incrementally in [`main.md`](../releases/main.md), which
3. Reset `main.md` to a clean template for the next release cycle
4. Verify that documentation for all included contributions is complete
5. Search for instances of `main (planned for:` and replace with the release version now that it is known.
- So, for example `` is replaced with ``
+ So, for example `` is replaced with ``.
+
+ Note that once the name of the next version is confirmed, badges may use the second form (e.g. ``.
+6. Search for instances of ``.
+ Remove this for features that are considered core and/or stable.
::: tip
Community members are encouraged to document changes as they are merged into `main`. This distributes the documentation workload and ensures changes are captured while they're fresh.