Hi Pablo
If the structure and licensing proposals are generally acceptable to the community then the next step will be to agree the Associate Fee structure and the qualified Members within each group (including possibly a Localisation/Translation group). How would you like to see us determine the qualification of Members to bootstrap the effort. The alternatives are: 1. Seek nominations from the list and then have a poll to see who are seen as the best candidates - take the top 'n'. (Democratic) 2. Seek nominations from the list, have a poll and seek 'n' of the candidates that provide the best mix of skills. (Mix of democratic and merit) 3. Seek nominations from the list, take the three best candidates and ask them to form a team from the rest. (Predominantly peer merit) According to our current proposal, the group would then nominate a leader and seek approval from the Board. We would then have our Program groups. The new direction is focussed on providing quality outputs efficiently - with Members working as individuals and being promoted by peers. From then on, the Program group would enlist and promote members, seeking direction and support from the Board. Funding for work would come either directly to team members (in kind) or through the Foundation. Another key element is to have an annual conference. I would suggest that this should be in Europe as that is our origin. We will need a location and sponsors. Cheers, Sam From: [email protected] [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Friday, 9 September 2011 2:48 AM To: openehr clinical Subject: RE: openEHR Transition: Community Knowledge repository Hi Ian, > I think we do have very good versioning / revisioning rules and CKM > has implemented these within its comparator function when we upload a > modified archetype. > What I meant was that: if we, in the future, have several CKMs around the world, maybe forming a hierarchy or not, we need a clear specification of the versioning rules for this distributed CKM. I don't know for sure if the versioning issue is solved or not, or if it's solved only at the CMK or if it's part of the specifications. What we need is the latter. Not so long ago there was a very interesting discussion about that: http://www.openehr.org/mailarchives/openehr-technical/msg05797.html > There is active work exploring how to tighten up the governance > issues, especially around namespaces but I think we are pretty close > to having this worked out. > I would love to see that. Can you point me to some information or discussions about those issues? > Once you consider the potential dependencies of templates, archetypes, > specialisations and termsets, there are some interesting challenges > ahead in understanding how best to keep good blend of agile > development and the kind of stability that vendors and other projects > will require. > Is this a closed discussion? I would like to help. > I think Release Sets will play an important part here by giving > different projects a fixed, coherent set of artefacts to work with, > even as the leading-edge development moves on. I think it is much more > likely that connections between repositories will be through Release > Sets than by full 'current' access. We are starting to look at this > issue of 'federation' in CKM but current thinking is that a simple > view of, or reference to, assets in another repository is really not > going to help real development very much. The key issue is how to > request and acheive change in a non-native artefact, and how to handle > the inevitable mismatch in development cycles between native and > non-native artefacts. > The Release Set is a nice idea. but I think CKMs should support individual artefact commits also. > Although the Ocean CKM is a pretty unique product for now, I am sure > alternatives, quite possibly open source, will emerge but as David > Ingram suggested this kind of functionality is complex and will take > time to develop. > Yep, it would take time, but is necessary if we want worldwide impact. Maybe is not only necessary, but strategic. > I would be much more interested in starting with a light-weight > community repository tool, without the burden of tight governance > requirements of a CKM-like application. I think this can get started > with relatively low development requirements based around Derek's > Snowcloud template tool. > We (the Open EHR Gen team) have developed very basic service oriented repository, a simple web oriented template editor that communicates with the reposiotry to load archetypes and templates, and save templates. It would be nice to try other groups tools and see how we can join efforts. regards, Pablo. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110909/9982cf70/attachment.html>
