diff --git a/docs/docsite/rst/playbook_guide/playbooks_blocks.rst b/docs/docsite/rst/playbook_guide/playbooks_blocks.rst
index 87dec31bd64..a628164655b 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_blocks.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_blocks.rst
@@ -41,7 +41,7 @@ All tasks in a block inherit directives applied at the block level. Most of what
       when: ansible_facts['distribution'] == 'CentOS'
       become: true
       become_user: root
-      ignore_errors: yes
+      ignore_errors: true
 
 In the example above, the 'when' condition will be evaluated before Ansible runs each of the three tasks in the block. All three tasks also inherit the privilege escalation directives, running as the root user. Finally, ``ignore_errors: yes`` ensures that Ansible continues to execute the playbook even if some of the tasks fail.
 
@@ -153,7 +153,7 @@ You can use blocks with ``flush_handlers`` in a rescue task to ensure that all h
         - name: Print a message
           ansible.builtin.debug:
             msg: 'I execute normally'
-          changed_when: yes
+          changed_when: true
           notify: run me even after an error
 
         - name: Force a failure
diff --git a/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst b/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst
index 9c131d86b3c..4b21f7cf924 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_checkmode.rst
@@ -37,14 +37,14 @@ For example:
   tasks:
     - name: This task will always make changes to the system
       ansible.builtin.command: /something/to/run --even-in-check-mode
-      check_mode: no
+      check_mode: false
 
     - name: This task will never make changes to the system
       ansible.builtin.lineinfile:
         line: "important config"
         dest: /path/to/myconfig.conf
         state: present
-      check_mode: yes
+      check_mode: true
       register: changes_to_important_config
 
 Running single tasks with ``check_mode: yes`` can be useful for testing Ansible modules, either to test the module itself or to test the conditions under which a module would make changes. You can register variables (see :ref:`playbooks_conditionals`) on these tasks for even more detail on the potential changes.
@@ -104,4 +104,4 @@ Because the ``--diff`` option can reveal sensitive information, you can disable
         owner: root
         group: root
         mode: '0600'
-      diff: no
+      diff: false
diff --git a/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst b/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst
index b13a7bd33ae..f920fd74b4b 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_conditionals.rst
@@ -29,7 +29,7 @@ The simplest conditional statement applies to a single task. Create the task, th
         ansible.posix.seboolean:
           name: mysql_connect_any
           state: true
-          persistent: yes
+          persistent: true
         when: ansible_selinux.status == "enabled"
         # all variables can be used directly in conditionals without double curly braces
 
diff --git a/docs/docsite/rst/playbook_guide/playbooks_debugger.rst b/docs/docsite/rst/playbook_guide/playbooks_debugger.rst
index 79ac720e09e..79d7c31ee09 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_debugger.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_debugger.rst
@@ -138,7 +138,7 @@ After Ansible invokes the debugger, you can use the seven :ref:`debugger command
 
     - hosts: test
       debugger: on_failed
-      gather_facts: no
+      gather_facts: false
       vars:
         var1: value1
       tasks:
@@ -253,7 +253,7 @@ Update args command
 
     - hosts: test
       strategy: debug
-      gather_facts: yes
+      gather_facts: true
       vars:
         pkg_name: not_exist
       tasks:
diff --git a/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst b/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst
index 389ef0b28de..d94fc1ef46c 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_error_handling.rst
@@ -20,7 +20,7 @@ By default Ansible stops executing tasks on a host when a task fails on that hos
 
     - name: Do not count this as a failure
       ansible.builtin.command: /bin/false
-      ignore_errors: yes
+      ignore_errors: true
 
 The ``ignore_errors`` directive only works when the task is able to run and returns a value of 'failed'. It does not make Ansible ignore undefined variable errors, connection failures, execution issues (for example, missing packages), or syntax errors.
 
@@ -37,7 +37,7 @@ You can ignore a task failure due to the host instance being 'UNREACHABLE' with
 
     - name: This executes, fails, and the failure is ignored
       ansible.builtin.command: /bin/true
-      ignore_unreachable: yes
+      ignore_unreachable: true
 
     - name: This executes, fails, and ends the play for this host
       ansible.builtin.command: /bin/true
@@ -47,14 +47,14 @@ And at the playbook level:
 .. code-block:: yaml
 
     - hosts: all
-      ignore_unreachable: yes
+      ignore_unreachable: true
       tasks:
       - name: This executes, fails, and the failure is ignored
         ansible.builtin.command: /bin/true
 
       - name: This executes, fails, and ends the play for this host
         ansible.builtin.command: /bin/true
-        ignore_unreachable: no
+        ignore_unreachable: false
 
 .. _resetting_unreachable:
 
diff --git a/docs/docsite/rst/playbook_guide/playbooks_loops.rst b/docs/docsite/rst/playbook_guide/playbooks_loops.rst
index a2090ccbf11..73d5a8a51c7 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_loops.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_loops.rst
@@ -239,7 +239,7 @@ You can use Jinja2 expressions to iterate over complex lists. For example, a loo
       community.mysql.mysql_user:
         name: "{{ item[0] }}"
         priv: "{{ item[1] }}.*:ALL"
-        append_privs: yes
+        append_privs: true
         password: "foo"
       loop: "{{ ['alice', 'bob'] | product(['clientdb', 'employeedb', 'providerdb']) | list }}"
 
@@ -448,7 +448,7 @@ Variable                    Description
 ::
 
       loop_control:
-        extended: yes
+        extended: true
 
 .. note:: When using ``loop_control.extended`` more memory will be utilized on the control node. This is a result of ``ansible_loop.allitems`` containing a reference to the full loop data for every loop. When serializing the results for display in callback plugins within the main ansible process, these references may be dereferenced causing memory usage to increase.
 
@@ -459,8 +459,8 @@ To disable the ``ansible_loop.allitems`` item, to reduce memory consumption, set
 ::
 
       loop_control:
-        extended: yes
-        extended_allitems: no
+        extended: true
+        extended_allitems: false
 
 Accessing the name of your loop_var
 -----------------------------------
diff --git a/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst b/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst
index 3b28d385a8d..7222ab33968 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_privilege_escalation.rst
@@ -42,7 +42,7 @@ For example, to manage a system service (which requires ``root`` privileges) whe
       service:
         name: httpd
         state: started
-      become: yes
+      become: true
 
 To run a command as the ``apache`` user:
 
@@ -50,7 +50,7 @@ To run a command as the ``apache`` user:
 
     - name: Run a command as the apache user
       command: somecommand
-      become: yes
+      become: true
       become_user: apache
 
 To do something as the ``nobody`` user when the shell is nologin:
@@ -59,7 +59,7 @@ To do something as the ``nobody`` user when the shell is nologin:
 
     - name: Run a command as nobody
       command: somecommand
-      become: yes
+      become: true
       become_method: su
       become_user: nobody
       become_flags: '-s /bin/sh'
@@ -316,7 +316,7 @@ To set ``enable`` mode for a specific task, add ``become`` at the task level:
      arista.eos.eos_facts:
        gather_subset:
          - "!hardware"
-     become: yes
+     become: true
      become_method: enable
 
 To set enable mode for all tasks in a single play, add ``become`` at the play level:
@@ -324,7 +324,7 @@ To set enable mode for all tasks in a single play, add ``become`` at the play le
 .. code-block:: yaml
 
    - hosts: eos-switches
-     become: yes
+     become: true
      become_method: enable
      tasks:
        - name: Gather facts (eos)
@@ -344,7 +344,7 @@ Often you wish for all tasks in all plays to run using privilege mode, that is b
    ansible_connection: ansible.netcommon.network_cli
    ansible_network_os: arista.eos.eos
    ansible_user: myuser
-   ansible_become: yes
+   ansible_become: true
    ansible_become_method: enable
 
 Passwords for enable mode
@@ -374,7 +374,7 @@ Ansible still supports ``enable`` mode with ``connection: local`` for legacy net
            gather_subset:
              - "!hardware"
          provider:
-           authorize: yes
+           authorize: true
            auth_pass: " {{ secret_auth_pass }}"
 
 We recommend updating your playbooks to use ``become`` for network-device ``enable`` mode consistently. The use of ``authorize`` and of ``provider`` dictionaries will be deprecated in future. Check the :ref:`platform_options` documentation for details.
@@ -423,7 +423,7 @@ task:
 
     - Check my user name
       ansible.windows.win_whoami:
-      become: yes
+      become: true
 
 The output will look something similar to the below:
 
@@ -725,9 +725,9 @@ Here are some examples of how to use ``become_flags`` with Windows tasks:
     ansible.windows.win_copy:
       src: \\server\share\data\file.txt
       dest: C:\temp\file.txt
-      remote_src: yes
+      remote_src: true
     vars:
-      ansible_become: yes
+      ansible_become: true
       ansible_become_method: runas
       ansible_become_user: DOMAIN\user
       ansible_become_password: Password01
@@ -735,12 +735,12 @@ Here are some examples of how to use ``become_flags`` with Windows tasks:
 
   - name: run a command under a batch logon
     ansible.windows.win_whoami:
-    become: yes
+    become: true
     become_flags: logon_type=batch
 
   - name: run a command and not load the user profile
     ansible.windows.win_whomai:
-    become: yes
+    become: true
     become_flags: logon_flags=
 
 
diff --git a/docs/docsite/rst/playbook_guide/playbooks_prompts.rst b/docs/docsite/rst/playbook_guide/playbooks_prompts.rst
index 61bd034ba0d..1afb3fa028f 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_prompts.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_prompts.rst
@@ -19,7 +19,7 @@ Here is a most basic example:
 
         - name: username
           prompt: What is your username?
-          private: no
+          private: false
 
         - name: password
           prompt: What is your password?
@@ -56,9 +56,9 @@ You can hash the entered value so you can use it, for instance, with the user mo
 
      - name: my_password2
        prompt: Enter password2
-       private: yes
+       private: true
        encrypt: sha512_crypt
-       confirm: yes
+       confirm: true
        salt_size: 7
 
 If you have `Passlib <https://passlib.readthedocs.io/en/stable/>`_ installed, you can use any crypt scheme the library supports:
@@ -107,8 +107,8 @@ Some special characters, such as ``{`` and ``%`` can create templating errors. I
    vars_prompt:
      - name: my_password_with_weird_chars
        prompt: Enter password
-       unsafe: yes
-       private: yes
+       unsafe: true
+       private: true
 
 .. seealso::
 
diff --git a/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst b/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst
index dee8573752f..dc230da2dab 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_reuse_roles.rst
@@ -324,8 +324,7 @@ role ``meta/argument_specs.yml`` file. All fields are lower-case.
            * Ensure that the default value in the docs matches the default value in the code. The actual
              default for the role variable will always come from ``defaults/main.yml``.
            * The default field must not be listed as part of the description, unless it requires additional information or conditions.
-           * If the option is a boolean value, you can use any of the boolean values recognized by Ansible:
-             (such as true/false or yes/no).  Choose the one that reads better in the context of the option.
+           * If the option is a boolean value, you should use `true/false` if you want to be compatible with `ansible-lint`.
 
         :choices:
 
diff --git a/docs/docsite/rst/playbook_guide/playbooks_tags.rst b/docs/docsite/rst/playbook_guide/playbooks_tags.rst
index 0e176d0f3ac..4da0af02f4a 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_tags.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_tags.rst
@@ -67,7 +67,7 @@ You can apply the same tag to more than one individual task. This example tags s
      ansible.builtin.service:
        name: ntpd
        state: started
-       enabled: yes
+       enabled: true
      tags: ntp
 
    - name: Install NFS utils
@@ -147,7 +147,7 @@ If you want to apply a tag to many, but not all, of the tasks in your play, use
        ansible.builtin.service:
          name: ntpd
          state: started
-         enabled: yes
+         enabled: true
 
    - name: Install NFS utils
      ansible.builtin.yum:
@@ -183,7 +183,7 @@ If all the tasks in a play should get the same tag, you can add the tag at the l
        ansible.builtin.service:
          name: ntpd
          state: started
-         enabled: yes
+         enabled: true
 
    - hosts: fileservers
      tags: filesharing
diff --git a/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst b/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst
index 3e8cb5ce803..e90947e6f54 100644
--- a/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst
+++ b/docs/docsite/rst/playbook_guide/playbooks_vars_facts.rst
@@ -537,7 +537,7 @@ By default, Ansible gathers facts at the beginning of each play. If you do not n
 .. code-block:: yaml
 
     - hosts: whatever
-      gather_facts: no
+      gather_facts: false
 
 Adding custom facts
 -------------------
@@ -615,7 +615,7 @@ By default, fact gathering runs once at the beginning of each play. If you creat
       - name: Create directory for ansible custom facts
         ansible.builtin.file:
           state: directory
-          recurse: yes
+          recurse: true
           path: /etc/ansible/facts.d
 
       - name: Install custom ipmi fact