Hi Wm

I wished to experiment in what budgeting should look like by using the existing engine, UI, and reporting infrastructure.


It's actually not that difficult to create a 'budget balance calculator'; whether it meets the needs for everyone is another matter. But for people who wish to experiment with envelope budgeting, I can confirm that it is possible.

Rules are:

 * budget transactions must be "outside the books" so to speak, i.e.
   they are not counted in any net worth, profit/loss, transaction
   report, etc. they must be, by default, invisible to the reporting
   engine.
 * in order to be acceptable by the engine, they should they should
   satisfy the double-entry equation.
 * it should be generally useful
 * it should be better than the current budget

So this is actually a success. I don't use transaction voiding, and have hacked "voided transactions" to become "budget transactions" and upgraded the status bar display. The results are available on the topmost commit in https://github.com/christopherlam/gnucash/commits/envelope-budgeting as a demo of "what can be achieved using the engine". But I stress this was an experiment.

HTH.

On 04/02/18 20:33, Wm via gnucash-devel wrote:
On 03/02/2018 00:12, Matt Graham wrote:
Wow! That become contentious quick!!!

Only sort of.  If you read the devel list before the user list you get a feeling for what isn't going to happen soon and why.

The primary issue I’m seeing here is one of philosophy. What is GNUCash for? What is the purpose? What “should” be included and what “shouldn’t” be?

It is for people, of course ! Perhaps you meant, "who is it for?" :)

There is a universe of people that like, use and prefer single entry accounting along with the budgeting spiritualism and personal mantras that accompany some of them.  gnc ain't that and may not be for them.

Let me mention something else I think should, for example, be removed once the db is sorted out: USA and other country specific tax stuff (I'm not even sure how much of it works any more as governments change their tax systems without consulting gnc, etc)

Double entry accounting has been around for a while, that is definitely going to be included for ever.

Budgeting is, as I said before, personal.  It varies from person to person (I think envelope budgeting is short sighted) and what is appropriate for a person is inappropriate for more formal organisations that might require auditing or oversight.

If *all* the myriad of wonderful budgeting weirdness was added to gnc the prog would more than double in size in a year ... each year ... and 3 people would be using each of the special budgets and another 2 requests would come in each year, etc.

It just doesn't make sense putting more into an over stretched db compared to an interface that anyone can grab anything they want from using an ordinary spreadsheet.

Am I making sense?
gnc isn't
for a person of a certain nationality, it should work for most
gnc isn't
for a person or an organisation, it should work for most
gnc isn't
for a charity vs a business, it should work for most
gnc isn't
for a country, it works with currencies
etc

As has been highlighted, when someone loads up software they have a preset notion in their own mind of how it “should” work, and that is usually their own very narrow context (e.g. “That’s not how budgets work!”).

gnc's existing budgeting is very useful to some businesses and charity organisations, even though I use them in that context I still think they should be pulled out in the long term.  Budgeting is too idiosyncratic.

And anyway, given a good interface you could use, I could probably write a budget app a day.

NB: budgeting is not complicated computing, it is largely a human problem rather than a computing one.

My assumption on purpose: Open source software is created out of need and altruism. People who know how and want help create and maintain the project both because they are interested in software and enjoy the process, but also because they like being altruistic and providing something that others find useful.

I won't speak for seniors, I do read what they say. Of course, my understanding is mine if incorrect.

Based on that assumption, I have had the attitude “All requests should be considered and prioritised by the devs, but of course they will mainly implement what they find useful and of course they will only give how much time they can afford to”.

devs may be busy, devs may have a long list, devs may have lives aside from the project, etc

The natural flow on from my attitude is that I should indeed throw in what I want/need from my financial tools, but not expect anyone to act on it. If I want it done, I need to donate my time and implement it because it is definitely unreasonable to demand others to do it when it isn’t useful for them. (On that note, I’m keen to help out, but don’t yet have knowledge (and also struggle for time) in all this).


The problem with gnc code at the moment is that there is very little most people (or at least I) can do coding wise until the seniors get their stuff done.

Monitoring the user list, knowing accounting, understanding stuff, these are all useful things to do.

I have lots of specific comments against what people are saying, but all would be unhelpful if my fundamental attitude to the project is wrong.

Take the time to read something like

http://plaintextaccounting.org/

I see gnc as part of the family, others don't because gnc *has* *a* *user* *interface*  :)

it can get odd.  happy reading


_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to