Re: Proposed change of priorities for 1.4

[Erik Huelsmann <..hidden..>]

Hi Chris,

> Due to the length of time it took to get 1.3 out I haven't had the
> time necessary to get 1.4 development going strong.

Although I do understand that you're doing the most of the development
at this time (and have done so for quite some time), I believe we both
agree that that's not the desired long-term situation. I'm saying this
so that people reading this conversation feel invited to join the
effort: it's not intentionally solely yours, is it?

As I've said in private conversations over the past months as well:
I'd like to contribute more as well, however, I'm unable to make
commitments to specific efforts as far as commitments to specific
release dates go.

> Replacing the financial logic is going to be a big job.

Agreed. Could we start working out a document which describes what
should happen? That way, it would be easier for other people to join
our effort: they'd simply have to read the document stating what we're
doing and how far along the effort we've gone so far.

>  What I don't want to see is another 4 year release cycle.

Absolutely agreed!

> So I am going to suggest we shift our priorities and
> don't tackle the financial logic yet.

Thinking about this some more, I agree with you if you mean "don't
start coding" by "don't tackle". However, I'm thinking we could start
drawing up the impact assessment and plan-of-attack, the outline of
the DB stored procs, triggers and what-not. If we create a good
outline document with the mentioned components, I'm thinking it'll be
easier for others to join the effort. And I think we want to make that
as easy as possible: it'll be good for the community if/when that
happens.

> 1.4 should include as part of core
> 1)  New recurring transactions logic based on the template transaction
> addon in 1.3

As we  discussed in our chat, this changes the way recurring
transactions are being posted; instead of copying a posted document,
the process will copy a valid (but not posted) accounting/invoice
document. The effect is that users will be able to schedule invoices
without being required to actually post one first. Even more, it
allows one to change all future invoices - which isn't currently
possible.

> 2)  New trial balance module based on the enhanced_tb addon (currently
> under testing for 1.3)

You tell me this module is much faster and more flexible, such as
allowing subsets of accounts to be selected. If we integrate the
change you mention under (3) - allowing account totals to be split by
the various classifications (departments, funds, etc) - that would
absolutely rock!

> 3)  Generalizing projects, departments, funds, etc. out for reporting
> purposes.  Making these hierarchical

Having hierarchical classifications as well as flexible
classifications sounds really good; can we take into account that
people may want to define multiple hierarchies for one specific class?
(i.e. two or three department hierarchies. Sounds ridiculous, but it
works great in practice.)

> 4)  Refactoring contact logic, making it more flexible, ensuring that
> customers and vendors can be tracked as individuals instead of just
> companies.

Personally, I'd assign a higher priority to developing (web)services
APIs than prioritizing this item. I'm not against this and definitely
see the value added as well. We do have use for this, but we're just
creating people as companies and setting them up as their own
contacts. It works well enough for now.

> Some of the work I have done on number/date formatting for 1.4 will be
> included and this will allow a wider range of number/date formats to
> be supported.

> The goal would be to have something we could target for release in
> summer/fall, and get our release schedule back on track, as well as
> providing a basic springboard for further development into the
> financial logic of the software.

As I have expressed in earlier conversations (possibly private only?)
I  think that's a great idea: having a dependable release cycle where
the functionalities which are done get released to the public. That
way, the part of the community which benefits from those changes
doesn't have to wait for some huge project to complete.

My idea for approaching the financial logic refactoring would be to
determine in the assessment which bits can be done on trunk as part of
any release. That'll help paving the way for 'the big change'. When
we're done refactoring the smaller bits, we move the main refactoring
to a branch where we work on it at our own pace. There, the work isn't
blocking releases of other functionality or fixes. Working on a branch
until we're ready to integrate means we won't be forced to have
another 4-year release cycle.

> If I have time I would be open to putting some time towards an appointment
> module, I would like to do that but at this point, there are no guarantees.
> What do people think?

Well, if you get funding for the appointment module, I'm the last one
to tell you to earn money :-) However, if I look at the current
structure of the application, I'm not sure where it fits in. I mean,
other CRM software integrates with e-mail clients and agendas these
days. Is an appointment module good enough?


Bye,


Erik.