Phases:
A. Person
Basic bio/demo data
Revision to first draft?
Advanced bio/demo data
Undergraduate school
Custom requests
B. Application
Basic application data
Advanced application data
Custom requests
C. Interaction/Activity/Source Data (Inquiry Details)
Basic interaction activity (incl. program of interest)
Advanced interaction activity
Messages
Custom interaction activity
D. Messages (Deliver Campaigns)
Phase | School/Instance | Delivery Date (Slate Team) | Delivery Date (Denodo Team) |
---|---|---|---|
A1 | Vet | ||
B1 | Vet | ||
C1 | Vet | ||
D1 | Vet | ||
A1 | TUSMGP | ||
B1 | TUSMGP | ||
C1 | TUSMGP | ||
D1 | TUSMGP | ||
A1 | NUTR | ||
B1 | NUTR | ||
C1 | NUTR | ||
D1 | NUTR |
What does “done” look like?
- Query in Slate is built and configured with web services
- Denodo “view” is built?
- Data refresh is scheduled/ongoing
- Field definitions are added
- Query description is added
- Access/permissioning is configured?
Notes:
Do we need a “beta” period?
Feedback from stakeholders/clients--how to factor that into the project plan?
How do we handle ongoing requests/concerns
Capturing the next “core fields” for the University
Questions for Group meeting/Matt
What happens to old data?
More access to update fields?
Who is in charge of naming fields/naming conventions?
Where do we solve the “fuzzy” definitions, in Slate or Denodo? To the “university” standard?
e.g. socioeconomic indicator
Add Comment