TAG Meeting 2021-07-15

Owned by Eric Jansson
Last updated: Jul 22, 2021 by Ann Su (Unlicensed)

Attendees

First NameLast NameOrganization
RohithChintamaneniArizona Department of Education
Rosh  DhanawadeIndiana University INsite
MindyDuFaultInfinite Campus
LaQuintaExtineLeon County Schools
StephenFuquaEd-Fi Alliance
Jean-Francois  GuertinEdWire
EricJanssonEd-Fi Alliance
VinayaMayyaEd-Fi Alliance
JimMcKayInstructure
DougQuintonPowerSchool
DanielRalyeaSouth Carolina Department of Education
MaxReinerNebraska Department of Education
AndrewRiceEducation Analytics
JimRobertsonPowerSchool
AudreyShayWisconsin Department of Public Instruction
GrishmaShresthaInfinite Campus
SayeeSrinivasanEd-Fi Alliance
MollyStewartIndiana University INsite
JohnWatsonSan Diego County Office of Education
PatrickYohoInnovateEDU Inc

Agenda

  1. Updates on past topics and actions related to those
    1. Level 1 error direction – see https://tracker.ed-fi.org/browse/ODS-5001
    2. Data model – proposed changes – see TAG Meeting 2021-06-28 - Subgroup on Data Standardization
  2. Operational context – moving it forward and UX to support it
    1. Andrew Rice has offered to present community work and needs in this area
  3. Data out issues (3rd priority raised by the TAG)
    1. “Story workshop” format for this, to capture ideas
    2. 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-5024 - Getting 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.