ਸਿੱਖੋ ਕਿ ਕਿਵੇਂ ਇੱਕ ਐਸੀ ਖੁੱਲ੍ਹਾ-ਸਰੋਤ ਪ੍ਰੋਜੈਕਟ ਵੈਬਸਾਈਟ ਯੋਜਨਾ ਬਣਾਈਏ, ਬਣਾਈਏ ਅਤੇ ਰੱਖਿਆ ਜਾਵੇ ਜੋ ਕਮਿਊਨਿਟੀ ਯੋਗਦਾਨਾਂ ਨਾਲ ਸਾਧਾ, ਸਪਸ਼ਟ ਵਰਕਫਲੋ, ਸਮੀਖਿਆ ਕਦਮ ਅਤੇ ਭਰੋਸੇਯੋਗ ਪ੍ਰਕਾਸ਼ਨ ਰੱਖਦੀ ਹੋਵੇ।
ਸਾਨੂੰ ਕਿਸੇ ਥੀਮ ਚੁਣਨ ਜਾਂ ਹੋਮਪੇਜ ਦਾ ਵਾਇਰਫ੍ਰੇਮ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸਪਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਾਈਟ ਦਾ ਕੀ ਮਨੋਰਥ ਹੈ। ਖੁੱਲ੍ਹੇ-ਸਰੋਤ ਵਾਲੀਆਂ ਸਾਈਟਾਂ ਅਕਸਰ ਸਭ ਕੁਝ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ—docs ਪੋਰਟਲ, ਮਾਰਕਟਿੰਗ ਪੇਜ, ਕਮਿਊਨਿਟੀ ਹੱਬ, ਬਲੌਗ, ਦਾਨ ਲਈ ਫਨਲ—ਅਤੇ ਆਖ਼ਿਰਕਾਰ ਕੋਈ ਵੀ ਚੀਜ਼ ਚੰਗੀ ਨਹੀਂ ਹੁੰਦੀ।
ਉਹ 1–3 ਕੰਮ ਲਿਖੋ ਜੋ ਵੈਬਸਾਈਟ ਨੂੰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਆਮ ਉਦਾਹਰਣ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਵੈਬਸਾਈਟ ਦਾ ਉਦੇਸ਼ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ ਤਾਂ ਯਾਤਰੀ ਵੀ ਨਹੀਂ ਸਮਝ ਪਾਵੇਗਾ।
ਆਪਣੇ ਮੁੱਖ ਦਰਸ਼ਕਾਂ ਨੂੰ ਲਿਸਟ ਕਰੋ ਅਤੇ ਹਰ ਗਰੁੱਪ ਲਈ ਉਹ “ਪਹਿਲੀ ਕਲਿੱਕ” ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ:
ਇੱਕ ਫਾਇਦemand ਅਭਿਆਸ: ਹਰ ਦਰਸ਼ਕ ਲਈ ਉਹ 3 ਮੁੱਖ ਸਵਾਲ ਲਿਖੋ ਜੋ ਉਹ ਲੈ ਕੇ ਆਉਂਦੇ ਹਨ (ਉਦਾਹਰਨ: “ਮੇਰੀ ਇੰਸਟਾਲ ਕਿਵੇਂ ਕਰਨੀ ਹੈ?”, “ਕੀ ਇਹ ਸਰਗਰਮ ਤਰੀਕੇ ਨਾਲ maintained ਹੈ?”, “ਬੱਗ ਮੈਂ ਕਿੱਥੇ ਰਿਪੋਰਟ ਕਰਾਂ?”).
ਸਧਾਰਨ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਲਕੜੀਆਂ ਨਾਲ ਜੁੜੇ ਹੋਣ ਅਤੇ ਟ੍ਰੈਕ ਕਰਨਾ ਸਧਾਰਨ ਹੋਵੇ:
ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਲਿਖੋ ਕਿ ਸਾਈਟ ਇਸ ਵੇਲੇ ਕੀ ਨਹੀਂ ਕਰੇਗੀ: ਕਸਟਮ ਵੈਬ ਐਪ, ਕਠਿੰਨ ਅਕਾਊਂਟ ਸਿਸਟਮ, ਭਾਰੀ ਇন্টਿਗ੍ਰੇਸ਼ਨ, ਜਾਂ ਵਿਸ਼ੇਸ਼ CMS ਫੀਚਰ। ਇਹ ਮੈਨਟੇਨਰਾਂ ਦਾ ਸਮਾਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਰਿਲੀਜ਼ਯੋਗ ਰੱਖਦਾ ਹੈ।
ਸਮੱਗਰੀ ਨੂੰ ਦੋ ਬਰਨੈਟਾਂ ਵਿੱਚ ਵੰਡੋ:
ਇਹ ਫੈਸਲਾ ਤੁਹਾਡੇ ਟੂਲ ਚੋਣ, ਰਿਵਿਊ ਵਰਕਫਲੋ ਅਤੇ ਯੋਗਦਾਨਕਾਰ ਅਨੁਭਵ ਨੂੰ ਬਹੁਤ ਪ੍ਰਭਾਵਿਤ ਕਰੇਗਾ।
ਜੇ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਫੈਸਲਿਆ ਕਿ “ਕਿਹੜੀ ਚੀਜ਼” ਸੀਟ 'ਤੇ ਰਹੇਗੀ ਅਤੇ ਕਿਹੜੀ ਰਿਪੋ ਵਿੱਚ, ਤਾਂ ਇੱਕ ਕਮਿਊਨਿਟੀ ਸਾਈਟ ਜਲਦੀ ਗੜਬੜ ਹੋ ਜਾਂਦੀ ਹੈ। ਟੂਲ ਅਤੇ ਥੀਮ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਸਧਾਰਨ ਸੰਰਚਨਾ ਅਤੇ ਸਪਸ਼ਟ ਸਮੱਗਰੀ ਮਾਡਲ 'ਤੇ ਸਹਿਮਤੀ ਕਰੋ—ਤਾਂ ਜੋ ਯੋਗਦਾਨਕਾਰ ਜਾਣਣ ਕਿ ਕਿੱਥੇ ਚੀਜ਼ਾਂ ਜੋੜਣੀਆਂ ਹਨ ਅਤੇ ਮੈਨਟੇਨਰ ਜਾਣਣ ਕਿ ਕਿਵੇਂ ਸਮੀਖਿਆ ਕਰਨੀ ਹੈ।
ਮੁੱਖ ਨੈਵੀਗੇਸ਼ਨ ਨੂੰ ਜਾਣ-ਪਛਾਣ 'ਤੇ ਸادہ ਰੱਖੋ। ਇੱਕ ਵਧੀਆ ਡਿਫੌਲਟ sitemap:
ਜੇ ਕੋਈ ਪੰਨਾ ਇਨ੍ਹਾਂ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਇਹ ਸੂਚਨ ਹੈ ਕਿ ਹੋ ਸਕਦਾ ਹੈ ਉਹ ਰਿਪੋ ਲਈ ਜ਼ਿਆਦਾ ਉਚਿਤ ਹੋਵੇ।
README ਨੂੰ developer-facing essentials ਲਈ ਵਰਤੋ: build ਨਿਰਦੇਸ਼, local dev setup, testing, ਅਤੇ quick project status. ਵੈਬਸਾਈਟ ਲਈ:
ਇਸ ਵੰਡ ਨਾਲ duplicated content ਜਿਸਦਾ drift ਹੁੰਦਾ ਹੈ, ਉਸਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।
ਹਰੇਕ ਖੇਤਰ (docs, blog/news, translations) ਲਈ content owners ਨਿਯੁਕਤ ਕਰੋ। Ownership ਛੋਟੀ ਟੀਮ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸਦੇ ਸਪਸ਼ਟ review ਜ਼ਿੰਮੇਵਾਰ ਹਨ—ਹਰ ਚੀਜ਼ ਲਈ ਇੱਕ ਹੀ gatekeeper ਦੀ ਲੋੜ ਨਹੀਂ।
ਇੱਕ ਛੋਟੀ tone and style guide ਲਿਖੋ ਜੋ ਗਲੋਬਲ ਕਮਿਊਨਿਟੀ ਲਈ ਦੋਸਤਾਨਾ ਹੋਵੇ: ਸਪਸ਼ਟ ਭਾਸ਼ਾ, ਇਕਸਾਰ ਸ਼ਬਦਾਵਲੀ, ਅਤੇ ਨਾਨ-ਨੈਟਿਵ English ਲਿਖਾਰੀ ਲਈ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼।
ਜੇ ਪ੍ਰੋਜੈਕਟ ਰਿਲੀਜ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਪਹਿਲੋਂ ਹੀ versioned docs ਲਈ ਯੋਜਨਾ ਬਣਾਓ (ਉਦਾਹਰਨ: “latest” ਅਤੇ supported versions)। ਇਹ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਬਾਅਦ ਵਿੱਚ retrofit ਕਰਨ ਨਾਲ ਕਾਫ਼ੀ ਖ਼ਰਾਬ ਹੋ ਸਕਦਾ ਹੈ।
ਤੁਹਾਡਾ ਸਾਈਟ ਸਟੈਕ ਐਸਾ ਹੋਵੇ ਕਿ ਕੋਈ ਵੀ ਆਸਾਨੀ ਨਾਲ typo ਠੀਕ ਕਰ ਸਕੇ, ਨਵਾਂ ਪੰਨਾ ਜੋੜ ਸਕੇ ਜਾਂ docs ਸੁਧਾਰ ਸਕੇ ਬਿਨਾਂ build ਇੰਜੀਨੀਅਰ ਬਣੇ। ਅਕਸਰ ਇਸਦਾ ਮਤਲਬ ਹੈ: Markdown-first content, ਤੇਜ਼ local ਸੈੱਟਅਪ, ਅਤੇ smooth pull-request ਵਰਕਫਲੋ ਜਿਸ ਨਾਲ previews ਮਿਲਣ।
ਜੇ ਤੁਸੀਂ layout ਤੇ ਜਲਦੀ iteration ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ ਸਟੈਕ ਨੂੰ ਫਾਈਨਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ site experience ਦਾ prototype ਬਣਾਉਣਾ ਸੋਚੋ। ਪਲੇਟਫਾਰਮ ਵਰਗੇ Koder.ai ਤੁਹਾਨੂੰ chat ਰਾਹੀਂ docs/marketing ਸਾਈਟ ਸਕੈਚ ਕਰਨ, React-ਆਧਾਰਿਤ UI ਤੇ ਬੈਕਐਂਡ ਜਨਰੇਟ ਕਰਨ ਅਤੇ ਫਿਰ source code export ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ—ਇਹ ਗਠਤ ਜਾਣਕਾਰੀ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਯੋਗਦਾਨੀ ਪ੍ਰਵਾਹਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਖੋਂਜਣ ਲਈ ਫਾਇਦੇਮੰਦ ਹੈ।
ਆਮ ਵਿਕਲਪ contribution-friendly docs ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਸਾਈਟ ਲਈ:
mkdocs.yml ਸੋਧੋ, ਇੱਕ ਕਮਾਂਡ ਚਲਾਓਉਹ ਹੋਸਟਿੰਗ ਚੁਣੋ ਜੋ preview builds ਨੂੰ ਸਮਰਥਨ ਕਰਦਾ ਹੋਵੇ ਤਾਂ ਜੋ ਯੋਗਦਾਨਕਾਰ ਆਪਣੀਆਂ ਬਦਲਾਵਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵੇਖ ਸਕਣ:
ਜੇ ਸੰਭਵ ਹੋਵੇ, ਡੀਫੌਲਟ ਰਾਹ ਬਣਾਓ “open a PR, get a preview link, request review, merge.” ਇਸ ਨਾਲ ਮੈਨਟੇਨਰਾਂ ਦਾ ਫੇਰ-ਫਿਰ ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਯੋਗਦਾਨਕਾਰਾਂ ਦੀ ਭਰੋਸਾ ਵਧਦੀ ਹੈ।
docs/website-stack.md (ਜਾਂ README.md ਵਿੱਚ ਇੱਕ ਸੈਕਸ਼ਨ) ਵਿੱਚ ਛੋਟੀ ਵਰਣਨਾ ਰੱਖੋ: ਤੁਸੀਂ ਕੀ ਚੁਣਿਆ ਅਤੇ ਕਿਉਂ: ਸਾਈਟ ਨੂੰ локਲ ਤੌਰ ਤੇ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ, previews ਕਿੱਥੇ ਲੱਭਦੀਆਂ ਹਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਕਿਸਮਾਂ ਦੀਆਂ ਬਦਲੀਆਂ website repo ਵਿੱਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
ਇੱਕ ਸੁਆਗਤਯੋਗ ਰਿਪੋ “drive-by edits” ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਯੋਗਦਾਨ ਵਿੱਚ ਅੰਤਰ ਪੈਂਦਾ ਹੈ। ਸੰਰਚਨਾ ਅਸਾਨ ਨੇਵੀਗੇਸ਼ਨਯੋਗ, ਸਮੀਖਿਆ ਲਈ ਅਨੁਮਾਨਯੋਗ ਅਤੇ ਲੋਕਲ ਤੌਰ ਤੇ ਚਲਾਉਣ ਲਈ ਸਧਾਰਨ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਵੇਬ-ਸੰਬੰਧੀ ਫਾਈਲਾਂ ਨੂੰ ਗਰੁੱਪਡ ਅਤੇ ਸਪਸ਼ਟ ਨਾਮ ਦਿੱਤੇ ਰੱਖੋ। ਇੱਕ ਆਮ ਪਹੁੰਚ:
/
/website # marketing pages, landing, navigation
/docs # documentation source (reference, guides)
/blog # release notes, announcements, stories
/static # images, icons, downloadable assets
/.github # issue templates, workflows, CODEOWNERS
README.md # repo overview
ਜੇ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਕੋਲ ਪਹਿਲਾਂ ਹੀ application ਕੋਡ ਹੈ, ਤਾਂ ਸਾਈਟ ਨੂੰ /website (ਜਾਂ /site) ਵਿੱਚ ਰੱਖਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਤਾਂ ਜੋ ਯੋਗਦਾਨਕਾਰ ਨੂੰ ਇਹ ਪਤਾ ਹੋਵੇ ਕਿ ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ।
/website ਦੇ ਅੰਦਰ ਇੱਕ ਕੇਂਦਰਤ README ਸ਼ਾਮਿਲ ਕਰੋ/website/README.md ਬਣਾਓ ਜੋ ਇਹ ਜਵਾਬ ਦੇਵੇ: “ਮੈਂ ਆਪਣੀ ਬਦਲਾਅ ਦਾ preview ਕਿਵੇਂ ਵੇਖਾਂ?” ਇਸਨੂੰ ਛੋਟਾ ਅਤੇ copy-paste friendly ਰੱਖੋ।
ਉਦਾਹਰਣ quickstart (ਆਪਣੇ ਸਟੈਕ ਲਈ ਢਾਲੋ):
# Website quickstart
## Requirements
- Node.js 20+
## Install
npm install
## Run locally
npm run dev
## Build
npm run build
## Lint (optional)
npm run lint
ਇਸ ਵਿੱਚ ਉਹ ਫਾਈਲਾਂ ਵੀ ਦਰਸਾਓ ਜਿੱਥੇ ਮੁੱਖ ਚੀਜ਼ਾਂ (navigation, footer, redirects) ਹਨ ਅਤੇ ਨਵਾਂ ਪੰਨਾ ਕਿਵੇਂ ਜੋੜਨਾ ਹੈ।
ਟੈਮਪਲੇਟ formatting ਬਾਰੇ ਵਾਦ-ਵਿਵਾਦ ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਸਮੀਖਿਆ ਤੇਜ਼ ਕਰਦੇ ਹਨ। ਇੱਕ /templates ਫੋਲਡਰ ਜਾਂ /docs/CONTRIBUTING.md ਵਿੱਚ ਟੈਮਪਲੇਟ ਦਿਓ।
/templates
docs-page.md
tutorial.md
announcement.md
ਇੱਕ ਨਿਊਨਤਮ docs ਪੰਨਾ ਟੈਮਪਲੇਟ:
---
title: "Page title"
description: "One-sentence summary"
---
## What you’ll learn
## Steps
## Troubleshooting
ਜੇ ਤੁਸੀਂ ਖੇਤਰਵਾਰ maintainers ਰੱਖਦੇ ਹੋ, /.github/CODEOWNERS ਜੋੜੋ ਤਾਂ ਜੋ ਸਹੀ ਲੋਕਾਂ ਨੂੰ ਆਟੋ-ਰਿਕਵੈਸਟ ਹੋਣ:
/docs/ @docs-team
/blog/ @community-team
/website/ @web-maintainers
ਹਰ ਟੂਲ ਲਈ ਇੱਕ canonical config ਫਾਈਲ ਪਸੰਦ ਕਰੋ ਅਤੇ ਛੋਟੀ ਟਿੱਪਣੀ ਦਿਓ ਕਿ “ਕਿਉਂ” (ਹਰ ਆਪਸ਼ਨ ਨਹੀਂ)। ਲਕੜੀ ਇਹ ਹੈ ਕਿ ਨਵਾਂ ਯੋਗਦਾਨਕਾਰ ਇਕ menu item ਬਦਲਣ ਜਾਂ typo ਠੀਕ ਕਰਨ ਲਈ ਤੁਹਾਡੀ ਪੂਰੀ build ਸਿਸਟਮ ਨਹੀਂ ਸਿੱਖਦਾ।
ਵੈਬਸਾਈਟ ਇੱਕ ਵੱਖਰਾ ਕਿਸਮ ਦਾ ਯੋਗਦਾਨ ਆਕਰਸ਼ਿਤ ਕਰਦੀ ਹੈ: copy edits, ਨਵੇਂ ਉਦਾਹਰਣ, ਸਕ੍ਰੀਨਸ਼ਾਟ, translations, ਅਤੇ ਛੋਟੇ UX ਸੁਧਾਰ। ਜੇ ਤੁਹਾਡਾ CONTRIBUTING.md ਸਿਰਫ developers ਲਈ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰਾ ਯੋਗਦਾਨ ਗਵਾ ਦੇਵੋਗੇ।
ਇੱਕ CONTRIBUTING.md ਬਣਾਓ (ਜਾਂ ਵੱਖਰਾ) ਜੋ ਵੈਬਸਾਈਟ ਬਦਲਾਵਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਹੋ: ਸਮੱਗਰੀ ਕਿੱਥੇ ਹੈ, ਪੰਨੇ ਕਿਵੇਂ ਜਨਰੇਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ “ਮੁੱਕ” ਹੋਣ ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇੱਕ ਛੋਟਾ “common tasks” ਟੇਬਲ (fix a typo, add a new page, update navigation, publish a blog post) ਵੀ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਨਵੇਂ ਆਏ ਲੋਕ ਮਿੰਟਾਂ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰ ਸਕਣ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਹੋਰ ਡਿੱਗੇ ਹੋਏ ਨਿਰਦੇਸ਼ ਹਨ, ਤਾਂ CONTRIBUTING.md ਵਿੱਚ ਉਹਨਾਂ ਲਈ ਕਲੀਅਰ ਲਿੰਕ ਦਿਓ (ਉਦਾਹਰਨ ਲਈ /docs ਹੇਠ ਇੱਕ walkthrough page)।
ਸਪਸ਼ਟ ਦੱਸੋ ਕਿ ਕਦੋਂ issue ਖੋਲ੍ਹੋ ਅਤੇ ਕਦੋਂ ਸਿੱਧਾ PR ਭੇਜੋ:
ਇੱਕ “good issue template” snippet ਸ਼ਾਮਿਲ ਕਰੋ: ਪੰਨੇ ਦਾ URL, ਕੀ ਬਦਲਣਾ ਹੈ, ਕਿਉਂ ਇਹ ਪਾਠਕਾਂ ਲਈ ਫਾਇਦੇਮੰਦ ਹੈ, ਅਤੇ ਕੋਈ ਸਰੋਤ।
ਚੁੱਪ ਹੋਣਾ ਹੀ ਅਕਸਰ ਨਿਰਾਸ਼ਾ ਦਾ ਕਾਰਣ ਹੁੰਦਾ ਹੈ। ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:
ਇੱਕ ਹਲਕਾ ਚੈੱਕਲਿਸਟ back-and-forth ਨੂੰ ਰੋਕਦਾ ਹੈ:
ਜਦੋਂ ਯੋਗਦਾਨਕਾਰ PR ਖੋਲ੍ਹਦੇ ਹਨ ਤਦੋਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ। ਲਕੜੀ ਇੱਕ ਅਜਿਹੀ ਵਰਕਫਲੋ ਬਣਾਉਣਾ ਹੈ ਜੋ ਪੇਸ਼ਗੋਈਯੋਗ, ਘੱਟ ਰੋਕ-ਟੋਕ ਵਾਲੀ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋ।
.github/pull_request_template.md ਜਿਵੇਂ ਇੱਕ ਟੈਮਪਲੇਟ ਜੋ ਸਿਰਫ ਉਹੀ ਪੁੱਛੇ ਜੋ ਰਿਵਿਊਅਰਾਂ ਨੂੰ ਲੋੜੀਦਾ ਹੈ:
ਇਹ ਰਚਨਾ ਰਿਵਿਊਜ਼ ਤੇਜ਼ ਕਰਦੀ ਹੈ ਅਤੇ ਯੋਗਦਾਨਕਾਰਾਂ ਨੂੰ “ਵਧੀਆ” ਕੀ ਲੱਗਦਾ ਹੈ ਉਹ ਸਿਖਾਉਂਦੀ ਹੈ।
Preview deployments enable ਕਰੋ ਤਾਂ ਜੋ ਰਿਵਿਊਅਰ ਬਦਲਾਅ ਸੱਚ-ਮੁੱਚ ਦੀ ਸਾਈਟ 'ਤੇ ਦੇਖ ਸਕਣ। ਇਹ ਖਾਸ ਕਰ ਕੇ ਨੈਵੀਗੇਸ਼ਨ, ਸਟਾਈਲ ਅਤੇ layout ਤਰਤੀਬਾਂ ਲਈ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜੋ ਪੇਟੇਕਸਟ ਡਿਫਫ ਵਿਚ ਨਹੀਂ ਦਿਖਦੇ।
ਆਮ pattern:
ਹਰ PR ਤੇ CI ਨਾਲ ਹਲਕੀ ਜਾਂਚ ਚਲਾਓ:
ਅਸਾਨੀ ਨਾਲ fail ਕਰੋ, ਸਾਫ error messages ਦੇ ਕੇ, ਤਾਂ ਜੋ ਯੋਗਦਾਨਕਾਰ ਬਿਨਾਂ ਮੈਨਟੇਨਰ ਦਖਲਦੇ ਖ਼ੁਦ ਠੀਕ ਕਰ ਸਕਣ।
ਇੱਕ ਸਪਸ਼ਟ ਨਿਯਮ ਦਸਤਾਵੇਜ਼ ਕਰੋ: ਜਦੋਂ PR ਨੂੰ approve ਕਰਕੇ main 'ਤੇ merge ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਸਾਈਟ ਆਪੋ-ਆਪ deploy ਹੋ ਜਾਂਦੀ ਹੈ। ਕੋਈ ਹੱਥ ਦੀ ਚਾਲ ਨਹੀਂ, ਕੋਈ ਖ਼ਾਸ ਕmaanਡ ਨਹੀਂ। /contributing ਵਿੱਚ ਵਧੇਰੇ ਬਿਆਨ ਰੱਖੋ ਤਾਂ ਉਮੀਦਾਂ ਸਪਸ਼ਟ ਰਹਿਣ।
ਜੇ ਤੁਸੀਂ ਹੋਸਟ ਵਰਤਦੇ ਹੋ ਜੋ snapshots/rollback ਸਮਰਥਿਤ ਕਰਦਾ ਹੈ (ਕੁਝ hosts ਕਰਦੇ ਹਨ, ਅਤੇ Koder.ai ਵੀ ਜਦੋਂ ਤੁਸੀਂ ਉਸ ਰਾਹੀਂ deploy ਕਰਦੇ ਹੋ), ਤਾਂ ਦੱਸੋ ਕਿ “last known good” build ਕਿੱਥੇ ਮਿਲੇਗਾ ਅਤੇ ਉਸਨੂੰ ਕਿਵੇਂ restore ਕਰਨਾ ਹੈ।
Deployments ਕਦੇ-ਕਦੇ ਟੁੱਟਦੇ ਹਨ। ਇੱਕ ਛੋਟੀ rollback playbook ਦਸਤਾਵੇਜ਼ ਕਰੋ:
ਜਦੋਂ ਪੰਨੇ ਇੱਕੋ ਜੇਹੇ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਤਾਂ ਕਮਿਊਨਿਟੀ ਵੈਬਸਾਈਟ ਦੋਸਤਾਨਾ ਰਹਿੰਦੀ ਹੈ। ਇੱਕ ਹਲਕਾ design system ਯੋਗਦਾਨਕਾਰਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਦਿੰਦਾ, ਸਮੀਖਿਆਵਾਂ ਵਿੱਚ nitpicks ਘਟਾਉਂਦਾ, ਅਤੇ ਪਾਠਕਾਂ ਨੂੰ ਠਹਿਰਾਅ ਦਿੰਦਾ—ਭਾਵੇਂ ਸਾਈਟ ਵਧੇ।
ਛੋਟੀ page “types” ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰੋ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਠੀਕ ਰਹੋ: docs page, blog/news post, landing page, reference page। ਹਰ ਕਿਸਮ ਲਈ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਕੀ ਹਮੇਸ਼ਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ (title, summary, last updated, table of contents, footer links) ਅਤੇ ਕੀ ਕਦੇ ਵੀ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
ਨੈਵੀਗੇਸ਼ਨ ਨੀਤੀਆਂ:
sidebar_position ਜਾਂ weight ਵਰਗਾ)ਯੋਗਦਾਨਕਾਰਾਂ ਨੂੰ “consistent ਬਣਾਉ” ਕਹਿਣ ਦੀ ਥਾਂ ਉਨ੍ਹਾਂ ਨੂੰ building blocks ਦਿਓ:
ਇਹਨਾਂ ਅੰਸ਼ਾਂ ਨੂੰ /docs/style-guide ਜਿਵੇਂ ਇੱਕ ਛੋਟੀ Content UI Kit ਪੇਜ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ, copy‑paste ਉਦਾਹਰਨਾਂ ਸਮੇਤ।
ਘੱਟੋ-ਘੱਟ ਨਿਰਧਾਰਨ: ਲੋਗੋ ਕਿਵੇਂ ਵਰਤਣਾ (ਕਿੱਥੇ stretched ਜਾਂ recolored ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ), 2–3 ਮੁੱਖ ਰੰਗ ਜੋ accessibility ਕੰਟ੍ਰਾਸਟ ਪੂਰੇ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਕ-ਦੋ ਫੋਂਟ। ਮਕਸਦ “ਕਾਫੀ ਚੰਗਾ” ਆਸਾਨ ਬਣਾਉਣਾ ਹੈ, ਨਾਂ ਕਿ ਕ੍ਰिएਟਿਵਟੀ ਨੂੰ ਰੋਕਣਾ।
ਰਾਹਦਾਰੀ ਤੇ ਸਹਿਮਤੀ ਬਣਾਓ: fixed widths, consistent padding, ਅਤੇ ਨਾਮਕਰਨ ਜਿਵੇਂ feature-name__settings-dialog.png. diagrams ਲਈ source ਫਾਇਲਾਂ ਰੱਖੋ (ਜਿਵੇਂ Mermaid ਜਾਂ editable SVG) ਤਾਂ ਕਿ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਡਿਜ਼ਾਈਨਰ ਦੀ ਲੋੜ ਨਾ ਹੋਵੇ।
PR ਟੈਮਪਲੇਟ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਚੈੱਕ: “ਕੀ ਪਹਿਲਾਂ ਹੀ ਇਸ ਲਈ ਇੱਕ ਪੰਨਾ ਹੈ?”, “ਕੀ ਸਿਰਲੇਖ ਉਸ ਸੈਕਸ਼ਨ ਨਾਲ ਮਿਲਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਹੈ?”, “ਇਹ ਕੀ ਨਵਾਂ top-level category ਬਣਾਏਗਾ?” ਇਸ ਨਾਲ content sprawl ਰੁਕਦਾ ਹੈ ਪਰ ਯੋਗਦਾਨਾਂ ਨੂੰ ਉਤਸ਼ਾਹ ਮਿਲਦਾ ਹੈ।
ਇੱਕ ਕਮਿਊਨਿਟੀ ਸਾਈਟ ਸਿਰਫ਼ ਉਪਯੋਗੀ ਹੋਣ ਤੇ ਹੀ ਕੰਮ ਕਰਦੀ—assitive tech 'ਤੇ, ਧੀਮੀ ਕਨੈਕਸ਼ਨ 'ਤੇ, ਅਤੇ search ਰਾਹੀਂ। accessibility, performance ਅਤੇ SEO ਨੂੰ ਡਿਫੌਲਟ ਮੰਨੋ, ਅਖੀਰ 'ਤੇ ਜੋੜੀ ਹੋਈ ਚੀਜ਼ ਨਹੀਂ।
ਸੈਮਾਂਟਿਕ structure ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। headings ਲੜੀਵਾਰ ਵਰਤੋ (H1 ਫਿਰ H2/H3), ਅਤੇ ਫੌਂਟ ਵੱਧ ਕਰਨ ਲਈ ਲੈਵਲ ਨਾ ਛੱਡੋ।
ਗੈਰ-ਟੈਕਸਟ ਸਮੱਗਰੀ ਲਈ ਮਾਇਨੇਦਾਰ alt text ਲਾਜ਼ਮੀ ਕਰੋ। ਨਿਯਮ: ਜੇ ਇਮੇਜ ਜਾਣਕਾਰੀ ਦਿੰਦੀ ਹੈ ਤਾਂ ਚਾਰਣ ਕਰੋ; ਜੇ ਸਜਾਵਟੀ ਹੈ ਤਾਂ alt="" ਵਰਤੋ ਤਾਂ screen readers ਇਸਨੂੰ ਛੱਡ ਸਕਣ।
ਡਿਜ਼ਾਈਨ tokens ਵਿੱਚ color contrast ਅਤੇ focus states ਚੈੱਕ ਕਰੋ ਤਾਂ ਕਿ ਯੋਗਦਾਨਕਾਰ ਅਟਕਣ ਨਾ। ਹਰ interactive ਚੀਜ਼ ਕੀਬੋਰਡ ਨਾਲ ਪਹੁੰਚਯੋਗ ਹੋਵੇ ਅਤੇ focus menu/dialogs/code examples ਵਿੱਚ trapped ਨਾ ਹੋਵੇ।
Image optimize ਕਰੋ: maximum display size ਲਈ resize, compress, ਅਤੇ ਜਿੱਥੇ build support ਕਰਦਾ ਹੋ ਉਹਨਾਂ ਆਧੁਨਿਕ ਫਾਰਮੈਟ ਵਰਤੋ। ਜ਼ਿਆਦਾ client-side bundles avoid ਕਰੋ ਜੇ ਪੰਨਾ ਜ਼ਿਆਦਾਤਰ ਟੈਕਸਟ ਹੈ।
ਤੀਸਰੇ-ਪਾਸਾ ਸਕ੍ਰਿਪਟਾਂ ਘੱਟ ਰੱਖੋ। ਹਰ widget ਵਜ਼ਨ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਸਾਈਟ ਧੀਮੀ ਕਰ ਸਕਦਾ ਹੈ।
Host ਦੇ caching defaults 'ਤੇ ਨਿਰਭਰ ਰਹੋ (immutable assets with hashes). ਜੇ ਤੁਹਾਡਾ SSG support ਕਰਦਾ ਹੈ ਤਾਂ minified CSS/JS ਜਨਰੇਟ ਕਰੋ ਅਤੇ ਸਿਰਫ ਜੋ critical ਹੈ ਉਹ inline ਕਰੋ।
ਹਰ ਪੰਨੇ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ title ਅਤੇ ਛੋਟੀ meta description ਦਿਓ ਜੋ ਪੰਨੇ ਨਾਲ ਮਿਲਦੀ ਹੋਵੇ। ਸਾਫ, ਸਥਿਰ URLs ਰੱਖੋ (ਜੋੜਾ ਰਹਿਣ; ਮਿਤੀਆਂ ਨਾ ਰੱਖੋ ਜੇ ਉਹ ਜ਼ਰੂਰੀ ਨਹੀਂ)।
sitemap ਅਤੇ robots.txt ਜਨਰੇਟ ਕਰੋ ਜੋ public docs ਨੂੰ index ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹੋਣ। ਜੇ ਤੁਸੀਂ versioned docs ਪ੍ਰਕਾਸ਼ਤ ਕਰਦੇ ਹੋ, ਤਾਂ duplicate content ਤੋਂ ਬਚਣ ਲਈ ਇੱਕ ਸੰਸਕਰਣ ਨੂੰ "current" ਬਣਾਓ ਅਤੇ ਹੋਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਲਿੰਕ ਕਰੋ।
ਕੇਵਲ ਉਸ ਸਮੇਂ analytics ਜੋੜੋ ਜਦੋਂ ਤੁਸੀਂ ਡੇਟਾ 'ਤੇ ਕਾਰਵਾਈ ਕਰੋਗੇ। ਜੇ ਤੁਸੀਂ ਕਰੋ, ਤਾਂ ਇਹ ਦੱਸੋ ਕਿ ਕੀ ਇਕੱਠਾ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਕਿਉਂ, ਅਤੇ opt-out ਕਿਵੇਂ ਕਰਨਾ ਹੈ /privacy ਵਰਗੇ ਅਲੱਗ ਪੰਨੇ 'ਤੇ।
ਆਖ਼ਿਰ 'ਚ, ਵੈਬਸਾਈਟ ਸਮੱਗਰੀ ਲਈ ਇੱਕ ਸਪਸ਼ਟ license ਨੋਟਿਸ ਸ਼ਾਮਿਲ ਕਰੋ (ਕੋਡ license ਤੋਂ ਵੱਖ)। ਇਸਨੂੰ footer ਅਤੇ repository README ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਯੋਗਦਾਨਕਾਰ ਜਾਣਣ ਕਿ ਉਨ੍ਹਾਂ ਦੀ ਲਿਖੀ ਸਮੱਗਰੀ ਅਤੇ ਇਮੇਜ ਦੁਬਾਰਾ ਕਿਵੇਂ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ।
ਤੁਹਾਡੀ ਵੈਬਸਾਈਟ ਦੇ ਮੁੱਖ ਪੰਨੇ ਨਵੀਂ ਯੋਗਦਾਨਕਾਰਾਂ ਲਈ "front desk" ਹਨ। ਜੇ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ—ਪ੍ਰੋਜੈਕਟ ਕੀ ਹੈ, ਕਿਵੇਂ ਟਰਾਈ ਕਰਨਾ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਮਦਦ ਚਾਹੀਦੀ ਹੈ—ਤਾਂ ਹੋਰ ਲੋਕ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਕੁਦਮ ਚੁੱਕਣਗੇ।
ਇੱਕ ਸਧਾਰਨ-ਭਾਸ਼ਾ overview ਪੇਜ ਬਣਾਓ ਜੋ ਦੱਸੇ ਕਿ ਪ੍ਰੋਜੈਕਟ ਕੀ ਕਰਦਾ ਹੈ, ਕਿਸ ਲਈ ਹੈ, ਅਤੇ ਕਾਮਯਾਬੀ ਦਾ ਮਾਪ ਕੀ ਹੈ। ਕੁਝ ਸਪਸ਼ਟ ਉਦਾਹਰਨ ਅਤੇ ਇੱਕ ਛੋਟਾ “Is this for you?” ਭਾਗ ਸ਼ਾਮਿਲ ਕਰੋ।
ਫਿਰ ਇੱਕ Quickstart ਪੇਜ ਜੋ momentum ਲਈ optimized ਹੋ: ਪਹਿਲੀ ਸਫਲ ਰਨ ਲਈ ਇੱਕ ਰਸਤਾ, copy‑paste commands ਅਤੇ ਇੱਕ ਛੋਟਾ troubleshooting ਭਾਗ। ਜੇ setup platform-ਵਾਈ ਵੱਖ-ਵੱਖ ਹੈ, ਤਾਂ ਮੁੱਖ ਰਸਤੇ ਨੂੰ ਛੋਟਾ ਰੱਖੋ ਅਤੇ ਵਿਸਥਾਰਿਕ ਗਾਈਡਾਂ ਨੂੰ ਲਿੰਕ ਕਰੋ।
ਸੁਝਾਅ ਪੰਨੇ:
ਇਕ single /contribute ਪੇਜ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਹੇਠਾਂ ਵੱਲ ਈਸ਼ਾਰੇ ਕਰੇ:
/docs/contributing)ਇਸਨੂੰ ਵਿਸ਼ੇਸ਼ ਰੱਖੋ: 3–5 ਕੰਮ ਨਾਮ ਲਵੋ ਜੋ ਤੁਸੀਂ ਇਸ ਮਹੀਨੇ ਕਰਵਾਉਣੇ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਸਿੱਧੇ relevant issues ਨੂੰ ਦਰਸਾਓ।
ਅਹੰਕਾਰ ਦੀਆਂ ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ ਪਹਿਲੀ ਕਤਾਰ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ਨਾਂ ਕਿ repo ਵਿੱਚ ਛੁਪਾਈਆਂ:
/community/meetings)/changelog (ਜਾਂ /releases) ਸ਼ਾਮਿਲ ਕਰੋ ਜਿਸ ਵਿੱਚ ਇਕ ਇਕਸਾਰ ਫਾਰਮੈਟ ਹੋਵੇ: ਮਿਤੀ, highlights, upgrade notes, ਅਤੇ PRs/issues ਦੇ ਲਿੰਕ। ਟੈਮਪਲੇਟ maintainers ਦਾ ਕੰਮ ਘੱਟ ਕਰਦੇ ਹਨ ਅਤੇ community-written notes ਨੂੰ ਅਸਾਨੀ ਨਾਲ ਸਮੀਖਿਆਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
Showcase ਪੰਨਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ stale lists credibility ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ /community/showcase ਜੋੜਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਹਲਕਾ rule ਰੱਖੋ (ਉਦਾਹਰਨ: “quarterly review”) ਅਤੇ ਇੱਕ ਛੋਟੀ submission form ਜਾਂ PR template ਦਿਓ।
ਇੱਕ community site ਤਦ ਹੀ ਸਿਹਤਮੰਦ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਅਪਡੇਟਸ ਅਸਾਨ, ਸੁਰੱਖਿਅਤ, ਅਤੇ ਇਨਾਮਦਾਇਕ ਹੋਂ। ਤੁਹਾਡਾ ਲਕੜੀ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ “ਕਿੱਥੇ ਕਲਿੱਕ ਕਰਣਾ ਹੈ?” ਦੀ ਘਟਨਾ ਘੱਟ ਹੋਵੇ ਅਤੇ ਛੋਟੇ ਸੁਧਾਰ ਕੀਮਤੀ ਮਹਿਸੂਸ ਹੋਣ।
Docs, guides ਅਤੇ FAQs 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ “Edit this page” ਲਿੰਕ ਸ਼ਾਮਿਲ ਕਰੋ। ਇਸਨੂੰ ਸਿੱਧਾ ਰਿਪੋ ਦੀ ਫਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ ਤਾਂ ਜੋ ਉਹਨਾਂ ਦਾ PR ਫਲੋਵ ਘੱਟ ਤੋਂ ਘੱਟ ਕਦਮਾਂ ਨਾਲ ਖੁਲ ਜਾਵੇ।
ਲਿੰਕ ਟੈਕਸਟ ਦੋਸਤਾਨਾ ਰੱਖੋ (ਉਦਾਹਰਨ: “Fix a typo” ਜਾਂ “Improve this page”) ਅਤੇ ਇਸਨੂੰ ਸਮਗ੍ਰੀ ਦੇ ਉਪਰ ਜਾਂ ਤਹਿਤ ਰੱਖੋ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ CONTRIBUTING guide ਹੈ, ਤਾਂ ਉਸਦਾ ਲਿੰਕ ਵੀ ਉਥੇ ਦਿਓ (ਉਦਾਹਰਨ: /contributing).
Localization ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਫੋਲਡਰ ਲੇਆਉਟ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਆਮ ਪਹੁੰਚ:
ਸਮਿਖਿਆ ਕਦਮ ਦਸਤਾਵੇਜ਼ ਕਰੋ: ਕੌਣ ਅਨੁਵਾਦ ਮਨਜ਼ੂਰ ਕਰ ਸਕਦਾ ਹੈ, partial translations ਨੂੰ ਕਿਵੇਂ ਹੈਂਡਲ ਕਰਦੇ ਹੋ, ਅਤੇ outdated translations ਨੂੰ ਕਿਵੇਂ ਟਰੈਕ ਕਰਦੇ ਹੋ। ਜੇ ਅਨੁਵਾਦ ਮੂਲ ਭਾਸ਼ਾ ਤੋਂ ਪਿੱਛੇ ਹਨ ਤਾਂ translated ਪੰਨਿਆਂ ਦੇ ਉੱਪਰ ਛੋਟਾ ਨੋਟ ਸ਼ਾਮਿਲ ਕਰਨਾ ਸੋਚੋ।
ਜੇ ਪ੍ਰੋਜੈਕਟ ਰਿਲੀਜ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਯੂਜ਼ਰਾਂ ਲਈ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕੀ ਪੜ੍ਹਣਾ ਹੈ:
ਬਿਨਾਂ ਪੂਰੀ docs versioning ਦੇ ਵੀ, ਇੱਕ ਛੋਟੀ ਬੈਨਰ ਜਾਂ ਸਿਲੈਕਟਰ ਜੋ ਇਹ ਵੱਖ ਕਰਕੇ ਦਿਖਾਏ ਗ਼ਲਤਫਹਮੀ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ support ਲੋਡ ਘਟਾਉਂਦਾ ਹੈ।
FAQs ਨੂੰ docs ਸਿਸਟਮ ਵਿੱਚ ਹੀ ਰੱਖੋ (ਨਾ ਕਿ issue comments ਵਿੱਚ)। ਇਸਨੂੰ ਪ੍ਰਮੁੱਖ ਤਰੀਕੇ ਨਾਲ /docs/faq 'ਤੇ ਲਿੰਕ ਕਰੋ ਅਤੇ ਲੋਕਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਹੱਲ ਵਾਲੇ ਡਾਲ ਬਣਾਉਣ ਲਈ ਲਗਾਉ।
ਖੁੱਲ੍ਹਾ ਤੌਰ 'ਤੇ ਛੋਟੇ ਤੇਜ਼-ਨਤੀਜੇ ਵਾਲੇ ਕੰਮਾਂ ਲਈ ਆਮੰਤਰ ਕਰੋ: typo fixes, ਅਸਪਸ਼ਟ ਉਦਾਹਰਣ, ਅਪਡੇਟਡ ਸਕ੍ਰੀਨਸ਼ਾਟ, ਅਤੇ “ਇਹ ਮੇਰੇ ਲਈ ਕੰਮ ਕੀਤਾ” troubleshooting ਨੋਟ। ਇਹ ਨਵੀਂ ਯੋਗਦਾਨਕਾਰਾਂ ਲਈ ਸ੍ਹੀਦ-ਦਰਵਾਜ਼ਾ ਹੁੰਦੇ ਹਨ ਅਤੇ ਲਗਾਤਾਰ ਵੈਬਸਾਈਟ ਨੂੰ ਸੁਧਾਰਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਲਿਖਣ ਅਤੇ ਰੱਖ-ਰਖਾਉ ਲਈ incentives ਦੇਣੇ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਇਨਾਮ ਦਿੰਦੇ ਹੋ (ਜਿਵੇਂ ਛੋਟੇ sponsorships ਜਾਂ credits); Koder.ai ਦਾ “earn credits” ਪ੍ਰੋਗਰਾਮ ਇੱਕ ਮਿਸਾਲ ਦੇ ਤੌਰ 'ਤੇ ਦਿੱਤਾ ਗਿਆ ਹੈ ਜੋ ਸਮੱਗਰੀ ਬਣਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ।
ਇੱਕ community-driven ਸਾਈਟ ਦੋਸਤਾਨਾ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ—ਪਰ ਇਹ ਕੁਝ ਲੋਕਾਂ ਦੇ ਅਤਿ-ਭਾਰ ਤੇ ਨਹੀਂ। ਲਕੜੀ ਇਹ ਬਣਾਉਣਾ ਹੈ ਕਿ ਰੱਖ-ਰਖਾਅ ਪੇਸ਼ਗੋਈਯੋਗ, ਹਲਕਾ, ਅਤੇ ਸਾਂਝਾ ਕਰਨਯੋਗ ਹੋਵੇ।
ਇਕ cadence ਚੁਣੋ ਜੋ ਲੋਕ ਯਾਦ ਰੱਖ ਸਕਣ ਅਤੇ ਜੋੜੀ ਗਈ ਚੀਜ਼ਾਂ ਨੂੰ ਆਟੋਮੇਟ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਇਸ ਤਹਿ /CONTRIBUTING.md ਵਿੱਚ ਇਸ ਸਿਲੇਬਸ ਨੂੰ ਰੱਖਦੇ ਹੋ (ਛੋਟਾ ਰੱਖੋ), ਤਾਂ ਹੋਰ ਲੋਕ ਭਰੋਸੇ ਨਾਲ ਕਦਮ ਚੁੱਕ ਸਕਦੇ ਹਨ।
ਸਮੱਗਰੀ ਬਾਰੇ اختلاف ਆਮ ਹਨ: tone, naming, homepage 'ਤੇ ਕੀ ਰਹੇ, ਜਾਂ ਬਲੌਗ ਪੋਸਟ "official" ਹੈ ਜਾਂ ਨਹੀਂ। ਲੰਮੇ ਬਹਿਸਾਂ ਤੋਂ بچਣ ਲਈ ਲਿਖੋ:
ਇਹ ਨਿਯਮ ਕਾਬੂ ਕਰਨ ਲਈ ਨਹੀਂ, ਸਗੋਂ ਸਪਸ਼ਟਤਾ ਲਈ ਹਨ।
ਇੱਕ calendar ਫ਼ੈਨਸੀ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਇੱਕ single issue (ਜਾਂ markdown file) ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਆਉਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਲਿਖੀਆਂ ਹੋਣ:
ਇਸਨੂੰ blog/news planning notes ਤੋਂ link ਕਰੋ ਤਾਂ ਕਿ ਯੋਗਦਾਨਕਾਰ ਆਪਣੇ ਆਪ assignment ਕਰ ਸਕਣ।
ਦੌਰਾਨ-ਦੌਰਾਨ ਆਉਣ ਵਾਲੇ website issues (typos, outdated screenshots, missing links, accessibility fixes) ਨੂੰ track ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ “good first issue” ਨਾਲ label ਕਰੋ। acceptance criteria ਸਪਸ਼ਟ ਪਾਓ ਜਿਵੇਂ “ਇੱਕ ਪੰਨਾ update ਕਰੋ + formatter ਚਲਾਓ + ਨਤੀਜਾ screenshot ਕਰੋ।”
ਆਪਣੀਆਂ docs ਵਿੱਚ ਇੱਕ ਛੋਟਾ “Common local setup issues” ਸੈਕਸ਼ਨ ਰੱਖੋ। ਉਦਾਹਰਣ:
# clean install
rm -rf node_modules
npm ci
npm run dev
ਉਹ 2–3 ਆਮ ਗਲਤੀਆਂ ਜਿਹੜੀਆਂ ਅਕਸਰ ਦਿਖਦੀਆਂ ਹਨ (ਥੀਕ Node version ਨਾ ਹੋਣਾ, Ruby/Python dependency ਮਿਸਿੰਗ, port ਪਹਿਲਾਂ ਹੀ ਵਰਤਿਆ ਜਾ ਰਿਹਾ) ਦਾ ਜ਼ਿਕਰ ਕਰੋ। ਇਹ back-and-forth ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਮੈਨਟੇਨਰਾਂ ਦੀ ਊਰਜਾ ਬਚਾਉਂਦਾ ਹੈ।
ਇੱਕ ਇਕ-ਵਾਕ ਦੀ ਉਦੇਸ਼ ਬਿਆਨ ਲਿਖੋ, ਫਿਰ ਉਹ ਟੌਪ 1–3 ਕੰਮ ਲਿਖੋ ਜੋ ਸਾਈਟ ਨੂੰ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ: docs, downloads, community, updates). ਜੇ ਕੋਈ ਪੰਨਾ ਜਾਂ ਫੀਚਰ ਉਨ੍ਹਾਂ ਕੰਮਾਂ ਨੂੰ ਸਹਾਇਤਾ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਇਸਨੂੰ ਇਸ ਵੇਲੇ ਨਾਨ-ਗੋਲ ਮੰਨੋ.
ਇੱਕ ਸਧਾਰਨ ਚੈੱਕ: ਜੇ ਤੁਸੀਂ ਸਾਈਟ ਦਾ ਉਦੇਸ਼ ਇਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਯਾਤਰੀ ਵੀ ਨਹੀਂ ਸਮਝ ਪਾਏਗਾ।
ਆਪਣੇ ਮੁੱਖ ਦਰਸ਼ਕ ਲਿਸਟ ਕਰੋ ਅਤੇ ਹਰ ਇਕ ਲਈ ਉਹ ਪਹਿਲੀ ਕਲਿੱਕ ਦੱਸੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ:
ਹਰ ਦਰਸ਼ਕ ਲਈ ਉਨ੍ਹਾਂ ਦੀਆਂ ਸਿਖਰ ਦੀਆਂ 3 ਸਵਾਲਾਂ ਲਿਖੋ (ਜਿਵੇਂ “ਕੀ ਇਹ ਸਰਗਰਮ ਤਰੀਕੇ ਨਾਲ maintained ਹੈ?”, “ਮੈਂ ਬੱਗ ਕਿੱਥੇ ਰਿਪੋਰਟ ਕਰਾਂ?”) ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਨੈਵੀਗੇਸ਼ਨ ਉਹਨਾਂ ਦੇ ਪ੍ਰਸ਼ਨਾਂ ਦੇ ਜਵਾਬ ਤੇਜ਼ੀ ਨਾਲ ਦਿੰਦੀ ਹੈ।
ਇੱਕ “ਜਾਣ-ਪਛਾਣ ਲਈ ਉਦੇਸ਼ਤ” sitemap ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਲੋਕ ਕਿਸ ਤਰ੍ਹਾਂ ਸੋਚਦੇ ਹਨ ਉਸਦੇ ਨਾਲ ਮੈਚ ਕਰਦਾ ਹੋਵੇ:
ਜੇ ਨਵੀਂ ਸਮੱਗਰੀ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦੀ, ਤਾਂ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਨਵਾਂ ਸਮੱਗਰੀ ਕਿਸਮ ਚਾਹੀਦੀ ਹੈ (ਕੰਮਨ ਨਹੀਂ) ਜਾਂ ਜਾਣਕਾਰੀ ਰਿਪੋ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ।
README ਨੂੰ developer-facing ਜ਼ਰੂਰਤਾਂ ਲਈ ਰੱਖੋ: build ਨਿਰਦੇਸ਼, local dev setup, testing, ਅਤੇ ਤੁਰੰਤ project ਸਥਿਤੀ। ਵੈਬਸਾਈਟ ਲਈ ਵਰਤੋ:
ਇਸ ਵੰਡ ਨਾਲ ਡੁਪਲਿਕੇਟ ਸਮੱਗਰੀ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਅਲੱਗ ਹੋ ਸਕਦੀ ਹੈ।
ਉਸ ਸਟੈਕ ਨੂੰ ਚੁਣੋ ਜੋ “Markdown-first” edits ਅਤੇ ਤੇਜ਼ local preview ਸਮਰਥਿਤ ਕਰਦਾ ਹੋਵੇ.
ਆਮ ਚੋਣਾਂ:
ਅਜਿਹਾ ਸਧਾਰਨ ਟੂਲ ਚੁਣੋ ਜੋ ਅੱਜ ਦੀਆਂ ਜਰੂਰਤਾਂ ਪੂਰੀ ਕਰੇ।
ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਡੀਫੌਲਟ ਰਾਹ ਹੋਵੇ PR → preview → review → merge.
ਵਾਸਤਵਿਕ ਰਸਤਾ:
main deploys”)ਇਸ ਨਾਲ ਰਿਵਿਊਅਰ-ਕੰਮ ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਯੋਗਦਾਨਕਾਰਾਂ ਨੂੰ ਯਕੀਨ ਮਿਲਦਾ ਹੈ।
ਸੰਰਚਨਾ ਅਤੇ ਟੈਮਪਲੇਟ ਵਰਤੋ ਤਾਂ ਕਿ ਫਾਰਮੇਟਿੰਗ ਬਾਰੇ ਬਹਿਸ ਘੱਟ ਹੋਵੇ:
ਸਹਾਇਕ ਜ਼ਰੂਰੀ ਚੀਜ਼ਾਂ:
CONTRIBUTING.md ਨੂੰ “website-first” ਅਤੇ ਨਿਰਦਿਸ਼ਟ ਬਣਾਓ.
ਸ਼ਾਮਿਲ ਕਰੋ:
ਇਸਨੂੰ ਅਜਿਹਾ ਰੱਖੋ ਕਿ ਲੋਕ ਇਸਨੂੰ ਅਸਾਨੀ ਨਾਲ ਪੜ੍ਹਣ ਅਤੇ ਫੋਲੋ ਕਰਨ।
ਇਹਨਾਂ ਨੂੰ ਡੀਫੌਲਟ ਸਮਝ ਕੇ ਕਰੋ, ਨਿਕਾਸ ਨਹੀਂ:
alt=""ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ automated checks (link checker, Markdown lint, formatting) ਵਰਤੋ ਤਾਂ ਜੋ ਰਿਵਿਊਅਰ ਮੈਨੂਅਲ ਕੰਮ ਘੱਟ ਹੋਵੇ।
ਆਪਡੇਟਸ ਅਸਾਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਓ.
ਕਮਿਊਨਿਟੀ ਅਪਡੇਟ ਲਈ:
/docs/faq)/docs/en/, /docs/es/)ਮੇਨਟੇਨਰ ਸੁਸਤੇਨਬਿਲਟੀ ਲਈ:
/website, /docs, /blog, /.github ਵਰਗਾ ਲੇਆਉਟ/website/README.md ਜਿੱਥੇ copy-paste commands ਦਿੱਤੇ ਹੋਣ/templates ਫੋਲਡਰ (docs page, tutorial, announcement)CODEOWNERS ਜੋ ਖੇਤਰ ਅਨੁਸਾਰ ਰਿਵਿਊ ਰੂਟ ਕਰੇਮਕਸਦ ਇਹ ਹੈ ਕਿ ਕੋਈ ਵੀ ਵਿਅਕਤੀ typo ਠੀਕ ਕਰ ਸਕੇ ਬਿਨਾਂ build ਮਾਹਿਰ ਬਣੇ।
/privacy ਪੰਨਾ ਰੱਖੋ ਅਤੇ ਸਪਸ਼ਟ ਦੱਸੋ ਕਿ ਕੀ ਇਕੱਠਾ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਅਤੇ ਕਿਉਂ