Hi, I'd like to contribute more as well. So a list with to-do's would be useful.
But i think we also need a document explaining a bit more the addons directory. How does one start an addon? e.g. by announcing one's intentions on development list? How does one test addons with actual 1.3-branch code? Without too much svn-administration overhead? etc. Thanks, Herman 2011/12/11 Chris Travers <[email protected]>: > Hi Erik; > > Thank you for your reply. > > On Sun, Dec 11, 2011 at 3:33 AM, Erik Huelsmann <[email protected]> wrote: >> 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. > > Right. Nor do I think it proper to expect the same from any contributors. >> >>> 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. > > I think for GL stuff we are pretty close in the way things currently > work. For AR/AP I think we need two things: > > 1) Discussions on -users asking the question "anything you think we > need to change?" in affected areas. Also we need to go through > feature requests a few times in these areas too. > > 2) After this, I think we can discuss workflows on -devel, as well as > other stuff. Take proposals back to -users after we have something > generally discussed. >> >>> 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. > > Technically by "tackle" I mean "don't make disruptive changes to the > codebase in trunk." Coding might be fine, but not for 1.4. > >> >>> 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. > > yeah, but web service API's will be cleaner for this area if we do it. > I'd like to revive Jason's REST work regarding the old codebase too > and add invoices, orders, etc. to those. Reading the code there, that > shouldn't be too hard. >> >>> 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? > > It's good enough for some use cases. Those use cases can bring > additional projects later. > > > Also want to integrate the work I have been doing on payroll. > > best Wishes, > Chris Travers > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > Ledger-smb-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
