-
-
Notifications
You must be signed in to change notification settings - Fork 192
Contributing
Contributions are highly welcome! Be it bug reports, feature requests or PRs. However, please keep a bunch of "rules" in mind when wanting to contribute.
Please don't set your expectations too high or put any pressure. Wakapi is for free and built for fun and out of passion. Please be kind, respectful and do not demand anything by any means when requesting new features.
Be indulgent if your feature request or PR gets rejected. While we're open for suggestions of all kinds, Wakapi is ultimately maintained by @muety (me) as the author and core contributor. Even if a feature- or change request may objectively be sensible, I still reserve to have the final say (sorry ✌️).
Please do not submit a PR out of the blue. Before submitting a PR and requesting a review, please file an issue first and spark a discussion about your intended change.
In accordance with our design goals, try to keep things as minimalist as possible (KISS). Don't over-engineer things. Use the standard library as extensively as possible and only pull in new dependencies if they are really needed.
Please do not submit AI-generated code. My views might be somewhat old-fashioned in this regard, but I think coding is for fun and so is the whole of this project. Therefore, I expect contributions to be "hand-written". Letting some LLM run over the code base and then blindly submitting its output is not the point of open source in my opinion. I'd rather want contributors to spend time familiarizing themselves with the code base, try to wrap their heads around how things work under the hood and then start coding.
Even though this is probably a less common pattern in the Go community, Wakapi's internal architecture roughly follows an MVC approach, involving model definitions, repositories, services and views. Repositories and services are the implementations of respective interfaces (which come in especially handy for mocking). We found this approach to work very well in the past, so please make yourself a little familiar with the existing code base in that regard.
We don't have strict coding guidelines, however, there are a few dos and don'ts.
- Try to avoid nil pointers for the sake of nullability. Let's try to avoid cluttering the code with null checks, but use zero-values instead.
- ...
Happy coding! 🤓