fix doc links

This patch fixes some doc links that were found when testing commit
I48b4dde3ffd1902a31bf6f352b7143d4c15f3443.

Change-Id: I9b71868940c8480bc593037341cc859f50b83a9a

CONTRIBUTING.rst

@@ -10,5 +10,6 @@ http://docs.openstack.org/infra/manual/developers.html#development-workflow
 
 Pull requests submitted through GitHub will be ignored.
 
-Bugs should be filed on Launchpad, not GitHub:
-https://bugs.launchpad.net/neutron-lib
+Bugs should be filed on Launchpad in the neutron project using the ``lib``
+tag, not GitHub:
+https://bugs.launchpad.net/neutron/+bugs?field.tag=lib

doc/source/contributor/api_extensions.rst

@@ -50,8 +50,8 @@ API extensions consist of the following high-level constructs:
   implements the extension's behavior and should carry out the operations
   defined by the extension. This code resides under its respective project
   repository, not in ``neutron-lib``. For more details see the `neutron api
-  extension dev-ref <https://github.com/openstack/neutron/blob/master/doc/
-  source/devref/api_extensions.rst>`_.
+  extension dev-ref <https://docs.openstack.org/neutron/latest/contributor/
+  internals/api_extensions.html>`_.
 
 
 Using neutron-lib's base extension classes

doc/source/contributor/callbacks.rst

@@ -512,7 +512,8 @@ How is the notifying object expected to interact with the subscribing objects?
 Is the registry thread-safe?
 
   Short answer is no: it is not safe to make mutations while callbacks are being called (more
-  details as to why can be found `here <https://hg.python.org/releasing/2.7.9/file/753a8f457ddc/Objects/dictobject.c#l937>`_).
+  details as to why can be found line 937 of
+  `dictobject <https://hg.python.org/releasing/2.7.9/file/753a8f457ddc/Objects/dictobject.c>`_).
   A mutation could happen if a 'subscribe'/'unsubscribe' operation interleaves with the execution
   of the notify loop. Albeit there is a possibility that things may end up in a bad state, the
   registry works correctly under the assumption that subscriptions happen at the very beginning

doc/source/contributor/contributing.rst

@@ -46,7 +46,7 @@ Phase 1: Rehome
 
    - Refactor/enhance the code as part of the initial neutron-lib patch. If this change
      will be disruptive to consumers, clearly communicate the change via email list or
-     `meeting topic <https://wiki.openstack.org/wiki/Network/Meetings#Neutron-lib_and_planned_neutron_refactoring>`_.
+     `meeting topic <https://wiki.openstack.org/wiki/Network/Meetings>`_.
    - Leave the refactoring to the next (Enhance) phase. In this rehome phase, copy the code
      as-is into a private module according to our `conventions <./conventions.html>`_. This
      approach is slower, but may be necessary in some cases.
@@ -124,7 +124,7 @@ source.
 
 - If the change to consume the code from neutron-lib is widespread and/or "important",
   introduce your intentions for the change via the Neutron team
-  `meeting slot <https://wiki.openstack.org/wiki/Network/Meetings#Neutron-lib_and_planned_neutron_refactoring>`_
+  `meeting slot <https://wiki.openstack.org/wiki/Network/Meetings>`_
   for neutron-lib. Subsequently follow-up with an email to openstack-dev list using a
   subject with ``[neutron] neutron-lib impact`` providing additional details as necessary.
   Ideally we can identify the main impacted subprojects by

doc/source/index.rst

@@ -24,9 +24,8 @@ such consumers. The library is developed with the following goals in mind:
   sub-optimal patterns in their respective neutron-lib implementation.
 
 This document describes the library for contributors of the project, and assumes
-that you are already familiar with Neutron from an `end-user perspective`_.
-
-.. _`end-user perspective`: http://docs.openstack.org/trunk/openstack-network/admin/content/index.html
+that you are already familiar with Neutron from an end-user perspective. If not,
+hop over to the `OpenStack doc site <https://docs.openstack.org/>`__
 
 This documentation is generated by the Sphinx toolkit and lives in the source
 tree.  Additional documentation on Neutron and other components of OpenStack