The role of users

[Robin Chattopadhyay]

I've avoided getting drawn into this discussion, but...

I think the point Mike is making is that without a concrete action plan,
ideas are just that: ideas. In my professional world, someone (usually
management or sales) comes up with an idea. Then -- usually -- others write
the requirements, the functional specification, the system specification,
the test plan. Much of that work is done before a developer writes a single
line of code.

I'm not a developer, but I have done all of those other things. Turning an
idea into a detailed set of requirements isn't hard, but neither is it
trivial or fast. The quality of the finished work depends greatly on the
quality of the initial requirements and does require a fair bit of thought.

As for the negativity, I haven't been involved in other open source
projects other than this one, but I find the community support -- including
from those that actually do the development here -- to be far more helpful
than even those in my workplace that are being paid to support me.

To me, a lot of open source projects are a labor of love. It's as if a core
of people came together to create this program to meet their own needs and
THEN offered it to the rest of the world saying -- in effect -- "Here is
something I've created for my benefit, maybe you can find use from it as
well."

To the extent that Gnucash doesn't meet my needs (i.e. reporting), I have
solved my own problem by using the data in the sqlite file format to create
my own views/queries/reports. I've been using the program for three years;
once I got past the learning curve, I realized I'm never going back to
another program.

The one feature that I miss from M$ Money is the cash flow forecasting. I
have tried in my head to come up with a requirements document that would
adequately describe what I believe would be necessary to accomplish the
cash flow forecast while keeping in mind how the data is stored in the
database. And it hasn't been easy.

So, if ones doesn't like how the program works, there are several options
for the average user:

   1. Recognize that the program just doesn't do what you want it to do and
   move on
   2. Come up with your own workaround -- a companion spreadsheet,
   document, program, script etc. that fills the missing need
   3. Roll up your sleeves and get your hands dirty. Figure out how the
   program works and come up with a requirements definition that meets the
   needs that Mike describes
   4. If all else fails, find a more suitable program and try your luck
   there.

In this kind of community it isn't enough to point out a flaw or even come
up with an idea for a feature enhancement. One also has to have a set of
requirements that answers all the necessary questions and be able to
present to a developer how *they* would benefit from the improvement you've
suggested.

On Fri, Apr 20, 2012 at 12:15 PM, David T. <sunfish62 at yahoo.com> wrote:

> Michael--
>
> Is it your intention to turn THIS thread into another flame war about how
> members of the community are supposed to contribute? Because that's what it
> sounds like.
>
>
> Your comments also seem to imply that my observations in particular are
> not to be taken seriously, and I resent that.
>
> Unfortunately, your comments perpetuate the very negative atmosphere that
> others have noted about the Gnucash community.
>
>
> David
>
>
>
> ________________________________
>  From: Mike or Penny Novack <stepbystepfarm at mtdata.com>
> To: David T. <sunfish62 at yahoo.com>
> Cc: Ross Boylan <RossBoylan at stanfordalumni.org>; Gnucash user list <
> gnucash-user at gnucash.org>
> Sent: Friday, April 20, 2012 4:15 AM
> Subject: Re: The role of users
>
> In the "real world" the development of software involves the time and
> effort of more people than just the "developers". You do NOT have to be a
> coder to be useful. There is a role for users in the process, more than
> just a wish "I would like to have THIS" or "I would like to have THAT
> fixed" with only a vague description of what This or that might be.
>
> I would take more seriously the complaints IF the complaining users were
> to say I/we will agree to commit our time and effort to that part of the
> process which is the users role. In a real world software process usually
> at least 20% of time/effort is users coming up with a formal definition of
> what is wanted (from the users' point of view). What the software is
> supposed to do under normal circumstances and what it is supposed to do
> under all exceptional circumstances. And then coming up with the (user)
> test plan for acceptance and supplying users for that testing (comes after
> the coding developers have tested and eliminated gross errors). In fact,
> this can sometimes be much more than 20% of the process.
>
> If there is no formal definition of what some piece of software is
> supposed to do then whatever it does is correct (as long as it doesn't hang
> or loop).
>
> Users don't have to do this alone. Or shouldn't have to. If and when a
> "user team" comes into being they should be able to ask for the assistance
> of an analyst experienced with working the users side as well as the coder
> side.
>
> Michael D Novack, FLMI
>