Agenda

• Housekeeping
• Release cadence - continued
• Building a validation ecosystem
• Project Tanager milestones and discussions

Materials

Participants

Notes

These note complement the slide deck above and make the most sense when read along with the deck.

Housekeeping

• Please apply for 2024-2025 membership if interested in continuing on the TAG. In the comments box, can simply write "current TAG members" instead of providing detailed information.
• Any concern around publicly publishing old meeting notes during the upcoming Tech Docs migration?
  • In theory, following Chatham House rules and not attributing to any individual.
  • No one expressed concerns about publishing older content. At the same time, in general there isn't a need to revisit the older content. Might migrate only the most recent content or as-needed.

Release and Cadence

• Prior TAG conclusion "break-rest-rest" does not work well for state agencies, who like to take breaking changes every other year.
  • Therefore, the Ed-Fi Alliance will adopt a "break-rest-break-rest-..." plan
• Caveat: some domains are well used and need to be protected; others are not widely adopted and may need continued innovation.
  • Widely adopted / very stable: SIS, Assessment, TPDM, Finance, Transcript
  • Less widely adopted: Intervention, Survey, Gradebook, Others. (Initially called "experimental" and "less stable" in the slide deck)
• The "less widely adopted" domains: can we break them in minor releases, so that we can innovate more quickly?
  • Avoid calling these "experimental". Maybe "provisional" better communicates the intent?
  • Clarifying question: what does this mean for backward compatibility.
    • Example: Data Standard 5.1 has a breaking change to Intervention.
      • An integration written in conformance with Intervention from Data Standard 5.0 will fail if applied to an API running Data Standard 5.1
    • If the change was to add a new field to an existing resource, then this is not a "breaking" change: the Ed-Fi API running Data Standard 5.0 would simply ignore the new field.
  • When a vendor has already agreed to support one of domains, the breaking change could bring significant confusion and cost, and prompt organizations to skip minor releases that might have otherwise been useful.
  • Suggested: instead of making breaking changes, follow the Finance domain example.
    • Created a parallel Finance domain and used it for several years.
    • When the parallel was ready, then retired the prior model and kept only the new one.
  • There may be more people using these domains than the Ed-Fi Alliance realizes. Examples from the discussion:
    • South Carolina using Survey
    • Michigan using Intervention

    • CCMR (especially in Texas) using Gradebook

      Ed-Fi Alliance team needs to do more to track usage of domains, so that we're not relying only on anecdotal evidence / individual memory.

  • If using parallel models, how do we label these?
    • Could use an extension, as originally done for Finance or for TPDM.
      • Extension gives a separate namespace, for example compare /ed-fi/surveys  to a hypothetical /ed-fi-survey-2/surveys URL with different data models.
      • Expensive and difficult for the Ed-Fi Alliance Tech Team to maintain releases for multiple extensions.
    • Separate version numbers?
      • Watch out for confusion / proliferation of version numbers.
      • Maybe treat primarily as internal.

      • Does work well with the extension approach.

        The Ed-Fi Tech Team may need to investigate how to streamline managing multiple extensions and releases.

Building a Validation Ecosystem

• Ed-Fi Academy up-coming course on validation includes a sample spreadsheet for documenting validations and business rules, which could be shared with others.
• Sharing validation information can help new organizations startup, and can help vendors better understand expectations.
• Useful to further differentiate these validations:
  • "Sanity checks" that are widely applicable. For example, there is likely a problem if you have 5,000 students in the system and only 1,000 StudentSchoolAssociations. Or, if you have a student born in the future.
  • "Business rules" are typically more state-oriented, often driven by regulations and/or legislative requirements.
• What happened to the sanity check scripts in the old Dashboards?
  • Has not been maintained recently, though the scripts are available to the Ed-Fi Success Team.
  • Older scripts all used the ODS database directly, and we want to de-emphasize that going forward.
  • Suggestion for the Ed-Fi Alliance to consider building an API-driven tool for sanity check validations.
• The Validations API came up: good topic, but not exactly what we're discussing here. That API definition helps exchange information about errors, where this conversation is about the definitions behind the errors.
• Examples of share-able rules:
  • WISEdata Validation Rule List (Google Sheets)
  • Nebraska Adviser Validation Guide (pdf)
• General consensus seemed to be: yes, encourage organizations to share their validation rules broadly.

• Ran out of time to discuss specific mechanisms for sharing this information

  Ed-Fi Alliance staff can brainstorm on how to capture and share this information with the community.

Project Tanager Milestones

• Suggestion to convene a meeting for those who want to engage closely with the designs of Tanager.

  Stephen Fuqua will look into starting a Special Interest Group.

Next Meeting:

• At Tech Congress, 24 Apr 2024