From 33b641901cd50c4a44e21d36a021d2c51829d65e Mon Sep 17 00:00:00 2001
From: tysonbattistella <tysonbattistella@gmail.com>
Date: Fri, 28 Jan 2022 00:05:50 -0500
Subject: [PATCH] [feat] Contribution Guidelines

---
 .github/pull_request_template.md | 25 ++++++++++++++++++
 README.md                        | 45 ++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+)
 create mode 100644 .github/pull_request_template.md

diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
new file mode 100644
index 00000000..af29f72f
--- /dev/null
+++ b/.github/pull_request_template.md
@@ -0,0 +1,25 @@
+# New Module Proposal
+
+## Description
+
+<!--- Describe your changes in detail -->
+
+## Motivation and Context
+
+<!--- Why is this module required? What problem does it solve? -->
+
+## How has this been tested?
+
+<!--- Please describe in detail how you tested your changes. -->
+<!--- Include details of your testing environment, tests ran to see how -->
+<!--- your change affects other areas of the code, etc. -->
+
+## Checklist:
+
+<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+<!--- If you're unsure about any of these, don't hesitate to ask. -->
+
+- [ ] The module includes tests written for Foundry
+- [ ] The module is documented with [NATSPEC](https://docs.soliditylang.org/en/v0.5.10/natspec-format.html)
+- [ ] The documentation includes [UML Diagrams](https://plantuml.com/ascii-art) for external and public functions
+- [ ] The module is a [Hyperstructure](https://www.jacob.energy/hyperstructures.html)
diff --git a/README.md b/README.md
index e0c8a958..3515ae39 100644
--- a/README.md
+++ b/README.md
@@ -44,6 +44,51 @@ When a new market is registered, a ZORA Module Fee Switch NFT, or ZORF, is minte
 
 Once registered, anyone is able to use the market module by approving it via the ZoraModuleManager.
 
+## Contributing
+
+ZORA V3 is meant to be as extensible as possible. As such, there are a number of ways for developers to contribute. This protocol is being developed in the open, and anyone can propose a module, audit a module, or suggest new module types for the community to begin using.
+
+As the protocol matures, so too will these contribution guidelines. If you have a suggestion on how we can collaborate better on this protocol, [please let us know](#leaving-feedback).
+
+### Registering a New Module
+
+New modules are added to V3 in three stages. We track which stage each module is in with PR labels:
+
+- Draft / RFC
+- Community Audit
+- Ready for Deployment
+
+Note that we also include a 4th label, "ZORA Bug Bounty" for Modules that are created by the ZORA core team and ready for a community audit.
+
+#### Draft / RFC
+
+In this stage, the ZORA community is able to give design feedback and start discussions about what the module aims to accomplish. A new draft module can be started by [creating a new pull request](https://github.com/ourzora/v3/compare).
+
+#### Community Audit
+
+Once a module has been designed, built, tested and documented, the module can undergo community audits. If the module has been audited by a third party, the audit report can be included in the PR.
+
+Modules that are written by the ZORA core team are open to our bug bounty program, which allows community auditors to claim up to 25 ETH for vulnerabilities that may have been missed during development. The rubric we use to determine bug bounties is as follows:
+
+| **Metric**                                                                | **Maximum Bug Bounty** |
+| ------------------------------------------------------------------------- | ---------------------- |
+| Can the vulnerability result in lost funds / assets for all ZORA users?   | Up to 25 ETH           |
+| Can the vulnerability result in lost funds / assets for individual users? | Up to 5 ETH            |
+| Can the vulnerability cause unexpected or undesirable outcomes?           | Up to 1 ETH            |
+| Not sure?                                                                 | Let's talk :~)         |
+
+Although not required, developers outside the ZORA core team are able to create and fund their own bug bounty programs, if desired. Feel free to outline your audit program in your PR description.
+
+After a module has undergone a community audit (ideally about 3-7 days), the module can be deployed and registered
+
+#### Registering a Module
+
+Since the ZORA DAO is currently controlled by a multi-sig, the ZORA Core team will deploy and register audited modules manually. If the module is marked with a "Ready for Deployment" label, it will be picked up in the next available deployment window by the ZORA core team. Once deployed, the contract address will be available in the `addresses/` directory.
+
+### Leaving Feedback
+
+If you have suggestions or comments on how we can better collaborate on this codebase and/or the protocol as a whole, please [create an issue](https://github.com/ourzora/v3/issues/new) outlining your ideas and suggestions. We can then use the issue tracker as an open discussion forum.
+
 ## Local Development
 
 1. Install dependencies with `yarn`