TAG Meeting 2021-07-15
Attendees
First Name | Last Name | Organization |
Rohith | Chintamaneni | Arizona Department of Education |
Rosh | Dhanawade | Indiana University INsite |
Mindy | DuFault | Infinite Campus |
LaQuinta | Extine | Leon County Schools |
Stephen | Fuqua | Ed-Fi Alliance |
Jean-Francois | Guertin | EdWire |
Eric | Jansson | Ed-Fi Alliance |
Vinaya | Mayya | Ed-Fi Alliance |
Jim | McKay | Instructure |
Doug | Quinton | PowerSchool |
Daniel | Ralyea | South Carolina Department of Education |
Max | Reiner | Nebraska Department of Education |
Andrew | Rice | Education Analytics |
Jim | Robertson | PowerSchool |
Audrey | Shay | Wisconsin Department of Public Instruction |
Grishma | Shrestha | Infinite Campus |
Sayee | Srinivasan | Ed-Fi Alliance |
Molly | Stewart | Indiana University INsite |
John | Watson | San Diego County Office of Education |
Patrick | Yoho | InnovateEDU Inc |
Agenda
Updates on past topics and actions related to those
Level 1 error direction – see https://tracker.ed-fi.org/browse/ODS-5001
Data model – proposed changes – see TAG Meeting 2021-06-28 - Subgroup on Data Standardization
Operational context – moving it forward and UX to support it
Andrew Rice has offered to present community work and needs in this area
Data out issues (3rd priority raised by the TAG)
“Story workshop” format for this, to capture ideas
See prioritization from TAG Meeting 2021-06-17
Materials
Notes
Level 1 errors
String localization is anther possibility: some error messages are provided by the ODS, and allowing these to be locally customized could help. Raised as
The large size of the technical solution was discussed again: identifying unique cases will addcomplexity and bulk to the code
The question of whether to surface a code or a better error message was raised. In general, the suggestion was to do both: have a better "default" error, but use a code to allow for localization or overrides.
there is a possibility that the code and message aren't for some reason matched well which could cause confusion....like an error code that's specific but a message that's general.
Remove ODS internals from these (e.g., "-UZI" and other elements that API users don't see)
Should there be a link to documentation? Probably go with an error code first to support localization.
Discussion of operational context
An overview was provided by Andrew Rice - see slides. A few major points of discussion:
Are there current common areas of need? Attendance, Behavior was cited, even Race is not always federal.
General discussion of the need for a code-mapping system. Pointed out that the ODS has an interop schema already.
General agreement that operational context likely needs to support multiple contexts in the long, but for now solving for a local and state (2 contexts) seems like it would address most problem areas. Some discussion on if the state is a unified context or not: it could/should be, but there can be challenges to its ability to make uniform data requests.