TAG Meeting 2021-06-17

Owned by Eric Jansson
Last updated: Jul 21, 2021

Attendees

First NameLast NameOrganization
RohithChintamaneniArizona Department of Education
DavidClementsEd-Fi Alliance
MindyDuFaultInfinite Campus
LaQuintaExtineLeon County Schools
StephenFuquaEd-Fi Alliance
DavidHefleyNebraska Department of Education
EricJanssonEd-Fi Alliance
VinayaMayyaEd-Fi Alliance
JimMcKayInstructure
DougQuintonPowerSchool
DanielRalyeaSouth Carolina Department of Education
AndrewRiceEducation Analytics
AudreyShayWisconsin Department of Public Instruction
GrishmaShresthaInfinite Campus
MollyStewartIndiana University INsite
JohnWatsonSan Diego County Office of Education

Agenda

  1. Defining actions on Level-1 error messages
  2. Discuss TAG priorities: data model improvements
    1. Enumerate the ones the TAG wants to discuss
    2. Determine if there is overlap with the current agenda for the data
  3. 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-5001 - Getting 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)