rewrote resf

Author: bcoca

docs/docsite/rst/dev_guide/plugins_documenting.rst

@@ -23,7 +23,7 @@ Every Ansible plugin must be written in Python, with modules being the main exce
   Keen Python programmers may notice that contrary to PEP 8's advice we don't put ``imports`` at the top of the file. This is because the ``DOCUMENTATION`` through ``RETURN`` sections are essentially extra docstrings for the file. The imports are placed after these special variables for the same reason as PEP 8 puts the imports after the introductory comments and docstrings. This keeps the active parts of the code together and the pieces which are purely informational apart. The decision to exclude E402 is based on readability (which is what PEP 8 is about). Documentation strings in a plugin are much more similar to module level docstrings. Placing the imports below this documentation and closer to the code, consolidates and groups all related code in a congruent manner to improve readability, debugging and understanding.
 
 
-.. _shebang:
+.. _plugins_shebang_and_encoding:
 
 Python shebang & UTF-8 coding
 ===============================
@@ -33,7 +33,7 @@ So your first line will normally be the encoding::
 
     # -*- coding: utf-8 -*-
 
-.. _copyright:
+.. _plugins_copyright:
 
 Copyright and license
 =====================
@@ -52,7 +52,7 @@ Additions to the module (for example, rewrites) are not permitted to add additio
 Any legal review will include the source control history, so an exhaustive copyright header is not necessary.
 Please do not include a copyright year. If the existing copyright statement includes a year, do not edit the existing copyright year. Any existing copyright header should not be modified without permission from the copyright author.
 
-.. _documentation_block:
+.. _plugins_documentation_block:
 
 DOCUMENTATION block
 ===================
@@ -217,7 +217,7 @@ All fields in the ``DOCUMENTATION`` block are lower-case. All fields are require
 
   * Details of any important information that doesn't fit in one of the above sections.
 
-.. _module_documents_linking:
+.. _plugins_documents_linking:
 
 Linking within plugin documentation
 -----------------------------------
@@ -284,7 +284,7 @@ Possible macros include the following:
 
 Note that ``C()``, ``B()``, and ``I()`` do **not allow escaping**, and thus cannot contain the value ``)`` as it always ends the formatting sequence. If you need to use ``)`` inside ``C()``, we recommend to use ``V()`` instead; see the above section on semantic markup.
 
-.. _plugin_docs_fragments:
+.. _plugins_docs_fragments:
 
 Documentation fragments
 -----------------------
@@ -344,7 +344,7 @@ For example, all AWS modules should include:
 
 :ref:`docfragments_collections` describes how to incorporate documentation fragments in a collection.
 
-.. _examples_block:
+.. _plugins_examples_block:
 
 EXAMPLES block
 ==============
@@ -355,7 +355,7 @@ Use a fully qualified collection name (FQCN) as a part of the plugin's name. For
 
 If your examples use boolean options, favor yes/no values, this is not always possible as some plugins will force using Python or Jinja2 specific booleans.
 
-.. _return_block:
+.. _plugins_return_block:
 
 RETURN block
 ============
@@ -401,7 +401,7 @@ Here are two example ``RETURN`` sections, one with three simple fields and one w
         type: bool
     '''
 
-.. _python_imports:
+.. _plugins_python_imports:
 
 Python imports
 ==============