A side-project page checklist and description template

Write a sentence that connects a person, a task, and an outcome. As an illustrative example: “A shared rehearsal planner that helps small bands find a time everyone can make.” That tells a visitor more than “An innovative full-stack scheduling platform.”

Then describe the current stage in plain language: a clickable prototype, a working first version, or a service people can use today. Explain significant limitations next to the capabilities they affect. Keep technical details for readers who want to understand how it was built or contribute.

Replace each prompt with facts about your project. These prompts are an editorial checklist, not a list of mandatory fields in the editor.

• The problem: Who encounters it, and what is difficult today?
• The project: What can someone do with it?
• Current state: What works, and what is still experimental or missing?
• Try it: Where should someone begin, and what example task should they attempt?
• Feedback wanted: What is the one question you need answered next?
• Contributors: Who made it, and how should their work be credited?
• Technical context: Which technologies or repository links would help a contributor?

Do not fill gaps with projected usage, unsupported results, or features you have not built. A clear limitation helps a visitor give relevant feedback.

Show the core task in a real screen. A logo establishes identity, while a screenshot can explain what the user actually does. Include enough surrounding context to make the screen understandable and remove private information from the image.

Check the page on a narrow screen. Read the description without assuming the visitor knows your terminology. Open the demo link in a signed-out browser and verify that the stated starting point is reachable. If access is limited, explain that before asking someone to try it.

Confirm the URL, description, images, and credits. Use the editor’s own publishing checks for the current required fields; this checklist helps with clarity, while the interface determines whether the draft is ready to submit.

Publishing sends a draft for review. Wait for approval before telling others it is available in the public directory. When it is visible, share the public project link with a focused request using the feedback template. If a competition is relevant, review the round and enter separately rather than assuming publication includes entry.