--- SHEiP: SHEiP-1 title: Shenanigan Improvement Proposals (SHEiP) author: Victor Ginelli (http://github.com/youngkidwarrior) discussions-to: https://github.com/Shenanigannetwork/SHEiP/issues/1 status: Draft category: Meta type: created: 2021-07-15 requires: replaces: --- ## Simple Summary This proposal describes the process for SHE Improvement Proposals (SHEiPs). ## Abstract SHE Improvement Proposals (SHEiPs) are standards for improving the Shenanigan platform, including core development updates, community organization, design standards, DAO operations, and written documentation. As a result, SHEiPs empower SHE to mature as an open source project and community. # Template SHEiP: <to be assigned> title: <SHEiP title> author: <a list of the author's or authors' name(s) and/or username(s), or name(s) and email(s), e.g. (use with the parentheses or triangular brackets): FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName LastName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> discussions-to: <URL of the Github issue for this SHEiP (if this is a PR)> status: <Idea | Draft | Last Call | Pending> category: <Standards | Meta | Informational> type: <Development | Design | Community | Operations | Documentation> created: <date created on, in ISO 8601 (yyyy-mm-dd) format> edited: <date created on, in ISO 8601 (yyyy-mm-dd) format> requires: <EIP number(s)> replaces: <EIP number(s)> <!--PROPOSE A NEW SHEiP--> <!--NOTE: You can leave these HTML comments in your SHEiP and delete the visible text guides, they will not appear and may be helpful to refer to if you edit your SHEiP again.--> <!-- STEPS TO SUBMIT A SHEiP: 1. Complete the header above. 2. Fill in as much content as is appropriate for the status of your SHEiP. 3. Add Github labels for status, category, and type.--> <!--ADDITIONAL INSTRUCTIONS FOR HEADER SECTION ABOVE--> <!--<REMOVE>: Remove the <REMOVE> elements from above and below the header. Leave the --- characters.--> <!--[SHEiP]: Leave this section blank for new issues. Once you submit a PR later in the process, an editor will assign you a canonical number.--> <!--[title]: Give your issue a concise, descriptive title prefixed by either its *type* for standards SHEiPs or its category for other SHEiPs. (i.e. Development: Smart Contract Upgrade, Meta: Define SHEiP Process, etc.).--> <!--[status]: Here is a description of status terms. - `Idea`: a SHEiP issue that is incomplete. - `Draft`: a SHEiP issue that is complete but undergoing rapid iteration and changes. - `Last Call`: a SHEiP issue that is stable and ready for final review by the community. - `Pending`: a SHEiP that has been submitted as a PR or merged but not finalized.--> <!--[category]: Here is a description of category terms. - `Standards`: a SHEiP that affects the product or community. - `Meta`: a SHEiP that affects the governance process for SHEiPs. - `Informational`: a SHEiP that is merely for informational purposes but requires no action by the community, and will not be merged as a SHEiP.--> <!--[type]: Here is a description of type terms. These are only applicable to SHEiPs in the *Standards* category. - `Development`: a SHEiP that affects code or codebase standards. - `Design`: a SHEiP that affects the way SHE interacts with its members. - `Operations`: a SHEiP that affects DAO processes or conventions . - `Documentation`: a SHEiP that affects the written word of SHE--> <!--[requires]: A list of SHEiP(s) that this SHEiP depends on. *Optional.--> <!--[replaces]: A list of SHEiP(s) that this SHEiP replaces. *Optional.--> ## Simple Summary <!--Provide a simplified and layman-accessible explanation of the SHEiP.--> Simple summary goes here. ## Abstract <!--A short (~200 word) description of the technical issue being addressed.--> Abstract goes here. ## Motivation <!--Motivation is critical for SHEiPs that want to change SHE. It should clearly explain why SHE is inadequate in its current state and then address the problem that the SHEiP solves. SHEiP submissions without sufficient motivation may be rejected outright.--> Motivation goes here. ## Specification <!--The technical specification should describe the syntax and semantics of any new feature.--> Specification goes here. ## Rationale <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is works in other environments. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> Rationale goes here. ## Backwards Compatibility <!--All SHEiPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The SHEiP must explain how the author proposes to deal with these incompatibilities. SHEiP submissions without a sufficient backwards compatibility section may be rejected outright.--> Backwards compatibility goes here. ## Implementation <!--The implementations must be completed before any SHEiP is given status "Final", but it need not be completed before the SHEiP is accepted.--> Implementation goes here. ## Security Considerations <!--All SHEiPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. SHEiP submissions missing the "Security Considerations" section will be rejected. An SHEiP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.--> Security considerations go here. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).