Homepage updates and sample data reorg

[lauriemerrell]

Pull Request

Before submitting a pull request, please read CONTRIBUTING.md.

For spec changes -- N/A

• Pull-requests must address an existing issue
• Update relevant documentation.

By contributing to this project, all contributors certify to the Developer Certificate of Origin in CONTRIBUTING.md.

Needs to merge after #261 otherwise broken links for getting started content

This PR:

• Decouples the TIDES homepage content from the GitHub README. Currently there's some straight up duplication which isn't ideal but per offline discussion with Carl, @jlstpaul, @chrisyamas it seems like we are ready to do this and have the homepage be a little less technical (and leave the technical content for the GitHub)
• Changes the Sample Data top-level navigation to point to the resources page, in anticipation of the Cal-ITP data sharing. I'll have a separate PR to update the awesome-list repo to add the existing Sample Data content there, although I am a little mixed on the utility since the samples/ directory is currently empty and the data-sharing pattern described hasn't necessarily been validated in practice

[chrisyamas]

@lauriemerrell, I just pushed a merge commit (3f5bb31) to resolve the conflict from #261's nav addition. I kept your Sample Data: resources#sample-data line and brought in the Getting Started: getting-started.md line from #261. No other changes.

I went with a merge rather than a rebase since CONTRIBUTING.md doesn't specify, but the historical pattern in this repo has been back-merging main into the feature branch. See c21d5ac, 9d6a3e6, e664906, f854141, 7c8a9ab. All of which land on main with the back-merge intact, which only holds if the PR was merge-resolved rather than rebased and force-pushed.

Wondering if it would be worth documenting that convention in CONTRIBUTING.md? Might be worth raising as a minor order of business at the next Contributors Group meeting.

[lauriemerrell]

I'm fine either way but yeah would do it as a separate follow up, and not sure if the TIDES community more broadly would have a preference or if there are any special considerations for spec changes in particular (what do the GTFS spec repos do?)

[chrisyamas]

Approving, but I am interested to see if the resources#sample-data syntax works as expected. @lauriemerrell do you want to test that locally to confirm before we merge?

[chrisyamas]

I'm fine either way but yeah would do it as a separate follow up, and not sure if the TIDES community more broadly would have a preference or if there are any special considerations for spec changes in particular (what do the GTFS spec repos do?)

I took a look across MobilityData specs. GTFS spec and TODS are on the same merge + back-merge convention as TIDES; GBFS uses squash-and-merge. Sample back-merges: GTFS f64ad81, 6b66ed7, bd291fd; TODS 97cea85, 7ee4a46. Neither has merge/rebase guidance in CONTRIBUTING (TODS doesn't have one at all). So there's no monolithic MobilityData spec family convention, but TIDES aligns with GTFS and TODS on convention at least

On spec vs docs, I don't see anything tying merge style to spec changes in any of these CONTRIBUTING files. TIDES's governance differentiation is about who reviews (Board via CODEOWNERS on /spec/ and /docs/governance/), not history shape. So no reason for spec changes to use a different convention.

I'd still value getting input from the Contributors group on whether they care for us to formalize merge + back-merge in CONTRIBUTING.md as a follow-up. Slight lean is yes, since it saves any future contributors from ambiguity around this, but no urgency, and since TODS has even managing fine without any CONTRIBUTING.md at all suggests it's not necessarily load-bearing for ours to be overly prescriptive on conventions like this.

[lauriemerrell]

Yes I confirmed that the resources#sample-data syntax works locally

[lauriemerrell]

(I don't have perms to merge so will need someone else to do it)