Several recent developments signal a promising new level of maturity in the Sakai community and product. The Sakai Foundation (SF) has created two new staff positions that will together enable the SF to better coordinate and communicate our work in Sakai.
Long-time Sakai community member Clay Fenlason is the new Sakai Product Manager. Clay is an excellent choice to coordinate our community’s already successful work to further develop Sakai as a coherent, reliable product with a meaningful roadmap. Pieter Hartsook joins our community as Sakai Communications Manager. I don’t know Pieter well yet, but was impressed by his experience and intelligence at the recent Sakai Boston 2009 conference and expect him to become an enormously valuable participant in our efforts to tell the Sakai story more effectively internally and externally. Read more about these new positions in SF Executive Director (ED) Michael Korcuska’s blog.
This new maturity is further demonstrated by the formation of a community-based Sakai Product Council (SPC), which will “ensure exceptional quality and cohesiveness of Sakai product releases in support of varied teaching, research and collaboration needs” in the words of SF ED Michael Korcuska.
I’m honored to be named to the SPC along with key community contributors Noah Botimer, Eli Cochran, Michael Feldstein, David Goodrum, John Lewis, Stephen Marquard, John Norman, and Max Whitney, along with the new Sakai Product Manager, Clay Fenlason. As the SF ED, Michael Korcuska will also serve on the council as a non-voting, ex officio member. You can read more about the formation and ongoing activities of the SPC on the Sakai wiki.
In Boston, the SPC had our second ever and first face-to-face meeting and we began to sketch out some of our attitudes, roles, and processes. There was also significant discussion about the SPC in the product coordination meetings held just before and just after the conference, as well as during the various conference BOFs focused on further defining the shape Sakai 3. It’s still very early, but we appear to have settled on some shared understanding of how we will undertake our charge to shepherd Sakai’s integrity as a product. Here’s my own personal take on some early SPC thinking, but I invite other councilors and the community at large to weigh in and further develop and critique these thoughts.
First, we agree that we share two basic attitudes toward our work on the SPC. We agree to carry out our work and deliberations as publicly and transparently as we can, using existing Sakai community communications channels (primarily the Sakai mailing lists). We also agree that although each of us represents specific constituencies and institutions within the community, as councilors, we will be informed by our specific viewpoints, but attempt as best as we are able to act for the good of the community and product as a whole.
Second, we discussed three basic roles we expect the SPC to play. 1) To consider the coherence and completeness of the whole Sakai product and advise in the formation of the product roadmap. 2) To evaluate the status of new product development projects against characteristics established by the community. 3) To resolve significant issues blocking timely product release.
Third, we began to outline some of the processes we might follow in our evaluation of project status. We agree that the community should shift to work using the product development process already proposed. We see an immediate task to work with the community to define a series of specific characteristics that we will ask projects to demonstrate in order to move to the what the process above calls “Product Development” status in the community product. We expect to collaborate with the community to develop those characteristics using existing models as a starting point (eg, the Sakai tool “scorecard”, the portfolio community procedure for feature requests). We expect that projects will produce their own demonstrations that they meet these specific characteristics for community and SPC review. We expect to help provide guidance to projects on how they can develop and demonstrate these specific characteristics.
We also began to outline what role the SPC will play in the Sakai release process, where we will be focused primarily on evaluating the status of new capabilities. We identified that we may have two evaluation processes, one more lightweight, to use when new features are added to existing Sakai capabilities (eg, new features for a Sakai 2 tool already in the product), and another, heavier process, to use when whole new clusters of capabilities are added (eg, a whole new Sakai 2.x tool, everything in Sakai 3). We are thinking that in a given release cycle, the Sakai Product Manager (Clay Fenlason) will be the primary shepherd of new capabilities up to code freeze, ensuring they are considered by the SPC. While from code freeze to formal release, the release/QA/security teams will be the primary shepherds of those new capabilities along with the entire product. During the release process, if the Product Manager and release/QA/security teams agree that an issue is blocking release that can’t be resolved via typical community collaboration, they will then bring the issue to the SPC for resolution.
We understand that we may have to think differently about Sakai 2 and Sakai 3, given their very different architectures and maturity. We also agree that we are open to helping the community shift to different product release practices. For example, there might be a separation between a slimmer, core Sakai product and a number of Sakai extensions that might follow independent release cycles. Any such changes would obviously take place only after full community deliberation.
Last, but not least, we agreed that while we do not necessarily think that the SPC formation process was ideal, we do agree that the outcome was sound. We think the current SPC represents a good balance of different experiences, skills and viewpoints and that we will be able to work together effectively. We agree with our basic outline of structure and governance that it will be best if the community revisits the SPC formation process only after the current SPC shepherds at least one complete product release cycle, so we can establish and evaluate core practices before we make substantial changes.
As a councilor and community member, I look forward to working with all to demonstrate that the SPC, the new SF staff positions, and the new processes we are initiating will indeed combine to raise Sakai to a new level of maturity as a product and as a community.