Step 1
Choose a real source
Start with a source family that has clear provenance, reasonable licensing, and an actual use case in the map.
Docs / Make A Pack
How to make a
DaedalMap pack.
This is the scaffold for the contributor workflow: choose a source, shape it into a pack, document it clearly, and move it toward QA and eventual release. It is written for internal use now, but it is also meant for outside contributors.
Step 2
Package it cleanly
The pack needs structured files, human-readable source documentation, and enough metadata that someone else can understand it.
Step 3
Run QA and promote
Pack creation should flow into QA, release gates, and eventually public publication or maintained-pack promotion.
1. Pick the source and scope
Decide what the pack is for before touching file structure. The pack should have a clear subject, geography, time range, and reason it belongs in DaedalMap.
2. Build the pack shape
The final pack should have a stable identity, data files, metadata, and a human-readable source sheet. Contributors should not have to guess what “done” looks like.
3. Write the source data sheet
Every pack should carry its public-facing source summary: who made it, where the data came from, what methodology was used, when it was updated, what years it covers, and what caveats matter.
4. Run QA
This tutorial will eventually tie directly into the pack QA and release model. For now, treat QA as part of the pack creation definition of done, not an optional afterthought.
Intended release path
- Can share: the pack is structured, readable, and testable.
- Can release: QA passes and the pack is suitable for public/runtime use.
- Production ready: the pack is stable enough to promote and rely on more broadly.
5. Credit the contributor
A source pack should visibly credit the person or team who made it usable. That is important for recognition, maintenance continuity, and contributor pride. If a student or collaborator built the pack, the site should make that legible.