Skip to content

DCAT Interagency Maintenance Team CHARTER

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

Draft Charter: DCAT Interagency Maintenance Team

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

This page provides a draft charter for the DCAT Interagency Maintenance Team.

The charter is intended to define the team’s purpose, scope, roles, decision-making process, meeting cadence, expected outputs, and launch approach for maintaining the DCAT-US v3.0 metadata standard.

Items marked as Decision Needed should be discussed and confirmed by the DCAT Interagency Maintenance Team and the Data.gov team before the charter is finalized.

1. Team Name

Draft team name:
DCAT Interagency Maintenance Team

The DCAT Interagency Maintenance Team supports ongoing maintenance of the DCAT-US v3.0 metadata standard.

Decision Needed

  • Confirm the official team name.
  • Confirm whether the team name should appear in public-facing documentation.
  • Confirm whether the team name should be used in GitHub release notes, resources.data.gov, and agency communications.

2. Charter Purpose

The purpose of this charter is to establish a shared operating model for maintaining DCAT-US v3.0.

This charter describes:

  • The purpose of the team
  • The scope of maintenance activities
  • Roles and responsibilities
  • Issue triage and review process
  • Release cycle responsibilities
  • Agency feedback expectations
  • Meeting cadence
  • Decision-making process
  • Documentation and communication responsibilities
  • Initial pilot approach

Decision Needed

  • Confirm that a charter is needed for the team.
  • Confirm whether this charter is internal only or agency-facing.
  • Confirm who approves the charter.
  • Confirm where the final charter should be published or stored.

3. Background

DCAT-US v3.0 follows a semi-annual maintenance cycle covering schema governance, documentation, and agency communication.

The maintenance process includes:

  • Continuous issue triage
  • Cycle 1 spring release in March/April
  • Cycle 2 summer release in July
  • Annual retrospective
  • Documentation review and updates
  • Release communications
  • Agency feedback
  • Implementation support

The Data.gov team at GSA maintains the DCAT-US repository and coordinates the maintenance cycle.

Major version changes, such as DCAT-US v4.0, are planned separately.

Decision Needed

  • Confirm that the maintenance cycle described here is accurate.
  • Confirm whether the charter should explicitly reference the semi-annual release cycle.
  • Confirm how major version changes should be referenced.
  • Confirm whether any additional background or policy context should be included.

4. Mission Statement

The DCAT Interagency Maintenance Team provides interagency review, coordination, and decision support for maintaining DCAT-US v3.0.

The team helps ensure that DCAT-US v3.0 remains implementable, documented, and responsive to agency needs while preserving consistency, interoperability, and stability across federal metadata implementations.

Decision Needed

  • Confirm the mission statement.
  • Confirm whether the mission should emphasize governance, implementation support, or both.
  • Confirm whether interoperability, stability, and agency implementation burden should be explicitly included.
  • Confirm whether the mission statement should mention Data.gov harvesting and display considerations.

5. Objectives

The DCAT Interagency Maintenance Team supports the following objectives:

  1. Provide a structured process for reviewing proposed changes to DCAT-US v3.0.
  2. Support transparent triage and disposition of DCAT-US GitHub issues.
  3. Identify whether proposed changes are breaking or non-breaking.
  4. Consider agency implementation impacts before changes are released.
  5. Support clear release planning and communication.
  6. Identify documentation, example, FAQ, and migration guidance needs.
  7. Support annual review of validation trends and implementation blockers.
  8. Help prioritize future maintenance work.
  9. Provide a venue for selected agency feedback on proposed changes.
  10. Support consistent implementation of DCAT-US v3.0 across agencies.

Decision Needed

  • Confirm these objectives.
  • Identify any objectives that should be removed.
  • Identify any additional objectives.
  • Confirm whether the team should have formal authority to approve schema changes or provide recommendations to another decision-making body.
  • Confirm whether the team should prioritize implementation support, schema governance, documentation quality, or all of these equally.

6. Scope

6.1 In Scope

The DCAT Interagency Maintenance Team may review and support decisions related to:

  • Proposed changes to the DCAT-US metadata standard
  • Schema bugs or inconsistencies
  • Non-breaking schema enhancements
  • Clarifications to field definitions, usage notes, or requirements
  • Questions about schema intent or behavior
  • Documentation updates related to DCAT-US v3.0
  • Updates to examples and implementation guidance
  • Deprecation notices for future breaking changes
  • Review of validation trends and recurring implementation issues
  • Agency communication about releases and grace periods
  • Annual retrospective findings
  • Priorities for the next annual maintenance cycle

Decision Needed

  • Confirm what is in scope.
  • Confirm whether documentation updates are within the team’s decision scope or only coordination scope.
  • Confirm whether implementation guidance and FAQs are within scope.
  • Confirm whether validation behavior is within scope.
  • Confirm whether Data.gov harvesting and display impacts should be considered during schema review.

6.2 Out of Scope

The DCAT Interagency Maintenance Team does not directly manage:

  • Agency-specific harvest source change requests
  • Routine harvest source configuration updates
  • Data.gov product bugs or enhancements
  • Inventory.data.gov account access requests
  • Major version changes, such as DCAT-US v4.0, unless separately assigned

Those items should use the appropriate existing process.

Item Appropriate Process
Request a new DCAT-US 3 harvest source Harvest Source Change Request Form
Request a change to an existing harvest source Harvest Source Change Request Form
Track harvest source request status Harvest Source Management Board
Report Data.gov product bugs, enhancements, or defects Data.gov Team Board
Request or renew Inventory.data.gov access Inventory.data.gov Access Request Form
Request a change to the DCAT-US metadata standard DCAT-US GitHub Issues

Decision Needed

  • Confirm what is out of scope.
  • Confirm whether major version planning should be entirely out of scope or referenced as a related process.
  • Confirm how out-of-scope items should be redirected.
  • Confirm whether the team should review issues that overlap between schema behavior and Data.gov product behavior.

7. Authority and Decision-Making

The DCAT Interagency Maintenance Team governs schema maintenance decisions for DCAT-US v3.0.

The team may review issues and assign dispositions such as:

  • Approved for PR
  • Deferred
  • Closed as won’t fix
  • Needs more information
  • Documentation update only
  • FAQ update only

The Data.gov team maintains the repository and coordinates the operational maintenance cycle.

Decision Needed

  • Confirm the team’s decision authority.
  • Confirm whether the team approves schema changes directly or recommends changes for Data.gov implementation.
  • Confirm who has final approval for pull requests.
  • Confirm who has final approval for release scope.
  • Confirm who has final approval for release notes and agency communications.
  • Confirm whether decisions require consensus, majority agreement, designated approver approval, or another approach.
  • Confirm how unresolved disagreements should be escalated.
  • Confirm whether decisions must be documented in GitHub issues, meeting notes, or both.

8. Membership

The DCAT Interagency Maintenance Team should include participants who can support schema review, implementation impact assessment, documentation quality, release planning, and agency communication.

Recommended participants include:

  • Data.gov product or program lead
  • DCAT-US repository maintainer
  • Data.gov technical or schema representative
  • Documentation representative
  • Harvesting or validation representative
  • Selected agency metadata or data inventory representatives
  • Selected agency technical implementation representatives
  • Optional policy or data governance representatives
  • Optional communications or outreach representative

Decision Needed

  • Confirm the minimum required membership.
  • Confirm whether membership is by individual, role, agency, or organization.
  • Confirm whether participating agencies are standing members or invited by issue/release cycle.
  • Confirm whether members serve for a fixed term.
  • Confirm whether membership should rotate annually.
  • Confirm whether alternates are allowed.
  • Confirm whether the team should maintain a public or internal membership list.

9. Agency Participation

Agency participation helps ensure that maintenance decisions are informed by real implementation experience.

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 a specific issue under review
  • Validation or harvesting patterns relevant to the issue under review

Participating agencies may provide feedback on:

  • Implementation burden
  • Validation impacts
  • Harvesting impacts
  • Documentation gaps
  • Examples or edge cases
  • Migration guidance needs
  • Release timing concerns

Decision Needed

  • Confirm how agencies will be selected for participation.
  • Confirm whether the initial agency group should be limited to a pilot subset.
  • Confirm how many agencies should participate in the initial pilot.
  • Confirm what commitment agencies are expected to make.
  • Confirm whether agency participation is advisory or decision-making.
  • Confirm whether agency participation should rotate.
  • Confirm whether agencies may self-nominate.
  • Confirm whether feedback meetings are open to all agencies or invitation-based.

10. Member Expectations

Members are expected to participate in good faith and support the maintenance process by reviewing issues, providing feedback, and completing assigned follow-up actions.

Expected member responsibilities may include:

  • Attend scheduled maintenance meetings, where possible
  • Review agenda materials before meetings
  • Review GitHub issues assigned for discussion
  • Provide feedback on proposed schema changes or clarifications
  • Consider cross-agency implementation impacts
  • Identify documentation, FAQ, or migration guidance needs
  • Raise implementation concerns or blockers
  • Complete assigned follow-up actions
  • Help communicate relevant updates within their agency or team

Decision Needed

  • Confirm member expectations.
  • Confirm expected time commitment.
  • Confirm whether members are expected to review materials asynchronously.
  • Confirm how action items will be assigned and tracked.
  • Confirm whether lack of participation affects membership.
  • Confirm whether members may delegate attendance to alternates.

11. Data.gov Team Responsibilities

The Data.gov team at GSA maintains the DCAT-US repository and coordinates the maintenance cycle.

Data.gov team responsibilities may include:

  • Maintaining the DCAT-US GitHub repository
  • Coordinating issue triage
  • Applying issue labels within two weeks of submission
  • Cross-filing issues received through Zendesk or interagency channels
  • Preparing issues for team review
  • Managing release milestones
  • Coordinating pull requests
  • Coordinating release readiness
  • Tagging releases
  • Coordinating changelog entries
  • Coordinating resources.data.gov documentation updates
  • Publishing or coordinating release notes
  • Supporting agency outreach
  • Supporting annual retrospective analysis
  • Tracking follow-up actions

Decision Needed

  • Confirm Data.gov team responsibilities.
  • Confirm who on the Data.gov team owns maintenance coordination.
  • Confirm who maintains GitHub labels and milestones.
  • Confirm who prepares issue review materials.
  • Confirm who coordinates documentation updates.
  • Confirm who publishes release notes.
  • Confirm who tracks action items.
  • Confirm who coordinates annual retrospective inputs.

12. Issue Submission and Triage

Requests or issues related to the DCAT-US metadata standard should be submitted through the DCAT-US GitHub Issues page:

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

Issues are triaged on a rolling basis.

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

Classification labels include:

Label Meaning
bug The schema behaves incorrectly or inconsistently with the specification
enhancement A proposed addition or improvement to the schema
question A request for clarification on schema intent or behavior

Decision Needed

  • Confirm the GitHub issue tracker as the official intake path for standard-level requests.
  • Confirm issue labels.
  • Confirm whether additional labels are needed.
  • Confirm the two-week triage expectation.
  • Confirm who is responsible for triage.
  • Confirm how issues received through other channels will be cross-filed.
  • Confirm how time-sensitive issues should be handled.
  • Confirm how out-of-scope issues should be closed or redirected.

13. Issue Review and Disposition

During each release cycle, the team reviews prioritized issues assigned to the relevant milestone.

For each issue, the team should consider:

  • Issue type
  • Affected field or schema area
  • Whether the issue is breaking or non-breaking
  • Agency implementation impact
  • Validation impact
  • Harvesting or display impact
  • Documentation impact
  • Whether a security considerations note is needed
  • Whether agency feedback is needed
  • Whether deprecation notice is required
  • Whether a 90-day implementation window is required

Possible dispositions include:

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
FAQ update only The issue should be addressed through a FAQ rather than a schema or documentation change

Decision Needed

  • Confirm disposition categories.
  • Confirm how dispositions are documented.
  • Confirm who can assign or approve dispositions.
  • Confirm whether agency feedback is required before certain dispositions.
  • Confirm whether documentation-only and FAQ-only dispositions should be separate.
  • Confirm whether additional dispositions are needed.
  • Confirm how deferred issues are revisited.

14. Release Cycle

DCAT-US v3.0 follows a semi-annual maintenance cycle.

Cycle Timing Focus
Cycle 1: Spring Release March/April Non-breaking changes, critical documentation updates, release notes, deprecation notices
Cycle 2: Summer Release and Retrospective July Summer release, alignment with M-25-05 annual compliance reference date, annual retrospective

Decision Needed

  • Confirm the semi-annual release cycle.
  • Confirm Cycle 1 timing.
  • Confirm Cycle 2 timing.
  • Confirm whether additional off-cycle releases are allowed.
  • Confirm criteria for off-cycle releases, if allowed.
  • Confirm whether July alignment with the M-25-05 annual compliance reference date should be retained.
  • Confirm whether the annual retrospective should remain part of Cycle 2.

15. Change Types and Release Rules

The maintenance process uses different release rules depending on the type of change.

Change Type Example Earliest Release Notice Required
Non-breaking addition New optional field Next cycle None
Non-breaking clarification Updated field description Next cycle None
Breaking change Removed field, changed enum Cycle after notice Deprecation notice in prior cycle outreach

Breaking changes require a minimum 90-day agency implementation window before enforcement.

Decision Needed

  • Confirm change type definitions.
  • Confirm release rules.
  • Confirm the 90-day implementation window.
  • Confirm whether all new requirements receive a 90-day grace period.
  • Confirm whether breaking changes may only occur in Cycle 2.
  • Confirm how deprecation notices are approved.
  • Confirm how enforcement timing is communicated.

16. Security Considerations

Schema changes touching any of the following fields must include a security considerations note in the pull request:

  • accessRestriction
  • useRestriction
  • cuiRestriction

The security considerations note should describe:

  • Which field is affected
  • What behavior is changing
  • Whether validation is affected
  • Whether agency implementation is affected
  • Whether representation of access, use, or CUI-related restrictions is affected
  • Recommended agency review considerations

Decision Needed

  • Confirm that security considerations notes are required for these fields.
  • Confirm whether additional fields should require security considerations notes.
  • Confirm who reviews security considerations notes.
  • Confirm whether security review must occur before PR approval.
  • Confirm how security considerations are documented in release notes.

17. Documentation Responsibilities

Documentation maintenance may include:

  • Updating resources.data.gov
  • Updating examples
  • Updating implementation guidance
  • Updating migration guidance
  • Updating technical FAQs
  • Updating changelogs
  • Auditing documentation against the live schema

Cycle 1 documentation activities may include:

  • Resolve all P1 documentation issues
  • Validate examples against the current schema
  • Audit DCAT-US pages on resources.data.gov against the live schema

Cycle 2 documentation activities may include:

  • Resolve all P1 and P2 documentation issues
  • Publish migration guidance within 30 days of release if field-level changes affect existing data.json implementations
  • Update the changelog on resources.data.gov

Decision Needed

  • Confirm documentation responsibilities.
  • Confirm who owns resources.data.gov updates.
  • Confirm who owns GitHub wiki FAQ updates.
  • Confirm who validates examples.
  • Confirm who assigns P1/P2 documentation priority.
  • Confirm whether documentation updates must be complete before release.
  • Confirm when migration guidance is required.
  • Confirm how documentation issues are tracked.

18. Release Communications

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

Release notes should be shared through:

  • GitHub release notes
  • CDO Council channel
  • Data.gov mailing list

Release communications should include:

  • Release version
  • Release date
  • Summary of changes
  • Changelog link
  • Schema changes
  • Documentation changes
  • Breaking changes, if applicable
  • Deprecation notices, if applicable
  • 90-day grace period information
  • Agency action items
  • Links to updated documentation
  • Contact information

Decision Needed

  • Confirm communication channels.
  • Confirm who drafts release notes.
  • Confirm who approves release notes.
  • Confirm who sends outreach messages.
  • Confirm whether release notes must be published within two weeks.
  • Confirm whether all release communications should include grace period language.
  • Confirm whether release communications should be discussed in the DCAT Interagency Info Sharing Session.
  • Confirm whether CDO Council touchpoints should be used for major changes.

19. Annual Retrospective

The annual retrospective occurs in July as part of Cycle 2.

The retrospective may include:

  • Review of harvest validation error trends using New Relic data
  • Review of GitHub issue trends
  • Review of agency feedback
  • Review of documentation gaps
  • Review of release communications
  • Identification of systemic field-level error patterns
  • Identification of agency cohorts that may benefit from targeted assistance
  • Development of an annual compliance support summary
  • Identification of next-cycle priorities

The annual compliance support summary is an implementation support tool and is not an enforcement document.

Decision Needed

  • Confirm the retrospective timing.
  • Confirm retrospective participants.
  • Confirm use of New Relic data.
  • Confirm who prepares retrospective materials.
  • Confirm whether an annual compliance support summary will be produced.
  • Confirm who receives the compliance support summary.
  • Confirm how retrospective findings become GitHub issues, documentation tasks, or support activities.
  • Confirm whether retrospective findings are public, internal, or shared with selected stakeholders.

20. Meeting Cadence

The maintenance process may use the following meetings.

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

Decision Needed

  • Confirm meeting types.
  • Confirm cadence for issue triage.
  • Confirm whether agency feedback meetings are standing or as-needed.
  • Confirm whether release readiness meetings are required.
  • Confirm whether post-release outreach occurs through existing meetings or separate sessions.
  • Confirm meeting owners.
  • Confirm who prepares agendas.
  • Confirm where meeting notes are stored.

21. Records and Documentation

Maintenance decisions should be documented in a transparent and consistent way.

Documentation may include:

  • GitHub issue comments
  • GitHub labels and milestones
  • Pull requests
  • Meeting notes
  • Release notes
  • Changelog entries
  • Documentation updates
  • Agency feedback summaries
  • Annual retrospective summaries

Decision Needed

  • Confirm what records must be maintained.
  • Confirm where meeting notes should be stored.
  • Confirm whether decisions must be documented in GitHub.
  • Confirm whether agency feedback summaries are stored publicly or internally.
  • Confirm whether release materials are archived.
  • Confirm whether records are subject to any additional agency records policies.

22. Relationship to Existing DCAT Engagement Forums

The maintenance process is 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

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

Decision Needed

  • Confirm how office hours feed into the maintenance process.
  • Confirm how info sharing sessions support release outreach.
  • Confirm whether maintenance topics should appear regularly in existing DCAT meetings.
  • Confirm whether issue discussions from meetings should be cross-filed in GitHub.
  • Confirm who is responsible for converting meeting topics into GitHub issues or FAQ updates.

23. First-Year Pilot

The first year of the DCAT Interagency Maintenance Team may be treated as a pilot.

Pilot goals may include:

  • Test the semi-annual release cadence
  • Confirm whether continuous triage within two weeks is feasible
  • Validate the issue review process
  • Determine whether agency feedback meetings are useful
  • Identify the right agency participant mix
  • Confirm release note and outreach workflows
  • Identify improvements for the next annual cycle

Decision Needed

  • Confirm whether the first year should be treated as a pilot.
  • Confirm pilot duration.
  • Confirm pilot success criteria.
  • Confirm when pilot evaluation occurs.
  • Confirm who participates in pilot evaluation.
  • Confirm how pilot findings will update the charter.

24. Initial Launch Checklist

To launch the DCAT Interagency Maintenance Team, the following actions should be completed.

  • Confirm draft charter.
  • Confirm team name.
  • Confirm team scope.
  • Confirm team membership.
  • Confirm GitHub labels.
  • Confirm GitHub milestones.
  • Review current open GitHub issues.
  • Prepare initial issue inventory.
  • Schedule kickoff meeting.
  • Schedule first issue triage meeting.
  • Schedule first schema review meeting.
  • Identify initial agency feedback participants.
  • Publish or share wiki pages.
  • Confirm where meeting notes and decisions will be stored.

Decision Needed

  • Confirm launch checklist.
  • Confirm launch owner.
  • Confirm target launch date.
  • Confirm whether launch requires approval before scheduling meetings.
  • Confirm which items must be complete before kickoff.

25. Open Decisions Summary

The following decisions should be resolved before or during the initial launch period.

Area Decision Needed
Team name Confirm official team name
Charter approval Confirm who approves the charter
Scope Confirm in-scope and out-of-scope activities
Authority Confirm decision-making authority
Membership Confirm required members and agency participation model
Agency role Confirm whether agency participants are advisory or decision-making
GitHub workflow Confirm labels, milestones, and triage responsibilities
Release cycle Confirm Cycle 1 and Cycle 2 timing
Breaking changes Confirm deprecation and 90-day implementation rules
Security considerations Confirm required review for restriction-related fields
Documentation Confirm documentation ownership and release requirements
Communications Confirm release note channels and approval process
Retrospective Confirm annual retrospective process and outputs
Meetings Confirm meeting cadence and owners
Records Confirm where decisions and meeting notes are documented
Pilot Confirm first-year pilot approach and success criteria

26. Related Resources

DCAT-US GitHub Repository

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

DCAT-US GitHub Issues

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

DCAT-US 3 Implementation Guide

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

DCAT-US 3 Technical Implementation FAQs

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

DCAT-US 3 Updates

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

Data.gov Help

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

datagovhelp@gsa.gov

27. 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