/
TAG Meeting 2021-06-17

TAG Meeting 2021-06-17

Jul 21, 2021

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

  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)