Proposed feature requests on uservoice: Do we want them, or decline them?

Tue May 7 20:47:47 EDT 2013

decline!

Many of the desired features are already there, if people would actually
*learn* how the use the application to it's fullest extent.

It's apparent to me, folks are looking for a turn-key solution to every
thing, or a silver bullet to all their accounting, and inventory needs.

I've been using GNUCash for desktop for a few years now I still have to
discover all that it can do. Given the fact it's open source, and I knew
how to program, or knew someone that did, I can make it [GNUCash] do
just about whatever I want. 

I think some folks are also just trying to be real cheapskates. They
don't want to pay for what is already out there to solve their business
financial/logistical issues.

In my defense, I love free stuff, but I'm not a greedy heinous person
that takes without giving something in return. While I'm not a coder by
anymeans, I'll support financially, or give back to the open source
community in other ways. But also too, some folks just don't give back,
which is fine. I'm happy with folks who use and like what I produce.

~Benjamin 

On Mon, 2013-05-06 at 15:51 -0700, John Ralls wrote:
> 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
> 
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 1056 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20130507/d735d1a1/attachment.bin>