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
