fnts happily welcomes new contributions, requests, questions and bug reports.
In order to make this right for both sides of this process – a contributor and the library author – it is of utter importance to read this document first.
Herein, I'll try my best to describe what and how you, a contributor, should do to make your effort enjoyable and productive.
First and foremost, please understand that I, the fnts author, am a regular person making this project in my free time and when inspiration strikes. I cannot and will not respond immediately as this is not my full time job.
Any proposals and solutions you make will be reviewed and answered but are not guaranteed to be accepted as I'd want to keep fnts source code and direction as close as possible to what I envision for it myself.
Make sure to look at the existing issues and study the subject of your interest.
If in any way you are positive on what you'd like to propose or ask, please write as comprehensive and full description of it as possible.
Any bug report is much appreciated by its own as I'd want my library to not break on other people and deliver the best experience it can.
To make it faster and easier for everyone, I'd suggest describing the problem in details and creating a basic reproduction in any environment you like (e.g. a repo or repl).
As stated above, I cannot guarantee any features or ideas that do not correlate with my own vision to make their way into fnts. However good and thorough they are.
What I can guarantee is that I will at least take a look at and try to discuss them if they stick to my heart and mind.
As with bug reports, it is your own responsibility to describe the feature fully and understandably so that it has the most chances to live and appear in the code.
Please, do not hurry with writing the actual code for it, as you may waste your valuable time on something that could not be accepted at all. The code, as in any other project, is a product of thought, and in fnts it's expected to appear only after the discussion. You can even be not the one coding in the end.
Every question is valid as long as you are in context of what this library is (e.g. have read the documentation) and made sure to study other issues. People may have asked the same question before and it is probably already answered. If not – I'll make sure to give the best answer possible so that you get what you've came here for.
If you've decided to submit an actual piece of code, please follow the suggestions below:
- Try your best to follow the project structure and code style present in
fnts. It does not have linters or formatters, but the code of the library is written in a way that must be followed without any automatic tools. - Make sure to not introduce bugs. There are tests for existing functionality, and you probably should add your own tests for the code you submit (or at least test it manually).
- Follow the conventional commits guidelines as in
fntsthey're used for automatic versioning and changelog generation. - A pull request must target the
developbranch so that your code will appear in a future release set up from it. - Add the description to your PR so that the introduced changes can be documented and understood before actually reading the code for them.
Once again, I thank you for the effort to check this library out. Remember, that we're all having fun here, and fun, as well as pure interest, should drive anything we do with fnts.