Hi I have summarised the decision as a comment on the Proposal handling tracker item (https://tracker.physiomeproject.org/show_bug.cgi?id=347)
This currently only applies for the CellML specification work. Regards, Randall > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:cellml-discussion- > [EMAIL PROTECTED] On Behalf Of Andrew Miller > Sent: Wednesday, 5 March 2008 3:11 p.m. > To: CellML Discussion List > Subject: Re: [cellml-discussion] Call for community input: final > decisions on anumber of specification related issues > > David Nickerson wrote: > > Hi Andrew, > > > > While I agree that the listed proposals all seem to have reached > > consensus and that final decisions need to be made in order for the > > development of CellML 1.2 to progress, this seems a rather arbitrary > > manner in which to be declaring the proposal handling method. > > Especially > > as the discussion actually dealing with the handling of proposals > > (tracker item 347) has yet to come close to an agreed upon method for > > dealing with this issue. > > > Hi Andre, > > I think this creates a bit of a 'catch-22' situation because we need a > decision process to decide on a decision process. I think that until we > have such a process, we need to stick to the status quo, which has > generally been that we discuss things with the community, and if there > is disagreement, then a smaller group of people make the decision (I > personally would prefer a more formalised voting based system with a > fairly large number of eligible voters, but both Poul and Peter seem to > favour a system where we define a fairly small set of people from a > range of different groups who can vote, and only use this mechanism to > make a decision when the community has discussed an issue and not > reached agreement). > > > I would suggest that the proposed method for handling decisions on > > proposals contained in this email should be added to the discussion > of > > tracker item 347 where we can debate its merits and be assured that > > community members outside the Auckland meeting can have some input > into > > this process > > I think that this has already happened on tracker item 347 (and in the > past, on the mailing list). > > > and hence achieve some consensus on the handling of > > proposals before deadlines are set on the actual proposal decisions. > > > > Just to note in advance of the expected discussion, we have > previously > > decided against using such a "passive" decision making process back > in > > the early days of the CellML project. > > > I think that for a project with a large number of people involved, most > people don't care about most issues, and because not everyone in the > community is going to want to put in effort for every issue, once > everyone has had a fair opportunity to respond to a proposal, we only > really want to delay resolution if there is an explicit objection. > > Just to clarify, are you objecting to all or any of the deadlines (on > any of the specific issues listed below) or are you happy with the > actual tracker items (as opposed to the decision-making process)? We > obviously don't want to retrospectively decide that decisions we > thought > were made actually weren't made because the process was wrong. I think > that even if the process needs improvement, if there are no objections > to making the decisions themselves, we could still use the process as > an > interim measure. As Randall pointed out at today's CellML meeting, the > process only really matters for the issues where there is no consensus, > and so we can actually still use the easy 'is there unanimous > agreement' > part of the process without defining the harder 'what do we do if we > don't have unanimous agreement' part yet. > > Best regards, > Andrew > > > > > David. > > > > > > > > Andrew Miller wrote: > > > >> Hi all, > >> > >> There are a number of items in the CellML tracker regarding > decisions > >> about the next version of the CellML specification, which have been > >> discussed in the past and around which consensus seems to have been > >> reached, but on which we have yet to declare a final decision. By > making > >> a final decision as a community on a set of questions, further > important > >> questions about what will be in the specification can be more easily > >> discussed (without having to consider the interaction with every > >> possible other decision that is still open). > >> > >> There has recently been some discussion over the best process to > make > >> decisions on specification related proposals. Although the exact > details > >> of the process still has to be worked out, there was agreement (at > least > >> amongst people in Auckland) that we should make decisions by > unanimous > >> agreement where possible, and only fall back onto some other process > >> where this has been shown not to be possible. The process for > >> determining such unanimous agreement seems to be to that the issue > is > >> proposed, discussion on the proposal takes place, and when this > >> discussion dies down and there is an apparent consensus, community > input > >> is sought, and a deadline (sufficiently far in the future) for > >> objections is provided. In the event that no objections are raised > by > >> the expiry of the deadline, the decision has been made. Objections > could > >> relate to the substance of the proposal, or simply be to request > more > >> time for the decision to be made. > >> > >> So that the list of decisions I identified can be made, I have set a > >> deadline of one week from now, that is, Wednesday March the 12th, at > >> 00:00:00 GMT (which is March 12th, 1:00 pm in NZDT). If you feel > that > >> this is not enough time, please make a note of this on the tracker > item, > >> including when you think the deadline should be, before the expiry > of > >> the March 12th deadline, so that the decision won't be made without > your > >> input. > >> > >> The list of tracker items with my summary of them follows. If you > are > >> interested in discussion on these issues, please add yourself to the > CC > >> list for the individual tracker item concerned (you will need to > create > >> an account on the tracker if you don't have one already, but this is > a > >> process which anyone can do). > >> > >> Tracker item 312 > >> (https://tracker.physiomeproject.org/show_bug.cgi?id=312) - proposal > is > >> that in the spec, we call individual CellML 'files' CellML Infosets, > and > >> we call all the files together 'CellML Models'. > >> Tracker item 319 > >> (https://tracker.physiomeproject.org/show_bug.cgi?id=319) - Proposal > is > >> that names like _1a be treated as valid CellML identifiers (fixes a > >> conflict in CellML 1.1) > >> Tracker item 167 > >> (https://tracker.physiomeproject.org/show_bug.cgi?id=167) - Proposal > is > >> that imports create an instance of a model, and so it is invalid to > >> import the same component twice in a single import element. > >> Tracker item 193 > >> (https://tracker.physiomeproject.org/show_bug.cgi?id=193) - Proposal > >> about when we change namespaces on elements and when we keep the > >> namespace from the previous version. > >> Tracker item 331 > >> (https://tracker.physiomeproject.org/show_bug.cgi?id=331) - Proposal > is > >> that RDF/XML inside extension elements should only contain extension > >> specific metadata. > >> Tracker item 332 > >> (https://tracker.physiomeproject.org/show_bug.cgi?id=332) - Proposal > is > >> that we should allow references to secondary specifications which > narrow > >> down CellML to a specific type of problem (resolves issues relating > to > >> the CellML Subset in CellML 1.1 and the fact that the core CellML is > too > >> general to be fully implemented). > >> Tracker item 56 > (https://tracker.physiomeproject.org/show_bug.cgi?id=56) > >> - That we consider the issues arising from the CellML subset > resolved > >> (conditional on tracker item 332) > >> Tracker item 84 > (https://tracker.physiomeproject.org/show_bug.cgi?id=84) > >> - Proposal for a standardised real number format using a decimal > point > >> (as opposed to a decimal comma or decimal momayez). > >> > >> I haven't included tracker item 337, about removing directionality > from > >> connections, because discussion on it seems to have stagnated > without > >> reaching agreement on the details of the best approach. > >> > >> Best regards, > >> Andrew > >> > >> _______________________________________________ > >> cellml-discussion mailing list > >> [email protected] > >> http://www.cellml.org/mailman/listinfo/cellml-discussion > >> > > > > > > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
