Project pages
How to structure a project page so visitors can understand the work, try it when appropriate, and follow the active trail without mixing in platform docs.
Page structure
A strong project page has two layers: the stable project overview and the live workspace trail.
- Overview explains what the project is, what it is for, and how access works.
- Build log captures milestones, failures, launches, pivots, and releases.
- Notes and discussion hold lighter thinking, quick ideas, voice memos, and comments.
- Project docs hold reference material that should remain more stable than the workspace stream.
Access model
Not every project needs a public clone command or install step. vicode supports public source, private source, public install or download, private-by-request distribution, or showcase-only publishing.
What belongs on the page versus in project docs
Keep the project page focused on overview, access, proof, and the live trail.
- Put overview, demo, source access, and install/download actions on the project page.
- Put build log, notes, voice memos, and discussion on the project page.
- Put setup guides, architecture, limitations, and reference material in project docs.
- Put platform-wide publishing or API rules in vicode docs, not inside a single project.