Add Changelog and contributing file (#31)

* Add issue/PR templates

Co-authored-by: Pratyush Mishra <pratyushmishra@berkeley.edu>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,25 @@
+---
+name: Bug Report 
+about: Create a report to help us squash bugs!
+
+---
+
+<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ 
+v                            ✰  Thanks for opening an issue! ✰    
+v    Before smashing the submit button please review the template.
+v    Please also ensure that this is not a duplicate issue :)  
+☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  -->∂
+
+## Summary of Bug
+
+<!-- Concisely describe the issue -->
+
+## Version
+
+<!-- git commit hash or tagged version -->
+
+## Steps to Reproduce
+
+<!-- Also please note what feature flags the library was compiled with? -->
+<!-- If this is a build issue, also indicate your OS and compiler versions (clang --version) -->
+

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,35 @@
+---
+name: Feature Request
+about: Create a proposal to request a feature
+
+---
+
+<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺ 
+v                            ✰  Thanks for opening an issue! ✰    
+v    Before smashing the submit button please review the template.
+v    Word of caution: poorly thought-out proposals may be rejected 
+v                     without deliberation 
+☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  -->
+
+## Summary
+
+<!-- Short, concise description of the proposed feature -->
+
+## Problem Definition
+
+<!-- Why do we need this feature? 
+What problems may be addressed by introducing this feature?
+Are there any disadvantages of including this feature? -->
+
+## Proposal
+
+<!-- Detailed description of requirements of implementation -->
+
+____
+
+#### For Admin Use
+
+- [ ] Not duplicate issue
+- [ ] Appropriate labels applied
+- [ ] Appropriate contributors tagged
+- [ ] Contributor assigned/self-assigned

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,26 @@
+<!-- < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < ☺
+v                               ✰  Thanks for creating a PR! ✰
+v    Before hitting that submit button please review the checkboxes.
+v    If a checkbox is n/a - please still include it but + a little note why
+☺ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  -->
+
+## Description
+
+<!-- Add a description of the changes that this PR introduces and the files that
+are the most critical to review.
+-->
+
+closes: #XXXX
+
+---
+
+Before we can merge this PR, please make sure that all the following items have been
+checked off. If any of the checklist items are not applicable, please leave them but
+write a little note why.
+
+- [ ] Targeted PR against correct branch (master)
+- [ ] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
+- [ ] Wrote unit tests
+- [ ] Updated relevant documentation in the code
+- [ ] Added a relevant changelog entry to the `Pending` section in `CHANGELOG.md`
+- [ ] Re-reviewed `Files changed` in the Github PR explorer

CHANGELOG.md

@@ -0,0 +1,28 @@
+## Pending
+
+### Breaking changes
+- Requires all crates from `arkworks-rs/algebra` to have version `v0.2.0` or greater.
+
+### Features
+- #3 Add constraints for 
+        `ark-bls12-377`,
+        `ark-ed-on-bls12-377`,
+        `ark-ed-on-bls12-381`,
+        `ark-ed-on-bn254`,
+        `ark-ed-on-cp6-782`,
+        `ark-ed-on-bw6-761`,
+        `ark-ed-on-mnt4-298`,
+        `ark-ed-on-mnt4-753`,
+        `ark-mnt4-298`,
+        `ark-mnt6-298`,
+        `ark-mnt4-753`,
+        `ark-mnt6-753`
+- #7 Add benchmarks for Edwards curves
+- #19 Change field constants to be provided as normal strings, instead of in montgomery form.
+
+### Bug fixes
+- #28 fix broken documentation links
+
+## v0.1.0
+
+Initial Release

CONTRIBUTING.md

@@ -0,0 +1,65 @@
+# Contributing
+
+Thank you for considering making contributions to `curves`!
+
+Contributing to this repo can be done in several forms, such as participating in discussion or proposing code changes. 
+To ensure a smooth workflow for all contributors, the following general procedure for contributing has been established:
+
+1) Either open or find an issue you'd like to help with
+2) Participate in thoughtful discussion on that issue
+3) If you would like to contribute:
+    * If the issue is a feature proposal, ensure that the proposal has been accepted
+    * Ensure that nobody else has already begun working on this issue. 
+    If they have, please try to contact them to collaborate
+    * If nobody has been assigned for the issue and you would like to work on it, make a comment on the issue to inform the community of your intentions to begin work. (So we can avoid duplication of efforts)
+    * We suggest using standard Github best practices for contributing: fork the repo, branch from the HEAD of `master`, make some commits on your branch, and submit a PR from the branch to `master`.
+    More detail on this is below
+    * Be sure to include a relevant change log entry in the Pending section of CHANGELOG.md (see file for log format)
+        * If the change is breaking, we may add migration instructions.
+
+Note that for very small or clear problems (such as typos), or well isolated improvements, it is not required to an open issue to submit a PR.
+But be aware that for more complex problems/features touching multiple parts of the codebase, if a PR is opened before an adequate design discussion has taken place in a github issue, that PR runs a larger likelihood of being rejected.
+
+Looking for a good place to start contributing? How about checking out some good first issues
+
+## Branch Structure
+
+`curves` has its default branch as `master`, which is where PRs are merged into. Releases will be periodically made, on no set schedule.
+All other branches should be assumed to be miscellaneous feature development branches.
+
+All downstream users of the library should be using tagged versions of the library pulled from cargo.
+
+## How to work on a fork
+Please skip this section if you're familiar with contributing to opensource github projects.
+
+First fork the repo from the github UI, and clone it locally.
+Then in the repo, you want to add the repo you forked from as a new remote. You do this as:
+```bash
+git remote add upstream git@github.com:arkworks-rs/curves.git
+```
+
+Then the way you make code contributions is to first think of a branch name that describes your change.
+Then do the following:
+```bash
+git checkout master
+git pull upstream master
+git checkout -b $NEW_BRANCH_NAME
+```
+and then work as normal on that branch, and pull request to upstream master when you're done =)
+
+## Updating documentation
+
+All PRs should aim to leave the code more documented than it started with.
+Please don't assume that its easy to infer what the code is doing,
+as that is usually not the case for these complex protocols.
+(Even when you already understand the paper!)
+
+Its often very useful to describe what is the high level view of what a code block is doing,
+and either refer to the relevant section of a paper or include a short proof/argument for why it makes sense before the actual logic.
+
+## Performance improvements
+
+All performance improvements should be accompanied with benchmarks improving, or otherwise have it be clear that things have improved.
+For some areas of the codebase, performance roughly follows the number of field multiplications, but there are also many areas where
+hard to predict low level system effects such as cache locality and superscalar operations become important for performance.
+Thus performance can often become very non-intuitive / diverge from minimizing the number of arithmetic operations.