On May 6, 2013, at 2:47 PM, Christian Stimming <christ...@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@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
