| 1 | # Contributing to UIkit
|
| 2 |
|
| 3 | You want to contribute to UIkit? Awesome. Please take a few moments to
|
| 4 | review the following guidelines to get you started. Cheers.
|
| 5 |
|
| 6 | * [Communication channels](#communication)
|
| 7 | * [Team members](#team)
|
| 8 | * [Documentation](#documentation)
|
| 9 | * [Issue tracker](#issues)
|
| 10 | * [Bug reports](#bugs)
|
| 11 | * [Pull requests](#pull-requests)
|
| 12 | * [Versioning](#versioning)
|
| 13 | * [License](#license)
|
| 14 |
|
| 15 | <a name="communication"></a>
|
| 16 | ## Communication channels
|
| 17 |
|
| 18 | Before you get lost in the repository, here are a few starting points
|
| 19 | for you to check out. You might find that others have had similar
|
| 20 | questions or that your question rather belongs in one place than another.
|
| 21 |
|
| 22 | * Chat: https://discord.gg/NEt4Pv7
|
| 23 | * Website: https://getuikit.com
|
| 24 | * Twitter: https://twitter.com/getuikit
|
| 25 |
|
| 26 |
|
| 27 | <a name="team"></a>
|
| 28 | ## Team members
|
| 29 |
|
| 30 | UIkit is developed as an open source project by [YOOtheme](http://yootheme.com)
|
| 31 | in Hamburg, Germany. The core maintainers you will encounter in this project
|
| 32 | are all part of YOOtheme.
|
| 33 |
|
| 34 | ## Documentation
|
| 35 |
|
| 36 | The UIkit documentation is maintained as a collection of Markdown files in its
|
| 37 | [own repository](https://github.com/uikit/uikit-site). Any pull requests are highly appreciated.
|
| 38 |
|
| 39 | <a name="issues"></a>
|
| 40 | ## Using the issue tracker
|
| 41 |
|
| 42 | The issue tracker is the preferred channel for [bug reports](#bugs),
|
| 43 | [features requests](#features) and [submitting pull
|
| 44 | requests](#pull-requests), but please respect the following restriction:
|
| 45 |
|
| 46 | Please **do not** use the issue tracker for personal support requests (use [Discord chat](https://discord.gg/NEt4Pv7)).
|
| 47 |
|
| 48 | <a name="bugs"></a>
|
| 49 | ## Bug reports
|
| 50 |
|
| 51 | A bug is a _demonstrable problem_ that is caused by the code in the repository.
|
| 52 | Good bug reports are extremely helpful - thank you!
|
| 53 |
|
| 54 | A good bug report shouldn't leave others needing to chase you up for more
|
| 55 | information. Please try to be as detailed as possible in your report. What is
|
| 56 | your environment? What steps will reproduce the issue? What would you expect to
|
| 57 | be the outcome? All these details will help people to fix any potential bugs.
|
| 58 |
|
| 59 | <a name="pull-requests"></a>
|
| 60 | ## Pull requests
|
| 61 |
|
| 62 | Good pull requests - patches, improvements, new features - are a fantastic
|
| 63 | help. Thanks for taking the time to contribute.
|
| 64 |
|
| 65 | **Please ask first** before embarking on any significant pull request,
|
| 66 | otherwise you risk spending a lot of time working on something that the
|
| 67 | project's developers might not want to merge into the project.
|
| 68 |
|
| 69 | UIkit follows the [GitFlow branching model](http://nvie.com/posts/a-successful-git-branching-model). The ```master``` branch always reflects a production-ready state while the latest development is taking place in the ```develop``` branch.
|
| 70 |
|
| 71 | Each time you want to work on a fix or a new feature, create a new branch based on the ```develop``` branch: ```git checkout -b BRANCH_NAME develop```. Only pull requests to the ```develop``` branch will be merged.
|
| 72 |
|
| 73 | <a name="commit-message-convention"></a>
|
| 74 | ## Commit Message Convention
|
| 75 |
|
| 76 | UIkit adapts the [Vue's commit convention](https://github.com/vuejs/vue/blob/dev/.github/COMMIT_CONVENTION.md). Commit messages can have the following types:
|
| 77 |
|
| 78 | - `build:` Changes that affect the build system or external dependencies
|
| 79 | - `chore:` Changes to readme, etc
|
| 80 | - `ci:` Changes to our CI configuration files and scripts
|
| 81 | - `docs:` Documentation only changes
|
| 82 | - `feat:` A new feature
|
| 83 | - `fix:` A bug fix
|
| 84 | - `perf:` A code change that improves performance
|
| 85 | - `refactor:` A code change that neither fixes a bug nor adds a feature
|
| 86 | - `style:` Changes that do not affect the meaning of the code (white-space, formatting, etc)
|
| 87 | - `test:` Adding missing tests or correcting existing tests
|
| 88 |
|
| 89 | ## Versioning
|
| 90 |
|
| 91 | UIkit is maintained by using the [Semantic Versioning Specification (SemVer)](http://semver.org).
|
| 92 |
|
| 93 | <a name="license"></a>
|
| 94 | ## License
|
| 95 |
|
| 96 | By contributing your code, you agree to license your contribution under the [MIT license](LICENSE)
|
| 97 | |
| \ | No newline at end of file |