The question
About 30 hand-written overview pages explain a subject (Town Meeting, Property Taxes, Open Meeting Law…). The tree needs to know which page belongs to which subject so it can give the page a sidebar, list it in the Resource Library and link to it from the menu. The link has to live somewhere an editor can set it. Two sensible places.
What exists today
- Nothing connected the two until this week. We built the link on the tree node side as a working draft: a "Landing page" field on each node, and filled it for the 31 nodes where the right page was obvious. 16 nodes have two candidate pages or only a placeholder and are waiting for a person.
- Example of a page that now has a node: draftTown Meeting ↔ the "Town Meeting" node under Elections & Town Meeting.
- The field can be moved to the page side in an afternoon if VLCT prefers; the data is the same either way.
Options
Option A — On the tree node ("this subject's page is …") our recommendation
- One admin screen, "Topic Tree", shows the whole map: 70 subjects and which page explains each.
- Easy to spot gaps: a node with no page stands out.
- Editors who only ever edit pages will not see it; a content lead maintains the map.
Option B — On the page ("this page is the overview for …")
- Editors set it where they already work, in the page editor.
- Harder to see the whole picture; two pages can claim the same subject without anyone noticing.
- Gaps are invisible: nothing shows which subjects have no page.
What changes
Only the admin experience. Readers see the same result either way. Reversible? Yes; the link is a single value per subject and can be moved between the two places by script.
What we need from you
- Option A: on the tree node (recommended)
- Option B: on the page
If we hear nothing before the next build, we go with the recommendation: the field stays on the tree node. Reply to Kalman by email, or comment on the linked issue.
Related: #83 (the field as built), plan document TOPICS-PLAN.md §4 Q3.
← 1 · One tree · All decisions · 4 · Addresses →