On Wed, 30 Nov 2005 13:14:12 +0100 Sebastian Hilbert <[EMAIL PROTECTED]> wrote:
> > From my point of view there is no project official vision. I live here and > now. My day has 24h. I know what you mean. A project needs a vision for other > people to be attractive. I know what you mean. Endless thinking has been put > into this by me and Karsten. One day I simply had a choice to make. >... This sounds somewhat like you would have to decide either for thinking about what the vision for gnumed is or to do other important things (PR, packaging, etc.). I strongly believe that a project without a well-thought project goal (=vision) is not able to achieve anything. Nor does it make sense to invest in PR for such an project. Gnumed can't be everything to everyone. You have to decide what GnuMed should be. Nevertheless, I'm convinced that there *are* people in GnuMed that have a clear vision of what GnuMed should achieve. I suspect there is even more than one vision available at request :). All we have to do is to write it down, print it out and put it above our monitors. Maybe it is already in the Wiki. > > Over the last years I learned that large and complex projects without a > > final specification *before* starting to work will either have difficulties > > or fail completely. I'm quite convinced that GnuMed is complex enough to > > need a specification. > We have specs. Just no active mainatainers and no active lobbyists. Richard's > GUI specs have been there for ages but never revised. I mean they represent > what he knows is best for him but noone took the liberty to follow up the > endless discussions we had on it and revised thos specs. True. There are specs, but we never took time to get a revision everybody could live with. Which is sad, because this eventually means that all good points which were raised in discussion will be buried in tons of mails. > What other specs you need ? We don't have any specs before we code individual > plugins. True. But I am not going to write up specs for GNUmed/Archive > because this project is so self contained that one person working on it is > sufficient. If I start writing up missing specs for yet to be defined modules > who is going to code the GNUmed/Archive. See the catch ? I am not arguing > against specs. It's just not me who is going to write them. I suspect that you believe that you can do the second well without the first (i.e. code without specs). Let me explain why I believe that this is an misconception. Specs are basically (at least to me) nothing but your ideas put into words and written down. If you start coding, you usually have a clear idea of what you are going to do. If not, you will probably have to change your code again and again until you found out what your goal really is (please note that I'm talking about recoding because of unclear goals, not technical improvements and bug-fixes). This idea usually consists of two parts: requirements and an idea of how you would like to realize them (say, how the user interface should look like). The latter part is usually called design. So even for more or less self contained projects that can be done by one single person will have specs, you just don't write them down. Now why would one want to 'waste' time with putting down specs ? Well, I see the following benefits: 1. The process of writing something down helps you see clearly what you are going to do and to identify possible problems in your design or requirements you might have forgotten before. One rule of thumb is that if you have difficulties writing requirements and design down, this usually means that you still have no thourough understanding of what you are going to do. Think of building a house: before moving the first brick you usually make at least a sketch of what rooms/space you need. 2. Written specs help you and others talk about the part of software you are writing. Imagine I would ask you to tell me what your Archive Module is supposed to do and what it will look like. Instead of writing lengthy emails you could just point to the specs - which might even save you time. Since your Archive Module will be used in the context of GnuMed, it will help others to understand better which functionality will provided by your module. This will especially help newbies that still do not know how the modules relate to each other. 3. It helps you defining what state you have reached, what will be the next steps and future plans. Instead of everybody having his own ToDo-List, you can add you on requiremenrts, ideas and request by others to your specs. > We are no company. Show me one successful project which has detailed specs > out. If people that have to earn money by writing software use specs they can't be so bad an idea to increase efficiency of software creation. The level of detail you use should be adapted to the needs and available ressources of the project team. GnuMed will probably not need an industry-strength development process. But writing specs for a module you can develop on your own shouldn't take much more than one our (given you really knwon what you want). Discussing it may take some time if there are others involved, but specs help a lot once they are finished. > > I'm sure Karsten knows exactly how he wants to build > > GnuMed (as knows Ian, as knows Richard, ...), however, I believe we would > > be able to get more collaborators if we could only show a well-thought plan > > what milestones we want to achieve next. > Don't be disappointed about what I am going to say now. You are wrong. I once > thought like you. One day I stopped. Right or Wrong. That's what happened. > There is no magical vision for GNUmed as far as *I know* IMHO there is a vision (see above). Something you can put in two-three phrases. I'm sure Karsten can tell us his vision instantly. Maybe there is no detailed roadmap (another point that can be get easier to define once you have specs at least for some further milestones). > For Germany GNUmed will be code plugin by plugin. Order of completion > depending entirely on what code is there already plus real use cases > 0.1 - structured medical documentation > 0.2 - GNUmed Archive - getting paper into digital form > 0.3 - lab module - Jim's use case. > > See a pattern here ? I don't see a problem if modules are done one by another. Just that I would like to see specs for every module that gets coded. > For Australia it has been pointed out that GNUmed is all or nothing which is > not coding to happen with German coders. We will *support* efforts made by > Australian doctors best we can *but* not more. So if you have to accomodate different needs it's even better to have specs ready. After all, you better talk before everything is ready if GnuMed-DE should have something in common with GnuMed-AU (or GnuMed-CA,...). > > I therefore suggest that at least some energy should be spent in > > documenting and discussing our plans for the nearer future. > I once had that dream as well. Karsten never talked me out of it. But he > showed me that his way of doing things led to more usable results. I am > converted. I still have that dream. Maybe I can help *you* start. Karsten's way of doing things is a hard one. Basically because there was nobody else colloborating he decided to do it his way and implements what he needs most. Which is ok if you want to continue alone. But every day without Karsten sharing his ideas (say, specs) with the rest of the world there is less a chance to get other people to work on GnuMed. Even if you reach a revision where basic things work for Germany you can't expect others to join the project if you can't tell them how GnuMed works and what is the idea behind it. Karsten, I'm not criticizing you here, I know you are willing to share your knowledge if only somebody else cares to write it down. I already offered to start working on specs some time ago. I'm still willing to do so, as far as my limited spare time allows. Hilmar -- _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
