How we made a China pre-trip checklist safe to reuse as JSON

#opensource #showdev #data #webdev

A travel checklist looks simple until one of its items depends on a rule that can change. Entry eligibility, transit conditions, and app availability are poor candidates for hard-coded, timeless advice. At the same time, a checklist is much more useful when people can reuse it in notes, small apps, or their own travel workflow.

We built an open version of YouChina's pre-trip checklist to handle that tension.

What we published

The resource has three forms:

a human-readable README
a printable web page
a versioned JSON file

Repository: https://github.com/Fisher521/china-entry-readiness-checklist

Printable page: https://fisher521.github.io/china-entry-readiness-checklist/

Release download: https://github.com/Fisher521/china-entry-readiness-checklist/releases/tag/v1.0.0

The important design decision

The checklist separates relatively stable preparation tasks from time-sensitive policy claims.

For example, "check whether you need a visa" is a durable task. A sentence that promises a specific traveler can enter visa-free for a specific number of days is not durable unless it is tied to current official guidance.

So the JSON represents the task and records when an official source is required. It does not try to become an immigration database.

A simplified item looks like this:

{
  "id": "verify-entry-route",
  "category": "entry",
  "task": "Verify your eligible entry or transit route",
  "when": "before-booking",
  "officialSourceRequired": true,
  "status": "not-started",
  "note": "Recheck the relevant authority before travel."
}

That distinction makes the file useful without pretending it can replace an authority.

Why JSON instead of another article

Articles are good for explanation, but they are awkward to reuse. A small JSON file can be:

imported into a personal planning tool;
transformed into a printable list;
localized without changing the underlying identifiers;
compared between releases; and
validated by another application.

The README remains the place for context. The JSON remains deliberately boring and portable.

Versioning and corrections

The first release is tagged v1.0.0. Future changes can be reviewed as diffs instead of silently replacing the checklist. The repository also has a changelog, and corrections can be raised publicly.

We intentionally left out affiliate IDs, booking claims, and hard-coded policy promises. The goal is a reusable preparation layer, not a sales funnel disguised as open data.

Feedback we are looking for

The schema is small on purpose. The most useful feedback would be:

a missing pre-arrival task that is broadly applicable;
a field that would make the JSON easier to integrate;
a claim that should be moved behind an official-source warning; or
a clarity problem in the printable version.

If you build travel tools or maintain structured checklists, I would be interested in how you balance usefulness with information that expires.

DEV Community