[#2] Add project documentation and templates

.github/ISSUE_TEMPLATE/bug-report.md

@@ -0,0 +1,45 @@
+---
+name: Bug report
+about: Create a report about a bug in Secant Android Wallet.
+title: ''
+labels: 'bug'
+assignees: ''
+
+---
+
+<!--
+This issue tracker is only for technical issues related to Secant Android Wallet.
+
+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 behaviour + errors
+<!-- Tell us what happens instead including any noticable 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/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/ISSUE_TEMPLATE/ux-report.md

@@ -0,0 +1,18 @@
+---
+name: UX report
+about: Was this wallet hard to use? It's not you, it's us. We want to hear about it.
+title: 'UX: '
+labels: 'usability'
+assignees: ''
+
+---
+
+<!-- Did the wallet not do what you expected?
+Was it hard to figure out how to do something?
+Could an error message be more helpful?
+It's not you, it's us. We want to hear about it. -->
+
+## What were you trying to do
+
+## What happened
+

.github/pull_request_template.md

@@ -0,0 +1,23 @@
+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?
+- [ ] Manual tests: Did you update the [manual tests](../blob/main/docs/testing/manual_testing) as appropriate? _While we aim for automated testing of the application, some aspects require manual testing. If you had to manually test something during development of this pull request, write those steps down._
+- [ ] Code coverage: Did you check the code coverage report for the automated tests?  _While we are not looking for perfect coverage, the tool can point out potential cases that have been missed._
+- [ ] Documentation: Did you update documentation as appropiate? (e.g [README.md](../blob/main/README.md), etc.)
+- [ ] Run the app: Did you run the app and try the changes?
+- [ ] Screenshots: Did you provide before and after UI screenshots in the description of this pull request?  _This is only applicable for changes that modify the UI._
+- [ ] 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/main/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 your changes and when possible, leave it in a better place._
+- [ ] Documentation: Did you review Docs, [README.md](../blob/main/README.md), and [Architecture.md](../blob/main/docs/Architecture.md) as appropriate?
+- [ ] Run the app: Did you run the app and try the changes? _While the CI server runs the app to look for build failures or crashes, humans running the app are more likely to notice unexpected log messages, UI inconsistencies, or bad output data. Perform this step last, after verifying the code changes are safe to run locally._

.gitignore

@@ -0,0 +1,18 @@
+syntax: glob
+.DS_Store
+.gradle/
+.idea/caches
+.idea/codeStyles
+.idea/compiler.xml
+.idea/dictionaries/
+.idea/gradle.xml
+.idea/libraries/
+.idea/modules.xml
+.idea/tasks.xml
+.idea/workspace.xml
+.settings
+*.iml
+bin/
+build/
+gen/
+local.properties

README.md

@@ -1,2 +1,23 @@
 # secant-android-wallet
-Reference wallet showcasing Orchard and Halo features.
+_Note: As of September 2021, this is a brand new project.  Since it is being developed in the open from the beginning, initially this project will not be fully functional.  Some of the documentation below will be aspirational until the implementation is further along.  During this initial stage of development, the older [Zcash Android Wallet](https://github.com/zcash/zcash-android-wallet) may be a more helpful sample._
+
+This is a sample implementation of a Zcash wallet for Android leveraging the [Zcash Android SDK](https://github.com/zcash/zcash-android-wallet-sdk).  The goal is to exercise the SDK and related Zcash libraries, as well as demonstrate how the SDK works.
+
+While we aim to continue improving this sample, it is not an official product.  We open sourced it as a resource to make wallet development easier for the Zcash ecosystem.
+
+# Getting Started
+If you'd like to compile this application from source, please see our [Setup Documentation](docs/Setup.md) to get started.
+
+# Reporting an issue
+If you wish to report a security issue, please follow our [Responsible Disclosure guidelines](https://github.com/zcash/ZcashLightClientKit/blob/master/responsible_disclosure.md).  See the [Wallet App Threat Model](https://zcash.readthedocs.io/en/latest/rtd_pages/wallet_threat_model.html) for more information about the security and privacy limitations of the wallet.  There are some known security and privacy limitations:
+- Traffic analysis, like in other cryptocurrency wallets, can leak some privacy of the user.
+- The wallet requires a trust in the server to display accurate transaction information.
+
+If you'd like to report a technical issue or feature request for the Android Wallet, please file a [GitHub issue](https://github.com/zcash/secant-android-wallet/issues/new/choose).
+
+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)
+
+# Contributing
+Contributions are very much welcomed!  Please read our [Contributing Guidelines](docs/CONTRIBUTING.md) to learn about our process.

docs/Architecture.md

@@ -0,0 +1,2 @@
+# Architecture
+TODO This is a placeholder for describing the app architecture.

docs/CODE_REVIEW_GUIDELINES.md

@@ -0,0 +1,50 @@
+# Overall:
+
+- Does the contribution referece an existing Issue?
+- Are the requirements well defined?
+
+
+#  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.
+- When introducing modifications that affect the UI, screenshots might be provided in a BEFORE/AFTER fashion to speed up UI/UX requirement validation.
+- 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 UI changes are sensible and look good.
+- 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,38 @@
+# 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/secant-android-wallet/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.
+
+Our [Architecture.md](docs/Architecture.md) documentation is a good reference get oriented on the structure of the codebase.
+
+## 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/README.md

@@ -0,0 +1,4 @@
+# Documentation
+
+Here you'll find documentation
+TBD

docs/Setup.md

@@ -0,0 +1,44 @@
+# Setup Guide
+## Gradle
+The app is built with Gradle and can be compiled on macOS, Windows, and Linux.
+
+Tip: On macOS and Linux, Gradle is invoked with `./gradlew`.  On Windows, Gradle is invoked with `gradlew`.  Throughout the documentation, the macOS and Linux syntax is used by default.
+
+Tip: You do NOT need to install Gradle yourself.  Running it from the command line or building the application within Android Studio will download the necessary dependencies automatically.
+
+## Android Studio
+Development is typically done with the latest stable release of Android Studio.
+
+## Step by Step
+To get set up for development, there are several steps that you need to go through.  Going through these steps in order is important, as each step in the progression builds on the prior steps.
+
+Start by making sure the command line with Gradle works first, because **all the Android Studio run configurations use Gradle internally.**  The run configurations are not magic—they map directly to command line invocations with different arguments.
+
+When troubleshooting, fall back to trying the command line.  Android Studio is a large and complex application, although under the hood it uses Gradle.  Sometimes Android Studio will have a bug or failure that is bypassed by using the Gradle command line directly.
+
+1. Install Java
+    1. Java 16 is currently recommended. Java 11 is the minimum requirement for Android Studio.
+    1. To simplify installation, use [Oracle's JDK](https://www.oracle.com/java/technologies/javase-jdk15-downloads.html) installer that will place the Java installation in the right place
+1. Install Android Studio and the Android SDK
+    1. Download the [stable release of Android Studio](https://developer.android.com/studio#downloads)
+    1. TODO: Fill in step-by-step instructions for setting up a new environment and installing the Android SDK from within Android Studio.
+1. Check out the code.  _Use the command line (instead of Android Studio) to check out the code. This will ensure that your command line environment is set up correctly and avoids a few pitfalls with trying to use Android Studio directly.  Android Studio's built-in git client is not as robust as standalone clients_
+1. Compile from the command line
+    1. Navigate to the repo checkout in a terminal
+    1. Compile the application with the gradle command `./gradlew assemble`
+1. Compile from Android Studio
+    1. Open Android Studio
+    1. From within Android Studio, choose to open an existing project and navigate to the checked out repo
+    1. After Android Studio finishes syncing with Gradle, look for the green "play" run button in the toolbar.  To the left of it, choose the "App" run configuration under the dropdown menu.  Then hit the run button
+
+# Troubleshooting
+Sometimes during upgrades to Gradle or Kotlin, corruption or weird issues can happen with a build.  Try troubleshooting with the following steps:
+
+1. Try running from the command line instead of Android Studio, to rule out Android Studio issues.  If it works from the command line, try this step to reset Android Studio
+    1. Quit Android Studio
+    2. Deleting the invisible `.idea` in the root directory of the project
+    3. Relaunch Android Studio
+2. Clean the individual Gradle project by running `./gradlew clean` which will purge local build outputs.
+3. Run Gradle with the flag `--rerun-tasks` which will effectively disable the build cache by re-running tasks and repopulating the cache.  E.g. `./gradlew assemble --rerun-tasks`
+4. Reboot your computer, which will ensure that Gradle and Kotlin daemons are completely killed and relaunched
+5. Delete the global Gradle cache under `~/.gradle/caches`

docs/responsible_disclosure.md

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

docs/testing/local_coverage.md

@@ -0,0 +1,4 @@
+# Gathering Code Coverage
+The Android Gradle plugin supports code coverage with Jacoco.  This integration can sometimes be buggy.  For that reason, coverage is disabled by default and can be enabled on a case-by-case basis, by passing `-PIS_COVERAGE_ENABLED=true` as a command line argument for Gradle builds.  For example: `./gradlew :app:connectedCheck -PIS_COVERAGE_ENABLED=true`.
+
+When coverage is enabled, running instrumentation tests will automatically generate coverage reports stored under `build/reports/coverage`.

docs/testing/manual_testing/README.md

@@ -0,0 +1,5 @@
+# Manual testing
+
+We aim to automate as much as we possibly can. Still manual testing is really important for Quality Assurance. 
+
+Here you'll find our manual testing scripts. When developing a new feature you can add your own that provide the proper steps to properly test it.