Hi all, it is Saturday morning and I am sitting here with my cup of coffee so it is probably time for a status update. Hope you all had good holidays and took some time off. I had a great time learning Cocoa and Eclipse on my days off.
We have Sakai 2.2 penciled in for July 15 – we will likely need a longer QA period for 2.2 than any other previous version of Sakai because we will be integrating a number of new software from the community. We may need to do QA from May 15 through July 15.
Sakai 2.1.1 is already in the works – we should tag this soon and begin QA. Hopefully the 2.1.1 QA will be pretty straightforward. The maintenance branch code which makes up 2.1.1 is already in production at IU, so at some level the key element for community QA for 2.1.1 is to make sure we have no regressions from 2.1.
Sakai 2.1.2 is also in the works. This is scheduled for freeze for 2.1.2 in mid February and QA after that. If all goes well, Sakai 2.1.2 will be the base for OSP 2.1 and we will (finally) be at the point where the OSP and Sakai code bases are synchronized. The nice thing about 2.1.2 is that the OSP team will be doing QA on Sakai so we will have a more significant QA effort on the 2.1.2+OSP package. The hope is that folks can go to 2.1.2 Sakai and then “drop in OSP”. It might not be that simple when it all works out – but that is the hope.
In terms of personnel, you have probably heard by now that Carol Dippel resigned as Sakai QA Director back in December. She will still be involved – just not as the QA lead. Carol did a great job for the Sakai project and she produced outstanding results in a challenging environment. We miss her leadership already.
We really cannot go for long without a QA Director – we are working on Carol’s replacement and hope to have it all worked out and announced in time for the new director to lead the 2.1.1 QA effort.
Some big follow on work after the Austin conference is the Sakai Community Practices group. This is in the process of forming a charter. See http://bugs.sakaiproject.org/confluence/display/SCP/Charter for more details.
Another important area is the Requirements Group. There is now a really cool requirements form in JIRA. Go to http://bugs.sakaiproject.org/jira, Create New Issue, Project: Sakai Requirements, Issue Type: Requirement. The Requirements DG is going to lead a process where the community enters requirements, then prioritizes these requirements, and then we use the resulting list and try to find resources between now and May 15 to work on those requirements that the community wants the most. Of course the best way to get your favourite requirement worked on is to work on it yourself :)

I wish that the Challenger Space Shuttle never went down and created the concept of the Challenger memo. Because of the Challenger memo, our culture was forever changed. People feel that if there is some little complaint that forms in their head – they are duty-bound to blast the complaint out as loudly as possible in case it “saves the next space shuttle crew”.
As a result, since the Challenger went down there have been literally billions of people who have written critical messages feeling all the while that they were saving the world. Mostly what they really want is the satisfaction that when something goes wrong – they get to point back to their memo written *before* the event happenned.
The problem with this is that events like the Challenger explosion happen very seldom and these memos get written many times per day in many organizations so the losers writing the memos are ready for the next disaster.
But these memos cause far more damage than simply wasting paper or E-Mail in boxes.
What if you were the person who was handed the Challenger memo, and then ignored it, and then the crash happenned, and then the memo writer points out that (a) they were so brilliant that they knew what was going to happen in advance of the event and (b) their idiot boss was handed the memo and ignored it.
So this creates a culture where we can’t just tell the Challenger memo writer to “go back and actually work on the solution rather than just bitching about the problem”. Each person handed the Challenger memo (remember that they almost never come true) must listen intently to the memo and engage in a long and useless disucssion with the memo writer that does not really get closer to the solution (remember the writer is not motivated by fixing the problem – just showing their brilliance in identifying the problem).
The purpose of the long discussion is so that when the one in a million chance hits and the problem actually happens, not only does the memo writer get credit for their brilliance, the boss of the memo writer can claim that there was a long involved discussion about the issue when it came to light and appropriate measures were taken.
Of course this does not apply to really bad things like sexual harassment or abuse or some other really bad thing – these should be brought to light and handle with care by all involved.
I am talking about the run of the mill Challenger memo which takes the form of, “If we switch from 45 pound paper to 40 pound paper, I predict dire consequences.”
I once had a boss named Lew who had a phrase – “Don’t bring me problems – bring me solutions.” He shared this with me years before the Challenger incident.
This “bring me solutions” is the essense of how we break the endless cycle of wirting Challenger memos and then covering the exposed parts of the anatomy which result. All of this chatter drains ones energy and removes people’s focus from the problem at hand and actually makes it more likely that some dire consequence will occur.
The sad thing is that the dire consequence is usually not the one the (hoping to be brilliant) Challenger memo writer predicted. Although perhaps some lucky person elsewhere wrote a challenger memo and can gain some benefit from the tragedy.

I went to Bloomington, Indiana in December and with Marlon Pierce’s help, started working on the Sakai JSR-168 portlet again. A really great steak from Zagreb always gets the juices flowing – Marlon said I could not have any steak until I had an initial version done – so motivation was high.
Now four days later, I have an even better release with a bunch of usable features. I attach some PowerPoint and source for you to take a look at. Here is a set of new stuff:
– Added Gallery Portlet
– Added a tree view portlet that shows all of your sites and tools
– Moving the code into SVN (when I get a good network connection)
– Configuration flexibility
– Added proxy portlets for common Sakai tools:
Announcements (sakai.announcements)
Assignments (sakai.assignment)
Chat Room (sakai.chat)
Discussion (sakai.discussion)
Gradebook (sakai.gradebook.tool)
Email Archive (sakai.mailbox)
Membership (sakai.membership)
Message Forums (sakai.messageforums)
Preferences Tool (sakai.preferences)
Presentation (sakai.presentation)
Profile (sakai.profile)
Resources (sakai.resources)
Wiki (sakai.rwiki)
Tests & Quizzes (sakai.samigo)
Roster (sakai.site.roster)
Schedule (sakai.schedule)
Site Info (sakai.siteinfo)
Syllabus (sakai.syllabus)
This basically means that you can drop a Samigo into a JSR-168 portal after a few details have been handled.

These are some more Sakai principles that were discussed by a few other folks.

The Sakai Foundation Board directs resources that belong to the Sakai Foundation or have been given/loaned to the Sakai Foundation. With limited resources, the Foundation tends to focus on investments which build and sustain the community. The Sakai board also provides some support for community-wide design and technical activities like project management, release management and quality assurance in the best interest of the community.

Nearly all of the work of designing, developing and producing Sakai releases is done by volunteers. These volunteers may be individual contributors or may work for an organization that is involved in Sakai and is making a voluntary organizational contribution. That said, one of the Sakai Foundation’s goals is to inform and guide volunteers making contributions how they might maximize the benefit of their efforts for the entire Sakai community.

Sakai’s direction is driven by contributions from the community. In order for an organization to effect the direction of Sakai it is best done through contributing resources to that aspect of Sakai that the organization feels is important.

Sakai efforts are organized into a number of separate projects, roughly modeled after Apache. Each project has a set of committers who self-manage their commit list. Generally the path to becoming a committer in a project is for one to develop an understanding of that element of Sakai and begin contributing through an existing committer. Once it becomes clear that the new contributor has achieved the appropriate skill level, they can then be granted committer status. The Sakai Foundation Board delegates operational authority for appointing appropriate committers to the leadership of the technical community.

Sakai is software which must maintain 100% production capability over its entire lifetime. Maintaining the performance, quality and reliability of Sakai releases is the founding principle of Sakai software engineering.

This is a set of guiding principles that we wrote down at the first meeting of the Sakai Foundation Board. This is really a brainstorming session more than anything else – but the nicely capture some of the truths about Sakai.

They are not “adopted” – just discussed.

Continue reading →

In my ever expanding quest for places to integrtate Sakai into, I have decided to start playing with VUE (http://vue.tccs.tufts.edu/). VUE is pretty cool – it makes context maps.
In my crazy design thoughts, I want Sakai to hand VUE maps over web services. Those maps will contain information about sites the user has access to on the Sakai Host, and pages within those sites.
This is a long term fun thing for me. Thanks to Jeff K and Anoop K for their help on this.
But I figured I would share how I got VUE to compile on my Mac in case you want to be a cool VUE developer too.
It is (yet another) Chuck C-Schell script that I wronte because I have a terrible memory!
It grabs source, does a bit of fiddling with the source, compiles, and runs VUE.

Continue reading →

It is January 1, 2006, and sitting watching Television last night – I thought back to 2000 and thought about the fear that we all held watching the ball drop and half-expecting the sewers to back up on Times Square as midnight kicked over.
Also today I am “cleaning out my closet” and pitching some old stuff and came across a Powerpoint Presentation that I made in 1999 about Y2K – at the time, I was the CIO of the College of Engineering at Michigan State University and I got a bit of flak about this talk.
Now six years later I am going to throw away the printout of my slides as I clean my closet so I figure that before I pitch them, I would type them in in case anyone in the future decides to ever look back at this point in time. Kind of a time capsule.
Here are images of this talk

Continue reading →