Planning, Developer Norms, and Project Management

Planning and tracking work

Our github project reflects our data updates, projects, and timelines. It focuses on issues rather than PRs.

To plan and track our work we use:

• Data Engineering github project
• Data Updates github project
• Data Engineering channel in Microsoft Teams

When we plan to work on something that will require multiple issues, we use a project issue as a home base for discussions and tracking of those smaller tasks.

To coordinate cross-team work we use our github project, the edm-overview repo, and any other repos other teams may be working in.

Documents

We use the DE Data Catalog excel file in SharePoint to document the release schedule for our data products.

We use the DE Goals and Projects excel file in SharePoint to plan work for the year.

We use the GDE Goals and Initiatives (2025) diagram in Sharepoint to align quarterly plans across GDE teams.

We use the ITD Projects Portfolio in Sharepoint to align plans across the division.

Meetings

Our periodic meetings are:

• daily standup
• biweekly sprint retro & planning
  • during the first standup of the sprint
  • meeting notes
• biweekly roadmapping
  • the first Wednesday of a sprint
  • meeting notes
• quarterly retro & planning
  • the week before the last sprint of a quarter
  • meeting notes

Github use

Repos

Previously, every data product the team built had it's own repo. We now use:

• data-engineering to build all data products, build, the QA app, and extract source data to S3 file storage
• edm-data-operations to alert ITD's QA team of certain data updates
• db-gru-qaqc to run QAQC checks for GRU-maintained products
• python-geosupport to create python bindings for DCP's geocoding software called Geosupport

Branches

We have a single main branch and many feature branches. Feature branches are merged to main via pull requests.

Commits

In the interest of more atomic and meaningful commits on main, we strongly encourage:

• cleaning up commits before seeking review
• rebasing or squashing commits when merging a PR

To clean up commits on a dev branch:

1. Casually make commits to your dev branch
2. Locally rewrite your dev branch's history using git rebase -i main or git reset --soft main
3. Force push the new commits via git push --force-with-lease

Note

See these tips to split up a commit on a dev branch.

Pull requests

Open a draft PR early in the development process. A descriptive title, links to relevant issues, or a short description are good ways to help reviewers get relevant information. Draft PRs are also helpful for the author to keep track of what's been done

PRs must have descriptions of the changes present.

For especially significant code, try to explain it for reviewers or request input during development:

• It's easiest to do this on lines of code or an entire file in the PR diffs.
• For higher-level brainstorms, starting a conversation in an issue or in Teams might be easier in order to organize the conversation and not overly clutter the PR.

Mark the PR as Ready for Review and request the reviewer(s) when development on the branch is finished.

Implement changes as needed, re-request final review (from same reviewer) after significant changes, and merge to main when the PR is approved! 🎉