Guidelines

This document provides general guidance to contributors, envisions the future of Taiga and describes how we can get there with your help.

How to Contribute

If you don't know how to code, don't be discouraged. You can still contribute by helping out other users or by taking part in discussions. You can even design new features, rather than simply requesting them. Just make sure to think them through and provide detailed explanations.

If you are a beginner in C++, beware: Taiga may not be the best example out there for you to learn the language. The code quality varies within the project. Some files, especially the old ones that haven't been updated for years, are in a condition less than desirable.

When you feel ready to contribute, you may take a look at open issues and find one that interests you. Usually it's better to talk about it first. But you may send a pull request directly if you know what you're doing.

I have arguably high standards when it comes to code quality. I expect new code to be at least as good as the code surrounding it. In that regard, here's a couple of points to keep in mind:

• Keep things simple. Tend to the codebase rather than polluting it.
• Do it properly. Don't settle with the first solution that comes to your mind.
• Reuse what's available. Make sure your code doesn't exist in another form.
• It's not okay to turn something into a user setting just because you can't make up your mind.
• Don't overthink as I do, though. It's bad for your health.
• Feel free to ask about anything!

Taiga follows Google C++ Style Guide for the most part. Some rules are bent depending on the situation or my personal preference. The key points are consistency and clarity. Please configure your text editor accordingly.

If you have significant experience in C++ and software design, I'd very much appreciate it if you could review the codebase (sans UI-related files). We can also team up to work on certain features. In case you haven't noticed, Taiga is almost entirely developed and maintained by a single person, which makes things go slowly.

Things to Come

Since the release of v1.3, I'm fixing bugs and going through my backlog to implement minor features. Major changes are postponed until I start working on v1.4 and finish refactoring the codebase.

Apart from the occasional "bug fixes and minor improvements", my plan for the near future is to make Taiga more modular. This involves conversion to standalone libraries, changing the project architecture, refactoring the code and, possibly, designing a plugin system. Separation of concerns helps in many ways, and this is the current trend for Taiga.

In general, improving core features takes priority over adding new ones. There are a few things that need mentioning specifically:

• It'd be nice to support more services and reach out to more people, but I need to be wary of the maintenance cost. Adding another service to Taiga is not among my short-term plans at the moment.
• Synchronization with multiple services would be great, but it doesn't seem feasible (see the relevant section at the FAQ page for more information). It is possible, but I decided to avoid the complexity for the time being.
• Manga list support is one of the most requested features ever. However, Taiga's architecture is not ready to support multiple media types yet.
• There are quite a number of features we cannot add due to limitations of MyAnimeList API. The situation will improve once their new API comes around.
• Significant UI changes are postponed until v2.0. For now, I'm trying to separate UI code from application logic as much as possible. Ideally, Taiga should be able to run without a GUI in the future.

For the long term, here are some of the things that need to be worked on:

• We need a proper event system where separate parts of the application can communicate without interference.
• File management needs to be improved. This involves better detection of anime folders, running search on a separate thread, caching available episodes, and so on.
• We need to find better alternatives to current scripts and torrent filters, as they're the worst offenders in terms of user friendliness. Even I get confused.
• Once the codebase is in a good shape, we will start transitioning to a cross-platform framework, namely Qt. There will be significant improvements to the UI, without giving up the native look. Then we will finally be ready to support Linux and Mac.
• World domination!