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