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.

1. 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.
2. 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 ✌️).
3. 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.
4. 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.
5. 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.
6. We don't have strict coding guidelines, however, there are a few dos and don'ts.
   1. 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.
   2. ...

Happy coding! 🤓