Add changelog and .github issue templates (#39)

* Add changelog and .github issue templates

.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 (main)
+- [ ] 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,29 @@
+## Pending
+
+### Breaking changes
+- #12 Make FpVar's ToBitsGadget output constant length bit vectors.
+
+### Features
+
+
+### Improvements
+- #5 Speedup BLS-12 pairing
+- #13 Add ToConstraintFieldGadget to ProjectiveVar
+- #15, #16 Allow cs to be none when converting a montgomery point into a twisted edwards point
+- #20 Add conditional select gadget to Uints
+- #21 Add Uint128
+- #22 Reduce density of `three_bit_cond_neg_lookup`
+- #23 Reduce allocations in Uints
+- #33 Speedup scalar multiplication by a constant
+- #35 Construct a FpVar from bits
+- #36 ImplementToConstraintFieldGadget for `Vec<Uint8>`
+
+### Bug fixes
+- #8 Fix bug in three_bit_cond_neg_lookup when using a constant lookup bit
+- #9 Fix bug in short weierstrass projective curve point's to_affine method
+- #29 Fix `to_non_unique_bytes` for `BLS12::G1Prepared`
+- #34 Fix `mul_by_inverse` for constants
+
+## v0.1.0
+
+Initial release

CONTRIBUTING.md

@@ -0,0 +1,65 @@
+# Contributing
+
+Thank you for considering making contributions to `arkworks-rs/r1cs-std`!
+
+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 `main`, make some commits on your branch, and submit a PR from the branch to `main`.
+    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
+
+`r1cs-std` has its default branch as `main`, 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/r1cs-std.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 main
+git pull upstream main
+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 almost always not the case for these complex protocols.
+(Even when you 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.