On Sat, Dec 17, 2005 at 03:11:53PM +0800, Richard Hosking wrote: > I find the code in Gnumed almost totally impenetrable Richard, is there anything you would urgently need to be documented for the code to become less impenetrable ? I can document pretty much anything if you come up with what hints you'd need.
> and I doubt I could add much > of value to the coding without fairly intensive direction. No problem there. If I looked at KDE core code or the linux kernel or BSD filesystem drivers I'd be totally lost, too. Please do ask for help and directions right here on the list. I'll be happy to answer any questions re backend/client you may have. Only thing I'd ask for in return is that you document in the Wiki what you learn from it. > I would not see Gnumed as a viable alternative in Australia in it's > current form Definitely not, neither so here in Germany. Also, "alternative" so much speaks of "competition". I don't see competing as any of my interests. Hence my current goal isn't replacement. It's cooperation which will undoubtedly lead to replacement eventually whether I like it or not. > - it needs accounting, a front desk module and prescribing. Yep, pick any of them and start researching, planning, proposing and coding. > It will be difficult to produce the functionality of alternatives, so it > will have to offer something new to compete Structured documentation is the big plus but most Drs don't care to my experience. > A proper robust database design We are not too bad on that side I hope. > and internet/network scalability are > other (major!) pluses, but most Drs would not necessarily see this as a > great advantage. I agree. > I think perhaps coding should stop and the "evaluation" part of the > cycle should be looked at Coding for 0.2 doesn't need to stop for evaluation to start. Just start evaluating and document what you find. > - what do we (and other users) want? We *know* what (some) users want: - first we needed something that did demographics in a basic way and implemented what we are here for - a sane structured way of capturing clinical information of any kind -- we have that, it's called Release 0.1 - second we want to move the only reference installation of legacy GNUmed code onto mainline GNUmed code -- this is what 0.2 does - it merges the old document archive code into the current code base - thirdly we have someone with a strong use case -- he needs to be able to handle lab data for a clinic -- so that's what 0.3 is planning to do > Does the current software achieve this? So far we are good in milestones. > If not, what are the priorities and who will do the work? I will, apparently no one else is interested in coding. The priorities are as laid down in the Wiki in the RoadMap. > By "management" of the project I would think we mean tracking this > process, and to certain extent directing (and assisting if necessary) > those interested to do certain tasks in a coordinated way Please do start today doing so ! I'd love to see that burden taken off me and/or Sebastian. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
