Scope of GNUCash

Tue Feb 13 23:46:22 EST 2018

Not sure why you think I’m one  of the “demanding” people... I’m not actually asking for anything – I’m trying to figure out how this all works, what I really need, and how I can contribute to make it happen.... I don’t expect anything specific from the core dev group – I just want to fit in with their plans.

I am not sure why you think I’m defining the scope for anyone in these emails.... I started this thread asking what the scope is (triggered because you keep telling me that all the stuff I’m interested in is out of scope...). I don’t expect to get a say – I just thought there would be something that states it so that I can admit you are right (and stop focussing on that) or get you to stop saying that things people want to do “isn’t what GNUcash is for”. (Note: “We haven’t had time to implement that and probably wont get time” is a very different statement from “we won’t implement that because that isn’t what GNUCash is for”. The former => no worries I’ll help out if I can to get it to happen. Until then, I’ll make do. The latter => No worries, I’ll figure out a way to do it out of GNUCash and I’ll stop asking about it. Again: I’M NOT DEMANDING ANYTHING – I’M TRYING TO UNDERSTAND.

So based on the questions I’m asking you (running around in circles?), I’m pretty confident I’m missing a lot of your points. I’ve read through a lot of the text accounting references you gave me a while ago about budgeting.... And it all seems pretty much in line with what Chris L and I were talking about ages ago. I was thinking along the lines of envelope budgeting with sub-accounts and tools to help that. Chris was talking about virtual transactions and how that would work. Both are described in various wiki’s and help docs found off the plain text accounting budgeting area: http://plaintextaccounting.org/#budgeting. So if I understand your point, you are saying that I should be exporting my accounts to text, then using another program to implement such a system?

  1.  I would rather use GNUCash over the plaintext tools if it is an option. Mainly because of the convenience in layout, display and interaction with my data. GNUCash it already gives somewhere between 70-85% of what I would need/want from the ideal.
  2.  I could spend my time learning the command line tools..... or I could spend my time helping out with GNUCash to build in the functionality I want (and evidently lots of other people want – but I don’t say any of this meaning the dev’s should do it for me. I say it to fend off your constant assertion: “that’s not what GNUCash is for!!!”. I’m still confused on what you think GNUCash should be for....).
  3.  If I am supposed to export from GNUcash regularly and then import to the command line tool to do stuff I’ll regularly want to do... then why wouldn’t I just use the command line tool for everything? Based on what you say, why do you use GNUCash at all??? What can it do that the command line tools can’t?

For David T: What I’m planning to put into the Tut and Concepts at the moment is a description of how to use sub-accounts for envelope budgeting – Similar to the “Poor Postgrad System” in this link (but for GNUCash): https://memo.barrucadu.co.uk/2018-budget.html

I hope I’m not being unreasonable (or being misunderstood) in all my posts. I am very grateful for the functionality and capability that GNUcash already has, and hopefully people aren’t getting offended when I ask my questions.
Is it unreasonable to always be looking for a better way of doing things???

Thanks and regards,

Matt

From: Wm via gnucash-devel<mailto:gnucash-devel at gnucash.org>
Sent: Wednesday, 14 February 2018 11:35 AM
To: gnucash-devel at lists.gnucash.org<mailto:gnucash-devel at lists.gnucash.org>
Subject: Re: Scope of GNUCash

On 13/02/2018 21:53, Matt Graham wrote:
> 😊 I think I would love to sit down in a pub with the three of you (Wm, Adrien, and Mike). I think we could have such awesome semi-drunken discussions about the nature of life, the universe and everything!

I'm in London. Mike is in a Trump voting bit of Merka. Don't know where
Adrien is and he shouldn't have to say.

Accounting is a way of measuring life.  Happiness is harder to quantify.
  Life should be enjoyable and measuring money shouldn't occupy too much
of our time.

Most crass philosophical sayings are also guaranteed to be crap.

> I think you have basically answered my question, and I think we all basically agree on the rough direction things *should* go in (separate interacting packages).

I'm the person arguing for stuff to be taken *out* of the basic package
so the important stuff can more easily be better interpreted or used,
the important stuff being the data that each of us owns or has
responsibility for.

Meanwhile, since I have a good understanding of accounting and databases
and related stuff, I just do the bits I need that gnc doesn't cover
using plain text accounting.  My point in that regard being that almost
all the *thought* problems have been solved in the plain text accounting
universe and plain text accounting has also solved some problems you and
I didn't even know existed and are way more esoteric than a budget being
to your specific needs or a report being formatted one column to the
left for the convenience of your tax accountant.

The problems have been solved, it is the presentation you are struggling
with.

 > I’m just not sure how to help make it happen (I’m an enthusiastic
amateur when it comes to programming).

The gnc code is almost impenetrable in parts.  I'm considerably above
average when it comes to programmings skills but there are, when I drill
down, bits that simply don't parse.  I know exactly what the code is
meant to be doing but someone has written it in such an obscure way I
just give up and return to understanding the data.

It is *this* that the seniors are working on rather than adding a bell
or a whistle.

If the code can't be brought into a form where more than a handful of
people can understand it the project is going to die with the seniors as
they naturally retire to caring more for their grandchildren than people
on the internet thing that demand they do this or that.

You seem like one of the demanding people to me, Matt

> I think I’ll start by updating the budget part of the tuts and concept guide like I have promised elsewhere, and then start looking into how the C++ modules have been structured (to see what connection will be possible within the 3.0 releases).

Ufff, you are welcome to try to understand the budgets but you are
warned, you aren't the first to think it makes sense to contribute
there.  You are also unlikely to succeed in explaining the way the
existing budgets work to anyone's satisfaction, possibly even your own
satisfaction.  I am not joking, by the time you have figured out how the
existing budgets work you will already be wondering why they were
included at all which brings us neatly back to you, Matt, wondering what
the scope is, remember ?

I don't think you should be defining the scope for other people any more
than me ... my wishlist is simple and if I don't get what I want I'm not
going to cry because I can do my accounting in more than one way.

--
Wm

_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel&data=02%7C01%7C%7Cc63146f72f87484b52ef08d57342e919%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636541653571311865&sdata=z3hyuJ%2FSvN3maNViwIUmD7Z9ZXmruo847NRrgAPjNvU%3D&reserved=0