Skip to content

Latest commit

 

History

History
28 lines (21 loc) · 2.54 KB

CONTRIBUTING.md

File metadata and controls

28 lines (21 loc) · 2.54 KB
Raw

Contributors guidelines

thank you for considering contributing to LLM.swift library. i hope that means you like using this library.

Ways to contribute

  • request features through issues. of course they have to be relavant to where LLM.swift is heading.

  • report bugs trough issues. provide a minimal code that can reproduce the bug that you've been experiencing. especially, since it's LLM, it's a good idea to:

    1. specify the model you've used,
    2. set a fixed seed when initializing,
    3. and to provide your device hardware details.

  • GitHub Sponsors. while money has never been my driving force, i need some stability to keep supporting this. if you think that you can earn good enough amount of income using this library, or if you are already doing so, share some with me so i can keep helping you, even with some other new libraries.

  • promote this project. send a link to people who will be interested to, or share your project to others and let them know you are using this library. you and i both know this project is the best, but others don't know.

  • GitHub Repo stars. it will draw more people. thus giving more reasons for me to maintain this.

  • create a PR if you are absolutely sure of the reasons behind it. when you do, make sure of these things:

    1. your changes should be minimal. as every PR needs to have a precise point instead of random changes everywhere.
    2. respect the code style. consistency matters a lot and i like my code style.
    3. there should not be any comments. i believe code that is readable without comments is the good code.
    4. best variable names are needed. we should be able to read the code as if we are reading the regular english text.
    5. function must not have a long body. generally, it should be fitted in a screen. if you think a certain function should have a long body, justify it.
    6. **avoid long lines as much as you can.
    7. commit messages should be clear. so i can review them swiftly.
    8. don't take it personally if your PR gets a rejection.

i'm a person of taste. it's not because i'm right and you're wrong, it's only because this is my project. if you don't like the way things are going here, you're always welcome to fork this and take it to whereever you want, and i think that's the beauty of open source projects we are all drawn to.