infra: content lifecycle strategy
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- git, github-actions
- Domain
- devops, documentation, release
Research direction
Start by reading sync-motoko.yml, update-syntax-grammars.yml, .sources/VERSIONS, and the submodule checklist in CLAUDE.md. Map the remaining submodules and the three requested ownership and review-policy areas; done means the required workflow coverage, CODEOWNERS file, and documented cadence are all defined.
Written by the indexing model from the issue text.
Description
Context
Define how docs stay fresh as upstream sources evolve. This covers change detection, sync automation, and freshness ownership.
Current state
Automated:
- Motoko pages:
sync-motoko.yml— weekly, detects newcaffeinelabs/motokoreleases and opens a PR with synced content already committed - Motoko + Candid grammars (Shiki):
update-syntax-grammars.yml— weekly, tracksdfinity/vscode-motokoreleases and opens a PR with updated TextMate grammars
Established conventions:
- Every content page carries an
<!-- Upstream: hand-written | sync from | informed by -->comment (decision: 2026-03-12) - Every submodule bump PR must follow the checklist in CLAUDE.md (per-submodule diff review, affected page updates, bump notice comments on open PRs)
.sources/VERSIONStracks current pinned versions for release-pinned submodules
Not yet in place:
- No automated change detection for the remaining 13+ submodules (
icp-cli,cdk-rs,motoko-core,icskills,examples,icp-js-sdk-docs,candid,response-verification,chain-fusion-signer,papi,ic-pub-key,internetidentity,icp-cli-recipes,icp-cli-templates) - No CODEOWNERS file — no defined ownership per section
- No documented review cadence or staleness policy
Remaining questions
- Submodule change detection: Build a workflow similar to
sync-motoko.ymlfor release-pinned submodules — check latest tag against.sources/VERSIONS, open a bump PR or issue when behind. Main/master-pinned submodules are harder (no release signal); a weekly diff summary issue may be more practical. - CODEOWNERS: Define section-level ownership (e.g. chain-fusion guides → chain-fusion team, Rust CDK pages → SDK team).
- Review cadence: Document a spot-check schedule for hand-written pages that are
informed byupstream sources.
Output
- Automated bump detection workflow(s) for release-pinned submodules
CODEOWNERSfile- Staleness / review cadence documented in
.docs-plan/decisions.mdorCONTRIBUTING.md
- Dominant language
- JavaScript
- Stars
- 4
- Forks
- 5
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 30
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dfinity/developer-docs
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
dfinity/developer-docs#281 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
dfinity/developer-docs#279 ·
-
docs: cycle cost docs follow-up — ICP formula, worked example, instruction profiling, cost traps Open
Difficulty 4/5 3-5 days Newbie friendliness 68/100
dfinity/developer-docs#274 ·
-
documentation enhancement
Difficulty 4/5 3-5 days Newbie friendliness 52/100
dfinity/developer-docs#232 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 65/100
dfinity/developer-docs#228 ·
All issues in dfinity/developer-docs
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
HarperFast/skills#96 ·
-
[Block] Latest Posts [Type] Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
sugarlabs/musicblocks#8847 ·