github.com/klaytn/klaytn@v1.12.1/CONTRIBUTING.md (about)

     1  # Contributing Guidelines
     2  
     3  Thank you for your interest in contributing to Klaytn. As an open source project, Klaytn is always open to the developer community and we welcome your contribution. Please read the guideline below and follow it in all interactions with the project.
     4  
     5  ## How to Contribute
     6  
     7  1. Read this [contributing document](./CONTRIBUTING.md).
     8  2. Sign [Contributor Licensing Agreement (CLA)](#contributor-license-agreement-cla).
     9  3. Submit an issue with proper [labeling](#usage-of-labels).
    10  4. Please wait until the label changes to `contribution welcome` - otherwise, it is not ready to be worked on.
    11  5. After the label changed to `contribution welcome`, you can start working on the implementation. To avoid any duplicate efforts, it is recommended to update the issue so that other developers see someone working on the issue.
    12  6. Before making a PR, you should format your change. Klaytn uses a stricter go format [gofumpt](https://github.com/mvdan/gofumpt). Please take a look [how to lint your change](HOW-TO-LINT-YOUR-CHANGE.md).
    13  7. Before making a PR, please make sure you fully tested the code. It is highly recommended to provide the test code as well. After submitting the PR, wait for code review and approval. The reviewer may ask you for additional commits or changes.
    14  8. Once the change has been approved, the PR is merged by the project moderator.
    15  9. After merging the PR, we close the pull request. You can then delete the now obsolete branch.
    16  
    17  ## Types of Contribution
    18  There are various ways to contribute and participate. Please read the guidelines below regarding the process of each type of contribution.
    19  
    20  -   [Issues and Bugs](#issues-and-bugs)
    21  -   [Feature Requests](#feature-requests)
    22  -   [Code Contribution](#code-contribution)
    23  
    24  ### Issues and Bugs
    25  
    26  If you find a bug or other issues in Klaytn, please [submit an issue](https://github.com/klaytn/klaytn/issues). Before submitting an issue, please invest some extra time to figure out that:
    27  
    28  - The issue is not a duplicate issue.
    29  - The issue has not been fixed in the latest release of Klaytn.
    30  Please do not use the issue tracker for personal support requests. Use developer@klaytn.com for the personal support requests.
    31  
    32  When you report a bug, please make sure that your report has the following information.
    33  - Steps to reproduce the issue.
    34  - A clear and complete description of the issue.
    35  - Code and/or screen captures are highly recommended.
    36  
    37  After confirming your report meets the above criteria, [submit the issue](https://github.com/klaytn/klaytn/issues). Please use [labels](#usage-of-labels) to categorize your issue.
    38  
    39  ### Feature Requests
    40  
    41  You can also use the [issue tracker](https://github.com/klaytn/klaytn/issues) to request a new feature or enhancement. Note that any code contribution without an issue link will not be accepted. Please submit an issue explaining your proposal first so that Klaytn community can fully understand and discuss the idea. Please use [labels](#usage-of-labels) for your feature request as well.
    42  
    43  #### Usage of Labels
    44  
    45  You can use the following labels:
    46  
    47  Labels for initial issue categories:
    48  
    49  - issue/bug: Issues with the code-level bugs.
    50  - issue/documentation: Issues with the documentation.
    51  - issue/enhancement: Issues for enhancement requests.
    52  
    53  Status of open issues (will be tagged by the project moderators):
    54  
    55  - (no label): The default status.
    56  - open/need more information : The issue's creator needs to provide additional information to review.
    57  - open/reviewing: The issue is under review.
    58  - open/re-label needed: The label needs to be changed to confirmed as being a `bug` or future `enhancement`.
    59  - open/approved: The issue is confirmed as being a `bug` to be fixed or `enhancement` to be developed.
    60  - open/contribution welcome: The fix or enhancement is approved and you are invited to contribute to it.
    61  
    62  Status of closed issues:
    63  
    64  - closed/fixed: A fix for the issue was provided.
    65  - closed/duplicate: The issue is also reported in a different issue and is being managed there.
    66  - closed/invalid: The issue cannot be reproduced.
    67  - closed/reject: The issue is rejected after review.
    68  - closed/wontfix: This issue will not be worked on.
    69  
    70  ### Code Contribution
    71  
    72  Please follow the coding style and quality requirements to satisfy the product standards. You must follow the coding style as best as you can when submitting code. Take note of naming conventions, separation of concerns, and formatting rules.
    73  
    74  The go implementation of Klaytn uses [godoc](https://godoc.org/golang.org/x/tools/cmd/godoc)
    75  to document its source code. For the guideline of official Go language, please
    76  refer to the following websites:
    77  - https://golang.org/doc/effective_go.html#commentary
    78  - https://blog.golang.org/godoc-documenting-go-code
    79  
    80  ## Contributor License Agreement (CLA)
    81  
    82  Keep in mind when you submit your pull request, you'll need to sign the CLA via [CLA-Assistant](https://cla-assistant.io/klaytn/klaytn) for legal purposes. You will have to sign the CLA just one time, either as an individual or corporation.
    83  
    84  You will be prompted to sign the agreement by CLA Assistant (bot) when you open a Pull Request for the first time.