Backportapalooza 11 10 (#79361)

* update backport instructions to 2.14 (#79354)

(cherry picked from commit 183c34db65)

* docfix for ssh_args FAQ (#79308)

(cherry picked from commit f9451dfaf8)

* communication.rst: add Storage WG info (#79359)

(cherry picked from commit 284e642cb9)

* Add note to command_line_tools.rst (#79351)

Documentation fix for #69390

(cherry picked from commit d02f96b78c)

Co-authored-by: prasadpatil49 <51715670+prasadpatil49@users.noreply.github.com>
Co-authored-by: Andrew Klychkov <aklychko@redhat.com>
Co-authored-by: saranti <tsarantis@proton.me>

docs/docsite/rst/command_guide/command_line_tools.rst

@@ -6,6 +6,9 @@ Working with command line tools
 Most users are familiar with `ansible` and `ansible-playbook`, but those are not the only utilities Ansible provides.
 Below is a complete list of Ansible utilities. Each page contains a description of the utility and a listing of supported parameters.
 
+.. note::
+    You should not run most Ansible CLI tools in parallel against the same targets.
+    
 .. toctree::
    :maxdepth: 1
 

docs/docsite/rst/community/communication.rst

@@ -122,6 +122,7 @@ Many of our community `Working Groups <https://github.com/ansible/community/wiki
 - `Network Working Group <https://github.com/ansible/community/wiki/Network>`_ - Matrix: `#network:ansible.com <https://matrix.to:/#/#network:ansible.com>`_ | IRC: ``#ansible-network``
 - `PostgreSQL Working Group <https://github.com/ansible-collections/community.postgresql/wiki/PostgreSQL-Working-Group>`_ - Matrix: `#postgresql:ansible.com <https://matrix.to:/#/#postgresql:ansible.com>`_
 - `Remote Management Working Group <https://github.com/ansible/community/issues/409>`_ - Matrix: `#devel:ansible.com <https://matrix.to:/#/#devel:ansible.com>`_ | IRC: ``#ansible-devel``
+- `Storage Working Group <https://github.com/ansible/community/wiki/Storage>`_ - Matrix: `#storage:ansible.com <https://matrix.to/#/#storage:ansible.com>`_
 - `Testing Working Group <https://github.com/ansible/community/wiki/Testing>`_  - Matrix: `#devel:ansible.com <https://matrix.to:/#/#devel:ansible.com>`_ | IRC: ``#ansible-devel``
 - `VMware Working Group <https://github.com/ansible/community/wiki/VMware>`_ - Matrix: `#vmware:ansible.com <https://matrix.to:/#/#vmware:ansible.com>`_ | IRC: ``#ansible-vmware``
 - `Windows Working Group <https://github.com/ansible/community/wiki/Windows>`_ - Matrix: `#windows:ansible.com <https://matrix.to:/#/#windows:ansible.com>`_ | IRC: ``#ansible-windows``

docs/docsite/rst/community/development_process.rst

@@ -23,8 +23,8 @@ If you want to follow the conversation about what features will be added to ``an
 * the :ref:`ansible-core project branches and tags <core_branches_and_tags>`
 * various GitHub `projects <https://github.com/ansible/ansible/projects>`_ - for example:
 
-   * the `2.12 release project <https://github.com/ansible/ansible/projects/43>`_
-   * the `core documentation project <https://github.com/ansible/ansible/projects/27>`_
+   * the `2.15 release project <https://github.com/ansible/ansible/projects/46>`_
+   * the `core documentation project <https://github.com/orgs/ansible/projects/94/views/1>`_
 
 
 .. _community_pull_requests:
@@ -330,7 +330,7 @@ We do **not** backport features.
 
    These instructions assume that:
 
-    * ``stable-2.13`` is the targeted release branch for the backport
+    * ``stable-2.14`` is the targeted release branch for the backport
     * ``https://github.com/ansible/ansible.git`` is configured as a ``git remote`` named ``upstream``. If you do not use a ``git remote`` named ``upstream``, adjust the instructions accordingly.
     * ``https://github.com/<yourgithubaccount>/ansible.git`` is configured as a ``git remote`` named ``origin``. If you do not use a ``git remote`` named ``origin``, adjust the instructions accordingly.
 
@@ -339,7 +339,7 @@ We do **not** backport features.
 .. code-block:: shell
 
        git fetch upstream
-       git checkout -b backport/2.13/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.13
+       git checkout -b backport/2.14/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.14
 
 #. Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary:
 
@@ -353,15 +353,15 @@ We do **not** backport features.
 
 .. code-block:: shell
 
-       git push origin backport/2.13/[PR_NUMBER_FROM_DEVEL]
+       git push origin backport/2.14/[PR_NUMBER_FROM_DEVEL]
 
-#. Submit the pull request for ``backport/2.13/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.13`` branch
+#. Submit the pull request for ``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` against the ``stable-2.14`` branch
 
 #. The Release Manager will decide whether to merge the backport PR before the next minor release. There isn't any need to follow up. Just ensure that the automated tests (CI) are green.
 
 .. note::
 
-    The branch name ``backport/2.13/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
+    The branch name ``backport/2.14/[PR_NUMBER_FROM_DEVEL]`` is somewhat arbitrary but conveys meaning about the purpose of the branch. This branch name format is not required, but it can be helpful, especially when making multiple backport PRs for multiple stable branches.
 
 .. note::
 

docs/docsite/rst/reference_appendices/faq.rst

@@ -138,7 +138,7 @@ or globally by setting ``ssh_args`` in ``ansible.cfg``.
 How do I get Ansible to notice a dead target in a timely manner?
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-You can add ``-o ServerAliveInterval=NumberOfSeconds`` in ``ssh_args`` from ``ansible.cfg``. Without this option,
+You can add ``-o ServerAliveInterval=NumberOfSeconds`` with the ``ssh_args`` parameter in `SSH connection plugin <https://docs.ansible.com/ansible-core/devel/collections/ansible/builtin/ssh_connection.html#parameter-ssh_args>`_. Without this option,
 SSH and therefore Ansible will wait until the TCP connection times out. Another solution is to add ``ServerAliveInterval``
 into your global SSH configuration. A good value for ``ServerAliveInterval`` is up to you to decide; keep in mind that
 ``ServerAliveCountMax=3`` is the SSH default so any value you set will be tripled before terminating the SSH session.