docs: add essential documents for set-up, build procedure, and execut…

…ing guides (#29)

* docs: update README.md

* docs: add docs folder and apply folder structure with ADR guides

* docs: add How-To and Tutorials contents

* docs: add resources in README.md

* docs: add more contents

* docs: add balance query

* feat: register gRPC gateway routes and sort imports

* docs: update api and cli README.md

* docs: make the sentence consistent with the name field

* Update docs/How-To/cli/README.md

Co-authored-by: dongsam <dongsamb@gmail.com>

* docs: move setup guide to Tutorials and update docs accordingly

* Update docs/Tutorials/localnet/README.md

Co-authored-by: dongsam <dongsamb@gmail.com>

README.md

@@ -1,8 +1,8 @@
 # Budget Module
 
-A budget module is a Cosmos SDK module that implements budget functionality. 
+A budget module is a Cosmos SDK module that implements budget functionality. It is an independent module from other SDK modules and core functionality is to distribute inflation and gas fees to different budget plans. Read [spec docs](./x/budget/spec/01_concepts.md) to get to know more about the module.
 
-⚠ **Budger module v1 is in active development - see "master" branch for the v1 mainnet version** ⚠
+⚠ **Budger module v1 is in active development - see "master" branch for the latest update** ⚠
 
 ## Installation
 ### Requirements
@@ -14,7 +14,7 @@ Requirement | Notes
 Go version  | Go1.15 or higher
 Cosmos SDK  | v0.44.0 or higher
 
-### Get Farming Module source code
+### Get Budget Module source code
 
 ```bash
 git clone https://github.com/tendermint/budget.git
@@ -41,4 +41,6 @@ $ make localnet
 
 ## Resources
 
-...
+- [Documentation about Command-line Interfaces](./docs/How-To/api)
+- [Documentation about REST APIs](./docs/How-To/cli)
+- [MVP Demo](./docs/Tutorials/demo.md)

docs/Explanation/ADR/PROCESS.md

@@ -0,0 +1,67 @@
+# ADR Creation Process
+
+1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md`
+
+2. Create a draft Pull Request if you want to get an early feedback.
+
+3. Make sure the context and a solution is clear and well documented.
+
+4. Add an entry to a list in the [README](./README.md) file.
+
+5. Create a Pull Request to propose a new ADR.
+
+## ADR life cycle
+
+ADR creation is an **iterative** process. Instead of trying to solve all decisions in a single ADR pull request, we MUST initially understand the problem and collect feedback by having conversations in a GitHub Issue.
+
+1. Every ADR proposal SHOULD start with a [new GitHub issue](https://github.com/tendermint/starport/issues/new/choose) or be a result of existing Issues. The Issue must contain a brief proposal summary.
+
+2. After the motivation is validated, create a new document that is on the `adr-template.md`.
+
+3. An ADR solution doesn't have to arrive to the `master` branch with an _accepted_ status in a single PR. If the motivation is clear and the solution is sound, we SHOULD be able to merge PRs iteratively and keep a _proposed_ status. It's preferable to have an iterative approach rather than long, not merged Pull Requests.
+
+4. If a _proposed_ ADR is merged, then the outstanding changes must be clearly documented in outstanding issues in ADR document notes or in a GitHub Issue.
+
+5. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it.
+
+6. Merged ADRs SHOULD NOT be pruned.
+
+### ADR status
+
+Status has two components:
+
+```
+{CONSENSUS STATUS} {IMPLEMENTATION STATUS}
+```
+
+IMPLEMENTATION STATUS is either `Implemented` or `Not Implemented`.
+
+#### Consensus Status
+
+```
+DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEEDED by ADR-xxx
+                  \        |
+                   \       |
+                    v      v
+                     ABANDONED
+```
+
++ `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form.
+
++ `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet.
+
++ `LAST CALL <date for the last call>`: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Budge module maintainers) has been reached and we still want to give it a time to let the community react or analyze.
+
++ `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design.
+
++ `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
+
++ `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
+
++ `ABANDONED`: the ADR is no longer pursued by the original authors.
+
+## Language used in ADR
+
++ Write the context/background in the present tense.
+
++ Avoid using a first, personal form.

docs/Explanation/ADR/README.md

@@ -0,0 +1,39 @@
+# Architecture Decision Records (ADR)
+
+Use this location to record all high-level architecture decisions in the Budget module.
+
+### Definitions
+
+Within the context of an ADR we define the following:
+An Architectural Decision (**AD**) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant.
+An Architecturally Significant Requirement (**ASR**) is a requirement that has a measurable effect on a software system’s architecture and quality.
+An Architectural Decision Record (**ADR**) captures a single AD, and is as often done when writing personal notes or meeting minutes. The collection of ADRs created and maintained in a project constitute its decision log. All these records are within the topic of Architectural Knowledge Management (AKM).
+
+You can read more about the ADR concept in the [Documenting architecture decisions, the Reverb way](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t) blog post.
+
+## Rationale
+
+ADRs are intended to be the primary mechanism for proposing new feature designs and new processes, for collecting community input on an issue, and for documenting the design decisions.
+An ADR should provide:
+
+- Context on the relevant goals and the current state
+- Proposed changes to achieve the goals
+- Summary of pros and cons
+- References
+- Changelog
+
+Note the distinction between an ADR and a specification. The ADR provides the context, intuition, reasoning, and justification for a change in architecture, or for the architecture of something new. The specification is a summary of everything as it stands today.
+
+If recorded decisions turned out to be lacking the required substance, the process is to convene a discussion, record the new decisions here, and then modify the code to match.
+
+## Creating new ADR
+
+Read about the [PROCESS](./PROCESS.md).
+
+#### Use RFC 2119 Keywords
+
+When writing ADRs, follow the same best practices for writing RFCs. When writing RFCs, key words are used to signify the requirements in the specification. These words are often capitalized: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL. They are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
+
+## ADR Table of Contents
+
+- [ADR XXX: Self Sovereign Identity](./adr-001-self-sovereign-identity.md)