Product Council Review - Noah Botimer

1.1 - The PDP has some useful bits but is also troublesome. It is confounding to consider the same process for both Sakai 2 and Sakai 3, given that there is inertia in both cases, in very different products. The process has been declared, but I'm not sure that it's really running yet. Also, there are some specific issues:

The process encourages "one big release", neglecting a rich ecosystem of optional components. I am reminded a bit of education, where some proportion of teachers/faculty seek an administration track. But, this doesn't define success – many choose to stay in the classroom/lab and become leaders there. Our process neglects the possibility of mature projects that don't seek to be included in the community release – but look and feel like they could. It disregards the difference between maturity and broad adoption. Consider a "contrib" tool that is very polished – it may or may not be widely desirable enough to take the steps toward getting support commitment and eventual inclusion.

Also, I think Incubation needs to be reconsidered. It does not seem very helpful, as defined, in the big picture.

1.2 - The non-project teams that exist (as roughly defined by the conference calls and WG lists) are largely organic. They have emerged from work that needed to be done and I think reflect most necessary components. That is, releases are produced (RM) after being tested (QA). Components not receiving institutional support are watched over (MT). The core infrastructure and security concerns have people watching them (K1/SEC-WG). Where we struggle is in terms of listening to users for enhancements, planning platform evolution, and projecting and delivering on a roadmap. That is to say, we could use more whole-product functional and technical leadership – lazy consensus needs something to consent to.

1.3 - I think the PC's role is best suited as a broad surveyor and facilitator. That is, discussing coherence, incompatibilities, risks and opportunities, and communicating them to project teams and institutional leaders.

1.4 - The PC should provide broad institutional memory and seek to make groups aware of things that seem to be missed. It should not be a mediator.

2.1 - I hoped that the PC would discuss whole-product and whole-community issues and lend insight to things that "should probably be done". These would bring focus to broadly important topics and facilitate commitments, roadmaps, and delivery.

2.2 - I think the charter is generally fine, but there needs to be clarity about what the PC will not do.

2.4 - An official, term-appointed group that has regular meetings with the product manager and ED is rather visible. I think that it speaks to the community philosophy of software development and delivery. This can bring various impressions and the community needs to have a clear value proposition and definition of "what it does" to avoid wildly divergent assumptions.

3.1 - The charter indicates a chair. How do we decide whether there should be one and what that role would mean? If we won't have one, remove the language from the charter.

4.1 - The initial focus was on understanding what projects would ideally supply to the community in terms of documentation for an almost-mature project. The later focus shifted to "kicking off" Sakai 3.

4.2 - The clarity around what the PC would like to see from projects offers some consistently formed information to be perused, not only for PC evaluation, but by community members making adoption decisions. This is a success in that adopters can understand what's coming in a way that was more difficult before.

Many of the conversations about criteria served to codify community expectations around quality and coherence. This process is working toward a shared vision of how product success is defined.

However, the conversations around Sakai 3 sputtered some. Some of this is surely due to trying to figure out the right shape and size of a process for Sakai 3, and the question is whether the process the PC guides should be at a higher level.

Many community members were confused about the role of the PC. This caused a number of negative effects, from misplaced hopes, to some paralysis amongst teams (RM/QA/MT) that were confused about what the PC would be doing in their area. This role clarity issue must be resolved.

4.3 - Thus far, I think the pay-off is that there is now a reasonably well-regarded set of questions that projects can use to check if they are on track with community expectations, at least for Sakai 2.x. We have also raised a set of organizational and operational questions that are not new, but have been tacit too long. That is, we have made a start.

Long term, I think the big pay-off is having a group that meets regularly to discuss the entire state of the community/product. These are conversations that often go by as "too lofty" on the lists. Scheduled commitments to discuss broad, high level concerns help keep track of community health and can serve to identify issues and inspire innovation.