Palo Alto Board Minutes - April 28-29, 2005
This is a "combined" document, containing all the notes from the Palo Alto Board Meeting that Lois and Joseph took on Wed, April 28th and Friday, April 29th, 2005, and the Notes sent to the all-hands list the 28th.
Corrections, suggestions should be sent to Joseph and Mary M.
Board Notes from April 28, 2005 (these were sent out to the 'all-hands' list April 28)
Open for comment and discussion
Current legal directions in the Sakai Project -
Licensing - a comprehensive review of the licenses that are part of the Sakai distribution has been initiated with help from Ithaka. Ithaka is a Mellon, Hewlett etc- funded not-for-profit organization "with a mission to accelerate the productive uses of information technologies for the benefit of higher education around the world." This license review will be similar to the one done by r-smart staff for the OSPI project (see enclosed docs, which are not for general distribution). A strategy that covers how we legally evaluate new code for inclusion into the Sakai distribution was also done by the OSPI organization and the board would like to ask everyone to review it for adoption by the Sakai project. It looks good to us.
Incorporation - the board is interested in forming a legal organization (a "Sakai Foundation") to generally carry on the business of the Sakai Project by, among other things, providing liability protection for contributors, accepting contributions, negotiating with commercial affiliates and entities, contracting with staff and others, etc.
We are looking at 3 possibilities: forming a legal entity under the wing of a university; forming an independent USA not-for-profit corporation; forming a not-for-profit corporation outside the USA.
Collaboration and Learning Environment Direction -
The Board reaffirms the fact that the Sakai Project is dedicated to building a Collaboration and Learning Environment and this should be part of the design and development as the kernel, common APIs and tools are designed and implemented. It is particularly important to ensure that immediate priorities in matching the essential functionality of commonly used Leaning Management Systems do not prevent the use of the Sakai CLE for other uses such as Research, and Social and Administrative Collaboration. The ability to support research, in addition to learning, collaboration, ensures that the Sakai CLE can meet the broadest possible requirements of the broadest possible number of institutions, including those in minorities not served well by current vendors and products. In the medium term, by developing along a path which points to convergence with that of the eScience and eResearch communities, the Sakai Framework will provide access to a range of tool transferability and re-use. This is of significant benefit to both communities, in both enriching available tools and reducing the waste of duplicated development.
Evolving Sakai Board Composition
The Board should optimally be composed of 10 -12 members, with 3-4 Board members rotating out each year. By January 1, 2006, current Board member retirements would leave 7 or 8 existing members. The Board identified and agreed to invite at least one further member to join immediately. This would produce a Board membership of 8 or 9 on January 1, 2006. The Board will elaborate a means of filling the remaining 4 places by the Summer Conference. We would like nominations to come from the Sakai Community, including the SEPP and the SCA, as well as the Board. We do not envision any seats dedicated to R1 schools, or any other constituency.
There was considerable interest expressed at the Sakai publishers' meeting by at least two of the publishers concerning joining the Sakai Commercial Affiliates. The Board decided that we would invite them as SCA members and not form another organization specifically for publishers. SCA membership is $10,000 a year for all new members (existing will be grand-fathered in under arrangements TBD). A document is under construction that will describe what we expect of the applying SCA members and an agreement for them to sign describing rights and obligations (e.g., with respect to use of Sakai name and logo) will also be constructed. The current practice of having prospective SCA affiliates describe to us in a document of their creation what they would contribute to the Sakai Community will continue to be a part of this process.
Sakai: Organizational Practices - Resource Development
The Sakai project was initiated by a small group of institutions in order to integrate and synchronize their software development efforts and create a Collaboration & Learning Environment (CLE), a pre-integrated collection of modular open source tools including collaboration, course management system and research tools, with portal capability, built to a framework that would allow usage of interoperable tools. It was clear that in order to do this within a time frame of less than two years, the core institutions had to commit to the project in very tangible terms. This manifested itself in two ways:
¿ the core institutions committed to implementing the course management system at their own institutions, and,
¿ each of them committed FTEs for the duration of the project where the FTEs committed would be under the guidance of the Sakai Project Board.
From our experience over the past year and a half, it is clear that Sakai will continue to need commitments from its community, including donation of FTEs to work under the direction of the Board, but that there will be many other ways for contributions to be made. The Board will look to the following ways to develop resources and acquire contributions:
¿ Tools developed by Sakai WGs
¿ FTEs committed by members of the Sakai Board
¿ FTEs committed by Sakai community members
¿ Donated software, whether open source or otherwise
¿ SCA staff time
¿ Grants from foundations and other bodies
¿ Soliciting the community at large
¿ Paid development
This does not preclude other options that the Sakai Board and community may come up with in the future.
Enterprise Bundle (EB) - Selection Process Discussion
Items discussed in regard to a selection process for inclusion into the Sakai distribution, the Enterprise Bundle, include:
o Establish a process that provides development teams with guidance on UI, usability, and other compliance issues in the early stages of development, especially if tools are desired to be included in the EB.
o Identify/appoint core individuals who will review and sign off new tools to be included in the EB - and/or recommend fixes. Reviewers may include the chief architect, UI designer, accessibility expert, and others (TBD) who will verify that the tools meet the established standards.
o Support tool developers with pre-release tasks for the inclusion of the tool in the EB.
o Establish a process that checks the usability of new tools as part of the release process of EB.
o Develop a process for deciding whether a tool meets a gap, ie, provides new functionality, as part of the EB inclusion process.
o Evaluate new tools to determine whether there is overlap with existing tools in the EB, and recommending integration methods.
o Establish a check-off list of requirements or compliance items that must be met if a tool is to be considered for inclusion in the EB.
Concerns raised include:
o A rigid process may place too many barriers and hurdles on projects and exclude good tools.
o At what level/percentage of compliance to check-list does a tool have to be to be included? What is good enough? (based on the understanding that developing tools is an evolutionary process.)
1. Issues arising from the planning process so far:
i. Many more requests for conference slots than time available.
ii. Questionable effectiveness of demo room in New Orleans? Distractions from demonstrations problematic but time for questions and contact very useful. Examine potential for fixing this by providing demonstration and discussion rooms
iii. Projections running at around estimated 325 attendees
i. Track on deployment, "How to Sakai" from production point of view
ii. Track on deployment, "How to Sakai" from developers point of view
iii. Tools track of expanded demos to accompany wine and demo session
iv. Small room of 20-30 where ad hoc presentations could be held.
v. Possibility to end the conference before lunch. Have a separate session on the last day (over lunch) with board and DG/WG leads (invitation) at the end of the conference to debrief, connect.
3. Pending work:
i. C Level session: no movement as yet. To be developed. Will be run by Joseph and/or Brad. Time slot set. New Orleans Conference a wide range of participants (both strategic and tactical). Need to focus the session more, but almost universal approval from previous conference.
ii. Senior level approval within JISC for a brief, focused presentation of work of JISC, which will emphasize growing connections. Ian D will present for the JISC.
4. Question about Friday afternoon: should there be another session for local colleges who aren't in Sakai, not attending the Sakai meeting?
i. Jim will contact academic officers to ask if they are interested in a session.
5. Note: make sure JISC presentation is on the conference agenda.
6. Note to board: to support the Conference Chairs, it may be necessary to increase frequency of board phone calls between now and the event.
Sakai Staff Needs
As an open source and institution-independent organization, Sakai will need to support, maintain, manage and develop both the product and the community.
The general organizational functions that will need to be supported are as follows:
¿ The board (oversight and direction)
o Product definition (requirements)
o User Interaction Design (Interface, usability, accessibility)
o Release and QA
o Project management
¿ Sakai Community Support
o Communications and collaboration support
o Community collaboration systems support
¿ Documentation distribution and management
¿ Collaboration tools
o SCA and Vendor support
o Tech support and Training
¿ Project Support
Following is a list of the roles that the board has recognized as important for the success of the organization, some of which are currently filled by board institution resources and some not. An asterisk next to a role indicates a leadership role that should be the highest priority positions supported by SEPP funds. They are briefly described in the section following the list. The other roles might be solicited through a variety of ways (discussed elsewhere in this document).
¿ * Product lead
¿ * User Interaction designer
¿ Requirements manager
¿ Systems Administration (community collaboration tool support)
¿ * Architecture lead (Commit Manager?)
¿ Tech Support
¿ Sakai Community Communications manager
¿ SCA/Vender manager
¿ * QA/Release manager
¿ Documentation Manager
¿ Events Coordinator
¿ Financial Management
¿ Project Manager
Sakai Product Lead
This position needs to oversee Architecture, QA/Release, and UI managers. They are responsible for the translation of user functional requirements into technical specifications and deliverables. Working with the managers they will define each product release from a technical and a functional perspective.
Sakai User Interaction Design Manager
The UID Manager defines and oversees the Sakai enterprise bundle usability/accessibility/interface guidelines. They are responsible for ensuring a usable and accessible product. This role will create and manage documentation and guidelines from a UID perspective for Sakai development projects to utilize. It will review tools submitted or solicited to for enterprise inclusion.
Sakai Architecture Manager
This role oversees the Sakai Architecture direction and technology decisions. It manages all commits to the Sakai Enterprise CVS, and solicits and managers Sakai development resources (committed from the Sakai community) to deliver architectural changes.
Sakai Community Communications Manager
The Sakai organization needs to support the events, activities, and collaborations that occur in the project and community, and needs a committed leader to make this happen. This role will define and oversee the Sakai website and other collaboration tools that are needed to support the project, working with a set of Sakai support staff to make it happen.
Sakai QA/Release Manager
The QA/Release Manager managers the QA and release process for each enterprise release. Coordinating Sakai volunteers, they will work with distributed development teams to complete QA on the tool and integration levels.
The Project Manager will coordinate all development task for each release. They will work to ensure that all enterprise subprojects have adequate resources, defined deliverables and milestones, and keep the board and teams appraised of risks or slippage.
Sakai Board Meeting - Thursday Morning - Lois Brooks scribing
April 28, 2005
(snip - JH)
a. Vote: One SCA program with wider participation (not a number of specialized programs). Have a document that describes kinds of contributions they will give to the program. Charge them 10K. Carried 6-0. We have a decision.
b. Action item: Babi and Brad will draft document
c. Action item: We need to make a connection with Moodle. We do this as opportunities arise in our various other forums, as opposed to getting a formal meeting together between projects.
d. Discussion items:
i. One SCA for any non-higher education partners or separate programs?
ii. What was Brad's original purpose? To have support partners. Moodle has commitments from their partners for 5% return of revenue. Moodle is now considering a SEPP-like organization.
iii. What level of support/handholding do the partners need? How is that accomplished? Not just handhold one organization in one effort. Need to make this a program. What can we do to assure that affiliates are up to speed?
iv. Branding; Logo'ed Sakai affiliate.
v. Who are the communities?
i. need to be more proactive in this area.
ii. Need to consider charging them more money.
iii. Balance of good support for a CLE vs. extending to support for wider collaboration.
f. Argument in favor of wider SCA: Opportunities for collaborating. It's good to mix different kinds of vendors. Okay to target invitations to meetings based on discussions.
g. Argument for flexibility: Moodle has a certification process; a way to have a branded community. We don't have time or resources to vet and approve services. Need to be more flexible.
8. Notes from the publisher's meeting
i. People are waiting for 2.0.
b. Discussion items:
i. Does this just become another cartridge spec in the suite of others? Or, does it provide a way to leverage better support into the CMS world in general?
ii. Sakai offers a viable platform for real use of an extended reference spec (is this best done as an SCA effort?)
iii. Ray Henderson, Pearson, is cranking up an IMS group (he's on the board) that has a reference implementation as an outcome.
iv. IMS is not the only standards body around; should not limit ourselves
9. IMS discussion
a. Discussion items:
i. Relative values of IMS participation.
ii. IMS not clear on cognizance of open source implications
iii. Visibility of internal workings, e.g., standards in development
iv. OASIS: an example of an open group that works well
i. We set our own agenda and use IMS when appropriate, e.g., with the publishers.
10. Course evaluations
i. There are many teams building tools. How are they supported?
ii. Unrelated to above; there are many people who are interested in learning design
b. Discussion items:
i. Process for functional spec
ii. Who will code?
iii. Who will lead?
iv. Timing - no sooner than June
c. Question: do we proceed on an ad hoc basis?
11. Random ideas
a. Need to noodle on the idea of SEPP scholarships
i. Adopt strategy document
c. Discussion items
d. Legal structures
i. Do we form a corporation?
ii. Do we use Ithaka for legal help?
iii. Is the general trajectory that we would like to see a corporation that is separate from the universities?
1. Other options are to stay as we are, a loose federation a Michigan-hosted organization. Staff are either consultants or employees of UM
2. Sakai foundation¿503c or like
3. or to become an off-shore corporation
iv. Vote: get a lawyer to work on these issues. Carried 6-0
e. FTE commitments
f. Core continuing relationships
g. Governance - Craig Counterman's note - good
i. Sakai as an OEM
ii. Everyone else is a VAR or a user
h. Core continuing relationships
13. Staffing list:
a. Discussion item:
i. Do we ask for formal commitment of FTE?
ii. Relationship to governance discussion
b. Request for FTE commitments for 2006 needs to be sent around.
i. Roles need to be targeted
ii. To whom will we send this?
c. Roles needed to maintain product and community - should be in place transitioning starting September 05
i. User Interaction Design lead. gatekeeping function to core release. Accessiblity Lead (legal and functional, can be separate people) ? same person
iii. Sysadmin (tool support, e.g., confluence, jira, website, matchmaking tool, collab)
iv. Architecture lead (commiting function?)
vi. Tech Support
vii. SCA/vendor manager
viii. Communication Manager and Liaison Lead
c. Prospective /new member liaison
ix. QA Lead
x. Release manager
xi. Documentation lead - webperson
xiii. Project manager
xv. Financial manager
xvi. Tech lead/Product Lead
xvii. Events Coordinator
14. Board futures
b. Board composition - not necessary to specify reserved seats for R1 institutions
c. 3-4 rotate out each year:
d. will have 8
e. Jeff wants to rotate off
f. Carl wants to rotate off
g. Suggested next addition: Jutta Treviranus
i. SCA membership on board - not yet
15. Directions - Priorities for post 2.0
a. P (python, php, perl etc) tool integration
Lost in the mix - potentially misplaced discussions
Discussion re Enterprise Bundle
Role in release process
Requirements - what happens when original gaps are met extent they will be
JH - Tools team cannot check every tool that is proposed - not scaleable - board role in tools prioritization from central resourced effort?
Future organizational efforts
Development scenarios requiring coordination and prioritization
Core development effort at discretion of board
Contributed effort from partners
Grant related effort for Sakai tools
SCA staff donations
Board paid development by SCA
(7) Research Tools and Collaboration (raise with Chuck present Friday)
Issue around roles - no hard coded LMS roles governing (teacher/instructor)
(8) Discussion tool - issue of priority of redevelopment of discussion tool made at the last Board meeting - clarification required - redeveloped discussion tool has to take its place in a series of requirements including gradebook, samigo, hierarchy, common services. Strong desire of the board that this redevelopment take place, board needs tools team to give a report of resources it would take to produce a sufficient discussion tool.
Friday Morning - Joseph Hardin scribing
John Norman - on the phone - conference planning discussion
Setting up Sys Admin and John Leasia sessions - two different things
Demo Room - separate breakout room; demo reception Thursday evening 5-6:30;
Melete Presentation - Vivie wants to walk people through - full hour; talk to Chuck P; shouldn't be a problem
General plan that Wednesday is "this is the code day." Product day. Presentation type sessions.
Eg, what does Sakai 2 do - the newer tools - Melete, GB, Samigo - tools overview; how to write to Sakai - Mark's workshop; two could be parallel.
Thursday evening demos.
Thursday - working business of the DGs, thick strand on governance, parallel tech sessions
Friday is bringing strands together; looking forward to next 6 months; putting seal on governance; wrap-up, reports;
Board Meeting in Baltimore will be on Tuesday. Start at lunch? 12 noon?
Chuck and Mike present on status, updates,
The Advanced Resources Tool is progressing and agreements were reached in the arch meetings this morning about next steps, including the definition of 5 steps that would need to be completed to include this work in the release; it may or may not make the 2.0 release; probably not. The Board does not see its completion as part of the "Hell or High Water" set of highest priorities for 2.0.
The Board recommends everyone help Carol with the 2.0 QA.
Code freeze May 16; 16-20 everyone helps with the release candidate and docs. May 21 QA can start. June 15 is the release date. We will have a strong release candidate, a working 2.0, for the conference.
Stanford and IU have a strong interest in clear October release dates. So we need to have a clear definition of what is in 2.1 by early July. Sections in the tools, GB sections, Samigo, resource tools, discussion sections. New Discussion tool for 2.1.
Mara wants a tools team document soonest on what they see as 2.1 functionality.
Tool usability review, redesign and implementation is as high a priority as putting sections in, for Lois. This is Daphne's work. 5-6 targets. Resources on the bubble, not one of the 5-6.
Chuck recommends a Microsoft Project view of the June 15-Oct 15 work, resulting in 2.1 to get more clarity and more confidence for the Oct 15 release. Mike said the Jira work will help.
Mara said she felt 2.0 looks good.
The Board congratulates everyone that has been working on the 2.0 release and is now confident that the Sakai 2.0 release will move the Sakai work forward well.
Does the Board want to make integration with OSPI a goal of releases?
Should we have a meeting with OSPI? Maybe in Baltimore. Board should follow this up with Rob and Brad. Lois will report back to the board on conversations with Brad and Rob.
From Mike Elledge:
These are the high priority tools that have been identified by the Tools team
for review, redesign and implementation for the next major release:
These are being referred to as the: "Black-Eye List", now that the "Hell or
Highwater" list has been achieved.