fonts/nerd-fonts
1
0
Fork 0
mirror of https://github.com/ryanoasis/nerd-fonts.git synced 2025-10-30 23:43:47 +02:00
Code Issues Releases Activity

Adds contributing guidelines (fixes #66)

Browse Source 
* adds first version of contributing guidelines to help users with contributing
This commit is contained in:
Ryan L McIntyre
2016-03-19 20:58:04 -04:00
parent da0f629676
commit 931f693168
1 changed files with 43 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
contributing.md Normal file
View File

@@ -0,0 +1,43 @@
# 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)