Where to discuss the development of gnucash (Re: KMyMoney vs Gnucash)

[Geert Janssens]

Michael,

You're still hijacking the thread. A good hint for that should be the 
title: it's called "KMyMoney vs GnuCash", not "how should an accounting 
program be developed".

But since the original thread is now dead anyway, I will continue on 
this one but change the subject so people can more easily decide if they 
want to follow this twist in the subject or not. I didn't do so before 
because I presumed the discussion would end. I was wrong.

And I'll repeat my original stance: the *user* mailing list is *not* the 
place to discuss *how* gnucash should be designed. Here's the 
description of the mailing list [1]:

"Support
--------
The Gnucash team, together with experienced users, will answer your 
questions about the *use* of Gnucash on *gnucash-user*"
(emphasis mine)

And this is the description of the gnucash-devel mailing list:

"Development
------------
The following mailing lists are intended for discussion of the ongoing 
development of Gnucash, including submitting patches, helping with 
testing, or discussing future development directions.
...
gnucash-devel
..."

That's where design discussions belong, design as well as implementation 
discussions. And users are free to sign up for this list as well if they 
are interested in shaping the future of gnucash by discussing design 
decisions. The difference I see between gnucash-user and gnucash-devel 
is in the level of involvement, not the technical skills. gnucash-user 
doesn't require more involvement than using gnucash (or even considering 
using gnucash). gnucash-devel assumes you care about gnucash enough to 
think about how it should evolve.

That's what I meant when I said you're trying to evangelize the wrong 
crowd. Instead of listening to what the users say and encouraging them 
to continue to share their experiences you risk pushing them away. You 
risk crossing their threshold of involvement. On the devel list you'll 
get a better audience, because the subscribers there chose to be more 
involved.

Oh and did I say I agree users should be involved in deciding how 
gnucash should be designed ? I do. They're welcome to get involved on 
the gnucash-devel list.

And perhaps contrary to your experience in your "real world" *all* of 
the gnucash developers are also gnucash users or at least have been. 
Most started out as ordinary users and felt that parts of the program 
were lacking. So from there they moved from being users only to being 
both users and developers. So your suggestion that developers can't know 
what a system must do from a user's point of view can insult people in 
the gnucash context.

Of course developers don't know everything, just as a systems analist 
can't know it all or even one user can't know what another one wants or 
is missing. That's why I am encouraging people to express their 
frustrations as well as their good experiences on the gnucash-user list. 
The more is shared the better an understanding all people involved get 
of the state of gnucash. And the state of the community (another 
important aspect that wasn't even touched here). I hope to keep the 
environment open and welcoming to user experience feedback.

What I saw happen in the KMyMoney vs GnuCash thread is the exact 
opposite. It had started out as a very open conversation with a very 
positive attitude towards gnucash. That was gone the moment your first 
contribution in the thread came in. It suddenly was all about "how to 
design an accounting application vs a business system" (a discussion I 
refuse to go into here). It was not even about gnucash any more.

So what exactly did you contribute to the original conversation again ?

Geert


[1] This comes from here: http://wiki.gnucash.org/wiki/Mailing_Lists

On Friday 22 August 2014 08:57:04 Mike or Penny Novack wrote:
> > Actually no you didn't need to be clearer. Technically you are very
> > much hijacking a list thread which is considered bad mailing list
> > practice.
> > 
> > In addition you are trying to evangelize the wrong crowd. This is
> > the
> > *user* mailing list. When I'm engaged as a *user* in a community I
> > couldn't care less how exactly the internals of the program work.
> > How
> > the program *should* work is even further away. At best I'd ignore
> > such a reply, at worst I would be so annoyed as to leave the list.
> > 
> > If you want to share your systems analyst's experience you're most
> > welcome. However I invite you to do so on the gnucash-devel mailing
> > list.
> Sorry if you don't agree that THIS is the place (the user level) to be
> discussing what a system SHOULD do as opposed to the development list
> where the discussion should be about HOW to make the system do that.
> I was not talking about "internals" but "externals".
> 
> Look, when I was doing this in the "real world" (large financial
> systems) at least 20%, sometimes more of the project time was spent
> with users, with the help of analysts, deciding on the formal system
> requirements (what the system must DO, from the point of view of the
> user) and only after that was defined going to the more technical
> types plus analysts to decide how that was to be implemented. When 
> you say this (level) is for the developers to decide you guarantee
> dissatisfied users. If there is no formal set of requirements for
> what a system is supposed to do then whatever it does is correct (as
> long as it doesn't loop or hang).
> 
> It is here (at this level) we need to decide whether the accounting
> system gnucash should expand to a monolithic all encompassing system
> for the needs of businesses (inventory, point of sales, commissions,
> approvals, billable hours, etc, etc.) or whether those (including the
> accounting package) should be separate components of an overall
> "business system" in which case need only the parts your type of
> business needs and add then as become available.
> 
> It isn't with the developers that my analyst experience would be most
> needed though I often/usually wore that hat too. Our greatest weakness
> with many of these free source projects is inadequate USER commitment
> to the development process, the "system requirements" phase (and
> later commitment to the "testing" phase). Developers know the
> programming but it users that know the needs of the business.
> 
> Michael D Novack, FLMI
> 
> PS: Feel free to add to that "needs of business list. I intentionally
> included things like "commissions" and "approvals" because I hadn't so
> far seen any requests for the things needed to support those but that
> reflects the types of businesses users on this list represent. For
> example, there aren't many businesses that normally sell "on
> approval" (and so need to be able to account for goods in the
> possession of potential buyers but not yet sold to them). It would be
> a USER decision whether an "inventory system" (assuming one already
> existed) could be stretched to handle "approvals" or not.