2007-06-10 Follow up meeting notes

(Apologies for any misrepresentations. I scribbled these down for my own use rather than as an official minutes taker. Please edit with abandon. – Ray)

Ray's goal: A fair open agreed-upon process for improving shared services.

Issues to be addressed:

Fixing bugs.
Providing needed functionality.
Cleaning out wrong functionality due to disconnect from functionally driven process.
Fixing poor performance due to disconnect from testing process.
Replacing the service when better alternatives exist.
Simplifying interfaces to cut down on development overhead.

Lance: The problem to solve is risk mitigation with shared ownership.

Ray: John Norman has given a good description of a healthy development team.

Stephen: Other immediate problems are lack of purposeful design, and unknowingly competing efforts.

Sean: We should treat our governance goal like our technical goals: sustainability in an iterative process. We can set a process in motion and then return to it with better knowledge.

John: A smaller group should be able to move these pre-conference meeting topics forward more often with more solid results and less revisiting of old arguments. It can grow gradually and perhaps split into more focused subgroups early on.

Lance: We don't want to repeat the Requirements group, which did great work but had no resources to act on its conclusions.

Aaron: My goal is a developer's goal: a framework that doesn't get in my way. It needs to help instead of slowing me down.

John: Decisions have been informed by Requirements and discussion, but there still needs to be a process to deal with disputes.

Ian: Let's get the process in place to decide how contributions are judged, improved, and merged in.

Sean: If we take the lightweight branch approach, all is not lost even if you're denied immediate trunk access: you and others can work from the branch. To keep from slowing progress too much, the rule should be "No veto without justification and a suggestion for an approach that wouldn't be vetoed."

??: One thing that sways the validity of a branch is if it's a cross-institutional team.

(Ray, thinking later: Since the most efficient work is done by small cross-functional teams, it can be difficult in practical terms to get more than two institutions represented. There get to be too many constraints. But much of that problem can be made up for by doing cross-institutional research and making sure there's cross-institutional review and QA.)

Mara: If the goal here is just improving the framework, it's OK that you seem to be talking about a programmer-centric group. If the goal is broader – for example, release management – then that's not enough.

Lance: Kuali has a functional council and a technical council. Both are actively involved in subprojects. Members are appointed by participating institutions.

John: But Kuali has a narrow focus on a better understood functional domain. Sakai is broader.

Chuck: Not so much, if we concentrate on a "core": site setup and resources, let's say.

Lance: Here's a possible approach to the resources issue: The functional council makes a decision. Then each council member returns to their institution and explains why resources need to be donated.

Mara: A functional council makes most sense in specific problems domains. It often needs to be wider than a single tool.

Lance: I'll make a strawman proposal: Don't accept any code into the enterprise bundle without shared ownership.

??: We need a definition of "shared ownership".

Aaron: Let's take an iterative approach with definite targets. Get a group to quickly decide on what "the kernel" is. Then define requirements for the kernel. Then deal with them.

Lance: Wants a metagroup that will establish principles and enable the formation of framework and other horizontal teams.

Ray: But we seem to already agree on those principles. The only thing we're missing is a way to take the last step of the process: getting the code into the trunk. Why not start with the unsolved problem?

(Note taking ends in a flurry of flying feathers. Lance agreed that the metagroup group should be able to come to conclusions pretty quickly, probably within a month. He also pointed out that a framework-oriented group doesn't have to wait for permission to start.)