Skip to end of metadata
Go to start of metadata

Notes from face to face meeting of the 2009 Roadmap Development working group in Chicago September 29, 2009



Discussion of the architecture diagram (under background)...

All agreed that this kind of diagram is very useful. The discussion led to the realization that we need several diagrams to serve the interests of our community:

Marketecture diagram - This is intended to be a high level conceptual diagram that represents some combination of current reality and desired future. The current diagram is our marketecture diagram. (Cath added - need to update this diagram to add a box for "Rice Future Rich UI Framework" in the Rich User Interface Services layer. This box got left out when KNS was pulled off to the left side of the diagram.)

Deployment diagram - This is a technically accurate diagram that represents how Rice components are actually deployed. It needs further description but will probably show both physical and logical deployment.

Service diagram - Needs further description

Library version schematic - This will show the actual versions of all the libraries in use (dependencies and original code).

Action Items

Icon

The TRC will discuss these diagrams and take ownership of creating them.



There was a lot of discussion about component modularity. Though there wasn't one clear outcome from this discussion, it was clear that everyone involved favored increased modularity with regard to Rice components. With that in mind, we should be careful about prioritizing and implementing new capabilities and/or enhancements that increase tighter coupling or make it more difficult to decouple over time.

There was a fair bit of discussion about releasing Rice in modular ways. It would increase flexibility to be able to release just KIM, or just KEW without a complete release of Rice. The down side to release modularity is that it would take more effort in QA and would potentially increase complexity in other ways.

Tentative Resolutions

Icon

# At present there is no way to release individual components of Rice. There are circular dependencies that need to be resolved (for example KEW depends on KIM, and KIM depends on KEW). Near-term releases of Rice will be planned with a full Rice release model where all of Rice is released and versioned as one thing.

# We will prioritize work to ensure that over time, Rice becomes more decoupled so that at any point in time, individual Rice components could be released independently of any other Rice component. Once this state is reached, we may continue to release Rice as one big release, but at that point we would have the flexibility to release one or more of the components with it's own version number. The decision to do this would be made by the Rice ARC/TRC. 

 


Action Items

Icon

* *Eric* Work the concept of modular releases into the release cycle part of the roadmap. Particularly in how we would leverage milestone releases to increase flexibility.




Other Action Items

Icon

* *Chris* - The group believes accessibility standards for Kuali applications should be set by the Foundation. Chris will speak with Jennifer about making this the responsibility of the new QA directory to recommend accessibility standards that can be approved by the Foundation board.

* *Eric / Jerry* - Diagram KNS and it's components & share it with the group. The group believes this diagram will be helpful while prioritizing KNS related issues.

* *Leo* - Merge KRRM52 & KRRM46 into ONE research item with a target of v1.1. That research item will include the notion of how we will manage service contracts / service governance going forward. Note from Chris: I've already combined the two and assigned the resulting issue to Leo for elaboration on the specific research required and desired output from that research.

 * *Leo* - Add one roadmap item for v2.x that introduces independent component modularity. It could be one item for each of the components (KNS, KEW, etc.) so that each could be independently prioritized.