Re: Meeting Summary for Monday Jul 26, 2004

Hi guys.  Sorry for the delay.

The following is a summary of the Meeting Held on Monday, July 26, 
2004.   The minutes are organized by topic for clarity, and the 
commentary is heavily paraphrased as IRC discussion threads tend to be 
non linear - a diametrically opposing format to a linear summary 
document.  I hope I got everyones intent correct, my appologies 
aforehand for any errors - please file corrections to the group if you 
feel your commentary and or intent were misrepresented.



*** MEETING STARTED ON Mon Jul 26 13:07:21


Topic #1 - Packages and standards:

- First suggestion was to better define the gnue packages, how complete 
they should be, should they comply with any standards

- With regards to standards, the question of what would be worthy 
standards to follow came up.  It was suggested that maybe a better idea 
would be to push the envelope and the sate of the art first as standards 
tend to be designed by committe and as such reflect the 'design by 
committee' philosophy.

- We ought to observe standards that deal with segments of packages so 
as not to reinvent the wheel, only use standards that are worth using, 
for example, 'accounting standards' as published by various standards 
groups would need to be followed (particularly as accounting standards 
vary from country to country).

- Overall, it was suggested to have the packages follow the KISS principle.



Topic #2 - The competition:

- There are a lot of freely available packages that deal with ERP 
related solutions.

- It is suggested that we take the best parts of each and improve on 
them - look at what works and what doesn't by example as the research 
and development has already been done to some degree.

- Some examples of packages to to be looked at: SQL Ledger, GnuCash, 
Compiere



Topic #3 - Gnue related deails:

- A data dictionary or list of all tables, one does not exist yet 
outside of the domain of knowledge of the principal programmers on each 
package.

- A common db format should be established as all modules will 
eventually need to interact

- The modules should be kept small, without too many features.

- Security needs to be implemented.  For example, most organizations 
don't let the same person open Purchase Order and and Accounts Payable 
module (they are usually separate jobs).

- Currency is one example of where featuritis/complexity tends to creep 
in, however this is an issue that does not need to be addressed in the 
first relase.

- Some feature ideas:
---- gl ar and ap are all related, should ship together or be 
installable separately
---- payment reminders
---- good clients fore example may get the first second reminders, but 
never threats of going to court, wheras bad clients would get the 
automated nastygrams.
---- suggestion for gl ap ar to be the core group, not separable as they 
are dependent, but separately installed maybe (some need gl and ar, but 
not ap for example)




Topic #4 - Eat your own dogfood:

- It is suggested that to improve thequality of the product, that we use 
our own tools to manage the development of the ERP packages, the eat 
your own dogfood principle

- The first suggested tool to be built is a project management and bug 
tracking software such as DCL for internal use.

- UML is not discarded as a tool, but is looked upon as more of a burden 
than a tool.  Will be used selectively by developers as they deem necessary.




Topic #5 - Goals:

- It is suggested that we co-ordinate development on a much higher 
level, then drill down into the details.

- As an example, the tried and true open source route is to try 
something and learn from it, rather than approach it from a strictly 
academic perspective.  Build something now, something that works and 
meets the groups (and potential clients) immediate needs.

- Our goals should not aim too highat first, don't aim for replacing 
SAP, aim for smaller achievable goals

- It was noted that the SAP market is saturated, suggestion that small 
business is still looking for ERP solutions they can afford

- The development cycle needs milestones clearly set - perhaps as part 
of the implementation of our own project management software.  As 
refactoring is expected as par for the course, python was the perfect 
choice for a development language to take care of that need and UML 
would simply duplicate the effort.




Topic #6 - Current reality:

- Some developers wish to make a living with the releases, not aim for 
pie in the sky projects.

- Gnue is ready for a serious push into the marketplace and deployment 
into small business scenarios.

- Applications Server is ready for support contracts.

- As well there are 3 people working on packages currently: invoicing, 
accounting and hr.




Topic #7 - To Do list:

- The packages that are immediately needed are: General Ledger, Account 
Recievable, Account Payable, Human Resources.

- Packages that would be helpful are: Project Management and Bug 
Tracking software

- As it pertains to the packages listed above, what should be built 
first would depend on the teams needs initially, and further development 
would be paid for by the client.

- Gnue-SB (Small Business) edition is suggested as the initial release 
package group.

- Navigator needs some refactoring before it is ready for use by the 
typical Small Business owner.  Currently it is only suitable for developers.

- As Navigator and Forms will be the most used front ends, both need 
special attention.

- Currently there is no graphical User Interface for Reports - this 
needs to be remedied.

- In terms of Reports, users need to be able to generate "spontaneous" 
reports easily as they will have needs outside of the premade batch 
reports.  Currently Reports module does not have enough functionality to 
satisfy this need.

- Navigator needs a lot of work to work in embedded scenarios. It only 
supports wxWindows currently on embedded platforms.

- Navigator should let you launch more than 1 form, it should track open 
forms as well.

- Navigator is lower on the TO DO list overall as it needs a lot of work.

- Higher on the priority list is to start creating packages and 
fine-tuning the tools as we go along.

- It is suggested for Gnue-SB to have single directory per module for 
organization




Topic #8 - Tutorials

- The need for tutorials is obvious.  Mentoring is suggested as a "teach 
the teacher" method of expanding the userbase.

- Suggested to have 1 hour tutorials on:
---- tutorial on basics of accounts receivable
---- a tutorial on basics of accounts payable
---- a tutorial on basics of general ledger
---- a tutorial on basics of human resources
---- a tutorial on basics of ebXML


**** MEETING ENDED AT Mon Jul 26 15:41:15 2004



- Thanks again for all the great work you guys do, this is a little bit 
of my contribution to the effort ( I hope to allocate more resources as 
time goes on.)

- Robert