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 - ODS-5024Getting issue details... STATUS
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.