Proposed Principles and Definitions for the Soar Consortium
June 8, 2004
The purpose of this document is to present a set of definitions and principles that will guide a consortium in managing the continued open source development of Soar. The explicit understanding is that whenever there are decision points in the procedures, the principles will be used to direct the evaluations of alternative choices.
Definitions
Consortium: Refers to the Soar Consortium throughout the document
Consortium Review Process: Refers to the process for approval and integration of proposed SKS changes.
Soar Consortium: All organizations and individuals that have agreed to actively participate in the Soar project and abide by its rules.
Soar Kernel Suite (SKS) consists of:
· Soar Kernel: The Soar Kernel consists of all of the code that was part of the Soar 8.3 release and any changes made by Soar Technology to that code for any purposes, including the integration of gSKI. Any changes made to the Soar Kernel code base will continue to be considered part of the Soar Kernel.
· gSKI: A generic Soar Kernel Interface consisting of an interface design together with implementations in C++ and other languages for accessing the Soar Kernel, originally developed by Soar Technology.
Soar Project: The SKS and all Soar community members that have registered to use and maintain the SKS. At the time of writing this consists of Soar project Sourceforge members.
Consortium Principles
1. Openess: The SKS will be distributed using the BSD license.
2. Code Quality: All changes to the kernel will be thoroughly reviewed and tested according to consortium review process.
- Correctness: Analysis and tests must show that integration code executes the given design and that no undesirable side-effects occur.
- Robustness: Analysis and tests must show that the integration code executes correctly in a broad range of conditions, including error conditions.
c. Maintainability: Analysis must show that the integration code is implemented in such a way that it is readily understandable to another trained programmer and that modifications and improvements can be made without excessive effort.
3. Increase User Base: The consortium will have as an explicit goal increasing the user base for Soar. As part of the effort to achieve this goal, changes to the SKS will be evaluated along the following dimensions:
- Usability: The consortium will prefer changes that improve the usability of Soar to those that do not affect or reduce the usability of Soar. “Usability” includes system integration, architecture coding and development, Soar coding and development, and Soar model use.
b. Learnability: The consortium will prefer changes that make Soar easier to learn to those that do not affect or reduce the learnability of Soar. The emphasis on learnability will be placed mainly on Soar coding and development, but it also includes learning system integration, as well as learning architecture coding and development, and learning how to use Soar models.
4. Shared Contributions: Consortium members are expected to submit any significant SKS changes they make to the consortium. Whether or not these changes are actually integrated will be decided using the consortium review process.
5. Inclusive: All good faith proposals to change the SKS will be considered for acceptance by the consortium. However, before acceptance and integration, any change must pass the consortium review process.
6. Compatibility: New releases of Soar will minimize changes in existing applications that depend on SKS.
7. Timeliness: Changes to the SKS will be considered and reviewed in a timely manner. The exact time frame for the review process may be set by the consortium as it sees fit; however, bug fixes in particular will receive high priority for approval and integration.
8. Respect for Research and Commercial Needs: The needs of both academic research and commercial development will be respected and supported.