mirror of
https://github.com/twitter/twemoji.git
synced 2024-11-02 11:30:12 +00:00
69 lines
2.5 KiB
Markdown
69 lines
2.5 KiB
Markdown
|
# Contributing Guidelines
|
||
|
|
|
||
|
|
Looking to contribute something? Here's how you can help.
|
||
|
|
|
||
|
|
## Bugs reports
|
||
|
|
|
||
|
|
A bug is a _demonstrable problem_ that is caused by the code in the
|
||
|
|
repository. Good bug reports are extremely helpful - thank you!
|
||
|
|
|
||
|
|
Guidelines for bug reports:
|
||
|
|
|
||
|
|
1. **Use the GitHub issue search** — check if the issue has already been
|
||
|
|
reported.
|
||
|
|
|
||
|
|
2. **Check if the issue has been fixed** — try to reproduce it using the
|
||
|
|
latest `master` or development branch in the repository.
|
||
|
|
|
||
|
|
3. **Isolate the problem** — ideally create a reduced test
|
||
|
|
case and a live example.
|
||
|
|
|
||
|
|
4. Please try to be as detailed as possible in your report. Include specific
|
||
|
|
information about the environment - operating system and version, browser
|
||
|
|
and version... and steps required to reproduce the issue.
|
||
|
|
|
||
|
|
## Feature requests & contribution enquiries
|
||
|
|
|
||
|
|
Feature requests are welcome. But take a moment to find out whether your idea
|
||
|
|
fits with the scope and aims of the project. It's up to *you* to make a strong
|
||
|
|
case for the inclusion of your feature. Please provide as much detail and
|
||
|
|
context as possible.
|
||
|
|
|
||
|
|
Contribution enquiries should take place before any significant pull request,
|
||
|
|
otherwise you risk spending a lot of time working on something that we might
|
||
|
|
have good reasons for rejecting.
|
||
|
|
|
||
|
|
## Pull requests
|
||
|
|
|
||
|
|
Good pull requests - patches, improvements, new features - are a fantastic
|
||
|
|
help. They should remain focused in scope and avoid containing unrelated
|
||
|
|
commits.
|
||
|
|
|
||
|
|
Make sure to adhere to the coding conventions used throughout the codebase
|
||
|
|
(indentation, accurate comments, etc.) and any other requirements (such as test
|
||
|
|
coverage).
|
||
|
|
|
||
|
|
Please follow this process; it's the best way to get your work included in the
|
||
|
|
project:
|
||
|
|
|
||
|
|
1. Create a new topic branch to contain your feature, change, or fix:
|
||
|
|
|
||
|
|
2. Commit your changes in logical chunks. Provide clear and explanatory commit
|
||
|
|
messages. Use git's [interactive rebase](https://help.github.com/articles/interactive-rebase)
|
||
|
|
feature to tidy up your commits before making them public.
|
||
|
|
|
||
|
|
3. Locally merge (or rebase) the upstream development branch into your topic branch:
|
||
|
|
|
||
|
|
4. Push your topic branch up to your fork:
|
||
|
|
|
||
|
|
5. [Open a Pull Request](http://help.github.com/send-pull-requests/) with a
|
||
|
|
clear title and description.
|
||
|
|
|
||
|
|
## License
|
||
|
|
|
||
|
|
By contributing your code:
|
||
|
|
|
||
|
|
You agree to license your contribution under the terms of the MIT (for code) and CC-BY (for graphics) licenses
|
||
|
|
https://github.com/twitter/twemoji/blob/gh-pages/LICENSE
|
||
|
|
https://github.com/twitter/twemoji/blob/gh-pages/LICENSE-GRAPHICS
|