Conference Call Info: Video Bridge 22102
- Dial the Auto Attendant at 812-856-7060
- Enter the conference number (22102) followed by the # key (e.g., 22102#)
Attendees
Who |
With |
Attended |
---|---|---|
Benn Oshrin |
Internet2 / Various |
|
Eric Westfall |
Indiana U / Kuali |
|
Jeremy Rosenberg |
SFU |
|
Jessica Coltrin |
U of Arizona / Kuali |
|
Jimmy Vuccolo |
PSU |
|
Renee Shuey |
PSU |
|
RL "Bob" Morgan |
U. Washington / Internet2 |
|
Steven Carmody |
Brown |
|
Matt Sargent |
Indiana U / Kuali |
|
Agenda
- Introductions/Roll Call
- All - Status Updates
- Project Proposal - Eric/Matt/Jessica
- Strategy Group Updates - Bob
Notes
eric - I've invited Jessica Coltrin (the rice pm) to join us since she's helping with the framework document
bob - On the strategy group call last week, deadra from berkley, noted that she'd like to add some folks to this group in the future due to their interest in the work we're doing. i'll follow up with her. There has been talk that the Matching logic could be on it's own sub-project or put as priority 1 for a registry, but that doesn't sound too different from the directions we've talk about thus far.
eric - so the strategy group feels this is a good place to start?
bob - yes, the discussion also wondered if that would be too small of a function...
eric - i think we need to look at that as if it should be able to be set on top of different registries or if it's for a specific. catering to difference would probably give it a much wider appeal
benn - it sounded like it's almost a requirement that it be adaptable to any registry through API's etc. If we're having trouble getting moving on the bigger pieces, a smaller one like this could be a good place to start.
eric - were there specific folks that displayed interest in this and contributing?
bob - deadra for sure, kind of looking at UC Berkley and what it would take to get their investment
benn - yeah, i think next week we may have folks from Berkley. There are other parties even w/in the UC schools, it seems the identity match project would be easy enough of a place to start and that the functional/technical talks on that would need to happen
bob - yeah, we need to get to that place
benn - seems there's an API and an engine portion, but it may not be worth separating those two out
eric - so getting to the deliverables of that sub-project is on our best interest
bob - other than that I think that covers the SnL updates, benn?
benn - yup, that covers it
eric - we've started putting together a framework, any other items before we dive into that?
group - nope
eric - there's a link out there, but we've started carving out pieces of it. matt and jessica. is this the kind of thing we're looking for? obviously we don't have timelines and high level estimates, etc. put together as if Kuali were the caretaker
bob - obviously the project part includes a lot of material from the SnL overall structure, for the folks that we'd want to have looking at this, it's good to have that in there. I might suggest adding something in there that this is the intended structure for the other work-streams as well, not just the registry.
eric - you mentioned you were working on the architecture, could we include that in this? maybe a high level technical vision? should we even put those in this doc?
bob - I think having it be detail free isn't going to get much interest from those on the fence, but having them at least noted up front would be good to have it. I found myself writing a vision for the overall activity and see that now being the right way to start to ground the rest of the projects. it would lay out the principals and this document could reference that.
eric - that's what I was thinking, it'd reference the reference architecture and then mention any diversions/differences
bob - sounds good to go with adding in as much as we can then pull out what we don't need later
eric - need to layout the why? question as well as the what? the project might look like along with what the stages might be. if we're targeting those that want to think about investing, we need some of the CIO marketing details in there
bob - yeah, i guess up to a point we should include that, but maybe that's more for the overall materials for the IdM project....
eric - maybe the marketing needs to be separate, still wouldn't hurt to draft it.
matt - summary jive
renee - would like maybe to have a section of why build a new registry? supporting real time provisioning...another important part is to support batch and being more service oriented
eric - yup, the mention of modularity is along those lines, but we need to emphasize that
renee - yes, a separate bullet for that would be nice
bob - part of the goals pushing forward, i think we need to continue with Kuali Rice as the caretaker, so we should make crazy guesses to effort required and perspective dates/timeline. especially when we go looking for partners. that's a hard part, but getting that and engaging the strategy group would be nice. got to get to that point so that we have it out there for people to look at.
renee - yeah, that's the first thing we need to know so that we can make decisions
bob - that's right and I think the PSU experience would be super to have for a benchmark
renee - I can do that for sure, is it just development though?
bob - requirements gathering is a big part of this project so that would nice to include in the estimates
eric - can you hook up with Matt to work on this?
renee - sure, i'll snag some time off of Matt's calendar
eric - on thing would be to have a break out of what has to be done in series or what can be done in parallel. is everyone hearing that matching/merging/splitting is foremost in most folks minds? does it have to be first in the list? but is it more important than the registry part of our Registry project?
bob - I think UofA mentioned Matching as a big thing and Berkely agrees, but UW doens't see that being a big piece...it kind of depends on who raises their hand at the moment (or brings the funding)
renee - I can't really see them being separated (matching and the registry)
jimmy - we ended up having to write the algorithms...
bob - so it seems that those algorithms and making them plug-able to any registry would be the question we could look at