[WIP] Reboot of CEP7 development

source/cep/cep7.rst

@@ -0,0 +1,267 @@
+CEP 7 - Cyclus Community Constitution
+*************************************
+
+:CEP: 7
+:Title: Cyclus Community Constitution
+:Last-Modified: 2015-08-18
+:Author: Paul Wilson
+:Status: Active
+:Type: Process
+:Created: 2015-08-18
+
+Abstract
+========
+
+This CEP is intended to define fundamental principles of the |Cyclus|
+organization and a basis for governance within this community.  Prior to this
+document, governance was ad-hoc within a single institution.  As the
+individual and institutional relationships expand, such a document is
+considered important to maintain the health of the community.
+
+Mission
+=======
+
+The mission of the |Cyclus| organization is to foster the ongoing development
+of the open source |Cyclus| ecosystem as both a research platform and a user
+tool for the study of dynamic nuclear fuel cycles.
+
+Definitions
+===========
+
+|Cyclus| Ecosystem
+-------------------
+
+The |Cyclus| ecosystem is an organic collection of individuals, institutions,
+and their contributions to nuclear fuel cycle modeling and analysis within the
+|Cyclus| framework.  Those contributions may be distinct projects, individual
+lines of code, or some combination, and they may be owned individually,
+collectively, institutionally, or in some combination.
+
+|Cyclus| Organization
+----------------------
+
+The |Cyclus| organization (hereafter, "the Organization") is the subset of the
+|Cyclus| ecosystem that is managed and owned collectively under the |Cyclus|
+Github organization.  This document is designed to provide a basis for
+governance within this organization.  Membership in this organization is
+governed by a process defined below.
+
+Council of Principal Investigators
+-----------------------------------
+
+????
+
+Design Philosophy
+==================
+
+The fundamental design philosophy of |Cyclus| provides a basis for guiding the
+development of the components owned by the Organization and resolving
+technical disputes that may arise during such development.  Such a philosophy
+is embodied in the following set of principles.  Like any such system, the
+relative value placed in any single principle may not be universally held by
+all members of the Organization.
+
+Flexibility
+------------
+
+The foundational principle of |Cyclus| is to provide flexibility in both the
+range of nuclear fuel cycles that can be modeled and the range of analyses and
+use cases that may be applied to those cycles.  
+
+Open
+-----
+
+The Organization is commited to an open source development paradigm
+
+Scalability
+------------
+
+
+Stability
+----------
+
+Stability of |Cyclus| components is an important prerequisite for attracting a
+community of developers and users.  A stable |Cyclus| kernel is required to
+attract other archetype developers and stability in the other components is
+required to attract end users.
+
+Sustainability
+---------------
+
+
+Usability
+----------
+
+
+
+Code of Conduct
+================
+
+Some other related codes of conduct during the development of our own:
+
+* http://contributor-covenant.org/
+* http://www.ubuntu.com/about/about-ubuntu/conduct
+* http://www.apache.org/foundation/policies/conduct.html
+* https://www.mozilla.org/en-US/about/governance/policies/participation/
+
+
+Change Control Process
+========================
+
+The primary context for interaction among members of the Organization is the
+discussion and review of changes being made to the software.  Such changes are
+enabled by the pull request features of Github technology that hosts the
+primary software repositories.
+
+1. A developer or team of developers makes changes in a Github branch.
+2. Once a cohesive set of changes has been completed, a pull request is
+   generated that offers those changes as an ammendment to the primary branch.
+3. All members of the Organization are welcome to comment on all technical
+   aspects of the offered changes, including specfically:
+   * style
+   * technical correctness
+   * adherence to the design philosophy
+4. At least one member of the Organization that was not involved in the
+   development of the changes must approve the changes.
+5. Any member of the Organization can block the adoption of changes on
+   technical grounds.
+6. Changes are adopted when at least one member of the Organization has
+   approved the changes and no members of the Organization are blocking the
+   changes.
+
+Best Practices
+---------------
+
+(should these be in their own CEP)
+
+1. Substantive changes to the work of others should require those others to
+   comment during the review process.
+2. Individual pull requests should be as small as possible to facilitate
+   timely review.
+3. Before embarking on long time-intensive changes, it is wise to collect the
+   opinion of the |Cyclus| community on the value of such changes, generally
+   through the mailing list.
+
+Resolution of Technical Conflicts
+==================================
+
+It is natural and inevitable that during the process of implementing
+improvements, a technical difference of opinion may arise.  This is part of
+the healthy interaction in such a community. Most technical problems can be
+resolved in more than one way and there may no single correct answer.  
+
+The first mechanism for resolution of such conflicts is through discussion
+among major parties with the shared goal of seeking a common solution.
+Different modes of communication can help facilitate resolution in different
+ways.  Synchronous communication (chat, phone and/or video conference) can
+often lead to more creative solutions that satisfy all parties.  Inclusion of
+a knowledgeable third party can also help identify points of agreement and
+points of disagreement, leading to a more focused and successful outcome.
+Adherence to the Code of Conduct becomes extremely important during such
+discussions, and should be policed strictly.
+
+It is possible that such a process is unable to reach a resolution.
+Presumably, the proposed changes are technically correct, having been reviewed
+for
+
+If such a process is unable to reach a resolution, the decision can be
+escalated for the review of the Council of PIs.  This process presumes that
+the review process has resulted in a change proposal that is technically
+correct and conforms to the appropriate style guide, and therefore that
+continued disagreement lies in the interpretation and relative evaluation of
+the design philosophy.  This leads to the following process:
+
+1. Each party writes a justification of their position in particular context
+   of the design principles.
+2. Each party writse a rebuttal to the other party's justification, also in
+   the context of the design principles.
+
+The Council of PIs will evaluate these arguments and make a decision in the
+context of the overall design philosophy.
+
+Resolution of Social Conflicts
+===============================
+
+It is equally inevitable that conflicts will arise that are less technical in
+nature, generally as violations of the Code of Conduct.  This is not a part of
+the healthy interaction of such a community and must be carefully managed.
+This section outlines a spectrum of escalating responses to such social
+conflicts and infractions.  This set of responses: 
+
+* is specifically designed to allow for most conflicts to be resolved quickly and
+  quietly without escalation,
+* directly reinforces a culture of healthy cooperation and collaboration, 
+* presumes that all members of the Organization agree to the Code of Conduct,
+* presumes that all members of the Organization trust the process to bring
+  resolution, and
+* empowers all members of the Organization to enforce the Code of Conduct,
+  whether they experience violations directly or witness them as third
+  parties.
+
+1. Private Flags
+-----------------
+
+The first response is to simply inform the member that they have commited a
+violation of the Code of Conduct - to "raise a flag".  Importantly, this first
+response is intended to:
+
+* be private to the issuer and the receiver,
+* require little effort,
+* imply little judgment, and
+* impose little stigma.
+
+Any time that a flag is raised, a response is expected.  At minimum the
+response should acknowledge the flag, but may also require an apology.  If the
+original transgression occurred publicly, the response should also be public,
+even though the flag was private.
+
+Although the analogy is imperfect, flags can be viewed as the social
+equivalent to comments on style in the technical review.  As such, they are
+simple reminders of an accidental transgression that should result in equally
+simple corrective action.
+
+2. Public Flags
+----------------
+
+Very similar to a Private Flag, this response is issued more publicly in order
+to include a broader segment of the community.  This may be appropriate when
+the violation has been committed by or directed at a group.  
+
+It is important to recognize that even in situations where the issuer of such
+a flag intends little judgment, a Public Flag can both imply judgment and
+impose substantial stigma, and can become inflammatory.  Recognizing this does
+not negate the utility of a Public Flag, but calls for great care in its use.
+
+Any member of the community is empowered to choose this response at their own
+discretion.
+
+3. Monitored Flags
+-------------------
+
+Clearly an escalation from the previous responses, this follows the same
+pattern as other flags, but explicitly includes one or more members of the
+Council of PIs, as appropriate.
+
+Escalation to this response implies that previous attempts to resolve the
+situation were unsuccessful and/or that there is an emerging pattern of
+transgression.  The PI are included both to make them aware of the situation
+and to invite them to take independent action.  This response also implies an
+explicit judgment and hence imposes stigma on the recipient.
+
+Any member of the community is empowered to choose this response at their own
+discretion.
+
+4. Greivance
+-------------
+
+A party may explicitly request action by the PIs when they feel that other
+avenues have been exhausted.  Need a formal process for this??
+
+Document History
+================
+
+This document is released under the CC-BY 3.0 license.
+
+References and Footnotes
+========================
+