Forums

This has been a useful discussion, and IMHO the sort that we need to have more often. It went beyond what Nicolas originally meant to raise, but that's okay because it brought to light all sorts of issues. The SBML community has always made progress by hammering out consensus, which requires informed discussions.

My analysis of the situation so far is that the following problems exist; I further propose approaches (indicated by numbered paragraphs) to resolve each one.

Process problems
----------------

The voting on each proposal was supposed to encompass a proposed approach, not merely the idea for a package. The description of the proposed approach was not intended to be very heavy (addressing Chris Myers' concern about having to spend too much effort), though it was intended to be more than a hand-wave (addressing Sven and Pedro's points). However, the required degree of detail is not clarified in the SBML Development Process description, nor was it adequately discussed in explanations leading up to the votes. This has lead to misunderstandings about what is sufficient, even (embarrassingly) among the SBML Editors. Further, the Chair of the SBML Editors (me, more embarrassingly still) failed to detect and correct the inconsistencies prior to putting things up for a vote.

Separately, the fact that more people voted 'accept' than 'revise' on the "dyn" proposal can probably be understood in one or more of the following ways: (i) some people may like the idea of a given proposal and not *care* about the details; (ii) some people may not feel comfortable with the details of a given proposal and opt to vote 'accept' rather than 'revise' or 'reject', because in the voting form, the latter two options request an explanation and people may not feel comfortable stating one; (iii) some people may not have realized they could abstain from a vote because it was never mentioned as an option, so they felt they had to pick *something*, and they picked 'accept' because of the commonplace human behavior of giving other people the benefit of a doubt.

This leads me to suggest the following.

1) The SBML process definition needs to be amended to stipulate the minimum requirements for a package proposal, preferably via a concrete checklist of criteria that need to be satisfied, so that everyone (editors, community, voters) can ascertain whether a proposal has reached a stage of being votable.

2) The voting form needs an explicit "abstain" option, so that people do not feel they have to vote on every single proposal when they are faced with a page of proposals to vote on.

3) Voting on a proposal needs to be changed to being only about the proposed *approach*, not the idea of having a package for a given purpose. The goal of this proposed change is to reduce the risk that people vote to accept an idea alone, ignoring the proposed approach (or lack thereof) because they find the *idea* desirable and don't care or don't understand the details. By the time it reaches a vote, the question of whether it's a worthwhile idea is almost certainly going to be settled. (And to reiterate, this is about the proposed approach, *not a specification*, so it is still not going to involve the amount of work required to produce a draft specification.)


The status table on http://sbml.org/Community/Wiki
---------------------------------------------------

The status indicators on http://sbml.org/Community/Wiki was intended to mirror the stages of proposal development & voting. Nicolas points out that this leads to inconsistencies in at least two cases where the voting indicated acceptance but the proposal is not at the presumed stage of development. I believe the problem is rooted in the assumption of linear stages from proposal, to voting, to acceptance, to development of specification, etc.

4) I propose that the simplest and clearest solution would be to decouple the indicators for proposal/specification/etc status on the one hand, and voting on the other hand. This would be done by adding a new separate column in the table for the voting process. The existing status indicators would be reduced to a smaller set and used to indicate the status of the development of the effort.


The results of the voting on 'dyn'
----------------------------------

It is unfortunate we didn't catch the problem sooner, but now that the "dyn" voting has concluded, we have IMHO two options: (a) rescind the vote and put "dyn" to a vote again at a later time, after someone fleshes out a proposed approach, so that we treat all SBML package proposals as equally as we can; (b) keep the result anyway and move on.

5) We need to decide what to do. Although you will all cringe at the thought of another vote, my feeling is that the only fair way to reach consensus on a course of action now is to hold a quick vote on exactly this issue, for the two options (a-b) above. A few vocal people have made their positions clear in the discussions of the last few days, but many other people haven't said anything. If we were at an SBML meeting, we would hold a hands-up vote at this point, but we're some months away from the next meeting, and we need a resolution sooner because it may affect how other packages are put to a vote in the meantime.


I'm very interested to hear the replies to all this ;-).
MH
____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu