|
1 | | -# Contributing guidelines |
| 1 | +# Ways to contribute |
| 2 | +<img align="right" width="100" height="100" src="https://i.imgur.com/PYTV0jP.png"> |
2 | 3 |
|
3 | | -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. |
| 4 | +There are many different ways in which you can contribute. One of the easiest wazs is simply to use our software and providing us with your feedback in discussions. You can also participating on coding new features and fixing bugs by submitting pull requests with code changes. |
4 | 5 |
|
5 | | -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. |
| 6 | +We don't want to make things complicated so we try to follow these same rules in all our repositories. |
6 | 7 |
|
| 8 | +# Where to get support |
| 9 | +Please note that level of provided support is always determined by the [LICENSE](LICENSE.md) of a given open-source project. |
7 | 10 |
|
8 | | -## I have an idea for a new feature |
| 11 | +## I found a bug in a Kentico's open-source project |
| 12 | +<img align="right" width="100" height="100" src="https://i.imgur.com/TYIQdpv.png"> |
9 | 13 |
|
10 | | -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. |
| 14 | +Sorry to hear that. Just log a new [GitHub issue](../../../../issues) and someone will take a look at it. Remember, the more information you provide, the easier it will be to fix the issue. If you feel like it, you can also fix the bug on your own and submit a new pull request. |
11 | 15 |
|
12 | | -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](https://github.com/Kentico/Home#questions--answers). |
| 16 | +## I need help with using the projects and/or coding |
| 17 | +<img align="right" width="100" height="100" src="https://cdn.sstatic.net/Sites/stackoverflow/company/img/logos/so/so-icon.svg"> |
13 | 18 |
|
| 19 | +To get help with coding and structuring your projects, use [StackOverflow](https://stackoverflow.com/) to ask questions with one of the following tags: |
| 20 | +- [`kentico-cloud`](https://stackoverflow.com/questions/tagged/kentico-cloud) |
| 21 | +- [`kentico`](https://stackoverflow.com/questions/tagged/kentico) |
14 | 22 |
|
15 | | -## I found a bug |
| 23 | +Our team members and the community monitor these channels on a regular basis. |
16 | 24 |
|
17 | | -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 |
| 25 | +## I want to report a security bug |
| 26 | +<img align="right" width="100" height="100" src="https://i.imgur.com/z82nnJB.png"> |
18 | 27 |
|
19 | | -- Steps to reproduce the issue |
20 | | -- Environment and software version used |
21 | | -- Screenshot |
22 | | -- Error message |
23 | | -- What is the expected behavior |
| 28 | +Security issues and bugs should be reported privately, via email, to the Kentico Developer Community Team developerscommunity@kentico.com. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. |
24 | 29 |
|
25 | | -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. |
| 30 | + |
| 31 | +## I have an idea for a new feature (or feedback on existing functionality) |
| 32 | +<img align="right" width="100" height="100" src="https://i.imgur.com/rUFkyPy.png"> |
| 33 | + |
| 34 | +Everybody loves new features! You can submit a new [feature request](../../../../issues) or you can code it on your own and [send us a pull request](#submitting-pull-requests). In either case, don't forget to mention what's the use case and what's the expected output. |
26 | 35 |
|
27 | 36 |
|
28 | 37 | ## Submitting pull requests |
| 38 | +<img align="right" width="100" height="100" src="https://i.imgur.com/aSeiliy.png"> |
29 | 39 |
|
30 | | -If not stated otherwise, we use [feature branch workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow). To start with coding, fork the repository you want to contribute to, create a new branch and start coding. |
| 40 | +Unless you're fixing a typo, it's usually a good idea to discuss the feature before you submit a pull request with code changes, so let's start with submitting a new [GitHub issue](../../../../issues) and discussing the whether it fits the vision of a given project. |
| 41 | +You might also read these two blogs posts on contributing code: [Open Source Contribution Etiquette](http://tirania.org/blog/archive/2010/Dec-31.html) by Miguel de Icaza and [Don't "Push" Your Pull Requests](https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/) by Ilya Grigorik. Note that all code submissions will be rigorously reviewed and tested by the Kentico Maintainers teams, and only those that meet an high bar for both quality and design/roadmap appropriateness will be merged into the source. |
31 | 42 |
|
32 | 43 |
|
33 | 44 | ### Example - process of contribution |
| 45 | +If not stated otherwise, we use [feature branch workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow). |
34 | 46 |
|
35 | | -1. ```Tom``` forks this repository |
36 | | -2. Creates a new branch for his ```cool``` feature |
37 | | -3. Hacks his code |
38 | | -4. Writes some tests |
39 | | -5. Once he's happy with the changes, he submits a pull request from his ```cool``` branch to ```master``` branch |
40 | | -6. We discuss the pull request with ```Tom``` and maybe suggest some adjustments |
41 | | -7. Once the code is ready, someone from maintainers will merge it into the ```master``` branch |
42 | | - |
| 47 | +To start with coding, fork the repository you want to contribute to, create a new branch, and start coding. Once the functionality is [done](#Definition-of-Done), you can submit a [pull request](https://help.github.com/articles/about-pull-requests/). |
43 | 48 |
|
44 | 49 | ### Definition of Done |
| 50 | +<img align="right" width="100" height="100" src="https://i.imgur.com/g82Ohdv.png"> |
45 | 51 |
|
46 | | -- Code requirements: |
47 | | - - Code is buildable |
48 | | - - All tests are green |
49 | | - - Code design follows the .NET [Framework Design Guidelines](https://msdn.microsoft.com/en-us/library/ms229042.aspx) |
50 | | - - If you're not sure about some rules, follow the style of the existing code. |
51 | | - - Use "Format the whole document" button in Visual Studio to fix indentation  |
52 | | -- Documentation is updated |
53 | | - |
| 52 | +- New/fixed code is covered with tests |
| 53 | +- CI can build the code |
| 54 | +- All tests are pass |
| 55 | +- New version number follows [semantic versioning](https://semver.org/) |
| 56 | +- Coding style (spaces, indentation) is in line with the rest of the code in a given repository |
| 57 | +- Documentation is updated (e.g. code examples in README, Wiki pages, etc.) |
| 58 | +- All `public` members are documented (using XML doc, phpdoc, etc.) |
| 59 | +- Code doesn't contain any secrets (private keys, etc.) |
| 60 | +- Commit messages are clear. Please read these articles: [Writing good commit messages](https://github.com/erlang/otp/wiki/Writing-good-commit-messages), [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), [On commit messages](https://who-t.blogspot.com/2009/12/on-commit-messages.html) |
54 | 61 |
|
55 | 62 |
|
56 | | -### Learn how to write good commit messages |
| 63 | +### Feedback |
| 64 | +<img align="right" width="100" height="100" src="https://i.imgur.com/ZQfNzJJ.png"> |
57 | 65 |
|
58 | | -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. |
| 66 | +Your pull request will now go through extensive checks by the subject matter experts on our team. Please be patient. Update your pull request according to feedback until it is approved by one of the Kentico maintainers. After that, one of our team members may adjust the branch you merge into based on the expected release schedule. |
59 | 67 |
|
60 | | -- [Writing good commit messages](https://github.com/erlang/otp/wiki/Writing-good-commit-messages) |
61 | | -- [A Note About Git Commit Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) |
62 | | -- [On commit messages](https://who-t.blogspot.com/2009/12/on-commit-messages.html) |
63 | 68 |
|
64 | 69 | ## Code of Conduct |
| 70 | +<img align="right" width="100" height="100" src="https://i.imgur.com/cObdKQy.png"> |
65 | 71 |
|
66 | | -The Kentico team is committed to fostering a welcoming community. |
67 | | - |
68 | | -**Our Code of Conduct can be found here**: |
69 | | - |
70 | | -https://github.com/Kentico/Home/blob/master/CODE_OF_CONDUCT.md |
71 | | - |
72 | | -For a history of updates, see the page history here: |
73 | | - |
74 | | -https://github.com/Kentico/Home/commits/master/CODE_OF_CONDUCT.md |
| 72 | +The Kentico team is committed to fostering a welcoming community, therefore this project has adopted the [Contributor Covenant Code of Conduct](CODE_OF_CONDUCT.md). If you have any additional questions or comments, you can contact us directly at developerscommunity@kentico.com. |
75 | 73 |
|
76 | 74 |  |
0 commit comments