Skip to content

Maintenance Meeting Schedule

Jump to bottom
David Aguiar edited this page Aug 31, 2026 · 2 revisions

Maintenance Meeting Schedule

Draft for discussion and revision by the DCAT Interagency Maintenance Team and the Data.gov team.

This page describes the proposed meeting schedule for operating the DCAT-US v3.0 maintenance process.

The maintenance meeting structure is intended to support:

  • Continuous issue triage
  • Semi-annual schema review
  • Release planning
  • Agency feedback
  • Documentation coordination
  • Release communications
  • Annual retrospective review
  • Follow-up tracking

The DCAT Interagency Maintenance Team governs schema maintenance decisions. The Data.gov team at GSA maintains the DCAT-US repository and coordinates the maintenance cycle.

Meeting Schedule Summary

Meeting Cadence Primary Audience Purpose
Continuous Issue Triage Bi-weekly or monthly Data.gov team Review, label, and route new issues
Pre-Cycle Planning Twice per year Data.gov team + DCAT Interagency Maintenance Team leads Prepare milestone issues for review
DCAT Interagency Maintenance Team Schema Review Twice per year DCAT Interagency Maintenance Team + Data.gov team Review prioritized issues and assign dispositions
Agency Feedback Meeting As needed, likely once or twice per release cycle Selected agencies + Data.gov team + Maintenance Team representatives Gather implementation impact feedback
Release Readiness Meeting Twice per year Data.gov team + Maintenance Team representative Confirm PRs, documentation, release notes, and outreach readiness
Post-Release Outreach Twice per year Agencies, Data.gov team, Maintenance Team representatives Share release changes and answer agency questions
Annual Retrospective Annually in July DCAT Interagency Maintenance Team, Data.gov team, selected agencies Review validation trends, lessons learned, and priorities for the next cycle

Annual Maintenance Calendar

The following calendar provides a suggested annual operating rhythm for DCAT-US v3.0 maintenance.

Month Activity
Ongoing Continuous issue triage within two weeks of issue submission
January Cycle 1 pre-cycle planning and milestone review
February Cycle 1 DCAT Interagency Maintenance Team schema review
February/March Agency feedback meeting, if needed
March Cycle 1 release readiness meeting
March/April Spring release, release notes, and outreach
April/May Monitor agency questions and implementation feedback
May Cycle 2 pre-cycle planning and milestone review
June Cycle 2 DCAT Interagency Maintenance Team schema review
June Agency feedback meeting, if needed
Late June/July Cycle 2 release readiness meeting
July Summer release aligned with the M-25-05 annual compliance reference date
July Annual retrospective
August Share compliance support summary and next-cycle priorities, if applicable
September–December Continue triage, documentation updates, issue review, and implementation support

Continuous Issue Triage Meeting

Purpose

The Continuous Issue Triage Meeting supports rolling review of new DCAT-US GitHub issues and related items submitted through other channels.

Issues are triaged as they are submitted, rather than batched to a specific time of year.

The Data.gov team applies a classification label to each new issue within two weeks of submission.

Cadence

Suggested cadence:

  • Bi-weekly if issue volume is high
  • Monthly if issue volume is low
  • Asynchronous triage with a monthly checkpoint if issue volume is minimal

Duration

Suggested duration:

  • 30 minutes

Recommended Participants

Recommended participants include:

  • Data.gov product or program lead
  • DCAT-US repository maintainer
  • Data.gov technical representative
  • Documentation representative, if applicable
  • Schema team representative, if applicable

Agenda

A typical Continuous Issue Triage Meeting may include:

  1. Review new GitHub issues submitted since the last triage
  2. Review issues received through Zendesk, Data.gov Help, CDO Council channels, office hours, or other channels
  3. Apply classification labels:
    • bug
    • enhancement
    • question
  4. Determine whether each issue is:
    • Schema-related
    • Documentation-related
    • Implementation guidance-related
    • Harvesting-related
    • Data.gov product-related
    • Out of scope
  5. Assign issues to milestones, if appropriate
  6. Identify issues needing DCAT Interagency Maintenance Team review
  7. Identify time-sensitive issues
  8. Identify issues that need more information
  9. Route issues to other processes, if needed

Outputs

Expected outputs include:

  • New issues labeled
  • Issues routed to the appropriate process
  • Issues assigned to milestones, if appropriate
  • Issues needing more information identified
  • Issues requiring DCAT Interagency Maintenance Team review identified
  • Out-of-scope issues closed or redirected
  • Follow-up actions assigned

Pre-Cycle Planning Meeting

Purpose

The Pre-Cycle Planning Meeting prepares for an upcoming maintenance release cycle.

This meeting is used to review candidate issues, confirm release scope, identify documentation work, and prepare materials for DCAT Interagency Maintenance Team review.

Cadence

Twice per year:

  • Cycle 1 pre-cycle planning in January or early February
  • Cycle 2 pre-cycle planning in May or early June

Duration

Suggested duration:

  • 50 minutes

Recommended Participants

Recommended participants include:

  • Data.gov team
  • DCAT Interagency Maintenance Team leads or designated representatives
  • DCAT-US repository maintainer
  • Schema team representative
  • Documentation lead
  • Communications or outreach representative, if applicable

Agenda

A typical Pre-Cycle Planning Meeting may include:

  1. Confirm the upcoming release cycle and target timeline
  2. Review issues assigned to the upcoming cycle milestone
  3. Identify candidate issues for Maintenance Team discussion
  4. Identify likely non-breaking changes
  5. Identify potential breaking changes
  6. Identify documentation issues needing resolution
  7. Identify issues requiring agency feedback
  8. Identify issues requiring security considerations notes
  9. Confirm whether any changes may affect:
    • accessRestriction
    • useRestriction
    • cuiRestriction
  10. Confirm draft agenda for the Maintenance Team schema review
  11. Assign preparation tasks and owners

Outputs

Expected outputs include:

  • Draft issue review agenda
  • Candidate release scope
  • List of issues requiring Maintenance Team review
  • List of issues requiring agency feedback
  • Documentation worklist
  • Security considerations flags, if applicable
  • Proposed release timeline
  • Assigned preparation tasks

DCAT Interagency Maintenance Team Schema Review

Purpose

The DCAT Interagency Maintenance Team Schema Review is the primary governance meeting for reviewing prioritized DCAT-US v3.0 maintenance issues.

During this meeting, the DCAT Interagency Maintenance Team reviews issues in the relevant release cycle milestone and assigns dispositions.

Cadence

Twice per year:

  • Cycle 1 schema review in February
  • Cycle 2 schema review in June

Duration

Suggested duration:

  • 60 minutes for a standard review
  • 90 minutes if there are multiple high-impact issues or potential breaking changes

Recommended Participants

Recommended participants include:

  • DCAT Interagency Maintenance Team members
  • Data.gov team
  • DCAT-US repository maintainer
  • Schema team representative
  • Documentation representative
  • Invited agency subject matter experts, if needed

Agenda

A typical Schema Review Meeting may include:

  1. Welcome and meeting objectives
  2. Review release cycle timeline
  3. Review issue disposition options
  4. Review prioritized milestone issues
  5. For each issue, discuss:
    • Issue summary
    • Issue type
    • Affected field or schema area
    • Implementation impact
    • Validation impact
    • Documentation impact
    • Whether the change is breaking or non-breaking
    • Whether agency feedback is needed
    • Whether a deprecation notice is needed
  6. Assign disposition to each reviewed issue
  7. Confirm approved PR list
  8. Confirm deferred issue list
  9. Confirm documentation-only issues
  10. Confirm issues needing more information
  11. Confirm follow-up actions

Issue Dispositions

The DCAT Interagency Maintenance Team may assign one of the following dispositions:

Disposition Meaning
Approved for PR The issue should move forward as a pull request
Deferred The issue should be reconsidered in a future cycle
Closed as won’t fix The issue will not be addressed through a schema or documentation change
Needs more information Additional information is needed before a decision can be made
Documentation update only The issue should be addressed through documentation, examples, FAQs, or guidance rather than a schema change

Outputs

Expected outputs include:

  • Disposition assigned to each reviewed issue
  • Approved PR list
  • Deferred issue list
  • Closed issue list
  • Documentation update list
  • Issues needing more information
  • Issues requiring agency feedback
  • Deprecation notice list, if applicable
  • Follow-up actions and owners

Agency Feedback Meeting

Purpose

Agency Feedback Meetings provide an opportunity to gather practical implementation feedback from selected agencies before final maintenance decisions are made.

These meetings are especially useful when proposed changes may affect agency metadata workflows, validation behavior, harvesting, documentation, or existing data.json implementations.

Cadence

As needed.

Suggested timing:

Timing Purpose
February or March Gather feedback on Cycle 1 issues, proposed clarifications, or deprecation notices
June Gather feedback on Cycle 2 issues, eligible breaking changes, migration guidance, or retrospective topics
July Support annual retrospective discussion, if needed

Agency feedback meetings may not be needed for every release cycle.

Duration

Suggested duration:

  • 50 minutes for standard feedback discussions
  • 60–90 minutes for multiple high-impact issues or retrospective feedback

Recommended Participants

Recommended participants include:

  • Selected agency metadata or data inventory leads
  • Selected agency technical implementation leads
  • Selected agency policy or data governance representatives
  • Data.gov team members
  • DCAT Interagency Maintenance Team representatives
  • Documentation contributors, if relevant
  • Schema team representatives, if relevant

Agency Selection Criteria

Agencies may be invited based on:

  • Active DCAT-US 3 implementation work
  • High-volume Data.gov publishing
  • Complex or specialized metadata
  • Different metadata management approaches
  • Active harvest source transitions
  • Relevant implementation experience with the issue under review
  • Validation or harvesting patterns relevant to the issue under review

Agenda

A typical Agency Feedback Meeting may include:

  1. Welcome and purpose
  2. Review issue or topic being discussed
  3. Explain maintenance context and release cycle timing
  4. Present proposed change, clarification, or deprecation notice
  5. Discuss agency implementation impacts
  6. Discuss validation, harvesting, or display considerations
  7. Identify documentation or guidance needs
  8. Identify risks, blockers, or timing concerns
  9. Summarize feedback
  10. Confirm follow-up actions

Outputs

Expected outputs include:

  • Agency feedback summary
  • Implementation impact notes
  • Documentation recommendations
  • FAQ topics
  • Migration guidance needs
  • Examples or edge cases
  • Risks or blockers
  • Issues requiring additional review
  • Recommendations for Maintenance Team consideration

Release Readiness Meeting

Purpose

The Release Readiness Meeting confirms that approved changes, documentation updates, release notes, changelog entries, and outreach materials are ready before a release is tagged and communicated.

Cadence

Twice per year:

  • Cycle 1 release readiness in March
  • Cycle 2 release readiness in late June or early July

Duration

Suggested duration:

  • 50 minutes

Recommended Participants

Recommended participants include:

  • Data.gov team
  • DCAT-US repository maintainer
  • Schema team representative
  • Documentation lead
  • DCAT Interagency Maintenance Team representative
  • Communications or outreach representative, if applicable

Agenda

A typical Release Readiness Meeting may include:

  1. Confirm target release date
  2. Review approved pull requests
  3. Confirm PRs are ready to merge
  4. Confirm documentation updates are complete or tracked
  5. Confirm examples have been validated
  6. Confirm changelog entry is drafted
  7. Confirm GitHub release notes are drafted
  8. Confirm whether conformsTo URI requires updating
  9. Confirm security considerations notes are included, if applicable
  10. Confirm deprecation notices are included, if applicable
  11. Confirm 90-day grace period language is included, if applicable
  12. Confirm agency outreach message is ready
  13. Confirm post-release support plan
  14. Confirm release decision

Release Readiness Checklist

  • Issues assigned to the cycle milestone have been reviewed.
  • Issue dispositions have been documented.
  • Approved pull requests are ready to merge.
  • Breaking changes have received prior deprecation notice, if applicable.
  • Minimum 90-day agency implementation window has been considered, if applicable.
  • Security considerations notes are included for changes touching:
    • accessRestriction
    • useRestriction
    • cuiRestriction
  • Documentation updates are complete or tracked.
  • Example records have been validated against the current schema.
  • Changelog entry is drafted.
  • GitHub release notes are drafted.
  • conformsTo URI update decision has been confirmed.
  • Agency outreach message is drafted.
  • Grace period language is included, if applicable.
  • Deprecation notice language is included, if applicable.

Outputs

Expected outputs include:

  • Release readiness decision
  • Final PR merge list
  • Final documentation checklist
  • Changelog text
  • GitHub release notes
  • Outreach message
  • Deprecation notices, if applicable
  • Grace period language, if applicable
  • Confirmed release date
  • Post-release follow-up plan

Post-Release Outreach

Purpose

Post-Release Outreach communicates release changes to agencies and provides a forum for implementation questions.

Outreach may occur through GitHub release notes, CDO Council channels, the Data.gov mailing list, DCAT Interagency Info Sharing Sessions, CDO Council touchpoints, or other appropriate channels.

Cadence

Twice per year:

  • After Cycle 1 spring release
  • After Cycle 2 summer release

Timing

Release notes should be published within two weeks of the release tag.

A discussion or presentation may occur within two to four weeks after the release, if needed.

Recommended Participants

Recommended participants may include:

  • Data.gov team
  • DCAT Interagency Maintenance Team representatives
  • Agency metadata or data inventory leads
  • Agency technical implementation leads
  • CDO Council representatives
  • Documentation contributors, if needed

Outreach Topics

Post-release outreach may include:

  • Release version and date
  • Summary of changes
  • Schema updates
  • Documentation updates
  • Bug fixes
  • Enhancements
  • Clarifications
  • Deprecation notices
  • Grace period information
  • Migration guidance, if applicable
  • Recommended agency actions
  • Where to ask questions
  • Where to submit GitHub issues

Outputs

Expected outputs include:

  • Release notes published
  • Outreach message sent
  • Agency questions captured
  • Follow-up issues filed, if needed
  • FAQ updates identified
  • Implementation blockers documented
  • Office hours topics identified
  • Info Sharing Session topics identified

Annual Retrospective Meeting

Purpose

The Annual Retrospective Meeting reviews implementation experience, validation trends, documentation gaps, agency blockers, release process lessons learned, and priorities for the next annual maintenance cycle.

The retrospective is an implementation support activity and is not an enforcement activity.

Cadence

Annually.

Timing

July, as part of Cycle 2.

Duration

Suggested duration:

  • 60–90 minutes

Recommended Participants

Recommended participants include:

  • DCAT Interagency Maintenance Team members
  • Data.gov team members
  • Schema team representatives
  • Documentation contributors
  • Selected agency representatives
  • Agency metadata or data inventory leads
  • Agency technical implementation leads
  • Agency policy or data governance representatives
  • Data.gov analytics or monitoring representatives familiar with New Relic data
  • Harvesting or validation subject matter experts

Agenda

A typical Annual Retrospective Meeting may include:

  1. Welcome and objectives
  2. Review of the maintenance year
  3. Review Cycle 1 release activities
  4. Review Cycle 2 release activities
  5. Review harvest validation error trends
  6. Review New Relic data
  7. Identify systemic field-level error patterns
  8. Review GitHub issue trends
  9. Review agency feedback and blockers
  10. Review documentation and guidance gaps
  11. Review release communications and outreach
  12. Discuss annual compliance support summary
  13. Identify lessons learned
  14. Identify priorities for next annual cycle
  15. Confirm follow-up actions and owners

Outputs

Expected outputs include:

  • Annual retrospective notes
  • Annual compliance support summary
  • List of systemic validation or implementation issues
  • GitHub issues filed for schema clarification or guidance updates
  • Documentation update tasks
  • FAQ update tasks
  • Recommended agency support activities
  • Lessons learned
  • Priorities for the next annual maintenance cycle
  • Updates to maintenance process documentation, if needed

Meeting Relationship to Existing DCAT Engagement Forums

The maintenance meetings are separate from, but connected to, existing DCAT interagency engagement forums.

DCAT Interagency Q&A Office Hours

Office hours may surface:

  • Field interpretation questions
  • Validation issues
  • Implementation blockers
  • Recurring agency questions
  • Potential FAQ topics
  • Issues that should be filed in GitHub

Office hours are not a formal maintenance governance meeting, but issues raised there may feed into the maintenance process.

DCAT Interagency Info Sharing Session

The monthly information sharing session may be used to:

  • Share release updates
  • Present proposed changes
  • Demonstrate updated guidance
  • Discuss implementation patterns
  • Gather high-level agency feedback
  • Identify agencies interested in deeper maintenance participation

CDO Council Touchpoints

CDO Council touchpoints may be used to:

  • Communicate release notes
  • Share deprecation notices
  • Discuss broader implementation impacts
  • Gather agency feedback on major proposed changes
  • Support awareness of annual retrospective findings

Suggested First-Year Meeting Plan

For the first year of the maintenance process, the meeting structure may be treated as a pilot.

Pilot Goals

The first-year meeting pilot should help determine:

  • Whether the meeting cadence is appropriate
  • Whether issue triage within two weeks is feasible
  • Whether schema review meetings have enough time
  • Whether agency feedback meetings are useful
  • Whether release readiness meetings reduce release risk
  • Whether outreach meetings help agencies understand changes
  • Whether the retrospective identifies useful next-cycle priorities

First-Year Meeting Plan

Timeframe Meeting
Ongoing Continuous Issue Triage
January or early February Cycle 1 Pre-Cycle Planning
February Cycle 1 Schema Review
February or March Cycle 1 Agency Feedback Meeting, if needed
March Cycle 1 Release Readiness
March/April Cycle 1 Post-Release Outreach
May or early June Cycle 2 Pre-Cycle Planning
June Cycle 2 Schema Review
June Cycle 2 Agency Feedback Meeting, if needed
Late June or July Cycle 2 Release Readiness
July Cycle 2 Post-Release Outreach
July Annual Retrospective

Meeting Documentation

Each maintenance meeting should have enough documentation to support transparency and follow-up.

Meeting documentation may include:

  • Agenda
  • Attendees
  • Issues reviewed
  • Decisions or dispositions
  • Follow-up actions
  • Owners
  • Due dates
  • Links to GitHub issues
  • Links to pull requests
  • Links to documentation updates
  • Links to release notes
  • Notes on agency feedback or implementation impacts

Meeting Notes Template

The following structure may be used for meeting notes.

# Meeting Notes

## Meeting Name

## Date

## Participants

## Purpose

## Agenda

## Issues or Topics Reviewed

## Decisions

## Follow-Up Actions

| Action | Owner | Due Date | Status |
|---|---|---|---|

## Related Links

- GitHub issues:
- Pull requests:
- Documentation:
- Release notes:
- Meeting materials:

Related Resources

DCAT-US GitHub Issues

https://github.com/GSA/dcat-us/issues

Use this issue tracker to request or discuss changes to the DCAT-US metadata standard itself.

DCAT-US GitHub Repository

https://github.com/GSA/dcat-us

Repository for the DCAT-US metadata standard.

DCAT-US 3 Implementation Guide

https://resources.data.gov/resources/dcat-us-3-implementation/

Primary reference for agencies implementing the DCAT-US 3 metadata standard.

DCAT-US 3 Technical Implementation FAQs

https://github.com/GSA/dcat-us/wiki/DCAT-US-3-Technical-Implementation-FAQ

Frequently asked questions related to technical implementation of the DCAT-US 3 metadata standard are posted here as they are developed.

DCAT-US 3 Updates

https://resources.data.gov/resources/dcat-us-3-updates/

Use this page for meeting schedule updates and related DCAT-US 3 engagement information.

Data.gov Help

Questions about Data.gov harvesting or resources.data.gov documentation can be directed to:

datagovhelp@gsa.gov

Related Wiki Pages

DCAT-US 3 Implementation Support

Meetings

Implementation Resources

Data.gov Team Process

FAQs

Reference

DCAT Interagency Maintenance Team

Clone this wiki locally