Forums

The SBML Development Process includes a step of voting on Level 3 package proposals. In order that *all* package proposals be treated equally and fairly, we have been implementing a round of voting on all Level 3 package proposals, including those that predated the new development guidelines. The goal of each vote is to reach consensus on whether the SBML community believes (a) the need addressed by each proposed package is something that should be addressed by SBML, and (b) whether the general approach proposed by each package proposal is appropriate and desirable.

The present vote concerns one package proposal:
* Spatial Processes

Please use the following voting page to cast your vote:

http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/Surveys/Level_3_Package_Proposal_Vote:_Spatial

The voting closes Dec 1, 2011.

The structure of the voting page now reflects recent discussions about how to improve the voting process overall (see http://sbml.org/Forums/index.php?t=tree&goto=7063&rid=2 ). In particular, the voting page now asks for you to assess the proposal on several dimensions, based on principles the SBML Editors believe should apply to package proposals. This group of principles concerns the purpose and general orientation of a package:

1. Utility: A package must concern itself with a subject or problem area that enough SBML users find useful to sustain interest in the package.

2. Biological orientation: The overall aim of a package must be to support the description of biological processes and phenomena. (However, this does not preclude supporting the description of other phenomena, if doing so serves the overall aim.)

3. Coherence: A package must extend SBML in a way that follows naturally from Level 3 Core and other packages, reusing concepts as appropriate and integrating new concepts into the existing frameworks in a reasonably natural manner.

4. Orthogonality: As a general goal, SBML Level 3 and all its packages must strive to encode every given concept only once. Data and concepts should not be duplicated in multiple components or packages, except in extenuating circumstances or when a package is intentionally proposed as a replacement for another package.

If the developer(s) of a given package believe(s) that the package should not or cannot follow one or more of these principles, they must provide a compelling argument for their case.

Thanks,
On behalf of the SBML Editors
____________________________________________________________
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