Monday, June 22, 2009
Boston Sakai Conference Dine Arounds
For some non-virtual social networking consider the informal “dine arounds.” You’ll join a group of fellow conference attendees for dinner at a local restaurant. There is a sign up sheet on the conference wiki (http://confluence.sakaiproject.org/confluence/x/yYhDAw) and a dinner facilitator will help coordinate travel to destinations. Each attendee is responsible for their own bill and gratuity.
Wednesday, March 25, 2009
Proposed Sakai Development Model
Last Wednesday I had the opportunity to attend a webinar session given by Michael Korcuska, the Sakai Foundation Executive Director, on the proposed development model for Sakai. First, I want to say that even though there were some hiccups (gotta have them!), this was one of the most beneficial forums for communication and engagement that I’ve experienced in Sakai in a long time.
One of the things I liked about the proposal was that Sakai as a product is defined. I think a lack of vision has been a major hurdle these past few years. I see this a positive step forward but the devil is in the details. Before I dive into critique, I want to be clear that I don't think these are things that can't be worked through. They just happen to be points that need careful consideration and detail before we all drink the kool aid.
To begin with, the largest hurdle is going to be communication. Let's all be honest, we're all really bad at this for a multitude of reasons! The proposal adds complexity and without clear definition of who is to do what and how we're going to end up less coordinated. In addition, I have a few simple requests: I want it to be consistent, reliable and simple. Please, please don't make me read lengthy messages where I need to analyze every word for hidden meaning.
Also, I feel *strongly* that the product council should not include members of the board. The board should be visionary and assist in laying out a broad strategy for community execution (like the current proposal!). Once those members become bogged down in the day to day operational details, they will become less effective as the visionary leaders they have been elected to be. This isn't to say that there aren't members that wouldn't be a good fit on the council - they should just be one or the other.
Lastly, it seems that the product council is not only tasked with being the gatekeepers and shepherds but also the group that defines the standards. Performing as gatekeepers and shepherds requires quite a different skill set and temperament than defining the standards. I'd advocate that a short term task force that was charged with initially defining said standards that the council could use. I think that approach could result in a much faster implementation of this process as well as garner a wider breadth of knowledge. Something that will be *key* in ensuring we have appropriate standards/criteria. Future looking, when the standards/criteria need revisiting, the council could recommend the community assemble a new task force.
One of the things I liked about the proposal was that Sakai as a product is defined. I think a lack of vision has been a major hurdle these past few years. I see this a positive step forward but the devil is in the details. Before I dive into critique, I want to be clear that I don't think these are things that can't be worked through. They just happen to be points that need careful consideration and detail before we all drink the kool aid.
To begin with, the largest hurdle is going to be communication. Let's all be honest, we're all really bad at this for a multitude of reasons! The proposal adds complexity and without clear definition of who is to do what and how we're going to end up less coordinated. In addition, I have a few simple requests: I want it to be consistent, reliable and simple. Please, please don't make me read lengthy messages where I need to analyze every word for hidden meaning.
Also, I feel *strongly* that the product council should not include members of the board. The board should be visionary and assist in laying out a broad strategy for community execution (like the current proposal!). Once those members become bogged down in the day to day operational details, they will become less effective as the visionary leaders they have been elected to be. This isn't to say that there aren't members that wouldn't be a good fit on the council - they should just be one or the other.
Lastly, it seems that the product council is not only tasked with being the gatekeepers and shepherds but also the group that defines the standards. Performing as gatekeepers and shepherds requires quite a different skill set and temperament than defining the standards. I'd advocate that a short term task force that was charged with initially defining said standards that the council could use. I think that approach could result in a much faster implementation of this process as well as garner a wider breadth of knowledge. Something that will be *key* in ensuring we have appropriate standards/criteria. Future looking, when the standards/criteria need revisiting, the council could recommend the community assemble a new task force.
Saturday, March 7, 2009
Unsubscribe me!
If you haven't seen your Sakai mail for the past few days, you're going to see that about 1/2 the email on the lists are pleas from former subscribers to be removed from the list. At first they were comical but I have to admit they are starting to grate on my nerves!
If you are still in need of unsubscription, Seth Theriault posted options for unsubscribing that can be found at http://thread.gmane.org/gmane.comp.cms.sakai.devel/29319
Some suggestions to the foundation for any future changes to systems that are critical
1) Tell us exactly what is going to happen and with sufficient notice. I'd suggest at least a 24 hour lead time. With this notice you'd be able to get volunteers to assist in confirmation that things are working swell.
2) Please don't make changes at 10am on a weekday. I know this is a global project but 10am is a time that impacts a large portion of our community. When thing go awry (and we all know they often do), it'd be better to impact a smaller population
3) When there is a problem, have someone from the foundation tell us you know there is a problem, what it is, ect . .
That said, I'm sincerely happy that something was done to address the problems we were having with the lists on collab. As a community we had been crippled and are now able to communicate to make progress in an open manner. Further, the messages are now nicely tagged by audience.
If you are still in need of unsubscription, Seth Theriault posted options for unsubscribing that can be found at http://thread.gmane.org/gmane.comp.cms.sakai.devel/29319
Some suggestions to the foundation for any future changes to systems that are critical
1) Tell us exactly what is going to happen and with sufficient notice. I'd suggest at least a 24 hour lead time. With this notice you'd be able to get volunteers to assist in confirmation that things are working swell.
2) Please don't make changes at 10am on a weekday. I know this is a global project but 10am is a time that impacts a large portion of our community. When thing go awry (and we all know they often do), it'd be better to impact a smaller population
3) When there is a problem, have someone from the foundation tell us you know there is a problem, what it is, ect . .
That said, I'm sincerely happy that something was done to address the problems we were having with the lists on collab. As a community we had been crippled and are now able to communicate to make progress in an open manner. Further, the messages are now nicely tagged by audience.
Wednesday, September 24, 2008
Sakai 2.5.3 Released
I'm pleased to announce the availability of Sakai 2.5.3, the second maintenance release of the Sakai Collaboration and Learning Environment in the 2.5 series. This release includes 39 bug fixes and performance enhancements in Assignments, Blog, Database, Entity Broker, Messages, Forums, Worksite Setup/Site Setup and Wiki. This is an important milestone in the changes the community has been making in its release practices as the fixes selected for inclusion in the release targeted a subset of tools. The release is available in source, binary and demo versions from the main Sakai Subversion repository or from the Sakai website at http://source.sakaiproject.org/release/2.5.3/.
I’d like to thank all the QA and release team members that made this release possible: Bryan Batotich, Alan Berg, Angela Henry, Govind Iyengar, Matthew Jones, Huzefa Khalil , Peter Knoop, Michael Lockett, and Anthony Whyte.
I’d like to thank all the QA and release team members that made this release possible: Bryan Batotich, Alan Berg, Angela Henry, Govind Iyengar, Matthew Jones, Huzefa Khalil , Peter Knoop, Michael Lockett, and Anthony Whyte.
Thursday, September 4, 2008
Stepping Down from Sakai QA Director role
As many already know, I've accepted a promotion at Indiana University and will be stepping down from my role as the Sakai Quality Assurance Director. If you're interested in the 'official community announcement' it can be found at http://www.nabble.com/Sakai-s-Quality-Assurance-Director-td19291371.html.
Working on the Sakai project as the QA Director has been an honor and a privilege. Over the past few years we’ve made serious strides in improving our processes and testing practices that have lead not only to increased quality in our software but an increased collective consciousness about what quality means to us as a community. I look forward to seeing the momentum carried forward under new leadership.
Many of you may be wondering my new role at Indiana is. The position is the Quality Assurance Team Lead / Project Planning Coordinator which is one of two team lead positions that were added to the IU team that works on Sakai. I’ll be doing a lot of similar things I did for Sakai on a local level, but I’ll also be involved with other activities, like project management. As Michael mentioned, my responsibilities in this role do include community engagement so I’m extremely pleased to say you’ll still be seeing and hearing from me!
I do want the community to be assured that there will be a smooth transition to the new QA Director and that the release and testing activity for 2.6 will remain a top priority for me until the new QA Director is hired.
Working on the Sakai project as the QA Director has been an honor and a privilege. Over the past few years we’ve made serious strides in improving our processes and testing practices that have lead not only to increased quality in our software but an increased collective consciousness about what quality means to us as a community. I look forward to seeing the momentum carried forward under new leadership.
Many of you may be wondering my new role at Indiana is. The position is the Quality Assurance Team Lead / Project Planning Coordinator which is one of two team lead positions that were added to the IU team that works on Sakai. I’ll be doing a lot of similar things I did for Sakai on a local level, but I’ll also be involved with other activities, like project management. As Michael mentioned, my responsibilities in this role do include community engagement so I’m extremely pleased to say you’ll still be seeing and hearing from me!
I do want the community to be assured that there will be a smooth transition to the new QA Director and that the release and testing activity for 2.6 will remain a top priority for me until the new QA Director is hired.
Test case documentation
This evening I was perusing Confluence and noticed a recent update for some ongoing work with Sakai Session clustering via Terracotta. The title referenced manual testing and of course caught my eye. I found one of the most awesome documents about the testing I've seen in confluence. This page details the environment, configurations, test cases and current results . . . . check it out at http://confluence.sakaiproject.org/confluence/x/UgCEAg. Two thumbs up Cris Holdorph!
Saturday, June 28, 2008
Sakai Project Coordination - Day one am
Interesting update from Linda Place, the lead of the Performance work group. Many of you might not know this but since the conference last summer in Amsterdam a small group has been working on a proof of concept for a community wide set of processes and practices for performance testing. this includes
- provisioning of test environment - creation of sites and users. This is based off of work by Alan Berg
- Use of open source tool (Grinder) to create test scripts
- Baseline tests and results
Subscribe to:
Posts (Atom)
