1
0
mirror of https://github.com/ryanoasis/nerd-fonts.git synced 2024-12-01 16:55:57 +02:00
nerd-fonts/contributing.md
Ryan L McIntyre 931f693168 Adds contributing guidelines (fixes #66)
* adds first version of contributing guidelines to help users with contributing
2016-03-19 20:58:04 -04:00

44 lines
2.3 KiB
Markdown

# Contributing Guide
## How to contribute
Work In Progress, for now the minimum:
* Fork the project from the `master` branch and submit a Pull Request (PR)
* Explain what the PR fixes or improves
* Screenshots for bonus points
* Use sensible commit messages
* If your PR fixes a separate issue number, include it in the commit message
## Adding a new font
* Check the license even allows the font to be modified and shared
* Add the original (unpatched) version of the font and any readme and/or license files to the `unpatched-sample-fonts` directory inside a new directory
* e.g. Adding *XYZ Font*, create directory `unpatched-sample-fonts/xyz/{PUT FONT FILES HERE}`
* Do a basic test with the new font to ensure it patches correctly and generates a new font file, e.g.
* `./font-patcher unpatched-sample-fonts/XYZ/XYZ.ttf --powerline --powerlineextra`
* Make sure to then delete this new font file if it is in the repository (all patched fonts should be generated in the `patched-fonts/` directory)
* When fairly satisfied the font patches correctly, patch **all** of the variations/options, e.g.
* `./gotta-patch-em-all-font-patcher\!.sh XYZ`
* Add the new font to the README table of supported fonts
## Things to keep in mind
* Smaller PRs are likely to be merged more quickly than bigger changes
* If it is a useful PR it **will** get merged in eventually
* [E.g. see how many have already been merged vs. still open](https://github.com/ryanoasis/nerd-fonts/pulls)
* This project is using [Semantic Versioning 2.0.0](http://semver.org/)
* I try to group fixes into milestones/versions
* If your bug or PR is *not* trivial it will likely end up in the next **MINOR** version
* If your bug or PR *is* trivial *or* critical it will likely end up in the next **PATCH** version
* Most of the time PRs and fixes are *not* merged directly into master without being present on a new versioned branch
* Sometimes for small items I will make exceptions to get the fix or readme change on master sooner but even after there will *always* be a versioned branch to keep track of each release
## Commit messages
* squash or not to squash into 1 commit ? (@todo)
* require a specific format for commit messages for consistency ? (@todo)
## Code standards (@todo)
* tabs or spaces for Python :[ (@todo)