Child pages
  • Board Minutes 2005 June 7

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

This document contains minutes from the Board Meeting held in Baltimore, MD on June 7, 2005. Corrections, suggestions should be sent to Joseph and Mary Miles.

Attending: Joseph Hardin, Vivie Sinou, Jutta Treviranus, Mara Hancock, Jim Farmer, Babi Mitra, Carl Jacobsen, Ian Dolphin, Lois Brooks, Brad Wheeler, Mary Miles (staff)

Introduction of Jutta Treviranus
Jutta Treviranus, the Boards newest member, was introduced. Jutta is from the Adaptive Technology Resource Center (ATRC) at the University of Toronto (UT), where most of her work is in inclusive design - standards technology that accommodates a variety of needs. ATRC works with developers of emerging technologies and has partnerships with most of the technology providers, doing a lot of standards and specifications work, relating to creating a flexible user interface. From UT, there are three groups that will be working with Sakai (ATRC, Open Source/Open Access Project, and McLuhen School). Through these 3 units UT will contribute a programmer and has agreed to a path of adoption of Sakai. UT, with 65,000 students, 10,000 faculty, and 6,000 FTEs, is the largest university in Canada. They are home to the largest digital library in Canada and the third largest library in North America.

UT submitted a proposal to Hewlett to deliver a project which would transform the user interface and re-aggregate resources for Sakai for the tool set. The proposal was not accepted, but the same project has been funded through the Canadian government. This is intended to be a JAVA library with a user library that will match needs with resources. The technology has been implemented in a number of other instances. There are three pieces to this:
¿ User preference tool
¿ User specific re-styling
¿ User specific re-aggregation (searching for certain other learner needs that meet the same specifications)

Their project (TILE) is an E-Learning environment that enables learnercentric transformation of the learner. More information is available through their website: TILE meets 508 requirements and accessibility requirements but also provides quite a bit of discretion and institution branding, department differentiation, and other uses of this nature.

Joseph emphasized Jutta's experience in standards development. He explained that she has served on more committees than anyone else he knows. In the area of specifications and standards and the constant question of roadmapping, Jutta will be an extremely valuable resource and a welcome addition to the Board.

Conference Update
Mary Miles provided a very brief description of the recent interactions with the hotel and the minor changes to the agenda. There are spaces available for BOF sessions and a sign-up board will be located at registration which allows them to be scheduled. In addition, announcements are posted on Confluence of the sessions which have already been scheduled.

2.0 Release Status
Chuck Severance and Jeff Merriman are in California, and everyone is working on these issues. There are still a few "blockers" but they are being worked. Additional reports will be provided throughout the conference.

Governance will be a topic of discussion at the "all hands" meeting scheduled for July 6-7 at MIT. Several papers on this topic have already been posted to
In roughest form, two approaches seem to be emerging: whether or not Sakai is an open source project. If the answer is yes, then the concern is that there will be too little in the way of central activities. If the answer is no, the fear is that Sakai is going to become something like Microsoft, driving anyone with any creative energy away from the project. Significant differences exist between the two approaches. While the Board can see both sides and actually agree with parts of both, they must figure out how to be good at both. All agreed that there needs to be a central organization that can make decisions about important things and garner the resources to get them done, while at the same time having the distributed facilitation and empowerment of a large number of flourishing efforts. This is the emerging model(s) of community source approaches. These issues will be discussed at sessions throughout the conference.

The role of a central organization was discussed. There has always been an enterprise bundle that Sakai QA's, and another set of things in "contrib' that people can manage as they see fit. Metadata needs to be attached to contributions with each having a JIRA file showing users, bugs, and the number of people using it. If people are going to use the Sakai logo, they must begin with the enterprise bundle and build on top of that. Sakai central services will probably not be able to do much of the tool development; a lot of the tool development will be done at the edges, by concerned and motivated people setting up DGs and WGs and getting on with work they see as important. Strong pro-active organizations are going to have a bundle, which they will publish; others may simply take the tools and use them. Neither of these negate the need for Sakai to publish a bundle. There is a concern, however, that pushing this out to the periphery makes Sakai too weak. The enterprise bundle is like a firewall if we have a strong QA process.

It was noted that the Mellon grant implies that any project coming out of it carries a Mellon brand in the short term. That brand indicates that something is good, valuable, and can be trusted afterwards. Similarly, the Sakai "kitchen" is for projects that come out of Sakai Central (whatever that turns out to be). The project is giving a brand that indicates that it has been through the firewall and survived. The web takes care of brand status through mechanisms of communication and ranking.

But what happens if somebody builds a tool and then no longer has the resources to support it. Is it an orphan? The answer is unclear. Some people feel that Sakai Central should continue to support that tool, but is it appropriate to force Sakai to support a group of orphans that is not being used. If it becomes a part of the bundle, Sakai Central should perhaps support it. This implies a mechanism for removing something from the bundle.

Gradebook is a very critical application for everyone on the board. If there is no core oversight, various institutions may evolve in different directions (and that is fine), but if it is part of the enterprise bundle, it must always look to the enterprise and not take it in a direction that Sakai Central can not support. It is not yet clear how this is done, and with what resources. Members need to be able to find support in terms of use and installation, and push development more to the periphery.

There are two mechanisms for the community to step up: central and distributed. If there is sufficient interest and resources, a tool will continue. At the same time, what is the perception of Sakai going forward and what is the level of confidence that people have that it will continue may well rest on what responsibilities the Board takes on. If there is a good argument to leave a tool where it is, where it was produced initially, the problem arises when it is orphaned. There should be a mechanism, such as regularly scheduled voting on the next stage. Anything that floats to the top is given a cut-off date. If it is not picked up by a volunteer, it is considered by the entity. If the community demands it, it's integrated. If the community doesn't demand it, it's dropped. Jutta mentioned some such mechanisms in use by the ATutor community.

As an example, if Stanford did not have the resources to work on Samigo, Sakai central would have to find a way to keep it going. Sakai Central has to provide the framework and certain accepted tools. The framework is expected to evolve and become secure. Part of this is the QA effort. This implies the need for easy communication between the DGs/WGs, the edges in this case, and any central activity. The fact is that people are seeing that local requirements can best be met by spending some time working with other groups Much of the work that has been done has been challenging because people were trying to do things while the framework was changing. The complexity of trying to centrally manage 100 institutions integrating to a core is overwhelming. What you have centrally is a really good framework at the core, and that is what people build to. Coordination happens, in large part, through the work of building to that framework. This is not easy and it will get better, it's already gotten better. 2.0 is better than 1.5. In the end, it's not Sakai Central's role to take on everything that Sakai works on.

If Sakai Central takes on responsibility for everything that is in the bundle, some felt you keep it lean. The core bundle remains supported. Sakai Central works on things that are in the enterprise bundle, people should be secure that it's been through QA, etc. That does not mean that Sakai Central finances everything that is there. If Stanford says we can't do this any more then the Sakai Foundation has to decide if a response is required, and do we have the resources to do it, can we find someone to do it, but it's not a guarantee. It becomes a question of ongoing enhancements vs. functional requirements. Around the enterprise bundle we will attempt to coordinate that. Vivie has a place to go with her request and the Foundation says there are 10 requests, which are we going to fund?

Part of this discussion is what transitions are required of the current organization. One issue to confront is the prescriptive value of the style guide and its status going forward with the Sakai Foundation. There is support value in tools having a set of common approaches to them. Every tool should not be a new tool for the faculty. The frustration of the some, and this is felt most strongly by some of the current Tools Team members, is that they feel they know the best way to do this and the requirement for a common experience is felt very strongly by them. Just what the force of this requirement is, and what is the best way to obtain a sufficiently consistent experience for users is not so clear to others, including some actually building tools. That makes a lot of friction with respect to the tools that are built at the periphery and their adoption into the framework. It was suggested that Jutta engage in the discussion around the styleguide and its prescriptive orientation.

One of the questions that boils out of this is: What are the responsibilities of the Sakai Foundation with respect to the tools that are part of the core bundle?

There is not a need for a major change in the philosophy of governance. Some people don't like the idea of the central organization saying that there's a set of priorities, starting out with the framework at the bottom. Some do. Again, balancing the needs for a clean bundle (and what that means) with the needs for distributing the work, encouraging distributed development, are at the center of these discussions. The foundation can not do all of the work, but it can oversee significant parts of it. Objectives of the Foundation are to assemble the resources, as well as encouraging, cultivating, facilitating other work that is done by members in both tightly and loosely coupled fashions.

Incorporation Questions
Joseph led a discussion on the incorporation question. He noted that this is a board responsibility and they must be the ones to make these decisions. The bottom line question is why do we want to incorporate as a non-profit? This will allow Sakai to hold the copyright and to make people more inclined to contribute software, code, and other pieces.

The articles of incorporation were reviewed by the board. The attorneys can assist the board in completing these documents and incorporating the desires of the board. This is the first broad overview of these documents. As to where it should be incorporated, Michigan has people who have done this before, but there is no particular preference given to a non-profit. One slight twist is that Michigan allows non-profits to have stock and own subsidiaries. This has to be a process of formation that results in an organization that our universities, organizations will later be able to become a member of. The purpose of this review is to make sure that the bylaws don't present difficulties for others to join. The attorney retained by the board has agreed to help with the preparation of a single page document that describes this process. By having our attorney involved in this preparation, it will ensure that other attorneys will recognize it. That document will then be given to the members for approval by their board. Show-stoppers must be identified and dealt with. The four core schools must be given a separate document that described what happens to the IP. Individual schools will make individual decisions. The preference at this point is that if Michigan, Indiana, Sanford and MIT agree to donate copyright it gives them the high ground to ask something similar of others as we go along. There may be others who cannot give over the copyright. It would be the preference of some to do so unless legal counsel says we cannot do so.

A proposal was made for a 4 schools foundation IP assignment document. It is the board's preference for the individual schools to give ownership of the software that was developed under the 4 schools license to the foundation. Second preference is for the schools to give a copyright license as described in the Apache process. The schools would actually transfer ownership to the foundation. The Foundation may be able to offer terms to the university which makes it very attractive to do this. Brad agreed to write this up as a document and send it to the board.

It was suggested that a very short simple talking document would help the board members to open the door for this. Joseph will build that document as soon as this conference is over. In addition to the talking document, the board needs a one-pager that talks about its intent. Jutta suggested a task force to move forward with this one-pager as it relates to the IP status with respect to the core schools. The task force will consist of Joseph, Babi, Lois, Mara, and Ian. Lois will serve as the scribe for that task force.

The issue of trademarks was discussed. The board agreed to spend the $15-20,000 necessary to register our trademark in all countries as soon as possible.

IP Discussion
The IP discussion originally on the Board's agenda was passed to the task force rather than discuss it at this time.

Jim Farmer raised the issue of SEPP communications. It was suggested that every presentation, every document that is completed and ready to be release carry a common symbol and be released under a creative comments license. The Board approved this action.

Currently there is probably no legal standing even if software is given to core schools. The simplest thing is to go ahead with the ECL and then move it into the foundation when we get the copyright. At the present time the copyright is declared by the author and has to be ECL. This change in policy will have to be communicated. To do this an interim report will be prepared.

CSG Report
Chandler is a project to which Ira Fuchs asked the 25 comments solution group to contribute $50,000 over three years. This was then matched. The total funding was $2.4 million for a 2-year project. Brad will send excerpts of the report to the board.

Mellon Library
Lois reported that Indiana, Stanford, MIT & Michigan Libraries put together a proposal to Mellon. Although the proposal was not funded, the use cases were good and the CREE project has set up a fairly major meeting in July to focus on it.

Ian Dolphin reported on scenarios for potential interoperability with the U.S. and MOODLE. Some focus needs to be put into this. The priority is an open dialogue, with content interoperability at the top of the list. If someone authors content in Moodle, there must be a guarantee that it will work in Sakai and vice versa, without any intermediate change. Sakai needs to talk to the Moodle folks, but the question is how much talking needs to be done. Moodle is one of the sources of innovation in pedagogy and tools that may someday migrate into a Java tool. It is possible to begin tentative discussions concerning things that go beyond content. There is a space for both Sakai and Moodle, and they are both going to continue to exist. The discussion should focus on interoperability, data and content, and shared systems interfaces. In the UK there is likely to be specific interest in the integration of both systems with uPortal. It may well be that some funding may be available for this work. The questions of content and tools interoperability should all carry the same message. The board agreed that this will take a little time and that it has to be an open approach allowing for routes to the base of the community. Board members were encouraged to attend the June 19 Moodle meeting in the U.S.

Specifications and Standards

One question from the general community is the issue of what specifications and standards Sakai supports in a consolidated way, and what it is moving toward in the next 6 months. It would be useful to have a consolidated statement of what is currently supported and how. The board agreed that a short document was needed to document this. Jutta, Mark Norton and Chuck Powell were charged with working on a "rolling" document to enable the board to figure out what directions we think should be taken forward. In addition, Jim Farmer will work with both Chuck Severance and Chuck Powell to develop a short document that addresses the question, "what about Sakai and uPortal?"

Due to schedule conflicts, several of the board members may not be available for the Educause session. It was agreed that the board will meet on Tuesday, October 18, beginning at 1:00 p.m. at or near the airport. The Sakai seminars are scheduled for Wednesday and Thursday, October 19-20.

OSPI and Sakai
The OSPI board is asking to what extend portfolios are important to the long term roadmap. When portfolio pressure comes, Stanford plans to implement. There are people at Michigan who would like to see Portfolio implemented and we will run pilots this fall or winter. The default would be that when pressure arrives OSP would be the choice. There are many questions around what does it mean if OSP works more closely with Sakai. A big distinction should be made between OSPI as the organization and OSP as the software. The bottom line is that for OSPI there is no rash of people working to make it go forward prior to 2.0. Portfolios are not forced management systems. In its present form OSPI does not have a clear sustainable future. R-smart has more than carried the ball. People tend to have differing views on Portfolio. Some see Portfolio software as a silo unto itself. OSPI is aware that its grant is coming to an end and there is not a single clear path for going forward. At that point, OSP might well work through the Sakai Foundation. There is a requirement for PDP in Europe. IU will continue to invest development energy in OSP as a Sakai tool over the years. If OSP were then working with Sakai and you disbanded OSPI and took it to the DG, then what happens? The idea of unbundling tools is not a new idea. If you want OSP right now, you have to install Sakai. Sakai is a required technology, with OSP built on top of it. There's no disagreement on the fact that OSP is a valuable tool and as far as this board is concerned, this is a clear example of a tool that should have its own DG and that's where the decisions and coordination efforts need to originate from. There are two legal requirements: one at the European level, one at the UK level, and that will result in resources. There are resources available.

France could be convinced to move to OSP because it's Sakai architecture within the next 2-3 months. What responsibilities does the Sakai board take on by adding this to the core bundle? OSPI should be told that a number of Sakai institutions have Portfolio now or on the radar and plan to work with Sakai under a number of new or existing processes and they will be welcome. Portfolios are something that people care about. More discussion will follow after the OSPI conference.

Post 2.0 work...
What development work can be done prior to the July meeting? That's the point where we really need to have options presented such as where we to go from here, what resources can be committed (hierarchy, discussion tool, uPortal, etc). These are all open questions. The OSPI/Sakai Resources work is on the front burner. This board has to make some choices and it can't do so until it's had sufficient information about what the technical team sees as the options for the next 4 months leading to the next October release. Vivie agreed to send documents as to what their requirements for their Discussion tool are and noted that after Melete 2.0 is out they will shift resources to that.

Committee for December conference...
There is a clear need for a conference committee chair. Discussion focused around how to form that committee and who should be involved. It was felt that Sakai should award one conference committee seat to the OSPI board as they will have a track in Austin. Joseph will put out a call to the entire conference at Wednesday's welcome, but the meta message is: this is part of the transition, begin to work with the committee. Chuck will talk about moving discussions to the WGs.

SEPP Revenue Summary:
Affiliates are all currently paying the same as SEPP members. Joseph stressed that we have gotten 15 members to date this year, but that we need to close the year with 100 members. In a separate board action the board agreed to raise Mike Elledge's appointment from Sakai to 70% to reflect the additional work he is doing for the project.

Joseph indicated that we need to have a slide saying "each one bring one." SEPP partners should be encouraged to bring in an additional partner. This should be couched as an invitation to join a successful project and not something like an Amway invitation. This should be done at the wrap-up. At this conference, we will have 132 institutions and only 75 are partners.

Calendar for Future Meetings
Mary will update the calendar to reflect the updates from this meeting. July 6-7 is an all-hands meeting "all core." The next face-to-face meeting will be in October at Educause. It was agreed that board calls should go back to every 2 weeks, beginning June 23. They will continue to take place at 1:30 p.m. Eastern time (17:30 GMT). However, if there is a need for a special call, we have the mechanism in place to make it happen.

Tools team:
Questions were asked about the future of the tools team. Several members of the board felt it should be moved over to a DG and expanded as needed. The board needs to decide what we do between now and the end of the year, and then what we do into the future. The current stream of work needs to be examined and we need to commit resources from the same set of resources as we have up to this point in order to get the next release out by October.

Post-July we need to involve SEPP in a more positive way. The Tools Team history was they were chartered to figure out the requirements, and the architecture team was charged with making it work. They worked together and came up with top 42 items. Some of those were worked, and then they did the work on the style guide. A great many people feel that they need a very clear charter from this board for whatever they need to do in the remaining amount of time. There is a feeling that a lot of what they do and say goes to Chuck and the architecture side and there is a huge disconnect between the tools team and what is coming out of the project. Maybe they are doing the wrong things, or it may not be the stuff that we need. You will have a better idea of how much they are needed and what they should work on after the July meeting when you figure out what you work on for the remainder of the Mellon grant. Given what their role was in the beginning, they have been defined through December 05. Who's going to define how to interact with the tools. One solution is for the Tools team to be attached to sub-projects. Is this function a part of the core through December, or does this group need to be expanded to deal with a larger issue.

Part of the original function was to define best of breed for the board, and that work was done months ago. The gaps listed originally have now little relevance to the work going forward. The Board has responsibility to clarify their charter for the last 6 months. If you think back to the original grant, things were pretty clear. When technical decisions have to be made, Chuck was tasked with making decisions. When an agreement wasn't found or when it would take too long to find, Chuck was charged to make decisions. This board should give the tools team a clear charter for the next 6 months, with very clear function requirements on various issues. It was decided that the work should continue on the discussion tools and the hierarchy tools, as well as Gradebook. Available resources need to be determined as well as top priorities.

There is also the issue of getting "turn-around" that we need from an iterative team. There seems to be some disagreement between developers and designers and that's where some of this thinking originates. After a certain point, we have to decide which model we want to enforce. There are multiple models of what are functional specs. Confluence has a list under 3.0 features, but that list is not prioritized. There is some concern that people will not be ready to work on things after July 6-7 if there are no specs in place for them to work on.

To proceed, the board needs to figure out what to tell the tools team they should do in the next 4 months. Mark Norton and Charles Severance will be contacted and their input reported back to the board.

The board decided to continue this discussion at dinner....

The meeting adjourned at 6:30 p.m.

Final Note to Board Members: There is a 100% increase in attendance from last meeting. Meet as many people as you can. In all our individual discussions with members remember that the vast majority of input is that we have done a great job. Let's have a good time at this conference.