General questions and answers
My feature or change request is too specific, what do you mean by that?
Sometimes there is a feature request for Firefly III that could be a great addition to Firefly III, but it is just too specific. That means it is a request for a feature that is used by too few people, or that is so specific that it is not useful for a reasonable number of users.
It is also possible that such a request solves a very specific problem for a small group of users.
I must apologize, but such requests are generally not honored. The requested change will not be made, and I will also not accept a PR to fix it.
In this FAQ answer, allow me to explain when a feature request is too specific:
As a general rule, a feature or an enhancement has to make peoples lives better by virtue of existing. For example, Firefly III allows you to quick-select a quarterly report range. The data importer connects to a variety of third party importers. That is useful. Even if you don't use it. You know what it does and why it is there. Opposed to that, many requested features or changes follow this pattern:
- A user runs into a problem, Problem X.
- To solve the problem, a new feature or option is proposed, to prevent them (and others) from running into Problem X.
- It is impossible for you to appreciate or understand the new feature until you also run into Problem X, at which point you must:
- Learn that this is in fact "Problem X".
- Learn from the documentation or by sheer will that this has been fixed in the past, and has a solution.
- Apply the solution to your Problem X, by changing the setting or using the new feature.
- Undo whatever you did previously, and do it again but this time with the fix for Problem X applied.
As you can read, an important check for me to refuse feature requests for "Problem X"-type of issues is if you first need to run into Problem X. That in itself is not an issue. If the proposed solution to "Problem X" is not obviously to helpful or understandable to users who will never run into "Problem X" the feature is too specific.
When all the Problem Xs gets solved all the time by way of new features and settings, it means that Firefly III will become a mass of features, options, settings, choices and enhancements. None of those will bring value to the end user until they actually run into the associated problem and make the mental leap to the existing solution.
I've seen this destroy other product's usability and usefulness. They tend to become a massive pile of check boxes, system settings, environment variables and tutorials to make the product do exactly and only exactly what you want.
Doing this to Firefly III or the data importer would enormously increase the maintenance and support burden, because each and every new feature must be maintained, tested and documented. All the while, people will continue to ask about "Problem X", unaware that a solution exists (because nobody ever reads documentation). As a bonus, I fear that many people will apply the wrong solution to "Problem X" and run into even more problems, greatly increasing the maintenance and support burden.
I try to prevent Firefly III from becoming such a product. It will remain itself, with missing features and missing options. But whatever options it offers, I hope they make sense and that they will be useful. That means that the product does not exactly do what you need it to do. Sorry about that.