Prepare open source

.github/ISSUE_TEMPLATE/bug-report.md

@@ -0,0 +1,28 @@
+---
+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 release version -->
+
+## Steps to Reproduce
+<!-- What commands in order should someone run to reproduce your problem? -->
+
+____
+
+## For Admin Use
+
+- [ ] Not duplicate issue
+- [ ] Appropriate labels applied
+- [ ] Appropriate contributors tagged
+- [ ] Contributor assigned/self-assigned

.github/ISSUE_TEMPLATE/feature-request.md

@@ -0,0 +1,32 @@
+---
+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?
+What benefits does the SDK stand to gain by including 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/workflows/finschia-test.yml

@@ -17,7 +17,7 @@ jobs:
 
       - name: download contracts
         run: |
-          cd scripts/lbm/contracts
+          cd scripts/finschia/contracts
           bash download.sh
 
       - name: Set up Node.js
@@ -37,11 +37,11 @@ jobs:
       - name: Build
         run: yarn build
 
-      - name: start lbm
-        run: CI= scripts/lbm/start.sh
+      - name: start finschia
+        run: CI= scripts/finschia/start.sh
 
-      - name: init contract on lbm
-        run: scripts/lbm/init.sh
+      - name: init contract on finschia
+        run: scripts/finschia/init.sh
 
       - name: Unit Test
         run: |

.gitignore

@@ -36,4 +36,4 @@ coverage/
 # We are not using yarn's deferred versioning for now (see https://yarnpkg.com/features/release-workflow)
 # !.yarn/versions
 scripts/simapp/test_chain_data
-scripts/lbm/test_chain_data
+scripts/finschia/test_chain_data

CODE_OF_CONDUCT.md

@@ -0,0 +1,132 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, caste, color, religion, or sexual
+identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the overall
+  community
+
+Examples of unacceptable behavior include:
+
+- The use of sexualized language or imagery, and sexual attention or advances of
+  any kind
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or email address,
+  without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders 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, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at [dev@finschia.org]
+(mailto:dev@finschia.org). All complaints will be reviewed and investigated promptly 
+and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series of
+actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or permanent
+ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within the
+community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder][mozilla coc].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][faq]. Translations are available at
+[https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[mozilla coc]: https://github.com/mozilla/diversity
+[faq]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

CONTRIBUTING.md

@@ -0,0 +1,129 @@
+# How to contribute to Finschia-js
+
+First of all, thank you so much for taking your time to contribute!
+It will be amazing if you could help us by doing any of the following:
+
+- File an issue in [the issue tracker](https://github.com/line/finschia-js/issues) to report bugs and propose new features and
+  improvements.
+- Ask a question by creating a new issue in [the issue tracker](https://github.com/line/finschia-js/issues).
+  - Browse [the list of previously answered questions](https://github.com/line/finschia-js/issues?q=label%3Aquestion).
+- Contribute your work by sending [a pull request](https://github.com/line/finschia-js/pulls).
+
+## Contributor license agreement
+
+When you are sending a pull request and it's a non-trivial change beyond fixing typos, please sign 
+the ICLA (individual contributor license agreement). Please
+[contact us](mailto:dev@finschia.org) if you need the CCLA (corporate contributor license agreement).
+
+## Code of conduct
+
+We expect contributors to follow [our code of conduct](https://github.com/line/finschia-js/blob/main/CODE_OF_CONDUCT.md).
+
+## Commit message and Pull Request message
+
+- Follow [Conventional Commit](https://www.conventionalcommits.org) to release note automation.
+- Don't mention or link that can't accessible from public.
+- Use English only. Because this project will be published to the world-wide open-source world. But no worries. We are fully aware of that most of us are not the English-native.
+
+## Pull Requests
+
+To accommodate review process we suggest that PRs are categorically broken up.
+Ideally each PR addresses only a single issue. Additionally, as much as possible
+code refactoring and cleanup should be submitted as a separate PRs from bugfixes/feature-additions.
+
+### Process for reviewing PRs
+
+All PRs require two Reviews before merge (except docs changes, or variable name-changes which only require one). When reviewing PRs please use the following review explanations:
+
+- `LGTM` without an explicit approval means that the changes look good, but you haven't pulled down the code, run tests locally and thoroughly reviewed it.
+- `Approval` through the GH UI means that you understand the code, documentation/spec is updated in the right places, you have pulled down and tested the code locally. In addition:
+  - You must also think through anything which ought to be included but is not
+  - You must think through whether any added code could be partially combined (DRYed) with existing code
+  - You must think through any potential security issues or incentive-compatibility flaws introduced by the changes
+  - Naming must be consistent with conventions and the rest of the codebase
+  - Code must live in a reasonable location, considering dependency structures (e.g. not importing testing modules in production code, or including example code modules in production code).
+  - if you approve of the PR, you are responsible for fixing any of the issues mentioned here and more
+- If you sat down with the PR submitter and did a pairing review please note that in the `Approval`, or your PR comments.
+- If you are only making "surface level" reviews, submit any notes as `Comments` without adding a review.
+
+## Forking
+To create a fork and work on a branch of it, I would:
+
+- Create the fork on github, using the fork button.
+- Go to the original repo checked out locally
+- `git remote rename origin upstream`
+- `git remote add origin git@github.com:someone/finschia-js.git`
+
+Now `origin` refers to my fork and `upstream` refers to the finschia-js version.
+So I can `git push -u origin main` to update my fork, and make pull requests to finschia-js from there.
+Of course, replace `someone` with your git handle.
+
+To pull in updates from the origin repo, run
+
+- `git fetch upstream`
+- `git rebase upstream/main` (or whatever branch you want)
+
+Please don't make Pull Requests from `main`.
+
+## Dependencies
+
+We use [yarn 3.1](https://classic.yarnpkg.com/lang/en/) to manage
+dependency versions.
+
+The `main` branch of every finschia-js repository should just build with `yarn install`, `yarn build`,
+which means they should be kept up-to-date with their dependencies, so we can
+get away with telling people they can just go get our software.
+
+## Testing
+
+Tests can be ran by running `yarn test` at the top level of the finschia-js repository.
+
+To run tests that need to interact with the chain (e.g. contract instantiation), start the test chain with `./scripts/finschia/start.sh` and `./scripts/finschia/init.sh`. After start up a test chain, run tests with `SIMAPP_ENABLED=true yarn test`.
+
+## Branching Model and Release
+
+User-facing repos should adhere to the trunk based development branching model: https://trunkbaseddevelopment.com/.
+
+Libraries need not follow the model strictly, but would be wise to.
+
+This repo utilizes [semantic versioning](https://semver.org/).
+
+### PR Targeting
+
+Ensure that you base and target your PR on the `main` branch.
+
+All feature additions should be targeted against `main`. Bug fixes for an outstanding release candidate
+should be targeted against the release candidate branch.
+
+### Development Procedure
+
+- the latest state of development is on `main`
+- `main` must never fail `yarn build`, `yarn test`
+- `main` should not fail `yarn lint`
+- no `--force` onto `main` (except when reverting a broken commit, which should seldom happen)
+- create a development branch either on github.com/line/finschia-js, or your fork (using `git remote add origin`)
+- before submitting a pull request, begin `git rebase` on top of `main`
+
+### Pull Merge Procedure
+
+- ensure pull branch is rebased on `main`
+- run `yarn test` to ensure that all tests pass
+- run `yarn lint-fix` to ensure that linting is done
+- merge pull request (We are using `squash and merge` for small features)
+
+### Release Procedure
+
+- Start on `main`
+- Create the release candidate branch `rc/v*` (going forward known as **RC**)
+  and ensure it's protected against pushing from anyone except the release
+  manager/coordinator
+  - **no PRs targeting this branch should be merged unless exceptional circumstances arise**
+- On the `RC` branch, prepare a new version section in the `CHANGELOG.md`
+  - All links must be link-ified
+  - Copy the entries into a `RELEASE_CHANGELOG.md`, this is needed so the bot knows which entries to add to the release page on github.
+- After all test has successfully completed, create the release branch
+  (`release/vX.XX.X`) from the `RC` branch
+- Create a PR to `main` to incorporate the `CHANGELOG.md` updates
+- Tag the release (use `git tag -a`) and create a release in Github
+- Delete the `RC` branches
+