Thanx for the answer I was looking for :) > > > > > this plan is under modification right now actually, and some details > will change. We will also publish a simple, clear set of web pages so > that people can understand what the process is. The ASF page seems like > a good model.
I can remove the apache stuff from the page and attach that file to jira, if you want. > > >Describing how something should work (related to a community, in this > >case an open source community), must, in my view be kept simple. > >If you skim through the document (what I did in the first place, since > >there was a lot of text), people like me (= who likes to program and > >never RTFM, unless really necessary) get scared and draw wrong > >conclusions. > > > >Too much formality is scary (at least for people like me) :) > > > >Hope no one (esp. Thomas) feels offended, since it is not meant that > >way. (I admire the way you guys can write specs, if people ask me where > >my specs are "Read the code" will be my answer). > > > > > ah, well, you will discover there are limitations to that approach in > the long run (as I am sure you are aware;-) Don't totally agree here (depends on the area you are talking about). You can probably define 2 set of rules : 1) The meritocracy (as described in the how it all works document) 2) Legal issues 1 almost never fails, although there are scenarios that it does (eg Apache Avalon, but that was mainly clashing ego's and different views on architecture). The main reason this not failing, is the principle : if you veto a decision, you have to explain why, if you don't the veto is void. A veto can happen for votes and for eg commits (commit mails are important at apache, also for being able to have the necessary oversight, hope bitkeeper supports that) Also the main reason everything works "automatically" is that most people have common sense and there is huge degree of trust amongst each other (you have to assume no one is there to mess up everything on purpose) Eg The Episode discussion (assuming I have the proper access to change the specs), I could (technically) simply add the Episode stuff the way I see fit. Since I know you and others now way more about all those stuff, I will automatically discuss this first, before making the change. If I have the attitude "I know it all and I know it better, even though I don't" I will not last long in a community and move away automatically. Most difficult and not to be underestimated is 2, but that is probably for another thread :) If you are interested I can put down some things that are needed, so openehr.org keeps the owner ship of the source code. What is the license you want to use for openehr deliverables (meaning the code) ? > The openEHR community may > well get quite large, and we do need to write good quality documents. > But we are also dedicated to making things simple and understandable as > well - this doesn't mean throwing out our base documents That's why I changed my opinion from removing those chapters to referring to them from the simpler page :) > , it means > writing short & shart summaries on the website. We need people in the > community to tell us what to write (and offer to write things themselves > if so motivated), so this is good feedback. That's the "send a patch" spirit, which is good :) -- Mvgr, Martin - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
