docs: Repo Templates (#1483)

* first

* files

* reduce

* templates

* cont

* more files

* typo

* contrib

* typo

* headers

* Github Discussions

---------

Co-authored-by: Amit Zafran <[email protected]>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,46 @@
+name: 🐛 Bug report
+description: Create a report to help us squash bugs!
+title: "[Bug]: "
+labels: ["T:Bug"]
+
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to fill out this bug report!
+        Before smashing the submit button please review the template.
+
+  - type: checkboxes
+    attributes:
+      label: Is there an existing issue for this?
+      description: Please search existing issues to avoid creating duplicates.
+      options:
+        - label: I have searched the existing issues
+          required: true
+
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened?
+      description: Also tell us, what did you expect to happen?
+      placeholder: Tell us what you see!
+      value: "A bug happened!"
+    validations:
+      required: true
+
+  - type: input
+    attributes:
+      label: Lava Version
+      description: If applicable, specify the binary and the version you're using
+      placeholder: lavad v0.46, lavap v0.47, main, etc.
+    validations:
+      required: true
+
+  - type: textarea
+    id: reproduce
+    attributes:
+      label: How to reproduce?
+      description: If applicable could you describe how we could reproduce the bug
+      placeholder: Tell us what how to reproduce the bug!
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/feature-request.yml

@@ -0,0 +1,41 @@
+name: Feature Request
+description: Create a proposal to request a feature
+title: "[Feature]: "
+labels: ["T:feature-request"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+       ✰  Thanks for opening an issue! ✰  
+  - type: textarea
+    id: summary
+    attributes:
+      label: Summary
+      description: |
+        What are the user needs?
+        How could this solution fix the user facing problem? 
+      placeholder: Short, concise description of the proposed feature/changes to the repository
+    validations:
+      required: true
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem Definition
+      description: |
+        If applicable please answer the below questions
+        Why do we need this feature? 
+        What problems may be addressed by introducing this feature?
+        What benefits does Lava stand to gain by including this feature?
+        Are there any disadvantages of including this feature?
+      placeholder: Description of the issue being faced
+    validations:
+      required: false
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposed Feature
+      description: |
+        Description of the proposed features or changes to an existing feature to meet your needs
+      placeholder: Description of the proposed feature(s)
+    validations:
+      required: true

.github/pull_request_template.md

@@ -0,0 +1,47 @@
+# Description
+
+Closes: #XXXX
+
+<!-- Add a description of the changes that this PR introduces and the files that
+are the most critical to review. -->
+
+---
+
+## Author Checklist
+
+*All items are required. Please add a note to the item if the item is not applicable and
+please add links to any relevant follow up issues.*
+
+I have...
+
+* [ ] read the [contribution guide](../CONTRIBUTING.md)
+* [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title, you can find examples of the prefixes below:
+    <!-- * `feat`: A new feature
+    * `fix`: A bug fix
+    * `docs`: Documentation only changes
+    * `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+    * `refactor`: A code change that neither fixes a bug nor adds a feature
+    * `perf`: A code change that improves performance
+    * `test`: Adding missing tests or correcting existing tests
+    * `build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+    * `ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
+    * `chore`: Other changes that don't modify src or test files
+    * `revert`: Reverts a previous commit -->
+* [ ] confirmed `!` in the type prefix if API or client breaking change
+* [ ] targeted the `main` branch
+* [ ] provided a link to the relevant issue or specification
+* [ ] reviewed "Files changed" and left comments if necessary
+* [ ] included the necessary unit and integration tests
+* [ ] updated the relevant documentation or specification, including comments for [documenting Go code](https://blog.golang.org/godoc)
+* [ ] confirmed all CI checks have passed
+
+## Reviewers Checklist
+
+*All items are required. Please add a note if the item is not applicable and please add
+your handle next to the items reviewed if you only reviewed selected items.*
+
+I have...
+
+* [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
+* [ ] confirmed all author checklist items have been addressed
+* [ ] reviewed state machine logic, API design and naming, documentation is accurate, tests and test coverage

CODE_OF_CODUCT.md

@@ -0,0 +1,70 @@
+# Code of Conduct - Lava
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to make participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## 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
+* 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
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+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.
+
+## 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 <>.
+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.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://contributor-covenant.org/), version
+[1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct/code_of_conduct.md) and
+[2.0](https://www.contributor-covenant.org/version/2/0/code_of_conduct/code_of_conduct.md),
+and was generated by [contributing-gen](https://github.com/bttger/contributing-gen).

CODING_GUIDELINES.md

@@ -0,0 +1,124 @@
+# Coding Guidelines
+
+This document is an extension to [CONTRIBUTING](./CONTRIBUTING.md) and provides more details about the coding guidelines and requirements.
+
+## API & Design
+
+* Code must be well structured:
+    * packages must have a limited responsibility (different concerns can go to different packages),
+    * types must be easy to compose,
+    * think about maintainability and testability.
+* "Depend upon abstractions, [not] concretions".
+* Try to limit the number of methods you are exposing. It's easier to expose something later than to hide it.
+* Take advantage of `internal` package concept.
+* Follow agreed-upon design patterns and naming conventions.
+* publicly-exposed functions are named logically, have forward-thinking arguments and return types.
+* Avoid global variables and global configurators.
+* Favor composable and extensible designs.
+* Minimize code duplication.
+* Limit third-party dependencies.
+
+### Performance
+
+* Avoid unnecessary operations or memory allocations.
+
+### Security
+
+* Pay proper attention to exploits involving:
+    * gas usage
+    * transaction verification and signatures
+    * malleability
+    * code must be always deterministic
+* Thread safety. If some functionality is not thread-safe, or uses something that is not thread-safe, then clearly indicate the risk on each level.
+
+### Documentation
+
+When writing code that is complex or relies on another piece of the code, it is advised to create a diagram or a flowchart to explain the logic. This will help other developers to understand the code and will also help you to understand the logic better.
+
+Lava uses [Mermaid.js](https://mermaid.js.org/), you can find the documentation on how to use it [here](https://mermaid.js.org/intro/).
+
+## Acceptance tests
+
+Start the design by defining Acceptance Tests. The purpose of Acceptance Testing is to
+validate that the product being developed corresponds to the needs of the real users
+and is ready for launch. Hence we often talk about **User Acceptance Test** (UAT).
+It also gives a better understanding of the product and helps designing a right interface
+and API.
+
+UAT should be revisited at each stage of the product development:
+
+
+### Why Acceptance Testing
+
+* Automated acceptance tests catch serious problems that unit or component test suites could never catch.
+* Automated acceptance tests deliver business value the users are expecting as they test user scenarios.
+* Automated acceptance tests executed and passed on every build help improve the software delivery process.
+* Testers, developers, and customers need to work closely to create suitable automated acceptance test suites.
+
+### How to define Acceptance Test
+
+The best way to define AT is by starting from the user stories and think about all positive and negative scenarios a user can perform.
+
+Product Developers should collaborate with stakeholders to define AT. Functional experts and business users are both needed for defining AT.
+
+A good pattern for defining AT is listing scenarios with [GIVEN-WHEN-THEN](https://martinfowler.com/bliki/GivenWhenThen.html) format where:
+
+* **GIVEN**: A set of initial circumstances (e.g. bank balance)
+* **WHEN**: Some event happens (e.g. customer attempts a transfer)
+* **THEN**: The expected result as per the defined behavior of the system
+
+In other words: we define a use case input, current state and the expected outcome. Example:
+
+> Feature: User trades stocks.
+> Scenario: User requests a sell before close of trading
+>
+>     Given I have 100 shares of MSFT stock
+>        And I have 150 shares of APPL stock
+>        And the time is before close of trading
+>
+>     When I ask to sell 20 shares of MSFT stock
+>
+>      Then I should have 80 shares of MSFT stock
+>       And I should have 150 shares of APPL stock
+>       And a sell order for 20 shares of MSFT stock should have been executed
+
+*Reference: [writing acceptance tests](https://openclassrooms.com/en/courses/4544611-write-agile-documentation-user-stories-acceptance-tests/4810081-writing-acceptance-tests)*.
+
+### How and where to add acceptance tests
+
+Acceptance tests are written in the Markdown format, using the scenario template described above, and be part of the specification (`xx_test.md` file in *spec* directory). Example: [`eco-credits/spec/06.test.md`](https://github.com/regen-network/regen-ledger/blob/7297783577e6cd102c5093365b573163680f36a1/x/ecocredit/spec/06_tests.md).
+
+Acceptance tests should be defined during the design phase or at an early stage of development. Moreover, they should be defined before writing a module architecture - it will clarify the purpose and usage of the software.
+Automated tests should cover all acceptance tests scenarios.
+
+## Automated Tests
+
+Make sure your code is well tested:
+
+* Provide unit tests for every unit of your code if possible. Unit tests are expected to comprise 70%-80% of your tests.
+* Describe the test scenarios you are implementing for integration tests.
+* Create integration tests for queries and msgs.
+* Use both test cases and property / fuzzy testing.
+* Do not decrease code test coverage. Explain in a PR if test coverage is decreased.
+
+We expect tests to use `require` or `assert` rather than `t.Skip` or `t.Fail`,
+unless there is a reason to do otherwise.
+When testing a function under a variety of different inputs, we prefer to use
+[table driven tests](https://github.com/golang/go/wiki/TableDrivenTests).
+Table driven test error messages should follow the following format
+`<desc>, tc #<index>, i #<index>`.
+`<desc>` is an optional short description of what's failing, `tc` is the
+index within the test case table that is failing, and `i` is when there
+is a loop, exactly which iteration of the loop failed.
+The idea is you should be able to see the
+error message and figure out exactly what failed.
+Here is an example check:
+
+    ```go
+        <some table>
+        for tcIndex, tc := range cases {
+        <some code>
+            resp, err := doSomething()
+            require.NoError(err)
+            require.Equal(t, tc.expected, resp, "should correctly perform X")
+    ```