Add governance/values/nexp/roadmap

Co-authored-by: Dan Schult <dschult@colgate.edu>
Co-authored-by: Aric Hagberg <aric.hagberg+github@gmail.com>
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>

11 files changed, 886 insertions, 21 deletions

diff --git a/CODE_OF_CONDUCT.rst b/CODE_OF_CONDUCT.rst
index f543ddf3..0822de9a 100644
--- a/CODE_OF_CONDUCT.rst
+++ b/CODE_OF_CONDUCT.rst
@@ -1,3 +1,5 @@
+.. _code_of_conduct:
+
 Code of Conduct
 ===============
 
@@ -99,25 +101,21 @@ people may have a bad day, or be unaware of some of the guidelines in this Code
 of Conduct. Please keep this in mind when deciding on how to respond to a
 breach of this Code.
 
-For clearly intentional breaches, report those to the Code of Conduct committee
+For clearly intentional breaches, report those to the NetworkX Steering Council
 (see below). For possibly unintentional breaches, you may reply to the person
 and point out this code of conduct (either in public or in private, whatever is
 most appropriate). If you would prefer not to do that, please feel free to
-report to the Code of Conduct Committee directly, or ask the Committee for
+report to the NetworkX Steering Council directly, or ask the Council for
 advice, in confidence.
 
-You can report issues to the NetworkX Code of Conduct committee, at
-networkx-conduct@groups.io.
-Currently, the committee consists of:
-
-- Jarrod Millman @jarrodmillman
-- Dan Schult @dschult
-- Stéfan van der Walt @stefanv
+You can report issues to the
+`NetworkX Steering Council <https://github.com/orgs/networkx/teams/steering-council/members>`__,
+at networkx-conduct@groups.io.
 
-If your report involves any members of the committee, or if they feel they have
+If your report involves any members of the Council, or if they feel they have
 a conflict of interest in handling it, then they will recuse themselves from
 considering your report. Alternatively, if for any reason you feel
-uncomfortable making a report to the committee, then you can also contact:
+uncomfortable making a report to the Council, then you can also contact:
 
 - Senior `NumFOCUS staff <https://numfocus.org/code-of-conduct#persons-responsible>`__: conduct@numfocus.org.
 
@@ -125,8 +123,8 @@ uncomfortable making a report to the committee, then you can also contact:
 Incident reporting resolution & Code of Conduct enforcement
 -----------------------------------------------------------
 
-We will investigate and respond to all complaints. The NetworkX Code of Conduct
-Committee will protect the identity of the reporter, and treat the content of
+We will investigate and respond to all complaints. The NetworkX Steering Council
+will protect the identity of the reporter, and treat the content of
 complaints as confidential (unless the reporter agrees otherwise).
 
 In case of severe and obvious breaches, e.g., personal threat or violent, sexist
@@ -140,9 +138,9 @@ report will be:
 1. acknowledge report is received
 2. reasonable discussion/feedback
 3. mediation (if feedback didn't help, and only if both reporter and reportee agree to this)
-4. enforcement via transparent decision by the Code of Conduct Committee
+4. enforcement via transparent decision by the NetworkX Steering Council
 
-The committee will respond to any report as soon as possible, and at most
+The Council will respond to any report as soon as possible, and at most
 within 72 hours.
 
 
diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index 8d8cae68..3d950bc3 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -1,5 +1,7 @@
-Developer overview
-==================
+.. _contributor_guide:
+
+Contributor Guide
+=================
 
 1. If you are a first-time contributor:
 
@@ -93,6 +95,21 @@ For a more detailed discussion, read these :doc:`detailed documents
 
    If closing a bug, also add "Fixes #1480" where 1480 is the issue number.
 
+6. Document changes
+
+   If your change introduces any API modifications, please update
+   ``doc/release/release_dev.rst``.
+
+   If your change introduces a deprecation, add a reminder to ``TODO.txt``
+   for the team to remove the deprecated functionality in the future.
+
+.. note::
+
+   To reviewers: make sure the merge message has a brief description of the
+   change(s) and if the PR closes an issue add, for example, "Closes #123"
+   where 123 is the issue number.
+
+
 Divergence between ``upstream master`` and your feature branch
 --------------------------------------------------------------
 
@@ -266,11 +283,59 @@ you may be interested in more fundamental comments about design.
 When you think the pull request is ready to merge, change the title (using the
 *Edit* button) to remove the ``WIP:``.
 
-Developer Notes
----------------
+.. _deprecation_policy:
+
+
+Deprecation policy
+------------------
+
+If the behavior of the library has to be changed, a deprecation cycle must be
+followed to warn users.
+
+A deprecation cycle is *not* necessary when:
+
+* adding a new function, or
+* adding a new keyword argument to the *end* of a function signature, or
+* fixing buggy behavior
+
+A deprecation cycle is necessary for *any breaking API change*, meaning a
+change where the function, invoked with the same arguments, would return a
+different result after the change. This includes:
+
+* changing the order of arguments or keyword arguments, or
+* adding arguments or keyword arguments to a function, or
+* changing the name of a function, class, method, etc., or
+* moving a function, class, etc. to a different module, or
+* changing the default value of a function's arguments.
+
+Usually, our policy is to put in place a deprecation cycle over two releases.
+
+Note that the 2-release deprecation cycle is not a strict rule and in some
+cases, the developers can agree on a different procedure upon justification
+(like when we can't detect the change, or it involves moving or deleting an
+entire function for example).
+
+Explicitly not supporting directed or multigraph in a function
+--------------------------------------------------------------
+
+Use the decorator ``not_implemented_for`` in ``networkx/utils/decorators.py``
+to designate that a function doesn't accept 'directed', 'undirected',
+'multigraph' or 'graph'.
+The first argument of the decorated function should be the graph
+object to be checked.
+
+.. code-block:: python
+
+    @nx.not_implemented_for('directed', 'multigraph')
+    def function_not_for_MultiDiGraph(G, others):
+        # function not for graphs that are directed *and* multigraph
+        pass
 
-For additional information about contributing to NetworkX, please see
-the `Developer Notes <https://github.com/networkx/networkx/wiki>`_.
+    @nx.not_implemented_for('directed')
+    @nx.not_implemented_for('multigraph')
+    def function_only_for_Graph(G, others):
+        # function not for directed graphs *or* for multigraphs
+        pass
 
 Bugs
 ----
diff --git a/doc/developer/core_developer.rst b/doc/developer/core_developer.rst
new file mode 100644
index 00000000..390fc014
--- /dev/null
+++ b/doc/developer/core_developer.rst
@@ -0,0 +1,170 @@
+.. _core_dev:
+
+Core Developer Guide
+====================
+
+As a core developer, you should continue making pull requests
+in accordance with the :ref:`contributor_guide`.
+You are responsible for shepherding other contributors through the review process.
+You should be familiar with our :ref:`mission_and_values`.
+You also have the ability to merge or approve other contributors' pull requests.
+Much like nuclear launch keys, it is a shared power: you must merge *only after*
+another core developer has approved the pull request, *and* after you yourself have carefully
+reviewed it.  (See `Reviewing`_ and especially `Merge Only Changes You
+Understand`_ below.) To ensure a clean git history, use GitHub's
+`Squash and Merge <https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request#merging-a-pull-request-on-github>`__
+feature to merge, unless you have a good reason not to do so.
+
+Reviewing
+---------
+
+How to Conduct A Good Review
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*Always* be kind to contributors. Nearly all of NetworkX is
+volunteer work, for which we are tremendously grateful. Provide
+constructive criticism on ideas and implementations, and remind
+yourself of how it felt when your own work was being evaluated as a
+novice.
+
+NetworkX strongly values mentorship in code review.  New users
+often need more handholding, having little to no git
+experience. Repeat yourself liberally, and, if you don’t recognize a
+contributor, point them to our development guide, or other GitHub
+workflow tutorials around the web. Do not assume that they know how
+GitHub works (e.g., many don't realize that adding a commit
+automatically updates a pull request). Gentle, polite, kind
+encouragement can make the difference between a new core developer and
+an abandoned pull request.
+
+When reviewing, focus on the following:
+
+1. **API:** The API is what users see when they first use
+   NetworkX. APIs are difficult to change once released, so
+   should be simple, `functional
+   <https://en.wikipedia.org/wiki/Functional_programming>`__ (i.e. not
+   carry state), consistent with other parts of the library, and
+   should avoid modifying input variables.  Please familiarize
+   yourself with the project's :ref:`deprecation_policy`.
+
+2. **Documentation:** Any new feature should have a gallery
+   example that not only illustrates but explains it.
+
+3. **The algorithm:** You should understand the code being modified or
+   added before approving it.  (See `Merge Only Changes You
+   Understand`_ below.) Implementations should do what they claim,
+   and be simple, readable, and efficient.
+
+4. **Tests:** All contributions to the library *must* be tested, and
+   each added line of code should be covered by at least one test. Good
+   tests not only execute the code, but explores corner cases.  It is tempting
+   not to review tests, but please do so.
+
+Other changes may be *nitpicky*: spelling mistakes, formatting,
+etc. Do not ask contributors to make these changes, and instead
+make the changes by `pushing to their branch
+<https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork>`__,
+or using GitHub’s `suggestion
+<https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/commenting-on-a-pull-request>`__
+`feature
+<https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request>`__.
+(The latter is preferred because it gives the contributor a choice in
+whether to accept the changes.)
+
+Our default merge policy is to squash all PR commits into a single
+commit. Users who wish to bring the latest changes from ``master``
+into their branch should be advised to merge, not to rebase.  Even
+when merge conflicts arise, don’t ask for a rebase unless you know
+that a contributor is experienced with git. Instead, rebase the branch
+yourself, force-push to their branch, and advise the contributor on
+how to force-pull.  If the contributor is no longer active, you may
+take over their branch by submitting a new pull request and closing
+the original. In doing so, ensure you communicate that you are not
+throwing the contributor's work away!  You should use GitHub's
+``Co-authored-by:`` keyword for commit messages to credit the
+original contributor.
+
+
+Please add a note to a pull request after you push new changes; GitHub
+may not send out notifications for these.
+
+Merge Only Changes You Understand
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*Long-term maintainability* is an important concern.  Code doesn't
+merely have to *work*, but should be *understood* by multiple core
+developers.  Changes will have to be made in the future, and the
+original contributor may have moved on.
+
+Therefore, *do not merge a code change unless you understand it*. Ask
+for help freely: we have a long history of consulting community
+members, or even external developers, for added insight where needed,
+and see this as a great learning opportunity.
+
+While we collectively "own" any patches (and bugs!) that become part
+of the code base, you are vouching for changes you merge.  Please take
+that responsibility seriously.
+
+Closing issues and pull requests
+--------------------------------
+
+Sometimes, an issue must be closed that was not fully resolved. This can be
+for a number of reasons:
+
+- the person behind the original post has not responded to calls for
+  clarification, and none of the core developers have been able to reproduce
+  their issue;
+- fixing the issue is difficult, and it is deemed too niche a use case to
+  devote sustained effort or prioritize over other issues; or
+- the use case or feature request is something that core developers feel
+  does not belong in NetworkX,
+
+among others. Similarly, pull requests sometimes need to be closed without
+merging, because:
+
+- the pull request implements a niche feature that we consider not worth the
+  added maintenance burden;
+- the pull request implements a useful feature, but requires significant
+  effort to bring up to NetworkX's standards, and the original
+  contributor has moved on, and no other developer can be found to make the
+  necessary changes; or
+- the pull request makes changes that do not align with our values, such as
+  increasing the code complexity of a function significantly to implement a
+  marginal speedup,
+
+among others.
+
+All these may be valid reasons for closing, but we must be wary not to alienate
+contributors by closing an issue or pull request without an explanation. When
+closing, your message should:
+
+- explain clearly how the decision was made to close. This is particularly
+  important when the decision was made in a community meeting, which does not
+  have as visible a record as the comments thread on the issue itself;
+- thank the contributor(s) for their work; and
+- provide a clear path for the contributor or anyone else to appeal the
+  decision.
+
+These points help ensure that all contributors feel welcome and empowered to
+keep contributing, regardless of the outcome of past contributions.
+
+Further resources
+-----------------
+
+As a core member, you should be familiar with community and developer
+resources such as:
+
+-  Our :ref:`contributor_guide`
+-  Our :ref:`code_of_conduct`
+-  `PEP8 <https://www.python.org/dev/peps/pep-0008/>`__ for Python style
+-  `PEP257 <https://www.python.org/dev/peps/pep-0257/>`__ and the `NumPy
+   documentation
+   guide <https://numpy.org/doc/stable/docs/howto_document.html>`__
+   for docstrings. (NumPy docstrings are a superset of PEP257. You
+   should read both.)
+-  The NetworkX `tag on
+   StackOverflow <https://stackoverflow.com/questions/tagged/networkx>`__
+-  Our `mailing
+   list <http://groups.google.com/group/networkx-discuss/>`__
+
+You are not required to monitor all of the social resources.
diff --git a/doc/developer/index.rst b/doc/developer/index.rst
index 2d3658d7..cbf1a6de 100644
--- a/doc/developer/index.rst
+++ b/doc/developer/index.rst
@@ -6,6 +6,10 @@ Developer Guide
 .. toctree::
    :maxdepth: 2
 
+   values
    contribute
+   core_developer
    code_of_conduct
+   roadmap
+   nxeps/index
    gitwash/index
diff --git a/doc/developer/nxeps/_static/nxep-0000.png b/doc/developer/nxeps/_static/nxep-0000.png
new file mode 100644
index 00000000..0fc8176d
--- /dev/null
+++ b/doc/developer/nxeps/_static/nxep-0000.png
diff --git a/doc/developer/nxeps/index.rst b/doc/developer/nxeps/index.rst
new file mode 100644
index 00000000..b44cf71b
--- /dev/null
+++ b/doc/developer/nxeps/index.rst
@@ -0,0 +1,17 @@
+.. _nxep_list:
+
+Enhancement Proposals (NXEPS)
+*****************************
+
+NXEPs document any major changes or proposals to the NetworkX project.
+
+.. toctree::
+   :maxdepth: 1
+
+   nxep-0000
+   nxep-0001
+
+.. toctree::
+   :hidden:
+
+   nxep-template
diff --git a/doc/developer/nxeps/nxep-0000.rst b/doc/developer/nxeps/nxep-0000.rst
new file mode 100644
index 00000000..49444866
--- /dev/null
+++ b/doc/developer/nxeps/nxep-0000.rst
@@ -0,0 +1,289 @@
+.. _NXEP0:
+
+============================
+NXEP 0 — Purpose and Process
+============================
+
+:Author: Jarrod Millman <millman@berkeley.edu>
+:Status: Draft
+:Type: Process
+:Created: 2020-06-25
+
+
+What is a NXEP?
+---------------
+
+
+NXEP stands for NetworkX Enhancement Proposal.  NXEPs are the primary
+mechanisms for proposing major new features, for collecting community input on
+an issue, and for documenting the design decisions that have gone into
+NetworkX.  A NXEP should provide a concise technical specification of the
+feature and a rationale for the feature.  The NXEP author is responsible for
+building consensus within the community and documenting dissenting opinions.
+
+Because the NXEPs are maintained as text files in a versioned
+repository, their revision history is the historical record of the
+feature proposal [1]_.
+
+
+Types
+^^^^^
+
+There are three kinds of NXEPs:
+
+1. A **Standards Track** NXEP describes a new feature or implementation
+   for NetworkX.
+
+2. An **Informational** NXEP describes a NetworkX design issue, or provides
+   general guidelines or information to the Python community, but does not
+   propose a new feature. Informational NXEPs do not necessarily represent a
+   NetworkX community consensus or recommendation, so users and implementers are
+   free to ignore Informational NXEPs or follow their advice.
+
+3. A **Process** NXEP describes a process surrounding NetworkX, or
+   proposes a change to (or an event in) a process.  Process NXEPs are
+   like Standards Track NXEPs but apply to areas other than the NetworkX
+   language itself.  They may propose an implementation, but not to
+   NetworkX's codebase; they require community consensus.  Examples include
+   procedures, guidelines, changes to the decision-making process, and
+   changes to the tools or environment used in NetworkX development.
+   Any meta-NXEP is also considered a Process NXEP.
+
+
+NXEP Workflow
+-------------
+
+The NXEP process begins with a new idea for NetworkX.  It is highly
+recommended that a single NXEP contain a single key proposal or new
+idea. Small enhancements or patches often don't need
+a NXEP and can be injected into the NetworkX development workflow with a
+pull request to the NetworkX `repo`_. The more focused the
+NXEP, the more successful it tends to be.
+If in doubt, split your NXEP into several well-focused ones.
+
+Each NXEP must have a champion---someone who writes the NXEP using the style
+and format described below, shepherds the discussions in the appropriate
+forums, and attempts to build community consensus around the idea.  The NXEP
+champion (a.k.a. Author) should first attempt to ascertain whether the idea is
+suitable for a NXEP. Posting to the networkx-discussion `mailing list`_ is the best
+way to go about doing this.
+
+The proposal should be submitted as a draft NXEP via a `GitHub pull
+request`_ to the ``doc/nxeps`` directory with the name ``nxep-<n>.rst``
+where ``<n>`` is an appropriately assigned four-digit number (e.g.,
+``nxep-0000.rst``). The draft must use the :doc:`nxep-template` file.
+
+Once the PR for the NXEP is in place, a post should be made to the
+mailing list containing the sections up to "Backward compatibility",
+with the purpose of limiting discussion there to usage and impact.
+Discussion on the pull request will have a broader scope, also including
+details of implementation.
+
+At the earliest convenience, the PR should be merged (regardless of
+whether it is accepted during discussion).  Additional PRs may be made
+by the Author to update or expand the NXEP, or by maintainers to set
+its status, discussion URL, etc.
+
+Standards Track NXEPs consist of two parts, a design document and a
+reference implementation.  It is generally recommended that at least a
+prototype implementation be co-developed with the NXEP, as ideas that sound
+good in principle sometimes turn out to be impractical when subjected to the
+test of implementation.  Often it makes sense for the prototype implementation
+to be made available as PR to the NetworkX repo (making sure to appropriately
+mark the PR as a WIP).
+
+
+Review and Resolution
+^^^^^^^^^^^^^^^^^^^^^
+
+NXEPs are discussed on the mailing list.  The possible paths of the
+status of NXEPs are as follows:
+
+.. image:: _static/nxep-0000.png
+
+All NXEPs should be created with the ``Draft`` status.
+
+Eventually, after discussion, there may be a consensus that the NXEP
+should be accepted – see the next section for details. At this point
+the status becomes ``Accepted``.
+
+Once a NXEP has been ``Accepted``, the reference implementation must be
+completed.  When the reference implementation is complete and incorporated
+into the main source code repository, the status will be changed to ``Final``.
+
+To allow gathering of additional design and interface feedback before
+committing to long term stability for a language feature or standard library
+API, a NXEP may also be marked as "Provisional". This is short for
+"Provisionally Accepted", and indicates that the proposal has been accepted for
+inclusion in the reference implementation, but additional user feedback is
+needed before the full design can be considered "Final". Unlike regular
+accepted NXEPs, provisionally accepted NXEPs may still be Rejected or Withdrawn
+even after the related changes have been included in a Python release.
+
+Wherever possible, it is considered preferable to reduce the scope of a
+proposal to avoid the need to rely on the "Provisional" status (e.g. by
+deferring some features to later NXEPs), as this status can lead to version
+compatibility challenges in the wider NetworkX ecosystem.
+
+A NXEP can also be assigned status ``Deferred``.  The NXEP author or a
+core developer can assign the NXEP this status when no progress is being made
+on the NXEP.
+
+A NXEP can also be ``Rejected``.  Perhaps after all is said and done it
+was not a good idea.  It is still important to have a record of this
+fact. The ``Withdrawn`` status is similar---it means that the NXEP author
+themselves has decided that the NXEP is actually a bad idea, or has
+accepted that a competing proposal is a better alternative.
+
+When a NXEP is ``Accepted``, ``Rejected``, or ``Withdrawn``, the NXEP should be
+updated accordingly. In addition to updating the status field, at the very
+least the ``Resolution`` header should be added with a link to the relevant
+thread in the mailing list archives.
+
+NXEPs can also be ``Superseded`` by a different NXEP, rendering the
+original obsolete.  The ``Replaced-By`` and ``Replaces`` headers
+should be added to the original and new NXEPs respectively.
+
+Process NXEPs may also have a status of ``Active`` if they are never
+meant to be completed, e.g. NXEP 0 (this NXEP).
+
+
+How a NXEP becomes Accepted
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+A NXEP is ``Accepted`` by consensus of all interested contributors. We
+need a concrete way to tell whether consensus has been reached. When
+you think a NXEP is ready to accept, send an email to the
+networkx-discussion mailing list with a subject like:
+
+  Proposal to accept NXEP #<number>: <title>
+
+In the body of your email, you should:
+
+* link to the latest version of the NXEP,
+
+* briefly describe any major points of contention and how they were
+  resolved,
+
+* include a sentence like: "If there are no substantive objections
+  within 7 days from this email, then the NXEP will be accepted; see
+  NXEP 0 for more details."
+
+For an example, see: https://mail.python.org/pipermail/networkx-discussion/2018-June/078345.html
+
+After you send the email, you should make sure to link to the email
+thread from the ``Discussion`` section of the NXEP, so that people can
+find it later.
+
+Generally the NXEP author will be the one to send this email, but
+anyone can do it – the important thing is to make sure that everyone
+knows when a NXEP is on the verge of acceptance, and give them a final
+chance to respond. If there's some special reason to extend this final
+comment period beyond 7 days, then that's fine, just say so in the
+email. You shouldn't do less than 7 days, because sometimes people are
+travelling or similar and need some time to respond.
+
+In general, the goal is to make sure that the community has consensus,
+not provide a rigid policy for people to try to game. When in doubt,
+err on the side of asking for more feedback and looking for
+opportunities to compromise.
+
+If the final comment period passes without any substantive objections,
+then the NXEP can officially be marked ``Accepted``. You should send a
+followup email notifying the list (celebratory emoji optional but
+encouraged 🎉✨), and then update the NXEP by setting its ``:Status:``
+to ``Accepted``, and its ``:Resolution:`` header to a link to your
+followup email.
+
+If there *are* substantive objections, then the NXEP remains in
+``Draft`` state, discussion continues as normal, and it can be
+proposed for acceptance again later once the objections are resolved.
+
+In unusual cases, disagreements about the direction or approach may
+require escalation to the NetworkX :ref:`steering_council` who
+then decide whether a controversial NXEP is ``Accepted``.
+
+
+Maintenance
+^^^^^^^^^^^
+
+In general, Standards track NXEPs are no longer modified after they have
+reached the Final state as the code and project documentation are considered
+the ultimate reference for the implemented feature.
+However, finalized Standards track NXEPs may be updated as needed.
+
+Process NXEPs may be updated over time to reflect changes
+to development practices and other details. The precise process followed in
+these cases will depend on the nature and purpose of the NXEP being updated.
+
+
+Format and Template
+-------------------
+
+NXEPs are UTF-8 encoded text files using the reStructuredText_ format.  Please
+see the :doc:`nxep-template` file and the reStructuredTextPrimer_ for more
+information.  We use Sphinx_ to convert NXEPs to HTML for viewing on the web
+[2]_.
+
+
+Header Preamble
+^^^^^^^^^^^^^^^
+
+Each NXEP must begin with a header preamble.  The headers
+must appear in the following order.  Headers marked with ``*`` are
+optional.  All other headers are required. ::
+
+    :Author: <list of authors' real names and optionally, email addresses>
+    :Status: <Draft | Active | Accepted | Deferred | Rejected |
+             Withdrawn | Final | Superseded>
+    :Type: <Standards Track | Process>
+    :Created: <date created on, in dd-mmm-yyyy format>
+  * :Requires: <nxep numbers>
+  * :NetworkX-Version: <version number>
+  * :Replaces: <nxep number>
+  * :Replaced-By: <nxep number>
+  * :Resolution: <url>
+
+The Author header lists the names, and optionally the email addresses
+of all the authors of the NXEP.  The format of the Author header
+value must be
+
+    Random J. User <address@dom.ain>
+
+if the email address is included, and just
+
+    Random J. User
+
+if the address is not given.  If there are multiple authors, each should be on
+a separate line.
+
+
+References and Footnotes
+------------------------
+
+.. [1] This historical record is available by the normal git commands
+   for retrieving older revisions, and can also be browsed on
+   `GitHub <https://github.com/networkx/networkx/tree/master/doc/nxeps>`_.
+
+.. [2] The URL for viewing NXEPs on the web is
+   https://networkx.github.io/nxeps/.
+
+.. _repo: https://github.com/networkx/networkx
+
+.. _mailing list: http://groups.google.com/group/networkx-discuss/
+
+.. _issue tracker: https://github.com/networkx/networkx/issues
+
+.. _`GitHub pull request`: https://github.com/networkx/networkx/pulls
+
+.. _reStructuredText: http://docutils.sourceforge.net/rst.html
+
+.. _reStructuredTextPrimer: http://www.sphinx-doc.org/en/stable/rest.html
+
+.. _Sphinx: http://www.sphinx-doc.org/en/stable/
+
+
+Copyright
+---------
+
+This document has been placed in the public domain.
diff --git a/doc/developer/nxeps/nxep-0001.rst b/doc/developer/nxeps/nxep-0001.rst
new file mode 100644
index 00000000..6fbfe16c
--- /dev/null
+++ b/doc/developer/nxeps/nxep-0001.rst
@@ -0,0 +1,159 @@
+.. _governance:
+
+=======================================
+NXEP 1 — Governance and Decision Making
+=======================================
+
+:Author: Jarrod Millman <millman@berkeley.edu>
+:Author: Dan Schult <dschult@colgate.edu>
+:Status: Draft
+:Type: Process
+:Created: 2020-06-25
+
+Abstract
+========
+
+NetworkX is a consensus-based community project. Anyone with an interest in the
+project can join the community, contribute to the project design, and
+participate in the decision making process. This document describes how that
+participation takes place, how to find consensus, and how deadlocks are
+resolved.
+
+Roles And Responsibilities
+==========================
+
+The Community
+-------------
+The NetworkX community consists of anyone using or working with the project
+in any way.
+
+Contributors
+------------
+Any community member can become a contributor by interacting directly with the
+project in concrete ways, such as:
+
+- proposing a change to the code or documentation via a GitHub pull request;
+- reporting issues on our
+  `GitHub issues page <https://github.com/networkx/networkx/issues>`_;
+- discussing the design of the library, website, or tutorials on the
+  `mailing list <http://groups.google.com/group/networkx-discuss/>`_,
+  or in existing issues and pull requests; or
+- reviewing
+  `open pull requests <https://github.com/networkx/networkx/pulls>`_,
+
+among other possibilities. By contributing to the project, community members
+can directly help to shape its future.
+
+Contributors should read the :ref:`contributor_guide` and our :ref:`code_of_conduct`.
+
+Core Developers
+---------------
+Core developers are community members that have demonstrated continued
+commitment to the project through ongoing contributions. They
+have shown they can be trusted to maintain NetworkX with care. Becoming a
+core developer allows contributors to merge approved pull requests, cast votes
+for and against merging a pull request, and be involved in deciding major
+changes to the API, and thereby more easily carry on with their project related
+activities. Core developers appear as team members on the `NetworkX Core Team page
+<https://github.com/orgs/networkx/teams/core-developers/members>`_ and can
+be messaged ``@networkx/core-developers``. Core
+developers are expected to review code contributions while adhering to the
+:ref:`core_dev`.
+
+New core developers can be nominated by any existing core developer.
+Discussion about new core developer nominations is one of the few activities
+that takes place on the project's private management list. The decision to
+invite a new core developer must be made by “lazy consensus”, meaning unanimous
+agreement by all responding existing core developers. Invitation must take
+place at least one week after initial nomination, to allow existing members
+time to voice any objections.
+
+.. _steering_council:
+
+Steering Council
+----------------
+The Steering Council (SC) members are core developers who have additional
+responsibilities to ensure the smooth running of the project. SC members are
+expected to participate in strategic planning, approve changes to the
+governance model, and make decisions about funding granted to the project
+itself. (Funding to community members is theirs to pursue and manage.) The
+purpose of the SC is to ensure smooth progress from the big-picture
+perspective. Changes that impact the full project require analysis informed by
+long experience with both the project and the larger ecosystem. When the core
+developer community (including the SC members) fails to reach such a consensus
+in a reasonable timeframe, the SC is the entity that resolves the issue.
+
+Steering Council members appear as team members on the `NetworkX Steering
+Council Team page
+<https://github.com/orgs/networkx/teams/steering-council/members>`_ and
+can be messaged ``@networkx/steering-council``. Core
+
+Decision Making Process
+=======================
+
+Decisions about the future of the project are made through discussion with all
+members of the community. All non-sensitive project management discussion takes
+place on the project
+`mailing list <http://groups.google.com/group/networkx-discuss/>`_
+and the `issue tracker <https://github.com/networkx/networkx/issues>`_.
+Occasionally, sensitive discussion may occur on a private list.
+
+Decisions should be made in accordance with our :ref:`mission_and_values`.
+
+NetworkX uses a *consensus seeking* process for making decisions. The group
+tries to find a resolution that has no open objections among core developers.
+Core developers are expected to distinguish between fundamental objections to a
+proposal and minor perceived flaws that they can live with, and not hold up the
+decision making process for the latter.  If no option can be found without
+an objection, the decision is escalated to the SC, which will itself use
+consensus seeking to come to a resolution. In the unlikely event that there is
+still a deadlock, the proposal will move forward if it has the support of a
+simple majority of the SC. Any proposal must be described by a NetworkX :ref:`nxep`.
+
+Decisions (in addition to adding core developers and SC membership as above)
+are made according to the following rules:
+
+- **Minor documentation changes**, such as typo fixes, or addition / correction of a
+  sentence (but no change of the NetworkX landing page or the “about”
+  page), require approval by a core developer *and* no disagreement or requested
+  changes by a core developer on the issue or pull request page (lazy
+  consensus). Core developers are expected to give “reasonable time” to others
+  to give their opinion on the pull request if they’re not confident others
+  would agree.
+
+- **Code changes and major documentation changes** require agreement by *two*
+  core developers *and* no disagreement or requested changes by a core developer
+  on the issue or pull-request page (lazy consensus).
+
+- **Changes to the API principles** require a :ref:`nxep` and follow the
+  decision-making process outlined above.
+
+- **Changes to this governance model or our mission and values**
+  require a :ref:`nxep` and follow the decision-making process outlined above,
+  *unless* there is unanimous agreement from core developers on the change.
+
+If an objection is raised on a lazy consensus, the proposer can appeal to the
+community and core developers and the change can be approved or rejected by
+escalating to the SC, and if necessary, a NXEP (see below).
+
+.. _nxep:
+
+Enhancement Proposals (NXEPs)
+=============================
+
+Any proposals for enhancements of NetworkX should be written as a formal NXEP
+following the template :doc:`nxep-template`. The NXEP must be made public and
+discussed before any vote is taken. The discussion must be summarized by a
+key advocate of the proposal in the appropriate section of the NXEP.
+Once this summary is made public and after sufficient time to allow the
+core team to understand it, they vote.
+The workflow of a NXEP is detailed in :ref:`nxep0`.
+
+A list of all existing NXEPs is available :ref:`here <nxep_list>`.
+
+Copyright
+=========
+
+This document is based on the `scikit-image governance document
+<https://scikit-image.org/docs/stable/skips/1-governance.html>`_ and is placed
+in the public domain.
diff --git a/doc/developer/nxeps/nxep-template.rst b/doc/developer/nxeps/nxep-template.rst
new file mode 100644
index 00000000..7c2225cd
--- /dev/null
+++ b/doc/developer/nxeps/nxep-template.rst
@@ -0,0 +1,105 @@
+==================================
+NXEP X — Template and Instructions
+==================================
+
+:Author: <list of authors' real names and optionally, email addresses>
+:Status: <Draft | Active | Accepted | Deferred | Rejected | Withdrawn | Final | Superseded>
+:Type: <Standards Track | Process>
+:Created: <date created on, in yyyy-mm-dd format>
+:Resolution: <url> (required for Accepted | Rejected | Withdrawn)
+
+
+Abstract
+--------
+
+The abstract should be a short description of what the NXEP will achieve.
+
+Note that the — in the title is an elongated dash, not -.
+
+Motivation and Scope
+--------------------
+
+This section describes the need for the proposed change. It should describe
+the existing problem, who it affects, what it is trying to solve, and why.
+This section should explicitly address the scope of and key requirements for
+the proposed change.
+
+Usage and Impact
+----------------
+
+This section describes how users of NumPy will use features described in this
+NXEP. It should be comprised mainly of code examples that wouldn't be possible
+without acceptance and implementation of this NXEP, as well as the impact the
+proposed changes would have on the ecosystem. This section should be written
+from the perspective of the users of NumPy, and the benefits it will provide
+them; and as such, it should include implementation details only if
+necessary to explain the functionality.
+
+Backward compatibility
+----------------------
+
+This section describes the ways in which the NXEP breaks backward compatibility.
+
+The mailing list post will contain the NXEP up to and including this section.
+Its purpose is to provide a high-level summary to users who are not interested
+in detailed technical discussion, but may have opinions around, e.g., usage and
+impact.
+
+Detailed description
+--------------------
+
+This section should provide a detailed description of the proposed change.
+It should include examples of how the new functionality would be used,
+intended use-cases and pseudo-code illustrating its use.
+
+
+Related Work
+------------
+
+This section should list relevant and/or similar technologies, possibly in other
+libraries. It does not need to be comprehensive, just list the major examples of
+prior and relevant art.
+
+
+Implementation
+--------------
+
+This section lists the major steps required to implement the NXEP.  Where
+possible, it should be noted where one step is dependent on another, and which
+steps may be optionally omitted.  Where it makes sense, each step should
+include a link to related pull requests as the implementation progresses.
+
+Any pull requests or development branches containing work on this NXEP should
+be linked to from here.  (A NXEP does not need to be implemented in a single
+pull request if it makes sense to implement it in discrete phases).
+
+
+Alternatives
+------------
+
+If there were any alternative solutions to solving the same problem, they should
+be discussed here, along with a justification for the chosen approach.
+
+
+Discussion
+----------
+
+This section may just be a bullet list including links to any discussions
+regarding the NXEP:
+
+- This includes links to mailing list threads or relevant GitHub issues.
+
+
+References and Footnotes
+------------------------
+
+.. [1] Each NXEP must either be explicitly labeled as placed in the public domain (see
+   this NXEP as an example) or licensed under the `Open Publication License`_.
+
+.. _Open Publication License: https://www.opencontent.org/openpub/
+
+
+Copyright
+---------
+
+This document has been placed in the public domain. [1]_
diff --git a/doc/developer/roadmap.rst b/doc/developer/roadmap.rst
new file mode 100644
index 00000000..295b8a0d
--- /dev/null
+++ b/doc/developer/roadmap.rst
@@ -0,0 +1,4 @@
+=======
+Roadmap
+=======
+
diff --git a/doc/developer/values.rst b/doc/developer/values.rst
new file mode 100644
index 00000000..8d74dd33
--- /dev/null
+++ b/doc/developer/values.rst
@@ -0,0 +1,54 @@
+.. _mission_and_values:
+
+==================
+Mission and Values
+==================
+
+Our mission
+-----------
+
+NetworkX aims to be the reference library for network science algorithms in
+Python. We accomplish this by:
+
+- **being easy to use and install**. We are careful in taking on new
+  dependencies, and sometimes cull existing ones, or make them optional. All
+  functions in our API have thorough docstrings clarifying expected inputs and
+  outputs.
+- **providing a consistent API**. Conceptually identical arguments have the
+  same name and position in a function signature.
+- **ensuring correctness**. Test coverage is close to 100% and code is reviewed by
+  at least two core developers before being included in the library.
+- **caring for users’ data**. We have a functional API and don't modify
+  input data unless explicitly directed to do so.
+- **promoting education in network science**, with extensive pedagogical
+  documentation.
+
+Our values
+----------
+
+- We are inclusive (:ref:`code_of_conduct`). We welcome and mentor newcomers who are
+  making their first contribution.
+- We are open source and community-driven (:ref:`governance`).
+- We focus on graph data structures and algorithms for network science applications.
+- We prefer pure Python implementations using native data structures
+  (especially dicts) due to their consistent, intuitive interface and amazing
+  performance capabilities. We include interfaces to other data structures,
+  especially NumPy arrays and SciPy sparse matrices for algorithms that more
+  naturally use arrays and matrices or where time or space requirements are 
+  significantly lower. Sometimes we provide two algorithms for the same result,
+  one using each data structure, when pedagogy or space/time trade-offs justify
+  such multiplicity.
+- We value simple, readable implementations over getting every last ounce of
+  performance. Readable code that is easy to understand, for newcomers and
+  maintainers alike, makes it easier to contribute new code as well as prevent
+  bugs. This means that we will prefer a 20% slowdown if it reduces lines of
+  code two-fold, for example.
+- We value education and documentation. All functions should have `NumPy-style
+  docstrings <https://numpy.org/doc/stable/docs/howto_document.html>`,
+  preferably with examples, as well as gallery examples that showcase how that
+  function is used in a scientific application.
+
+Acknowledgments
+---------------
+
+This document is modified from the `scikit-image` mission and values document.