[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Migration and documents
- Subject: Re: Migration and documents
- From: "Chris Travers" <..hidden..>
- Date: Thu, 26 Apr 2007 18:12:12 -0700
On 4/26/07, David Tangye <..hidden..> wrote:
On Thu, 2007-04-26 at 17:46 -0700, Chris Travers wrote:
> First, I think that INSTALL and UPGRADE files should always be
> maintained. Those filenames are in upper case not because I am
> yelling but because that is the standard convention. If your install
> is a mess, I am guessing you didn't read these files :-)
Its not. I did read them. I read EVERYTHING. ALWAYS. (not shouting -
emphasising :-) )
> I do not expect we will ever stop maintaining them, and we will
> probably always document a manual install process regardless of
> whatever else we offer.
Well as long as there is a process to ensure both are in sync it does
not matter. My concern is there those sort of processes are not in
> The manual is written for people of any level of accounting or
> technical background. It comes with the sources so if people want, it
> can be stripped down for specific training sessions, but the idea is
> that it is out there to teach the people
> installing/maintaining/administering the software how it is supposed
> to work.
OK, what about the users?
The manual ought to be structured in such a way that a sole proprietor
should be able to teach himself how to administer and use the software
easily. The manual is designed to be worked through consecutively and
that is why it is all in one document. Advanced users and consultants
can find more technical information in part 2 which is separated from
the rest so that people know where to go for workflow or technical
documentation. It is also where it is because we assume the reader
has already read the rest of the manual.
Maybe your priorities are in producing software. Mine is more in making
it usable, partly by being understandable/presentable to more users. It
has become apparent that my priorities are not valued here. And I am not
sure I am very impressed by the "put your money where your mouth is."
sentiment either. I have been spending a lot of my time (= money) making
suggestions. If you do not value other suggestions and criticism, just
I suppose my past remarks deserve some clarification. It was not an
attempt to devalue your priorities. I just don't think those
priorities are things we can reasonably get to at the moment and
sometimes, I get the impression that you are making demands on us
without any idea of what you are asking.
We all know that the software needs a *lot* of work to be easily
usable by most people who have a basic knowledge of bookkeeping.
However, I don't think that any of this matters if the software does
not operate properly in terms of the priorities I mentioned: security
(including from malicious users), accounting logic (always posting the
right numbers in the right way), and process controls (so a business
has control over how transactions can be posted).
Those priorities are really the basics of any accounting system and
are as necessary in the realm of paper accounting as in the realm of
computers. If the accounting system doesn't do these things right,
then I don't care how easy it is to use, it is not to be trusted. And
I would hope people would want a solution to manage their money that
*could* be trusted. In fact, I would expect that to be more important
than anything else. After all, it is managing your money.
Also, as I have mentioned before, the code is very badly structured.
We are working on it, but making demands on our time, or insisting
that we get our priorities in the order you are articulating (user
experience first, the rest later) is not going to make it happen. If
you want to contribute, that is fine. If you want to wait until the
codebase is in better shape, that is fine. But frequently complaining
about user experience at the moment is not going to make the situation
So I gather that I am reacting against the presentation more than the ideas.