There are many different ways in which you can contribute. One of them is simply by using our software and providing us with your feedback or you can actively participate by coding some new features.
This guide describes general guidelines that most of the repositories refer to. We don't want to make things complicated so we try to follow the same rules in every repository. But sometimes there are some rules specific for that particular repository. Always check the contributing guideline and readme in that repository as well.
I have an idea for a new feature
Everybody loves new features! You can submit a new feature request or you can code it on your own and send us a pull request. In either case, don't forget to mention what's the use case and what's the expected output.
It's always a good idea to discuss the feature before you start the implementation. You can check with us whether the feature fits the vision of a given project. We may also give you some useful hints before you start coding. To start chatting, either create a new GitHub issue or contact us via the repository's default communication channel.
I found a bug
Sorry to hear that. Just create new GitHub issue and someone will take a look at that. Please, don't forget to provide us with all the important information like
- Steps to reproduce the issue
- Environment and software version used
- Error message
- What is the expected behavior
The more information you provide, the easier would it be to fix the issue. You can also fix the bug on your own and submit a new pull request.
Submitting pull requests
If not stated otherwise, we use feature branch workflow. To start with coding, fork the repository you want to contribute to, create a new branch and start coding.
Example - process of contribution
Tomforks this repository
- Creates a new branch for his
- Hacks his code
- Writes some tests
- Once he's happy with the changes, he submits a pull request from his
- We discuss the pull request with
Tomand maybe suggest some adjustments
- Once the code is ready, someone from maintainers will merge it into the
Definition of Done
- Code requirements:
- Code is buildable
- All tests are green
- Code design follows the .NET Framework Design Guidelines
- Documentation is updated
Learn how to write good commit messages
We hate sloppy commit messages. No more
Performance tuning or
Changed a few files. Please read the following articles to understand what a good commit message is.
Code of Conduct
The Kentico team is committed to fostering a welcoming community.
Our Code of Conduct can be found here:
For a history of updates, see the page history here: