Data Update Workflow

Data Product Update Workflow

Describes the lifecycle of a data product release from source data update through public distribution.

Stages

1. Ingest & Build

Create a parent GitHub issue to track the release. Update source data as needed, then run a build. The build output is archived in the build folder in S3.

2. Internal QA → Draft

DE reviews the build and addresses:

• All open GitHub sub-issues under the parent issue (including those filed by GIS or domain stakeholders)
• Any failed automated QA checks (refer to data check descriptions for context)
• QAQC Streamlit page checks

Once resolved, promote the build to the draft folder in S3. This initiates QAQC by domain experts.

3. GIS Team Review (for applicable products)

1. Add a yellow "GIS" tag to the parent issue and create a child issue for GIS QAQC, named <Product> <Version> QA - Draft <N> (e.g. "FacDB 24v2 QA - Draft 1"), assigned to all GIS team members.
2. GIS conducts review and records results in the child issue, then closes it regardless of outcome.
3. If the draft passes: promote to publish folder. If it fails: rebuild and repeat from step 1 with a new child issue.

4. Publish

Promote the approved draft to the publish folder in S3 for distribution.

Notes

• PLUTO Minor is an exception: GIS builds PLUTO Minor and promotes it to drafts directly via the Zoning Tax lots DataLoading action. A QA issue is created automatically.
• GIS team reference: Open Data Update Cycle Instructions (SharePoint)