github.com/kiali/kiali@v1.84.0/CONTRIBUTING.md (about) 1 # How to contribute to Kiali 2 3 We'd love your help! 4 5 Kiali is [Apache 2.0 licensed](LICENSE) and accepts contributions via GitHub 6 pull requests. 7 Kiali does not require any contributor agreement to submit patches. 8 9 This document outlines some of the conventions on development 10 workflow, commit message formatting, contact points and other resources to make 11 it easier to get your contribution accepted. 12 13 We gratefully welcome improvements to documentation as well as to code. 14 15 ## Making a change 16 17 Before you make a change, please: 18 19 - Open a [discussion](https://github.com/kiali/kiali/discussions) or an [issue](https://github.com/kiali/kiali/issues) describing in detail the motivation of work. Regardless of the repo where the work should be done (server, UI, operator, or helm charts), all discussions and issues should be submitted to the main kiali/kiali repo using those links provided. 20 - Let the maintainers comment on the question or refine the issue. 21 - Before starting work, make sure maintainers have agreed that the work should be done and has added the issue to the backlog. 22 - When the design/approach/discussion is ready, prepare a Pull Request with the changes. 23 24 ### Good first issues 25 26 If you are new to contributing to Kiali and want to pick some easier tasks to 27 get accustomed to the code base, you can pick [issues that are marked _good first issue_ 28 on GitHub](https://github.com/kiali/kiali/labels/good%20first%20issue). 29 30 ### Developing 31 32 The [README for the server](./README.adoc#building) and the [README for the UI](./frontend/README.adoc) have a pretty extensive guide on building Kiali server and UI. 33 34 ### Internationalization 35 36 If you want to add a new language or improve an existing one, you can check the internationalization section of the [README for UI](./frontend/README.adoc#internationalization-i18n) 37 38 ### Code Style Guide 39 40 See the [Style Guide](./STYLE_GUIDE.adoc) about getting your code in style. 41 42 ### Submitting changes 43 44 Once the issue has been agreed upon and developed, you can send a pull-request. 45 46 The pull-request should have a detailed explanation of the changes that you are doing (i.e. include screenshots for UI changes). 47 If you worked on a GitHub issue, please provide the link as part of the description. 48 49 Pull requests will be reviewed by the team of committers and they will come up with 50 suggestions on how to improve the pull-request. You should be prepared to take that 51 feedback into account, add further commits into the pull-request until the pull-request 52 is eventually merged. 53 54 ## License 55 56 By contributing your code, you agree to license your contribution under the terms 57 of the [Apache License](LICENSE).