Rolf Leggewie wrote: >Mike or Penny Novack wrote: > > >>IMHO you do not want "a person" who meets all those criteria. >> >> > >Mike, thank you for your reply. > >While your theoretical description may be correct, I think I have >accurately summed up why in reality gnucash is not moving forward for >European business users. That is, there is no person who can actually >code with time on their hands, an interest and an understanding of where >gnucash currently falls short. > >A number of bugs were recently closed as wontfix with the idea of >"support for European/German business users is out of scope for >gnucash". That is because all people concerned are well aware that it >won't happen anytime soon inside gnucash and thus it may be better to >pursue solutions outside of gnucash bolted on to the gnucash data. > > > Well first of all, "bolted on" MIGHT be the appropriate solution. That is precisely the reason for my "theoretical description" of the development process.
A "bug" is a program not doing what it is SUPPOSED to do (doing something wrongly). Failure to do something that was never part of the specifications is not a bug, it's a user request for development work. But to have jumped ahead from the "this is what I need" to "THIS application should be changed to provide that functionality" is an error. First the end users and the "business analysts" decide what is needed. Then decisions are made how to best fill that need. I faced this directly as I am both an end user and somebody quite capable of designing/coding --- all aspects of a project from inital user requirements analysis through final acceptance testing* -- though as I have already said, not great if wearing too many of the hats. In my case it was getting from the reports produced by GnuCash (income-expense statements, balance sheets, etc.) to the final form of the organizational financial statements as would be presented to the board of directors and filed with governmental agencies. I was advised NOT to try to add "finished form", that no accountant would want that, that they would simply take the reports as generated to be the data they then used to fill in a proper GAAP format report. And that they normally do this "by hand". BUT -- let's say that I was going to do that. Would it end up as "part of GnuCash"? (part of the same executable). Probably not. It would probably be a stand alone application which accepted as input the reports as produced by GnuCash plus some fixed test files but functioned more or less as and "editor" allowing the accountant to insert the necessary "notes" and texts. That, by the way, was why I was told "don't bother". Any accountant already has preferences as to which editor application he or she prefers to use and all of them allow the pasting in of the GnuCash reports and the fixed descriptive texts as a starting point. Point is, I don't have to live in Europe to design/code what you need. You assemble the European end users and agree on a specification of what you need done, what your "business requirements" are. Then we see whether what you need is for GnuCash to do this for you, some stand alone system that takes feeds from GnuCash (that can still be part of the GnuCash PROJECT), or something completely independent. Understand? Simply saying "GnuCash doesn't do what we need done" is not enough to get my attention. If I'm helping you with the "requirements phase" then I would probably rule myself out as a resource for later phases because wearing too many of those hats clouds judgement -- you need more distance from some of the decisions. The "business requirements" phase is NOT a trival part of the process. Michael D. Novack, FLMI * I'm a retired very senior sort of analyst who used to do this stuff for one of the world's largest financials _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel