Proposed feature requests on uservoice: Do we want them, or decline them?
John Ralls
jralls at ceridwen.us
Mon May 6 18:51:16 EDT 2013
On May 6, 2013, at 2:47 PM, Christian Stimming <christian at cstimming.de> wrote:
> Dear developers,
>
> over the years the gnucash uservoice page http://gnucash.uservoice.com has
> collected quite a number of suggestions from users about features they would
> like to see in gnucash. By the "voting" feature of uservoice, those proposals
> are also in a meaningful ordering.
>
> My assumption is that the vote numbers haven't been manipulated by single
> individuals (mostly because there hasn't been any incentive to do so), so I
> think the votes really reflect what "real users" really want. The interesting
> part in this story is that for new features, us developers tend to think only
> in terms of "what I want" (scratching my personal itch) and also "what is
> technically easily possible." However, those uservoice items tell the story in
> terms of "what a major part of our users want the most".
>
> I came to think we should listen to this voice, even when and specifically
> when those priorities contradict to our developer's ideas about the next new
> features. Here's the current Top 10 out of 220 items:
>
> #1 Transaction Classifications
> http://gnucash.uservoice.com/suggestions/1543027
>
> #2 Enable multi-user editing http://gnucash.uservoice.com/suggestions/1541003
>
> #3 Add Undo Functionality http://gnucash.uservoice.com/suggestions/1542903
>
> #4 Make it easier for users to work with alternative/non-ISO/private
> currencies. http://gnucash.uservoice.com/suggestions/2047887
>
> #5 Inventory system (mini inventory)
> http://gnucash.uservoice.com/suggestions/1540143
>
> #6 Add the ability to attached scanned images to invoices.
> http://gnucash.uservoice.com/suggestions/1535933
>
> #7 More charting: Budget vs. Actual chart
> http://gnucash.uservoice.com/suggestions/1539341
>
> #8 Type ahead search when entering the accounts to a transaction
> http://gnucash.uservoice.com/suggestions/1589607
>
> #9 Better Budgeting http://gnucash.uservoice.com/suggestions/1562955
>
> #10 Allow the database to be secured by way of a password
> http://gnucash.uservoice.com/suggestions/1547269
>
> HOWEVER: My thought on this is debatable. Let's take #10 as an example: We
> used to claim we don't want to do password protection, thus we silently
> declined this feature proposal so far. However, I want to challenge this our
> year-long response. If you read the uservoice item carefully, the request
> isn't about any real encryption. What's asked for is some sort of "mild
> blurring" so that other users of the same PC cannot directly access the money
> numbers. If we take this user seriously, we can very well add a feature for
> obscuring or blurring the data file and at the same time state clearly that we
> don't do any real encryption here. In my opinion this is something that we can
> indeed add as a feature.
>
> Alternatively, we should add some more honesty on the uservoice page. If
> requests such as #10 are considered a contradiction to gnucash's goals, we
> should really set the item on the uservoice page into the status "declined"
> and openly and clearly say that we don't want this behaviour in our project.
>
> But my point is that the uservoice feedback gives us a strong hint about the
> things that are really important to the users. Those are most likely different
> from what us developers considered important. I would love to see us taking
> the user's priorities seriously here. And by taking the user's needs
> seriously, we might also find that the implementation to meet this very needs
> can be chosen differently and maybe simpler than what we initially thought.
>
> In those cases where the "real user needs" can be fulfilled by relatively
> simple implementations, I'd like to see those implementations be added to
> gnucash. For this reason I think all 10 of the above are valid feature
> requests. We should try to get them implemented. Maybe not in the full-blown
> glory that some of the comments there were hoping for, but some parts of the
> features can be done and should be done.
>
Roger that there are real people voting, but many of them aren't users. They're
people who are claiming that they *would be* users if *only* we'd implement this
*one* feature.
Three of the requests are at odds with long-standing policy and need to be discussed and agreed upon before we offer them in the bounty program:
4: This is really "support BitCoin". We've long taken the position that it should
be treated as a commodity, but as some amount of actual commerce uses it as a
currency that doesn't really work right. At the simplest level it's just a matter
of adding a code for it as a special case in the currency lists until ISO gets
around to assigning a code for it. Getting quotes is another matter, and a problem for F::Q; similarly online processing with one of the clearing houses would require
support from Martin.
5: Inventory. Again, *accounting* for inventory is already possible. What the
request is asking for is ERP. I don't think we could go there even if we wanted
to, and there's already a bunch of FOSS solutions available: http://en.wikipedia.org/wiki/List_of_ERP_software_packages
10: Security. Again, we've long said that securing the database wasn't Gnucash's
job. There are plenty of external tools for that. That policy aside, it's pretty
simple to password-protect a file. In fact, the MySQL and Postgresql backends are
already password protected.
There are others on this list that are just too hard for a 1-month project. #2 heads
that list: It requires rewriting the engine, libqof, and the backends. That's
years of work. #8 and #9 aren't quite as big, but they're both significant design
efforts that aren't going to get done in a month.
Regards,
John Ralls
More information about the gnucash-devel
mailing list