TAG Meeting 2021-06-17
Attendees
First Name | Last Name | Organization |
Rohith | Chintamaneni | Arizona Department of Education |
David | Clements | Ed-Fi Alliance |
Mindy | DuFault | Infinite Campus |
LaQuinta | Extine | Leon County Schools |
Stephen | Fuqua | Ed-Fi Alliance |
David | Hefley | Nebraska Department of Education |
Eric | Jansson | Ed-Fi Alliance |
Vinaya | Mayya | Ed-Fi Alliance |
Jim | McKay | Instructure |
Doug | Quinton | PowerSchool |
Daniel | Ralyea | South Carolina Department of Education |
Andrew | Rice | Education Analytics |
Audrey | Shay | Wisconsin Department of Public Instruction |
Grishma | Shrestha | Infinite Campus |
Molly | Stewart | Indiana University INsite |
John | Watson | San Diego County Office of Education |
Agenda
- Defining actions on Level-1 error messages
- Discuss TAG priorities: data model improvements
- Enumerate the ones the TAG wants to discuss
- Determine if there is overlap with the current agenda for the data
- Operational context – discussion of how to move this forward
Materials
Results of TAG survey on priorities
Specific data model improvements (e.g., descriptors, course transcript domain, analytics domain, intervention domain) | 6 |
Operational context - moving it forward / user interface | 5 |
Tools and support for data flowing out of Ed-Fi APIs | 4 |
Making the Ed-Fi API usable by a Web applications directly (e.g., GraphQL, OAuth/OpenID) | 3 |
When to make breaking changes to the API surface / unblocking significant data model improvements | 3 |
API Publisher as a core tool (replicates data ODS-to-ODS via API) | 2 |
Improvements to certification (e.g., greater granularity, data elements required - e.g. current grades) | 1 |
Open source community maturity (e.g., talent directory, improved marketing) | 0 |
Notes
Level 1 Error messages
There was a lengthy discussion, taking most of the meeting. Some key points / attempts to capture main points:
- A registry is at best an OK idea, but since error conditions/message have no unique identity, a registry will likely be hard to use. It may be possible to enhance a registry with a search or discovery UX, but that may not achieve the usability needed for district staff.
- Stronger options included:
- Tagging error conditions with unique codes, so that client systems can override or supplement them for their users
- Making error messages more clear to district staff / less developer-centric
- The difficulty of introducing specific error codes into the ODS architecture was reviewed again
- However, it was noted that it might be possible/easier to do this with 403 errors / authorization errors, due to the ODS architecture
- It was also generally agreed that authorization errors are one of the (if not "the") major problem areas.
- Actions: Eric to write up a possible spike/effort to try our a more nuanced error system in this area, as a Tracker ticket (DONE - see - ODS-5001Getting issue details... STATUS )
Data model improvements
There was an effort to gather these at the meeting:
- Course Transcript –
- key and referential integrity
- Course attributes, e.g. CA A-G flags, etc.
- Student Assessment
- tie to an org for authorization
- alternative student IDs for data linking
- Reducing referential integrity in other domains
- e.g., Finance, TPDM, Assessment
- Analytics domain
- e.g.: value add metrics, progress over time, etc.
- Parent surveys
- CTE domain
- Section as independent of time/place/course grouping
Operational Context advancement
Was not discussed, but Ander Rice to help frame at the next meeting (action)