Fix minor nits with the devref's contribute section

Be more explicit on the adoption of Externally Hosted Plugins, which
are based on Extra.d Hooks.

Partially-implement: blueprint core-vendor-decomposition

Change-Id: I4510aaa74c8853278b1c17757d4f4fa67554093a

diff --git a/doc/source/devref/contribute.rst b/doc/source/devref/contribute.rst
index 0b2f2021bbfb41ac122b33e06c85fc484c158066..ce957d747156a79a4a2dc39f520c92890787252a 100644 (file)
--- a/doc/source/devref/contribute.rst
+++ b/doc/source/devref/contribute.rst
@@ -221,12 +221,12 @@ make sense depending on whether you are contributing a new or existing plugin or
 driver.
 
 If you are contributing a new plugin, the approach to choose should be based on
-`Extras.d Hooks <http://docs.openstack.org/developer/devstack/plugins.html#extras-d-hooks>`_.
+`Extras.d Hooks' externally hosted plugins <http://docs.openstack.org/developer/devstack/plugins.html#extras-d-hooks>`_.
 With the extra.d hooks, the DevStack integration is colocated with the vendor integration
 library, and it leads to the greatest level of flexibility when dealing with DevStack based
 dev/test deployments.
 
-Having said that, most Neutron Plugins developed in the past likely already have
+Having said that, most Neutron plugins developed in the past likely already have
 integration with DevStack in the form of `neutron_plugins <https://github.com/openstack-dev/devstack/tree/master/lib/neutron_plugins>`_.
 If the plugin is being decomposed in vendor integration plus vendor library, it would
 be necessary to adjust the instructions provided in the neutron_plugin file to pull the