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.
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 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. 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 -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
