[#17] Add GitHub templates

These templates are more or less copied from the Zcash Android SDK with minor modifications (removing reference to screenshots, Android, or UI manual tests)

.github/ISSUE_TEMPLATE/bug-report.md

@@ -0,0 +1,44 @@
+---
+name: Bug report
+about: Create a report about a bug in Kotlin BIP-39.
+title: ''
+labels: 'bug'
+assignees: ''
+
+---
+
+<!--
+This issue tracker is only for technical issues related to kotlin-bip39 library.
+
+General Zcash questions and/or support requests and are best directed to either:
+ * Zcash Forum: https://forum.zcashcommunity.com/)
+ * Discord Community: https://discord.io/zcash-community
+
+If you wish to report a security issue, please follow our Responsible Disclosure Guidelines: https://github.com/zcash/ZcashLightClientKit/blob/master/responsible_disclosure.md
+-->
+
+### Describe the issue
+<!-- Please provide a general summary of the issue you're experiencing -->
+
+### Can you reliably reproduce the issue?
+#### If so, please list the steps to reproduce below:
+1. 
+2. 
+3. 
+
+### Expected behaviour
+<!-- Tell us what should happen -->
+
+### Actual behavior + errors
+<!-- Tell us what happens instead including any noticeable error output (any messages
+displayed on-screen when e.g. a crash occurred) -->
+<!-- Note: please do not include sensitive information. blur, scratch or annotate any
+information like addresses, usernames, amounts or anything other that you might consider sensitive and it's not relevant to the problem you are reporting.  -->
+
+- App Version: 
+- Android Version:
+- Device: (if applies)
+
+### Any extra information that might be useful in the debugging process.
+<!-- Note: please do not include sensitive information. Blur, scratch or annotate any information like addresses, usernames, amounts or anything other that you might consider sensitive and it's not relevant to the problem you are reporting.-->
+

.github/ISSUE_TEMPLATE/dependency.md

@@ -0,0 +1,23 @@
+---
+name: Dependency update
+about: Update existing dependency to a new version.
+title: ''
+labels: dependencies
+assignees: ''
+
+---
+
+For a Gradle dependency:
+1. Update the dependency version in the root `gradle.properties`
+1. Update the dependency locks
+<!--    1. For Gradle plugins: `./gradlew dependencies --write-locks` -->
+<!--    1. For Gradle dependencies: `./gradlew resolveAll --write-locks` -->
+<!--1. Verify no unexpected entries appear in the lockfiles. _A supply chain attack could occur during this stage. The lockfile narrows the supply chain attack window to this very moment (as opposed to every time a build occurs)_ -->
+1. Are there any new APIs or possible migrations for this dependency?
+
+For Gradle itself:
+1. Update the Gradle version in `gradle/wrapper/gradle-wrapper.properties`
+1. Update the [Gradle SHA](https://gradle.org/release-checksums/) in `gradle/wrapper/gradle-wrapper.properties`
+1. Update the Gradle wrapper by running `./gradlew wrapper`
+1. Re-add the [Gradle SHA](https://gradle.org/release-checksums/) to `gradle/wrapper/gradle-wrapper.properties`
+1. Are there any new APIs or possible migrations?

.github/ISSUE_TEMPLATE/feature-request.md

@@ -0,0 +1,22 @@
+---
+name: Feature request
+about: Suggest an idea for the Secant wallet.
+title: ''
+labels: 'use case'
+assignees: ''
+
+---
+
+## Is your feature request related to a problem? Please describe.
+<!-- A clear and concise description of what the problem is. Example: I'm always
+frustrated when [...] -->
+
+## Describe the solution you'd like
+<!-- A clear and concise description of what you want to happen. -->
+
+## Alternatives you've considered
+<!--A clear and concise description of any alternative solutions or features you've
+considered. -->
+
+## Additional context
+<!-- Add any other context or screenshots about the feature request here. -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,19 @@
+This code review checklist is intended to serve as a starting point for the author and reviewer, although it may not be appropriate for all types of changes (e.g. fixing a spelling typo in documentation).  For more in-depth discussion of how we think about code review, please see [Code Review Guidelines](../blob/main/docs/CODE_REVIEW_GUIDELINES.md).
+
+# Author
+<!-- NOTE: Do not modify these when initially opening the pull request.  This is a checklist template that you tick off AFTER the pull request is created. -->
+- [ ] Self-review: Did you review your own code in GitHub's web interface? _Code often looks different when reviewing the diff in a browser, making it easier to spot potential bugs._
+- [ ] Automated tests: Did you add appropriate automated tests for any code changes?
+- [ ] Documentation: Did you update documentation as appropriate? (e.g [README.md](../blob/master/README.md), etc.)
+- [ ] Run the app: Did you run the demo app and try the changes?
+- [ ] Rebase and squash: Did you pull in the latest changes from the main branch and squash your commits before assigning a reviewer? _Having your code up to date and squashed will make it easier for others to review. Use best judgement when squashing commits, as some changes (such as refactoring) might be easier to review as a separate commit._
+
+
+# Reviewer
+
+- [ ] Checklist review: Did you go through the code with the [Code Review Guidelines](../blob/master/docs/CODE_REVIEW_GUIDELINES.md) checklist?
+- [ ] Ad hoc review: Did you perform an ad hoc review?  _In addition to a first pass using the code review guidelines, do a second pass using your best judgement and experience which may identify additional questions or comments. Research shows that code review is most effective when done in multiple passes, where reviewers look for different things through each pass._
+- [ ] Automated tests: Did you review the automated tests?
+- [ ] Manual tests: Did you review the manual tests?
+- [ ] How is Code Coverage affected by this PR? _We encourage you to compare coverage before and after changes and when possible, leave it in a better place._
+- [ ] Documentation: Did you review Docs and [README.md](../blob/master/README.md) as appropriate?

docs/CODE_REVIEW_GUIDELINES.md

@@ -0,0 +1,48 @@
+# Overall:
+
+- Does the contribution reference an existing GitHub issue?
+- Are the requirements well defined?
+- Does static analysis pass?  (e.g. `./gradlew detektAll`, `./gradlew lint`, `./gradlew ktlint`)
+
+#  Specification:
+
+- Are the requirements for the change well specified? Where are they documented? Bugfixes need a clear specification of the bug's cause and fix. (Small PRs might specify in a GitHub issue. Large changes may require stand-alone docs.)
+- Is there a documented test plan, which describes how to manually verify the change works on testnet prior to a release?
+
+# User Facing Documentation:
+
+- What is the "changelog" entry for this change? (All changes should include this.)
+- Are there any changes which require updates to user facing documentation?  If so, does the new documentation make sense? (documentation should be placed in [.](/docs) folder of the repo)
+
+# Testing:
+
+- For non-minor PRs (up to the code reviewers and PR creator if this is needed), we require authors to perform a thorough self-review and self-test of the resulting code base, including use cases that might not be visible affected by the introduced changes. Reviewers are not expected to run the changes locally, but are definitely encouraged to do so at their best judgement.
+- Are there new tests that check all of the requirements? If it's a bugfix does it include new tests testing the bug triggering condition? (Do they fail before the fix and pass after the fix?)
+- Do tests include edge cases, error conditions, and "negative case" tests to ensure the software is robust? Example: a function for verifying transaction signatures should include a bunch of tests for invalid signature cases.
+- Do tests include all "logical test coverage" in addition to requirements-focused tests? Logical test coverage verifies behavior of the code that isn't obvious or implied by the requirements themselves.
+- Have all of the automated tests been executed by CI? Read over the CI report to verify this. (Note: our CI system may not currently provide test results prior to review. We should change this! In the meantime, the reviewer should run the tests.)
+- Is it clear that the test plan does actually test the new change? Does the test plan include any edge case / negative case / error conditions?
+
+# Code Review:
+- Does the code structure make sense? Does it follow existing conventions / frameworks of existing code, or is it introducing new abstractions / structure?
+- Is the code style consistent with standard guidelines?
+    - [Kotlin Coding Conventions](https://kotlinlang.org/docs/reference/coding-conventions.html)
+    - [Android Open Source Project Conventions](https://source.android.com/source/code-style.html)
+- Does every change make sense? Make sure to ask questions, even or especially "basic" coding questions ("what does this mean in Kotlin?") and domain-newbie questions ("what is the priority system, and why does this line change the priority?").
+
+In summary, here's a checklist that summarizes what reviewers should be looking for when doing a Code Review [1]
+
+- The code is well-designed.
+- The functionality is good for the users of the code.
+- Any parallel programming is done safely.
+- The code isn’t more complex than it needs to be.
+- The developer isn’t implementing things they might need in the future but don’t know they need now or aren't using now.
+- Code has appropriate unit tests.
+- Tests are well-designed.
+- The developer used clear names for everything.
+- Comments are clear and useful, and mostly explain why instead of what.
+- Code is appropriately documented.
+- The code conforms to our style guides.
+- Make sure to review every line of code you’ve been asked to review, look at the context, make sure you’re improving code health, and compliment developers on good things that they do.
+
+[[1] What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)

docs/CONDUCT.md

@@ -0,0 +1,61 @@
+# Contributor Code of Conduct
+
+As contributors and maintainers of this project, and in the interest of
+fostering an open and welcoming community, we pledge to respect all people who
+contribute through reporting issues, posting feature requests, updating
+documentation, submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free
+experience for everyone, regardless of level of experience, gender, gender
+identity and expression, sexual orientation, disability, personal appearance,
+body size, race, ethnicity, age, religion, or nationality.
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery
+* Personal attacks
+* Trolling or insulting/derogatory comments
+* Public or private harassment
+* Publishing other's private information, such as physical or electronic
+  addresses, without explicit permission
+* Other unethical or unprofessional conduct
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful. Note that contributors may be volunteers
+who do not represent Electric Coin Company. They are free to express their own
+opinions so long as they adhere to these guidelines.
+
+By adopting this Code of Conduct, project maintainers commit themselves to
+fairly and consistently applying these principles to every aspect of managing
+this project. Project maintainers who do not follow or enforce the Code of
+Conduct may be permanently removed from the project team.
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting a project maintainer (see below). All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. Maintainers are
+obligated to maintain confidentiality with regard to the reporter of an
+incident.
+
+You may send reports to [our Conduct email](mailto:conduct@z.cash).
+
+If you wish to contact specific maintainers directly, the following have made
+themselves available for conduct issues:
+
+- Daira Hopwood (daira at z.cash)
+- Sean Bowe (sean at z.cash)
+
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.3.0, available at
+[https://www.contributor-covenant.org/version/1/3/0/][version]
+
+[homepage]: https://www.contributor-covenant.org
+[version]: https://www.contributor-covenant.org/version/1/3/0/
+

docs/CONTRIBUTING.md

@@ -0,0 +1,36 @@
+# Contributing Guidelines
+## Pull Requests
+We **love** pull requests!
+
+Pull requests should adhere to our [Code Review Guidelines](CODE_REVIEW_GUIDELINES.md) and [Code of Conduct](CONDUCT.md).
+
+## Getting Started
+Our backlog has many items [tagged with "good first issue"](https://github.com/zcash/kotlin-bip39/labels/good%20first%20issue).  If you'd like to pick one of these up, please fork the repo and make a pull request for us to review.
+
+## Developer's Certificate of Origin
+
+All contributions _will_ be licensed under the MIT license.
+
+By making a contribution to this project, I certify that:
+
+- (a) The contribution was created in whole or in part by me and I
+      have the right to submit it under the open source license
+      indicated in the file; or
+
+- (b) The contribution is based upon previous work that, to the best
+      of my knowledge, is covered under an appropriate open source
+      license and I have the right under that license to submit that
+      work with modifications, whether created in whole or in part
+      by me, under the same open source license (unless I am
+      permitted to submit under a different license), as indicated
+      in the file; or
+
+- (c) The contribution was provided directly to me by some other
+      person who certified (a), (b) or (c) and I have not modified
+      it.
+
+- (d) I understand and agree that this project and the contribution
+      are public and that a record of the contribution (including all
+      personal information I submit with it, including my sign-off) is
+      maintained indefinitely and may be redistributed consistent with
+      this project or the open source license(s) involved.

docs/responsible_disclosure.md

@@ -0,0 +1 @@
+Please see https://github.com/zcash/ZcashLightClientKit/blob/master/responsible_disclosure.md