doc: style fixes, stop using “we”

peknis · rlubos · commit b97017893d8a · 2025-05-22T12:52:43.000+02:00
In many docs, there are style violations using “we” as the subject.
Cleaned up them.

Signed-off-by: Pekka Niskanen &lt;pekka.niskanen@nordicsemi.no&gt;
diff --git a/applications/nrf_desktop/doc/dvfs.rst b/applications/nrf_desktop/doc/dvfs.rst
@@ -79,7 +79,7 @@ You can configure each DVFS state using the following Kconfig options:
   Some of the tracked application states have associated events that inform when the state is turned on and off (for example, USB connection).
   Other states have associated application events emitted periodically when active.
   There is no event explicitly informing that state is no longer active (for example, config channel).
-  For such states, we need to define a timeout that is used to turn off the tracked state after associated application events are no longer emitted.
+  For such states, you need to define a timeout that turns off the tracked state after associated application events are no longer emitted.
 
 Frequency change retry
 ======================
diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_quick_start.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_quick_start.rst
@@ -19,7 +19,7 @@ It covers essential concepts, practical steps for implementation, and references
 Learning resources
 ******************
 
-In case you do not have experience with bootloaders, we recommend going through the following learning resources first:
+In case you do not have experience with bootloaders, read through the following learning resources first:
 
 * `Bootloaders and DFU/FOTA`_ - The page is a part of the `Nordic Developer Academy`_ courses and offers is an introduction to bootloaders, DFU, and various transport features available in the |NCS|.
 * `Adding Device Firmware Update (DFU/FOTA) Support in nRF Connect SDK`_ - The webinar provides an overview of fundamental principles and best practices for adding DFU/FOTA support in an nRF Connect SDK-based firmware.
@@ -55,7 +55,7 @@ Explore MCUboot functionality using the samples provided.
 Note that some samples are located in the `sdk-nrf`_ repository, while others are in `sdk-zephyr`_.
 All supported samples are regularly tested to ensure reliability.
 
-We recommend beginning with the :zephyr:code-sample:`smp-svr` sample and using :ref:`zephyr:mcu_mgr` for interaction from a host.
+It is recommended to begin with the :zephyr:code-sample:`smp-svr` sample and use :ref:`zephyr:mcu_mgr` for interaction from a host.
 This setup supports both UART and Bluetooth® LE connections.
 
 The following samples are supported:
@@ -112,7 +112,7 @@ Supported features and configurations
 
 MCUboot is a customizable bootloader designed to meet specific requirements.
 This page outlines the tested configurations.
-For production builds, we recommend using the same set of configurations.
+For production builds, it is recommended to use the same set of configurations.
 
 The following table is an overview of the currently supported bootloaders:
 
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_custom_pcb.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_custom_pcb.rst
@@ -14,7 +14,7 @@ Prepare your PCB
 
 First, you need to create your PCB for the nRF54H20 SoC.
 
-We highly recommend using the PCB layouts and component values provided by Nordic Semiconductor, especially for clock and power sources, considering the following limitations:
+It is highly recommended to use the PCB layouts and component values provided by Nordic Semiconductor, especially for clock and power sources, considering the following limitations:
 
 * The DC/DC inductor must be present on the PCB for any of the supported power schemes.
   Use one of the following power supply options:
diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_suit_customize_qsg.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_suit_customize_qsg.rst
@@ -61,7 +61,7 @@ For this quick start guide, you need the following development kit:
 Software requirements
 =====================
 
-For this quick start guide, we will install the following software:
+For this quick start guide, install the following software:
 
 * The full |NCS| toolchain.
   See :ref:`ug_nrf54h20_gs` for instructions on how to install the toolchain.
diff --git a/doc/nrf/app_dev/device_guides/nrf70/wifi_advanced_security_modes.rst b/doc/nrf/app_dev/device_guides/nrf70/wifi_advanced_security_modes.rst
@@ -120,7 +120,7 @@ To  build the hostapd executable, complete the following steps:
       # RADIUS clients configuration
       radius_server_clients=hostapd.radius_clients
       radius_server_auth_port=1812
-      # Enable eap_server when we use hostapd integrated EAP server instead of external RADIUS authentication
+      # Enable eap_server when using hostapd integrated EAP server instead of external RADIUS authentication
       eap_server=1
       # EAP server user database
       eap_user_file=hostapd.eap_user_tls
diff --git a/doc/nrf/libraries/bin/lwm2m_carrier/CHANGELOG.rst b/doc/nrf/libraries/bin/lwm2m_carrier/CHANGELOG.rst
@@ -960,7 +960,7 @@ liblwm2m_carrier 0.6.0
 
 Initial public release for modem firmware version 1.0.1.
 This release is intended to let users begin the integration on the Verizon Wireless device management platform and start the certification process with Verizon Wireless.
-We recommend upgrading to the next release when it becomes available.
+It is recommended to upgrade to the next release when it becomes available.
 The testing performed on this release does not meet Nordic standard for mass production release testing.
 
 
diff --git a/doc/nrf/libraries/security/trusted_storage.rst b/doc/nrf/libraries/security/trusted_storage.rst
@@ -170,7 +170,7 @@ The trusted storage library can only be used on a build without Trusted Firmware
 This means that you must use a board target without :ref:`security by separation <ug_tfm_security_by_separation>` (``/cpuapp``).
 When you build for ``/cpuapp``, you build the firmware for the application core without Cortex-M Security Extensions (CMSE) and so without TF-M.
 The library can be used directly on such a build to store important assets.
-However, for cryptographic keys we suggest to use the `PSA functions for key management`_.
+However, for cryptographic keys, use the `PSA functions for key management`_.
 These APIs will internally use this library to store persistent keys.
 
 Dependencies
diff --git a/doc/nrf/protocols/bt/bt_mesh/overview/security.rst b/doc/nrf/protocols/bt/bt_mesh/overview/security.rst
@@ -51,7 +51,7 @@ Transport encryption
 
 	As an example, consider a mesh network deployed in a hotel.
 	In this example it is desirable to limit some features that are to be controlled by the staff (like configuration of key cards or access to storage areas), and some features to be available to guests (like controlling room lighting or air conditioning).
-	For this, we can have one application key for the guests and one for the staff, allowing the messages to be relayed across the same network, while preventing the guests and the staff from reading each other's messages.
+	For this, you can have one application key for the guests and one for the staff, allowing the messages to be relayed across the same network, while preventing the guests and the staff from reading each other's messages.
 
 While application keys are used to separate access rights to different applications in the network, the device keys are used to manage devices in the network.
 
diff --git a/doc/nrf/protocols/matter/end_product/index.rst b/doc/nrf/protocols/matter/end_product/index.rst
@@ -19,7 +19,7 @@ Watch the following video for an overview of the Matter end product development
    </h1>
 
 The pages that follow deal with the preparation of the device for market launch, starting with :ref:`ug_matter_device_prerequisites` and the reference to the :ref:`ug_matter_device_factory_provisioning` guide.
-Finally, we discuss topics related to Matter certification (:ref:`ug_matter_device_attestation`, :ref:`ug_matter_device_dcl`, :ref:`ug_matter_device_certification`, :ref:`ug_matter_ecosystems_certification`, :ref:`ug_matter_device_configuring_cd`, and :ref:`ug_matter_test_event_triggers`) and :ref:`ug_matter_device_bootloader`.
+Also, topics related to Matter certification (:ref:`ug_matter_device_attestation`, :ref:`ug_matter_device_dcl`, :ref:`ug_matter_device_certification`, :ref:`ug_matter_ecosystems_certification`, :ref:`ug_matter_device_configuring_cd`, and :ref:`ug_matter_test_event_triggers`) and :ref:`ug_matter_device_bootloader` are covered.
 
 .. toctree::
    :maxdepth: 1
diff --git a/doc/nrf/protocols/matter/getting_started/adding_clusters.rst b/doc/nrf/protocols/matter/getting_started/adding_clusters.rst
@@ -303,7 +303,7 @@ Create a callback for sensor activation and deactivation
 
 Handlers for the ``Sensor Activate`` and ``Sensor Deactivate`` tasks are now ready, but the tasks are not posted to the task queue.
 The sensor is supposed to be turned on and off remotely by changing the ``OnOff`` attribute of the On/off cluster, for example using the Matter controller.
-This means that we need to implement a callback function to post one of these tasks every time the ``OnOff`` attribute changes.
+This means that you need to implement a callback function to post one of these tasks every time the ``OnOff`` attribute changes.
 
 To implement the callback function, complete the following steps:
 
diff --git a/doc/nrf/protocols/matter/getting_started/index.rst b/doc/nrf/protocols/matter/getting_started/index.rst
@@ -23,7 +23,7 @@ The pages will guide you through the following getting started process:
 #. :ref:`ug_matter_gs_testing` will guide you through the process of setting up the development environment for Matter.
    Several options are available based on your choice of the IPv6 network and the Matter controller type.
    During this process, you will have to program a Matter sample.
-   We recommend using :ref:`Matter light bulb <matter_light_bulb_sample>`.
+   It is recommended to use the :ref:`Matter light bulb <matter_light_bulb_sample>` sample.
    You will also use some of the :ref:`ug_matter_tools` for this process.
 #. :ref:`ug_matter_gs_kconfig` describes the basic Kconfig configuration if you want to start developing your own Matter application.
 #. In :ref:`ug_matter_device_advanced_kconfigs`, you will learn about more advanced Kconfig options related to Matter.
diff --git a/doc/nrf/protocols/matter/getting_started/testing/thread_one_otbr.rst b/doc/nrf/protocols/matter/getting_started/testing/thread_one_otbr.rst
@@ -45,7 +45,7 @@ Program the sample
 ==================
 
 Program the development kit for the Matter accessory device with one of available :ref:`matter_samples`.
-We recommend using :ref:`Matter light bulb <matter_light_bulb_sample>`.
+It is recommended to use the :ref:`Matter light bulb <matter_light_bulb_sample>` sample.
 
 .. rst-class:: numbered-step
 
diff --git a/doc/nrf/protocols/matter/getting_started/testing/thread_separate_otbr_linux_macos.rst b/doc/nrf/protocols/matter/getting_started/testing/thread_separate_otbr_linux_macos.rst
@@ -48,7 +48,7 @@ Program the sample
 ==================
 
 Program the development kit for the Matter accessory device with one of available :ref:`matter_samples`.
-We recommend using :ref:`Matter light bulb <matter_light_bulb_sample>`.
+It is recommended to use the :ref:`Matter light bulb <matter_light_bulb_sample>` sample.
 
 .. rst-class:: numbered-step
 
diff --git a/doc/nrf/protocols/matter/getting_started/testing/wifi_pc.rst b/doc/nrf/protocols/matter/getting_started/testing/wifi_pc.rst
@@ -36,7 +36,7 @@ Program the sample
 ==================
 
 Program the development kit for the Matter accessory device with one of available :ref:`matter_samples`.
-We recommend using :ref:`Matter light bulb <matter_light_bulb_sample>`.
+It is recommended to use the :ref:`Matter light bulb <matter_light_bulb_sample>` sample.
 
 .. rst-class:: numbered-step
 
diff --git a/doc/nrf/protocols/matter/overview/network_topologies.rst b/doc/nrf/protocols/matter/overview/network_topologies.rst
@@ -109,7 +109,7 @@ The Matter controller interacts with the accessory devices using the following p
 * Regular IPv6 communication after the accessory device joins the Thread or Wi-Fi network - to interact with each other by exchanging application messages.
   For example, to report temperature measurements of a sensor.
 
-For testing Matter applications in the |NCS|, we recommend using the CHIP Tool for Linux or macOS as the Matter controller, which is compatible with the |NCS| implementation of Matter.
+For testing Matter applications in the |NCS|, use the CHIP Tool for Linux or macOS as the Matter controller, which is compatible with the |NCS| implementation of Matter.
 
 For information about how to build and configure this controller, see the pages in the :ref:`ug_matter_gs_testing` section.
 In the Matter upstream repository, you can find information and resources for implementing `other controller setups`_ (for example, mobile Matter controller for iOS).
diff --git a/doc/nrf/protocols/wifi/stack_configuration.rst b/doc/nrf/protocols/wifi/stack_configuration.rst
@@ -96,7 +96,7 @@ The nRF Wi-Fi driver provides the following software configurations to fine-tune
        The coalescing greatly improves the throughput for small frames or under high traffic load.
      - Performance tuning and Memory savings
      - This specifies the maximum number of frames that can be coalesced into a single Wi-Fi frame.
-       More frames imply more coalescing opportunities but can add latency to the TX path as we wait for more frames to arrive.
+       More frames imply more coalescing opportunities but can add latency to the TX path as more frames are expected to arrive.
    * - :kconfig:option:`CONFIG_NRF70_RX_NUM_BUFS`
      - ``1`` to ``Unlimited`` (based on available memory in nRF70 Series device)
      - Number of RX buffers
diff --git a/doc/nrf/releases_and_maturity/known_issues.rst b/doc/nrf/releases_and_maturity/known_issues.rst
@@ -1722,7 +1722,7 @@ KRKNWK-11602: Zigbee device becomes not operable after receiving malformed packe
   * Before the |NCS| v1.9.0: Power-cycle the Zigbee device.
   * After and including the |NCS| v1.9.0: Wait for the device to restart automatically.
 
-Given these two options, we recommend to upgrade your |NCS| version to the latest available one.
+  Given these two options, it is recommended to upgrade your |NCS| version to the latest available one.
 
 .. rst-class:: v3-0-1 v3-0-0 v2-9-0-nRF54H20-1 v2-9-1 v2-9-0 v2-8-0 v2-7-0 v2-6-4 v2-6-3 v2-6-2 v2-6-1 v2-6-0 v2-5-3 v2-5-2 v2-5-1 v2-5-0 v2-4-4 v2-4-3 v2-4-2 v2-4-1 v2-4-0 v2-3-0 v2-2-0 v2-1-4 v2-1-3 v2-1-2 v2-1-1 v2-1-0 v2-0-2 v2-0-1 v2-0-0 v1-9-2 v1-9-1 v1-9-0 v1-8-0 v1-7-1 v1-7-0 v1-6-1 v1-6-0 v1-5-2 v1-5-1 v1-5-0 v1-4-2 v1-4-1 v1-4-0
 
diff --git a/doc/nrf/security/tfm/tfm_building.rst b/doc/nrf/security/tfm/tfm_building.rst
@@ -234,8 +234,8 @@ The following static partition snippet shows a non-aligned configuration for nRF
       size: 0x4000
 
 In the above example, the ``tfm_nonsecure`` partition starts at address 0x8200, which is not aligned with the requirement of 0x4000.
-Since ``tfm_secure`` spans the ``mcuboot_pad`` and ``tfm`` partitions we can decrease the size of any of them by 0x200 to fix the alignment issue.
-We will decrease the size of the (optional) ``mcuboot_pad`` partition and thus the size of the ``tfm_secure`` partition as follows:
+Since ``tfm_secure`` spans the ``mcuboot_pad`` and ``tfm`` partitions, you can decrease the size of any of them by 0x200 to fix the alignment issue.
+Decrease the size of the (optional) ``mcuboot_pad`` partition, and thus the size of the ``tfm_secure`` partition, as follows:
 
 .. code-block:: console
 
diff --git a/doc/nrf/templates/cheat_sheet.rst b/doc/nrf/templates/cheat_sheet.rst
@@ -142,7 +142,7 @@ Tables
 | body row 2             | ...        | ...      |          |
 +------------------------+------------+----------+----------+
 
-We can create more complex tables as ASCII art:
+You can create more complex tables as ASCII art:
 
 +------------------------+------------+----------+----------+
 | Header row, column 1   | Header 2   | Header 3 | Header 4 |
@@ -177,7 +177,7 @@ We can create more complex tables as ASCII art:
      - On a stick!
    * - Crunchy Frog
      - 1.49
-     - If we took the bones out, it wouldn't be
+     - If you took the bones out, it wouldn't be
        crunchy, now would it?
    * - Gannet Ripple
      - 1.99
@@ -192,7 +192,7 @@ We can create more complex tables as ASCII art:
    :widths: 15, 10, 30
 
    "Albatross", 2.99, "On a stick!"
-   "Crunchy Frog", 1.49, "If we took the bones out, it wouldn't be
+   "Crunchy Frog", 1.49, "If you took the bones out, it wouldn't be
    crunchy, now would it?"
    "Gannet Ripple", 1.99, "On a stick!"
 
@@ -618,7 +618,7 @@ Read out an objects.inv file::
 Doxygen
 =======
 
-We usually include doxygen groups::
+Doxygen groups are included in the API documents::
 
    .. doxygengroup:: group_name
 
diff --git a/samples/cellular/nrf_cloud_multi_service/README.rst b/samples/cellular/nrf_cloud_multi_service/README.rst
@@ -1176,7 +1176,7 @@ You can provision and onboard your device in one of the following ways:
    The nRF Cloud Provisioning Service auto-onboarding is compatible with CoAP, REST and MQTT connectivity with nRF Cloud.
 
    With this method, use the `Serial Terminal app`_ and the nRF Cloud portal.
-   We recommend that the device ID used in the nRF Cloud portal is UUID format and not the 'nrf-\ *IMEI*\ ' format.
+   The recommended format of the device ID used in the nRF Cloud portal is UUID and not the 'nrf-\ *IMEI*\ ' format.
    See `device claiming <nRF Cloud device claiming_>`_ for more information.
 
 .. _nrf_cloud_multi_service_standard_onboarding:
diff --git a/samples/cellular/udp/README.rst b/samples/cellular/udp/README.rst
@@ -128,9 +128,7 @@ The following configurations are recommended for low power behavior:
 * :ref:`CONFIG_UDP_RAI_ENABLE <CONFIG_UDP_RAI_ENABLE>` enabled.
 
 .. note::
-   In applications where downlink messaging from the cloud to the device is expected, we recommend setting
-   the :kconfig:option:`CONFIG_LTE_PSM_REQ_RAT` option to a higher value than ``0`` to ensure data is received
-   before the device enters PSM.
+   In applications where downlink messaging from the cloud to the device is expected, it is recommended to set the :kconfig:option:`CONFIG_LTE_PSM_REQ_RAT` option to a value higher than ``0`` to ensure data is received before the device enters PSM.
 
 PSM and eDRX timers are set with binary strings that signify a time duration in seconds.
 For a conversion chart of these timer values, see the `Power saving mode setting`_ section in the nRF9160 AT Commands Reference Guide or the `same section <nRF91x1 Power saving mode setting_>`_ in the nRF91x1 AT Commands Reference Guide, depending on the SiP you are using.
diff --git a/samples/event_manager_proxy/README.rst b/samples/event_manager_proxy/README.rst
@@ -110,14 +110,14 @@ Complete the following steps to program the sample:
 Testing
 =======
 
-After programming the sample to your development kit for both cores, test it by performing the following steps:
+|test_sample|
 
 1. |connect_terminal|
 #. Reset the kit.
 #. Observe that output logged on two UART serial terminals.
    One for the host and the other for the remote core.
 
-   * On the host core, we expect the following messages:
+   * On the host core, the following messages are expected:
 
      .. code-block:: console
 
@@ -174,7 +174,7 @@ After programming the sample to your development kit for both cores, test it by
         [00:00:07.015,502] <inf> event_manager: e: ack_event
 
 Now all the measurement and control events are generated on the remote core and passed to the host core, where the statistics are generated.
-On the remote core, we can also see an :c:type:`ack_event`, which is not passed to the host core.
+On the remote core, you can also see an :c:type:`ack_event` that is not passed to the host core.
 
 Dependencies
 ************
