A. Boundaries:
What constitutes SAIL deliverable?
Need to keep the "lowest common denominator" as the thing we offer as open source - so that we don't push our embellishments, elaborations, etc into the open. We want the open source community to be really able to support and sustain the LCD
B. What are the SAIL/PAS technologies?
1. SAIL microportal
- Cohorts/collaborations?
- Needs to be supportive of expansion
- Needs to support portlets
2. SAIL CORE
- categories/ontologies where we can anticipate growth:
o collaboration/groups
o peer-to-peer
o discovery/networks
o content repository
3. Repository
- could use Sourceforge repository.
- Maven
4. "Researcher PAC"
- How to support open source community, vs.
- Slotta will coordinate development of Researcher Pac.
o Person will come to Berkeley, meet.
o Go to Boston, meet.
o Aim for delivery of SAIL PRP 1.0 by early 07.
C. Who is involved?
1. UCWISE
2. Toronto
3. TELS
4. Concord (outside of TELS)
5. Munich
6. Twente
7.
D. How do we get others involved?
- get people involved with other grant proposals
- SAIL researcher pac
- Workshops in the future to
E. Governance:
What needs to be "governed" by governance?
What are our models?
- Eclipse may be the best model
- Maven has been serving well enough for software organizing. Can add governance
- Could have bicameral:
1. "per project" (TELS, Concord), or "per portal" (Toronto, Berkeley, Boston, Munich)
2. per user (those with "commit authority/access"
H4. Q: How do we decide who gets commit access?
- Unanimous agreement of those with commit access in order to give access
- To apply, a person needs:
1. Some track record in getting patches through someone else who had commit access,
2. A good rationale for why they should get access, and
3. a statement about how they will serve the SAIL community.
- We should write a short statement about the social commitments. etc
- SAIL project administrators grant the actual commit access.