Drafts of governance, roadmap

[skip ci]

Author: matthew-brett

doc/source/devel/devguide.rst

@@ -108,3 +108,10 @@ the algorithms with implications to the performance or validity of results.
 
 It may list references to 3rd party bugtrackers, in case the reported bugs
 match the criteria listed above.
+
+Contributor guidelines
+======================
+
+Please see `our community guidelines
+<https://github.com/nipy/nibabel/blob/master/.github/CODE_OF_CONDUCT.md>`_.
+Other projects call these guidelines the "code of conduct".

doc/source/devel/governance.rst

@@ -0,0 +1,158 @@
+.. _governance:
+
+=======================================
+NXEP 1 — Governance and Decision Making
+=======================================
+
+:Author: Jarrod Millman <[email protected]>
+:Author: Dan Schult <[email protected]>
+: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>`.
+
+Acknowledgments
+===============
+
+This document is based on the `scikit-image governance document
+<https://scikit-image.org/docs/stable/skips/1-governance.html>`_.

doc/source/devel/index.rst

@@ -10,6 +10,8 @@ Developer documentation page
     :maxdepth: 2
 
     devguide
+    governance
+    roadmap
     add_test_data
     add_image_format
     devdiscuss

doc/source/devel/roadmap.rst

@@ -0,0 +1,13 @@
+=======
+Roadmap
+=======
+
+The roadmap is intended for larger, fundamental changes to the project that are
+likely to take months or years of developer time. Smaller-scoped items will
+continue to be tracked on our issue tracker.
+
+The scope of these improvements means that these changes may be controversial,
+are likely to involve significant discussion among the core development team,
+and may require the creation of one or more NIAPs (Nibabel Increased
+Awesomeness Proposals).
+