[Deploying Sakai] [Management] Organization and Governance (was MT deprecation recommendations for 2.7)

[Nate Angell]

First, administrativa:

Apologies for cross-posting, but enough people have weighed in on this thread that I want to be sure all have the opportunity to stay tuned. While this discussion probably properly belongs on the management list, it's not clear to me that everyone pays attention to what happens there.

I'm not quoting any earlier messages in the thread because I'm responding to all rather than any specific.

I'd be just as happy if those of you who were inspired to blog about these issues copied your posts to the thread as well so we have the opportunity to read it all in context in a single channel. Relevant community blog posts are not the email management issue I struggle with.

Second, what I really want to say:

I hear some frustration from Chuck, Megan, and others about 2.x management practices, and their possible mixture with 3.x management practices.

I don't really feel unsure about the purpose of the various groups mentioned (Product Council, Maintenance Team, QA, Release Management). Each seems to me to have a pretty distinct, useful purpose that is pretty well conveyed by their names alone, reflecting the community processes that generated them. I think we are still working out exactly where our boundaries diverge and overlap, but we seem to be communicating about it all fairly effectively (eg, the discussion around deprecation), so I'm not worried provided we don't go in too many circles.

I'm not a member of the other groups, so I won't comment more on them.

As for the Product Council, I believe it mainly arose to meet a justifiable concern in (and outside) the community that Sakai has lacked overall coherence as a product, or at the very least, lacked good communication about its coherence as a product. Those of us deep inside the community probably don't notice this (apparent) lack of coherence as much, but the farther you move from the community core, the more glaring it is.

I think I align with Noah (and probably others) in viewing the role of the Product Council not as an authority, but as the body that crystalizes the questions the community needs to ask to maintain product coherence. For innovation: how has your project addressed specific community standards and practices? And as has become clear, for maintenance: is your project still addressing those community standards and practices that signal viable participation in a coherent, live product?

If the PC doesn't hear satisfying answers to those questions for a specific project, then it makes sense for it to recommend the community further incubate or retire that project. The project itself and the community as a whole can respond to those recommendations by providing new, satisfying answers, as I think we saw well-demonstrated in deliberations around what was to be included in the 2.7 release. I don't think it matters what group or person suggests that this or that project, in incubation or release, might be due for some probing questions.

In my view, Sakai 3 is a project in incubation toward which the Product Council is now turning its ponderous, questioning eye. 

Some of what Chuck has written suggests a view of Sakai 2.x and 3.x as separate products that should be managed separately. While that has to be true at some level of detail for such things as code management, release, QA, and maintenance, I strongly support the idea that as a community, we should fully embrace  2.x and 3.x, and pathways from one to the other as a coordinated product/project. If the PC isn't addressing coherence at this broad level, then it's not really living up to its founding purpose. I think the PC should do a better job than it has, but I believe Sakai needs some mechanism to provide better product coherence, and think the PC should evolve to be that mechanism.

The people that founded Sakai—Chuck among them—initiated a project that centered around some important technology, but it also initiated a community, a culture, and practices that were a lasting innovation in themselves, and I hope a more lasting one than the technology alone. I think Sakai 3 has grown organically out of that foundational community, and we've watched as Sakai 3 has become part of the planned roadmaps of major Sakai institutions—Cambridge, GA Tech, Indiana, Berkeley, Cape Town, and more—and attracted significant new energy from institutions like NYU and more to come. Sakai 3's evolution may not match everyone's technical views, it may have moved too fast for some, too slow for others, but it seems to be a fully native growth of the Sakai community, where success relies so much on (sometimes ungainly) community convergence. That same community provides plenty of space for Sakai 2 to live the long, healthy life it is now probably about in the middle of.

I heard David H's call for input and leadership from the Product Council on matters like those under discussion here, but I echo Michael F's observation that not every one on the PC necessarily has the right background to make immediate, solo pronouncements on every matter.

What value the PC can add is probably more a result of its consideration of these matters as a body, which we haven't had a chance to do yet on the specific issue of deprecation that started this thread. Too do what it needs to do, I expect the PC to be more deliberative, rather than a nimble body that makes quick technical judgements. Those tasks, I believe will be addressed more often in RM, QA, and MT, with increasing guidance coming from the community, distilled and expressed through the PC.

I also speak only as myself rather than for the Product Council or rSmart, but trying to show what kind of thinking I take from and bring to those entities.

- Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20100318/01a48817/attachment.html