Tidy up Contributors Docs (#47619)

* Tidy up docs on GitHub, direct people to docs.ansible.com
* De-duplicate documentation and move useful info

docs/docsite/rst/dev_guide/developing_modules_best_practices.rst

@@ -39,6 +39,16 @@ General guidelines & tips
 * Avoid creating caches. Ansible is designed without a central server or authority, so you cannot guarantee it will not run with different permissions, options or locations. If you need a central authority, have it on top of Ansible (for example, using bastion/cm/ci server or tower); do not try to build it into modules.
 * If you package your module(s) in an RPM, install the modules on the control machine in ``/usr/share/ansible``. Packaging modules in RPMs is optional.
 
+Functions and Methods
+=====================
+
+* Each function should be concise and should describe a meaningful amount of work.
+* "Don't repeat yourself" is generally a good philosophy.
+* Function names should use underscores: ``my_function_name``.
+* Each function's name should describes what it does.
+* Each function should have a docstring.
+* If your code is too nested, that's usually a sign the loop body could benefit from being a function. Parts of our existing code are not the best examples of this at times.
+
 Python tips
 ===========
 
@@ -148,3 +158,14 @@ Ansible conventions offer a predictable user interface across all modules, playb
 * Strive for a consistent final state (aka idempotency). If running your module twice in a row against the same system would result in two different states, see if you can redesign or rewrite to achieve consistent final state. If you can't, document the behavior and the reasons for it.
 * Provide consistent return values within the standard Ansible return structure, even if NA/None are used for keys normally returned under other options.
 * Follow additional guidelines that apply to families of modules if applicable. For example, AWS modules should follow `the Amazon guidelines <https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/amazon/GUIDELINES.md>`_
+
+Module Security
+===============
+
+* Avoid passing user input from the shell.
+* Always check return codes.
+* You must always use ``module.run_command``, not ``subprocess`` or ``Popen`` or ``os.system``.
+* Avoid using the shell unless absolutely necessary.
+* If you must use the shell, you must pass ``use_unsafe_shell=True`` to ``module.run_command``.
+* If any variables in your module can come from user input with ``use_unsafe_shell=True``, you must wrap them with ``pipes.quote(x)``.
+* When fetching URLs, use ``fetch_url`` or ``open_url`` from ``ansible.module_utils.urls``. Do not use ``urllib2``, which does not natively verify TLS certificates and so is insecure for https.

docs/docsite/rst/dev_guide/developing_modules_checklist.rst

@@ -23,6 +23,7 @@ To contribute a module to Ansible, you must:
 * include comprehensive :ref:`tests <developing_testing>` for your module
 * minimize module dependencies
 * support :ref:`check_mode <check_mode_dry>` if possible
+* ensure your code is readable
 
 Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out via `Ansible's IRC chat channel <http://irc.freenode.net>`_ or the `Ansible development mailing list <https://groups.google.com/group/ansible-devel>`_.
 

docs/docsite/rst/roadmap/index.rst

@@ -3,7 +3,21 @@
 Ansible Roadmap
 ===============
 
-The Ansible team develops a roadmap for each major Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project. 
+The Ansible team develops a roadmap for each major and minor Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.0 and 2.8 have roadmaps, but 2.7.1 does not.
+
+We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions.
+
+Each roadmap offers a *best guess*, based on the Ansible team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, etc.
+
+Each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community.
+
+You can submit feedback on the current roadmap in multiple ways:
+
+- Edit the agenda of an IRC `Core Team Meeting <https://github.com/ansible/community/blob/master/meetings/README.md>`_ (preferred)
+- Post on the ``#ansible-devel`` Freenode IRC channel
+- Email the ansible-devel list
+
+See :ref:`Ansible communication channels <communication>` for details on how to join and use the email lists and IRC channels.
 
 .. toctree::
    :maxdepth: 1
@@ -11,4 +25,3 @@ The Ansible team develops a roadmap for each major Ansible release. The latest r
    :caption: Ansible Release Roadmaps
 
    ROADMAP*
-