...
- Provide the highest quality OpenRegistry project possible for the benefit of higher education
- Ensure that robust technical choices are made in the context of a meritocracy-based, open source development process
- Build a world-wide OpenRegistry development community with diverse representation and open communication
- Ensure that developers are able to participate on the project to the fullest extent that they are willing and capable
- Do nothing to compromise Rutgers' Rutgers’ ability to proceed unimpeded on their production-driven local implementation
- Permit multi-school development to continue during this time, with full participation and/or input from Rutgers, to their fullest extent, while working towards their production deadlines.
...
- We will come to agreement on a full list of functions/components for OpenRegistry and post them on the wiki. Initially, each institution will contribute their expectations (Jeremy and Omer)
- We need to settle on the best approach for the UI and a skinning framework. SFU will take a first cut at making a proposal. (Jeremy)
- Project decisions need to be made on the -dev list, by committers, following discussion on the list. Jonathan will aggregate Jasig and Apache conventions for handling this and will post to the list (Jonathan)
- We need to decide how best to configure trunk and branches considering that both teams need to be active in trunk. This will be an on-going discussion on the list (All)
- Non-code-based actions that impact the project (e.g., version numbering, demo videos, marketing, etc.) need to be discussed among the teams before they are put into effect. (All)