|
1 | | -## How to contribute to LINE Bot SDK for Go project |
| 1 | +# How to contribute to LINE Bot SDK for Go project |
2 | 2 |
|
3 | 3 | First of all, thank you so much for taking your time to contribute! LINE Bot SDK for Go is not very different from any other open |
4 | 4 | source projects you are aware of. It will be amazing if you could help us by doing any of the following: |
5 | 5 |
|
6 | 6 | - File an issue in [the issue tracker](https://github.com/line/line-bot-sdk-go/issues) to report bugs and propose new features and |
7 | 7 | improvements. |
8 | | -- Ask a question using [the issue tracker](https://github.com/line/line-bot-sdk-go/issues). |
| 8 | +- Ask a question using [the issue tracker](https://github.com/line/line-bot-sdk-go/issues) (__Please ask only about this SDK__). |
9 | 9 | - Contribute your work by sending [a pull request](https://github.com/line/line-bot-sdk-go/pulls). |
10 | 10 |
|
11 | | -### Contributor license agreement |
| 11 | +## Development |
| 12 | + |
| 13 | +### Understand the project structure |
| 14 | + |
| 15 | +The project structure is as follows: |
| 16 | + |
| 17 | +- `linebot`: The main library code, organized into sub-packages by API functionality. |
| 18 | +- `examples`: Example projects that demonstrate how to use the library. |
| 19 | +- `generator`: OpenAPI-based code generation tools and templates. |
| 20 | +- `script`: Utility scripts for development. |
| 21 | + |
| 22 | +### Edit OpenAPI templates |
| 23 | + |
| 24 | +Almost all code is generated with OpenAPI Generator based on [line-openapi](https://github.com/line/line-openapi)'s YAML files. |
| 25 | +Thus, you cannot edit most code under the `linebot` directory directly. |
| 26 | + |
| 27 | +You need to edit the custom generator templates under the `generator/src/main/resources` directory instead. |
| 28 | + |
| 29 | +After editing the templates, run the `generate-code.py` script to generate the code, and then commit all affected files. |
| 30 | +If not, CI status will fail. |
| 31 | + |
| 32 | +When you update code, be sure to check consistencies between generated code and your changes. |
| 33 | + |
| 34 | +### Add unit tests |
| 35 | + |
| 36 | +We use Go's built-in testing framework. To run all tests with race detection and coverage reporting: `bash script/codecov.sh` |
| 37 | + |
| 38 | +Especially for bug fixes, please follow this flow for testing and development: |
| 39 | +1. Write a test before making changes to the library and confirm that the test fails. |
| 40 | +2. Modify the code of the library. |
| 41 | +3. Run the test again and confirm that it passes thanks to your changes. |
| 42 | + |
| 43 | +### Run your code in your local |
| 44 | + |
| 45 | +You can use the [example projects](examples) to test your changes locally before submitting a pull request. |
| 46 | + |
| 47 | +### Documentation |
| 48 | + |
| 49 | +Please ensure that your code is well-documented. |
| 50 | +Use Go's standard documentation comments to explain the purpose of functions, methods, and types. |
| 51 | +Good documentation ensures that contributors and users can easily read and understand how the methods and classes work. |
| 52 | + |
| 53 | +## Contributor license agreement |
12 | 54 |
|
13 | 55 | When you are sending a pull request and it's a non-trivial change beyond fixing typos, please make sure to sign |
14 | 56 | [the ICLA (individual contributor license agreement)](https://cla-assistant.io/line/line-bot-sdk-go). Please |
|
0 commit comments