From 7f629f5320476820dc79f9f02b6f743f530cdd15 Mon Sep 17 00:00:00 2001 From: Youngjoon Lee Date: Tue, 10 Jan 2023 19:49:24 +0900 Subject: [PATCH 1/4] docs: add CONTRIBUTING.md --- CONTRIBUTING.md | 90 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..9a333311 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,90 @@ +# Contributing + +* [General Procedure](#general-procedure) +* [Development Procedure](#development-procedure) + * [Testing](#testing) + * [Pull Requests](#pull-requests) + * [Requesting Reviews](#requesting-reviews) + * [Updating Documentation](#updating-documentation) + + +Thank you for considering making contributions to the Panacea and related repositories! + +## General Procedure + +Contributing to this repo can mean many things, such as participating in +discussion or proposing code changes. To ensure a smooth workflow for all +contributors, the general procedure for contributing has been established: + +1. Start by browsing [new issues](https://github.com/medibloc/panacea-core/issues) and [discussions](https://github.com/medibloc/panacea-core/discussions). If you are looking for something interesting or if you have something in your mind, there is a chance it had been discussed. +2. Determine whether a GitHub issue or discussion is more appropriate for your needs: + 1. If want to propose something new that requires specification or an additional design, or you would like to change a process, start with a [new discussion](https://github.com/medibloc/panacea-core/discussions/new). With discussions, we can better handle the design process using discussion threads. A discussion usually leads to one or more issues. + 2. If the issue you want addressed is a specific proposal or a bug, then open a [new issue](https://github.com/medibloc/panacea-core/issues/new/choose). + 3. Review existing [issues](https://github.com/medibloc/panacea-core/issues) to find an issue you'd like to help with. +3. Participate in thoughtful discussion on that issue. +4. If you would like to contribute: + 1. Ensure that the proposal has been accepted. + 2. Ensure that nobody else has already begun working on this issue. If they have, + make sure to contact them to collaborate. + 3. If nobody has been assigned for the issue and you would like to work on it, + make a comment on the issue to inform the community of your intentions + to begin work. +5. To submit your work as a contribution to the repository follow standard GitHub best practices. See [development procedure](#development-procedure) below. + +**Note:** For very small or blatantly obvious problems such as typos, you are +not required to an open issue to submit a PR, but be aware that for more complex +problems/features, if a PR is opened before an adequate design discussion has +taken place in a GitHub issue, that PR runs a high likelihood of being rejected. + +## Development Procedure + +* The latest state of development is on `main`. +* `main` must never fail `make lint build test`. +* No `--force` onto `main` (except when reverting a broken commit, which should seldom happen). +* Create a branch to start work: + * Fork the repo (core developers must create a branch directly in the `panacea-core` repo), + branch from the HEAD of `main`, make some commits, and submit a PR to `main` in the `panacea-core` repo. + * For core developers working within the `panacea-core` repo, follow branch name conventions to ensure a clear + ownership of branches: `{issue#}-branch-name`. It is also recommended to use the [`Create a branch`](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-a-branch-for-an-issue) feature in the GitHub Issues. + +All pull requests are merged to the `main` after being reviewed, based on the [trunk-based development](https://trunkbaseddevelopment.com/). + +### Testing + +Tests can be executed by running `make test` at the top level of the `panacea-core` repository. + +### Pull Requests + +Before submitting a pull request: + +* merge the latest main `git merge origin/main`, +* run `make lint build test` to ensure that all checks and tests pass. This is also ran automatically by [GitHub Actions](./.github/workflows) in the `panacea-core` repo. + +Then: + +1. If you have something to show, **start with a `Draft` PR**. It's good to have early validation of your work and we highly recommend this practice. A Draft PR also indicates to the community that the work is in progress. + Draft PRs also helps the core team provide early feedback and ensure the work is in the right direction. +2. When the code is complete, change your PR from `Draft` to `Ready for Review`. +3. Go through the actions for each checkbox present in the PR template description. The PR actions are automatically provided for each new PR. +4. Be sure to include a relevant changelog entry in the `Unreleased` section of `CHANGELOG.md`. The entry should be on top of all others changes in the section. + +PRs must have a category prefix that is based on the type of changes being made (for example, `fix`, `feat`, +`refactor`, `docs`, and so on). The *type* must be included in the PR title as a prefix (for example, +`fix: `). This convention ensures that all changes that are committed to the base branch follow the +[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. +Additionally, each PR should only address a single issue. + +Pull requests are merged by [code owners](./CODEOWNERS). +All pull requests must be squashed before being merged, and also be rebased on top of the `main`. + +### Requesting Reviews + +[Code owners](./CODEOWNERS) are marked automatically as the reviewers. +All PRs require at least two review approvals before they can be merged. + +All PRs are squashed and merged by code owners after being reviewed. +Please note that PRs based on outdated `main` cannot be merged. Those PRs must be updated or rebased on top of the `main` by PR authors. + +### Updating Documentation + +If you open a PR, it is mandatory to update the relevant documentation in [`/.gitbook`](.gitbook). \ No newline at end of file From b0aa4e950aa05136eaf0422eab7e04141fe91c0b Mon Sep 17 00:00:00 2001 From: Youngjoon Lee Date: Tue, 10 Jan 2023 19:51:03 +0900 Subject: [PATCH 2/4] fix --- CONTRIBUTING.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9a333311..23c9d50e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -74,9 +74,6 @@ PRs must have a category prefix that is based on the type of changes being made [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification. Additionally, each PR should only address a single issue. -Pull requests are merged by [code owners](./CODEOWNERS). -All pull requests must be squashed before being merged, and also be rebased on top of the `main`. - ### Requesting Reviews [Code owners](./CODEOWNERS) are marked automatically as the reviewers. From 68d574e3427df1496b6c973aac587ff484b98d5a Mon Sep 17 00:00:00 2001 From: Youngjoon Lee Date: Tue, 10 Jan 2023 19:55:09 +0900 Subject: [PATCH 3/4] add CODE_OF_CONDUCT.md --- CODE_OF_CONDUCT.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 CODE_OF_CONDUCT.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 00000000..c9f9cc24 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,46 @@ +# Contributor Covenant Code of Conduct + +## Our Pledge + +In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a professional setting + +## Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to 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 both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at community@interchain.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version] + +[homepage]: http://contributor-covenant.org +[version]: http://contributor-covenant.org/version/1/4/ From c62739697a2724e561f15d5c822298f20f79f5cd Mon Sep 17 00:00:00 2001 From: Youngjoon Lee Date: Tue, 10 Jan 2023 19:59:14 +0900 Subject: [PATCH 4/4] fix --- CODE_OF_CONDUCT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index c9f9cc24..02fe6c0b 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -34,7 +34,7 @@ This Code of Conduct applies both within project spaces and in public spaces whe ## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at community@interchain.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at blockchain@medibloc.org. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.