مشارکت متن‌باز بدون کدنویسی؛ از Policy تا Review

مشارکت در پروژه متن‌باز بدون کدنویسی ممکن است؛ اما «عمومی‌بودن مخزن» دعوت نامحدود برای تست، انتشار داده یا تغییر هر فایل نیست. هر پروژه، قواعد، ظرفیت نگهداری، کانال و تعریف خودش را از contribution مفید دارد. یک typo fix کوچک که سیاست پروژه را رعایت می‌کند می‌تواند پذیرفتنی باشد؛ یک گزارش مفصل خارج از کانال یا حاوی داده حساس می‌تواند برای پروژه هزینه و خطر بسازد.

این راهنما یک Open Source Non-Code Contribution Record می‌سازد: Project/Version/Governance → Policy/Permission/Channel → Contribution Candidate → Reproduction/Artifact → Privacy/Security/License/Locale/Accessibility → Issue/Change → Review/Revision → Outcome/Maintenance/Withdrawal. هدف، تضمین merge، شهرت یا استخدام نیست؛ هدف، یک مشارکت محدود، قابل بررسی، محترمانه و قابل نگهداری است.

خلاصه عملی: دوازده Gate پیش از مشارکت

• Project: مخزن رسمی، وضعیت فعالیت، نسخه و governance معلوم است.
• Policy: README، CONTRIBUTING، Code of Conduct، SECURITY و template خوانده شده‌اند.
• Permission: تست، داده، حساب، شبکه و دامنه فعالیت مجازند.
• Channel: Question، Discussion، Issue، security report یا change route درست انتخاب شده است.
• Need: نیاز جاری است، duplicate نیست و maintainer آن را می‌خواهد یا دست‌کم منع نکرده است.
• Scope: یک outcome کوچک و حدود NotDoing دارد.
• Evidence: مشاهده، version، environment و artifact قابل بازبینی‌اند.
• Safety: secret، PII، exploit، داده Production و محتوای شخص ثالث منتشر نمی‌شود.
• Rights: authorship، license، contribution terms و اجازه کارفرما/مشتری بررسی شده‌اند.
• Quality: زبان، accessibility، locale، link و preview طبق معیار پروژه بررسی شده‌اند.
• Review: feedback، revision، disagreement و توقف محترمانه مدیریت می‌شوند.
• Lifecycle: accepted/closed/deferred/withdrawn ثبت و artifact در صورت نیاز نگهداری یا اصلاح می‌شود.

«بدون کدنویسی» دقیقاً یعنی چه؟

یعنی outcome اصلی تغییر منطق برنامه نیست؛ نه اینکه هیچ ابزار فنی وجود ندارد. ویرایش Markdown، کار با فرم Issue، گرفتن log پاک‌سازی‌شده، اجرای build آزمایشی، مقایسه نسخه‌ها یا ساخت Pull Request ممکن است لازم باشد. پروژه می‌تواند برای documentation هم lint، Git، امضای commit یا review فنی بخواهد. سطح ابزار را از task و policy استخراج کنید، نه از برچسب «non-code».

Contribution با Volunteering، Support و Portfolio یکی نیست

• Contribution: artifact یا تصمیمی که وارد workflow رسمی پروژه می‌شود.
• Community participation: پاسخ، تسهیل یا حضور که ممکن است artifact merge‌شدنی نداشته باشد.
• User feedback: تجربه کاربر؛ هنوز تا issue معتبر یا requirement فاصله دارد.
• Portfolio evidence: بازنمایی مجازِ سهم شما برای یک audience دیگر؛ پذیرش contribution خودبه‌خود اجازه بازنشر همه چیز نیست.

اگر قصد نمایش عمومی نتیجه را دارید، مسیر مستقل ساخت پورتفولیوی QA با Permission و Evidence را اجرا کنید.

پروژه را با یک Snapshot انتخاب کنید، نه با تعداد Star

Star، follower یا label به‌تنهایی نشان نمی‌دهد پروژه فعال، امن، خوش‌برخورد یا آماده پذیرش contribution شماست. مخزن رسمی و upstream را از وب‌سایت یا organization معتبر پیدا کنید. release، commit، issue و پاسخ‌های اخیر را فقط به‌عنوان signal با تاریخ ببینید؛ سکوت ممکن است ناشی از کمبود maintainer، انتقال پروژه یا سیاست پاسخ‌گویی باشد.

ProjectID | Name | Official owner/repository | Upstream evidence
SnapshotAt/Timezone | Default branch | Release/version/build
Activity signals/date | Maintainers/governance | Decision route
Contribution files/versions | Supported channels | Archived/read-only?
Assumptions | Unknowns | Contact route | Recheck trigger

Community Health را به ترتیب بخوانید

راهنمای رسمی GitHub درباره CONTRIBUTING توضیح می‌دهد که پروژه می‌تواند روش ساخت Issue و Pull Request، کانال‌های ارتباطی و انتظارهای رفتاری را در فایل راهنما و templateها مشخص کند. وجود یا نبود هر فایل حکم کیفیت قطعی نیست؛ آنچه وجود دارد را version و location کنید و تعارض میان repository-level و organization-level guidance را به maintainer ارجاع دهید.

• README: هدف، scope، نصب و support status؛
• CONTRIBUTING: setup، task claim، test، style، sign-off و review؛
• CODE_OF_CONDUCT: رفتار، enforcement و report route؛
• SECURITY: نسخه‌های پشتیبانی‌شده و کانال گزارش آسیب‌پذیری؛
• LICENSE/NOTICE: حقوق و تعهدها؛
• Issue/PR templates: fieldها، data و acceptance expectations؛
• GOVERNANCE/MAINTAINERS: اختیار تصمیم و escalation؛
• SUPPORT: مرز question/support با defect.

نبود CONTRIBUTING مجوز حدس‌زدن نیست

اگر guidance ناقص است، با کم‌ریسک‌ترین کانال عمومیِ تعیین‌شده یک سؤال کوتاه بپرسید: آیا این نوع contribution پذیرفته می‌شود، مسیر ترجیحی چیست و آیا کسی روی آن کار می‌کند؟ نبود پاسخ، approval نیست. برای vulnerability، حریم خصوصی، داده واقعی یا تست فعال، سکوت را اجازه تلقی نکنید.

Public Repository با Open Source و Permission یکی نیست

راهنمای رسمی GitHub درباره مجوز مخزن صریحاً میان public repository و مجوزی که حق استفاده، تغییر و توزیع می‌دهد فرق می‌گذارد. نبود license به معنی «هر کاری آزاد است» نیست. نوع license، مسیر contribution، CLA/DCO و مالکیت متن، ترجمه، تصویر یا داده را برای همان پروژه بررسی کنید؛ این مقاله مشاوره حقوقی نیست.

برای تحلیل عمیق‌تر Artifact، SPDX، obligation و distribution به راهنمای مجوز ابزار تست متن‌باز مراجعه کنید. افزودن یک license به fork یا فایل خودتان، حقوقی را که بر محتوای دیگری ندارید ایجاد نمی‌کند.

Permission تست را مستقل از مجوز کپی بسنجید

مجوز source code لزوماً اجازه scan، load، fuzz، account automation، scraping، دسترسی به instance عمومی یا مشاهده داده کاربران را نمی‌دهد. Target، owner، environment، activity، intensity، time، account، data، network، third party، stop condition و report channel باید مجاز باشند. راهنمای EULA و Permission Record تست این مرز را جداگانه پوشش می‌دهد.

قبل از کار، یک Contribution Candidate بسازید

CandidateID | ProjectID/version | Need/source/date
Type[docs,repro,triage,l10n,a11y,support,research,...]
User/problem | Proposed outcome | Acceptance evidence
Policy/channel | Issue/discussion link | Owner/claim status
Scope/NotDoing | Dependencies | Risk/data/rights screen
Effort range | Maintenance need | Go/Ask/Hold/Drop

Candidate را کوچک کنید تا review و بازگشت آسان باشد. «مستندات را بهتر می‌کنم» scope نیست؛ «برای نسخه X، مرحله گمشده Y را با یک مثال synthetic و لینک مرجع اضافه می‌کنم؛ ترجمه کل راهنما و تغییر API خارج از scope است» قابل بررسی‌تر است.

Good First Issue یک قرارداد پذیرش نیست

Label می‌تواند stale، خودکار یا برای سطح دیگری باشد. تاریخ، assignee، comment، linked PR و آخرین وضعیت را بررسی کنید. پیش از صرف زمان، طبق policy اعلام علاقه کنید و confirmation بخواهید؛ اما reservation دائمی مطالبه نکنید. اگر task مدتی بی‌پاسخ مانده، حق ندارید کار موازی دیگری را متوقف یا maintainer را ملزم به review فوری کنید.

Question، Discussion، Issue و Change را جابه‌جا نکنید

نیاز	کانال معمولِ نامزد	قبل از ارسال
نحوه استفاده یا support	SUPPORT، forum یا Discussion	مستندات و سؤال‌های قبلی را جست‌وجو کنید
ایده یا ابهام scope	Discussion یا proposal issue	نیاز و trade-off را بیان کنید
رفتار مشاهده‌شده	Bug template	نسخه، duplicate و reproduction را بررسی کنید
ضعف امنیتی	SECURITY یا private report	عمومی نکنید؛ نسخه و scope را چک کنید
تغییر کوچکِ از قبل توافق‌شده	PR/MR یا edit workflow	style، tests، sign-off و linked issue

مسیر اول: Reproduction و Triage غیرکدی

تستر می‌تواند issue موجود را روی نسخه یا محیط دیگری بازتولید کند، regression range را محدود کند، duplicateهای محتمل را پیوند دهد یا minimal fixture بسازد—اگر پروژه چنین مشارکتی را می‌پذیرد. Observation را از hypothesis جدا کنید. «در build A سه بار از سه بار رخ داد؛ در B رخ نداد» evidence است؛ «پس commit C علت است» بدون تحلیل علت، فرضیه است.

ReproID | Issue/Candidate | Build/commit/package source
OS/device/browser/runtime/config/locale/timezone
Preconditions | Synthetic fixture/hash | Exact actions
Observed/Expected source | Frequency/runs | First/last seen
Comparison matrix | Logs/screenshots/redaction | Hypotheses
NotTested/Unknown | Cleanup | Reproducer/date

Bug Report خوب احتمال بررسی را بالا می‌برد، رفع را تضمین نمی‌کند

راهنمای رسمی Bugzilla موزیلا بر summary متمایز، steps دقیق، expected/actual و جزئیات نسخه/محیط تأکید دارد و برای issueهای جدا، reportهای جدا توصیه می‌کند. همین guidance پروژه‌محور است، نه فرمول جهانی. برای طراحی کامل report، severity، evidence و follow-up از قالب Bug Report حرفه‌ای استفاده کنید.

قابل بازتولید بودن به maintainer کمک می‌کند، اما اولویت، roadmap، impact، capacity، compatibility و risk همچنان مؤثرند. Closed as duplicate، cannot reproduce، wontfix یا deferred توهین به reporter و اثبات بی‌ارزشی مشاهده نیست؛ معنای دقیق label را از همان پروژه بخوانید.

مسیر دوم: مستندات را به‌عنوان محصول تست کنید

• Accuracy: command، option، output و رفتار با نسخه هدف یکی است؟
• Completeness: prerequisite، permission، setup، verify، error و cleanup دارد؟
• Findability: عنوان، navigation، anchor و واژه کاربر مسیر را پیدا می‌کنند؟
• Actionability: کاربر می‌تواند outcome را مستقل مشاهده کند؟
• Safety: نمونه secret، destructive command یا Production target ندارد؟
• Consistency: terminology، link، version و sibling page متناقض نیستند؟
• Accessibility/locale: heading، link text، alt، code direction و زبان قابل استفاده‌اند؟

Documentation Issue و Documentation Patch را تفکیک کنید

اگر source، toolchain یا حق تغییر را نمی‌دانید، ابتدا issue محدود بسازید. اگر policy و acceptance روشن است، patch کوچک با before/after و verification بدهید. ادعای «واضح‌تر شد» کافی نیست؛ audience، task، نقطه شکست، تغییر و روش آزمون را بنویسید. screenshot ممکن است به‌سرعت stale شود؛ متن و تصویر باید version و نگهدارنده داشته باشند.

DocChangeID | Page/path/version | Audience/task
Problem evidence | Current wording/behavior | Proposed change
Source-of-truth | Examples/data origin | Links/anchors
Build/lint/preview/accessibility/locale checks
Before/after outcome | Limits | Reviewer | Maintenance trigger

ترجمه فقط جایگزینی واژه‌ها نیست

اول ببینید پروژه localization workflow، glossary، translation memory، locale owner و string freeze دارد یا نه. ترجمه fork‌شده خارج از workflow ممکن است هرگز منتشر نشود. متن UI، docs و marketing می‌توانند cadence و مجوز متفاوت داشته باشند. معنی action، placeholder، variable، code، link، plural، gender، date/number و screenshot را حفظ کنید.

برای فارسی، ی/ی و ک/ک، ZWNJ، جمع، لحن، RTL/LTR/Bidi، code span، Persian/Arabic/Latin digits، IRR در برابر تومانِ صرفاً نمایشی، UTC/Asia-Tehran و تقویم میلادی/جلالی را تست کنید. راهنمای ارتباط بین‌فرهنگی و Meaning Repair مالک تحلیل عمیق‌تر معنا و locale است.

مسیر سوم: Accessibility Review با Claim محدود

نکات رسمی W3C WAI برای نوشتن دسترس‌پذیر به عنوان‌های روشن، headingهای informative، link text معنادار، alt برای تصاویر و transcript/caption برای multimedia اشاره می‌کند. این tips نقطه شروع‌اند، نه گواهی انطباق. scope، صفحه/نسخه، روش، ابزار کمکی، یافته، مانع، عدم‌پوشش و نیاز به بازبینی افراد دارای تجربه زیسته را ثبت کنید.

• ساختار heading و ترتیب خواندن؛
• keyboard/focus و نام قابل‌فهم control؛
• معنای link بدون «اینجا کلیک کنید»؛
• alt متناسب با purpose، نه توصیف مکانیکی؛
• contrast و وابسته‌نبودن معنا فقط به رنگ؛
• caption/transcript و توضیح visual مهم؛
• zoom/reflow و RTL/Bidi؛
• پیام خطا، recovery و حفظ input.

مسیر چهارم: Support و Community Triage با اختیار محدود

پاسخ به سؤال‌های تکراری، برچسب‌گذاری، بازتولید، خوشه‌بندی و هدایت به docs می‌تواند کمک کند؛ اما فقط اگر role و policy اجازه دهد. خود را maintainer، نماینده یا سخنگوی پروژه معرفی نکنید. قول release، fix، security، compatibility یا refund ندهید. پاسخ را به نسخه و source پیوند دهید و Unknown را به owner ارجاع دهید.

مسیر پنجم: Research، UX و Feedback با رضایت

مصاحبه کاربر، survey یا usability session «صرفاً صحبت» نیست؛ purpose، participant notice/consent، recruitment، recording، incentive، data minimization، access، retention/delete و publication نیاز دارد. کاربران جامعه را بدون اجازه scrape یا برای تحقیق پیام انبوه ندهید. نتیجه نمونه کوچک را «نظر کاربران» تعمیم ندهید؛ denominator، selection bias و unanswered questions را نگه دارید.

Security Finding را در Issue عمومی نگذارید

راهنمای رسمی GitHub برای گزارش خصوصی آسیب‌پذیری توضیح می‌دهد که بعضی مخزن‌های عمومی این قابلیت را فعال می‌کنند؛ این قابلیت از فایل SECURITY جداست. ابتدا سیاست پروژه و کانال تعیین‌شده را بررسی کنید. نبود private-report button مجوز Issue عمومی یا exploit نیست. جزئیات را فقط به گیرنده مجاز و به حد لازم منتقل کنید.

اسکن فعال، proof-of-concept، دسترسی به حساب یا داده، bypass و load بدون authorization انجام ندهید. اگر ناخواسته secret یا داده شخصی دیدید، مشاهده را توسعه ندهید، عمومی نکنید، artifact را امن نگه دارید و طبق policy گزارش دهید. این راهنما مجوز تست امنیتی یا مشاوره حقوقی نمی‌دهد.

Screenshot، Log و Video را پیش از ضمیمه‌کردن ممیزی کنید

• نام، email، avatar، شناسه حساب و notification؛
• token، cookie، header، URL query، API key و QR code؛
• مسیر home، hostname، IP، نام سازمان و repository خصوصی؛
• order/payment/bank/card یا هر داده مالی و سلامت؛
• tab، bookmark، clipboard، history و پس‌زمینه صفحه؛
• EXIF، filename، PDF property، comment، revision و OCR؛
• اطلاعات مشتری/کارفرما یا شخص ثالث؛
• جزئیات vulnerability پیش از disclosure هماهنگ.

Blur همیشه برگشت‌ناپذیر یا کافی نیست. در صورت امکان artifact را با fixture مصنوعی مستقل دوباره بسازید. اصل پرخطر را فقط اگر مجاز و لازم است با access/retention/delete محدود نگه دارید؛ secret واقعی را صرفاً crop نکنید—مسیر revoke/rotate/incident را فعال کنید.

Authorship و Contribution Terms را ثبت کنید

متن، ترجمه، تصویر، diagram، dataset یا fixture باید منشأ و حق contribution داشته باشد. قرارداد کار یا پروژه، NDA، IP assignment، policy کارفرما و حقوق مشتری ممکن است بر زمان کاری، دستگاه، داده یا artifact اثر بگذارند. CLA، DCO، sign-off و terms پلتفرم را برای repository/version جاری بخوانید و در صورت ابهام از owner واجد صلاحیت کمک بگیرید.

RightsID | Artifact | Creator/source | Third-party content
Repository license/version | Contribution terms/CLA/DCO
Employer/client/NDA/IP candidate | Permission evidence/scope
AI/template/tool assistance | Attribution/notice obligations
CanSubmit/Unknown/Hold | Reviewer | Expiry/change trigger

استفاده از AI را پنهان نکنید

policy پروژه درباره AI-generated text، translation، image یا triage را بررسی کنید. خروجی می‌تواند نادرست، دارای citation ساختگی، مشابه محتوای شخص ثالث یا ناسازگار با license/style باشد. داده خصوصی، vulnerability، issue محرمانه یا محتوای دارای محدودیت را به سرویس نامجاز ندهید. contribution‌دهنده مسئول verification، attribution، disclosure و correction باقی می‌ماند.

هویت عمومی و ایمنی شخصی را طراحی کنید

commit، issue و profile ممکن است نام، email، timezone، employer، الگوی حضور و تاریخچه عمومی بسازند. policy پلتفرم و پروژه را برای email privacy، pseudonym، signing و attribution بررسی کنید. اطلاعاتی را که برای contribution لازم نیست منتشر نکنید. harassment، doxxing یا درخواست ناامن را شخصاً مدیریت نکنید؛ Code of Conduct، moderation و report route را به کار ببرید.

برای مشارکت‌کننده داخل ایران، دسترسی را با حدس دور نزنید

دسترسی به host، CAPTCHA، email، package registry، CI، cloud sandbox، payment/sponsorship یا contract می‌تواند با region، ارائه‌دهنده، حساب و زمان تغییر کند. شرایط جاری سرویس و پروژه را بررسی و نتیجه را با تاریخ ثبت کنید. از هویت، محل، شماره یا روش پرداخت جعلی و دورزدن کنترل‌ها خودداری کنید. اگر مسیر رسمی قابل استفاده نیست، maintainer می‌تواند—اما ملزم نیست—کانال مجاز دیگری پیشنهاد دهد.

Artifact را پیش از ارسال در محیط تازه Verify کنید

برای docs، link و commandها را در version هدف و محیط clean اجرا کنید؛ برای translation، preview و placeholderها را بررسی کنید؛ برای repro، fixture مصنوعی و تعداد run را ثبت کنید. نتیجه موفق خودتان proof عمومی نیست. تفاوت environment، permission، feature flag، dependency و زمان را در Limits بنویسید.

ArtifactID | CandidateID | Type/path/version/hash
Source inputs/licenses | Synthetic/real/mixed status
Build/render/repro method | Environment | Expected/observed
Lint/link/a11y/locale/privacy/security checks
Reviewer evidence | Unknown/limitations | Cleanup/retention
Ready/NeedsWork/Hold | VerifiedAt | Supersedes

یک Issue کم‌هزینه برای خواندن بسازید

• عنوان symptom/need + context متمایز؛
• project component و exact version؛
• مشاهده و sourceِ expected behavior؛
• minimal reproduction یا documentation path؛
• impact محدود و بدون اغراق؛
• artifact پاک‌سازی‌شده و قابل دسترسی؛
• جست‌وجوی duplicate و پیوندهای مرتبط؛
• NotTested، Unknown و سؤال مشخص؛
• اعلام آمادگی برای change فقط اگر واقعاً ممکن است.

شدت را از ناراحتی خودتان استنتاج نکنید و maintainer را mention انبوه نکنید. متن را برای یک خواننده پرمشغله با Purpose → Evidence → Requested action مرتب کنید؛ راهنمای ارتباط نوشتاری QA این ساختار را عمیق‌تر می‌کند.

Change کوچک باید Trace و Revert شود

branch/commit strategy، base branch، style، generated files، test/lint، sign-off و PR template پروژه را رعایت کنید. یک change را با یک purpose نگه دارید؛ refactor واژه‌ها، ترجمه گسترده و اصلاح linkهای نامرتبط را بی‌اجازه مخلوط نکنید. linked issue، before/after، verification، risk و rollback ساده ارائه دهید.

ChangeID | Candidate/Issue | Base/target/version
Purpose | Files/strings/artifacts | NotChanged
Before evidence | Proposed diff | Source/rationale
Checks/results | Rights/attribution | Risks/rollback
Reviewer questions | Revision history | Final outcome

GitHub Web UI تنها مسیر نیست

بعضی پروژه‌ها edit-in-browser، CMS، translation platform، mailing list، Gerrit، GitLab، Bugzilla یا patch email دارند. GitHub Issues و Pull Requests را استاندارد جهانی فرض نکنید. اگر workflow نیازمند Git یا command است، مقدار لازم را یاد بگیرید یا task دیگری انتخاب کنید؛ maintainer وظیفه ندارد برای هر preference مسیر موازی بسازد.

Review صف خدمت با SLA تضمینی نیست

زمان review به ظرفیت، release، ریسک، پیچیدگی و governance وابسته است. policy follow-up را رعایت کنید؛ یک یادآوری کوتاه پس از بازه معقول بهتر از ping روزانه، چندکاناله یا پیام خصوصی است. پاسخ‌ندادن را تأیید، رد شخصی یا اجازه merge تلقی نکنید. اگر task دیگر relevant نیست، وضعیت خود را شفاف کنید تا کار قفل نماند.

Feedback را Evidence ببینید، نه داوری شخصیت

هر comment را به Request، Rationale، Source، Owner، Status و Response تبدیل کنید. ناسازگاری با style، scope یا roadmap لزوماً خطای فنی شما نیست؛ و disagree بودن شما نیز مجوز نادیده‌گرفتن governance نیست. سؤال روشن بپرسید، alternative و trade-off ارائه دهید، revision را version کنید و resolved را بدون رسیدگی واقعی علامت نزنید.

ReviewID | Change/Artifact | Reviewer/role | At
Request/observation | Evidence/source | Severity/blocking?
Agree/Question/Alternative/Decline | Response rationale
Revision/commit | Verification | Resolved/Deferred/Disputed
Decision authority | Conduct/safety route if needed

Maintainer حق دارد تغییر را نپذیرد

حتی change درست می‌تواند با direction، maintenance cost، release timing یا scope پروژه ناسازگار باشد. پذیرش، تشکر و credit نیز حق قراردادیِ خودکار نیستند مگر policy یا terms چنین بگویند. شما هم می‌توانید با احترام participation را متوقف کنید. fork یا انتشار مستقل فقط در محدوده license، trademark، data، security و platform terms مجاز است.

Outcome را دقیق نام‌گذاری کنید

وضعیت	معنی محدود	چه چیزی اثبات نمی‌کند
Submitted	artifact به کانال ارسال شد	کامل یا پذیرفتنی است
Acknowledged	دریافت یا مشاهده تأیید شد	در roadmap قرار گرفته است
Needs changes	review درخواست اصلاح دارد	contributor بی‌مهارت است
Merged/Accepted	نسخه مشخص وارد target شد	release یا correctness همیشگی است
Closed/Declined	در این workflow ادامه ندارد	مشاهده یا شخص بی‌ارزش است
Deferred/Stale	فعلاً action فعال ندارد	هرگز بررسی نخواهد شد
Withdrawn	contributor درخواست را پس گرفت	همه نسخه‌ها یا کپی‌ها حذف شده‌اند

Merge پایان مسئولیت Evidence نیست

تغییر ممکن است در release بعدی بیاید، revert شود یا با version جدید stale شود. اگر reviewer سؤال follow-up دارد، تا حد commitment اعلام‌شده پاسخ دهید. اگر خطای خود را یافتید، correction شفاف پیشنهاد کنید. نگهداری دائمی را وعده ندهید؛ owner، review trigger و handoff را ثبت کنید.

اعتبار شغلی پیامد تضمینی مشارکت نیست

Issue یا PR عمومی می‌تواند بخشی از evidence باشد، اما تعداد contribution، badge، follower یا merge توانایی، اخلاق، suitability شغلی یا سهم واقعی را اثبات نمی‌کند. selection bias، task difficulty، reviewer capacity و access تفاوت دارند. برای ادعای حرفه‌ای، contribution، نقش فردی، limitations و permission بازنمایی را دقیق ثبت کنید؛ رزومه زنده و پیشنهاد شغل وعده این مقاله نیست.

Metric را علیه جامعه بازی ندهید

• تعداد Issue/PR بدون usefulness و maintenance؛
• Merge rate بدون scope و reviewer policy؛
• زمان پاسخ بدون capacity و timezone؛
• تعداد typo به‌جای task completion؛
• reaction/follower به‌جای evidence؛
• بستن Issue به‌جای resolution؛
• translation word count بدون accuracy و locale review؛
• تعداد accessibility finding بدون validity و user impact.

شاخص‌های بهتر پروژه‌محورند: درصد candidateهای preflight‌شده، duplicate جلوگیری‌شده، reproduction مستقل، artifactهای بدون data leak، review cycle با دلیل، correction latency، stale-doc detection و burden گزارش‌شده توسط maintainer—همراه denominator و محدودیت.

رکورد نهایی Contribution را ببندید

ContributionID | Project/Snapshot | Candidate/type/scope
Policies/permission/channel | Issue/Change/Artifact versions
Reproduction/verification | Data/security/rights decisions
Review requests/revisions | Decision authority | Outcome/date
Release status | Credit/representation permission | Maintenance owner
Unknown/limitations | Correction/withdrawal | Evidence links/retention

آزمایشگاه مستقل فارسی: پروژه کاملاً ساختگی

آزمایشگاه SYN-OSS-NOCODE-01 یک پروژه fake محلی به نام «Sabz Checkout Docs» دارد. هیچ network، repository، maintainer، user، شرکت، حساب، Issue، vulnerability، order، payment، PSP، بانک، card، credential، token، PII یا پول واقعی وجود ندارد. source و history ساختگی‌اند و نام‌ها به پروژه واقعی اشاره نمی‌کنند.

• README ساختگی، CONTRIBUTING و SECURITY محلی بسازید؛
• یک Candidate برای docs، یکی برای reproduction و یکی برای translation ثبت کنید؛
• fixtureهای fake Checkout/Order/PaymentAttempt/PSP Stub/Callback/Ledger/Reconciliation به کار ببرید؛
• timeout-before/after-fake-commit، retry، duplicate، late و reordered را توصیف کنید؛
• IRR ساختگی را از تومانِ صرفاً نمایشی جدا کنید؛
• Persian/Arabic/Latin digits، ی/ی، ک/ک، ZWNJ و RTL/LTR/Bidi را preview کنید؛
• UTC و Asia/Tehran را نگه دارید و جلالی را presentation-only بنویسید؛
• Issue، review، decline، revision، merge و correction را فقط در فایل‌های محلی شبیه‌سازی کنید.

خروجی آزمایشگاه فقط تمرین طراحی workflow است؛ Open Source بودن، permission، license compliance، امنیت، accessibility، کیفیت contribution، پذیرش maintainer، release، شهرت یا نتیجه شغلی را ثابت نمی‌کند.

Validator مستقل چه خطایی را آشکار کرد؟

یک validator مستقل از شبکه با Node.js ساخته شد. checker سطحی دید: مخزن عمومی، labelِ good-first-issue، Bug Report مفصل، docs patch و comment دوستانه؛ سپس به‌اشتباه VALUABLE_OPEN_SOURCE_CONTRIBUTOR_READY داد. ممیزی ساختاری دقیقاً ۳۹۷ کنترل یکتا در گروه‌های Identity، Governance، Policy، Channel، Permission، Scope، Candidate، Reproduction، Documentation، Localization، Accessibility، Privacy، Security، License، Authorship، Artifact، Issue، Change، Review، Communication، Outcome، Maintenance، Safety، Locale، Evidence و Limits پیدا کرد و HOLD-397 داد.

fixture هیچ پروژه، maintainer، user، repository، Issue، vulnerability یا career outcome واقعی ندارد. پس از pin شدن تمام کنترل‌های ساختگی، نتیجه READY_FOR_OPEN_SOURCE_CONTRIBUTION_REVIEW-0 شد؛ یعنی record آزمایشگاه برای بازبینی آماده است، نه اینکه permission، usefulness، correctness، safety، license compliance، accessibility، merge، release، reputation یا استخدام اثبات شده باشد.

۲۴ Anti-pattern که باید متوقف شوند

• Public repo → مجوز هر نوع تست یا استفاده؛
• Good First Issue → رزرو و پذیرش تضمینی؛
• ندیدن CONTRIBUTING، SECURITY یا Code of Conduct؛
• ساخت Issue برای سؤال support؛
• گزارش vulnerability در کانال عمومی؛
• اسکن یا load بدون authorization؛
• ضمیمه log یا screenshot خام؛
• Blur را anonymity قطعی دانستن؛
• آپلود secret و سپس فقط حذف comment؛
• کپی متن یا تصویر بدون منشأ و rights؛
• ترجمه ماشینی بدون review و disclosure؛
• ادعای conformance accessibility از یک tool؛
• هر رفتار عجیب → defect قطعی؛
• هر closed issue → بی‌احترامی؛
• هر merge → correctness یا release دائمی؛
• ping روزانه یا چندکاناله maintainer؛
• mention انبوه برای priority؛
• مخلوط‌کردن چند تغییر نامرتبط؛
• دستکاری هویت یا region برای دسترسی؛
• وعده رسمی از طرف پروژه بدون role؛
• تعمیم feedback نمونه کوچک به کاربران؛
• شمارش PR یا Issue به‌عنوان skill؛
• نمایش عمومی contribution بدون permission review؛
• تبدیل مشارکت داوطلبانه به وعده شغل و شبکه.

چک‌لیست ۳۰ موردی Contributor

• upstream رسمی و snapshot تاریخ‌دار؛
• وضعیت active/archive/read-only؛
• README و support boundary؛
• CONTRIBUTING و template جاری؛
• Code of Conduct و safety route؛
• SECURITY و private channel؛
• LICENSE/NOTICE/CLA/DCO؛
• governance و decision authority؛
• permission مستقل تست؛
• کانال درست؛
• duplicate و current-status search؛
• claim/assignment status؛
• Candidate و NotDoing؛
• version و environment دقیق؛
• synthetic fixture؛
• observation جدا از hypothesis؛
• expected-result source؛
• privacy و secret scan؛
• security disclosure gate؛
• authorship و third-party rights؛
• employer/client/NDA candidate؛
• AI policy و disclosure؛
• locale و RTL/Bidi checks؛
• accessibility scope و limits؛
• fresh-environment verification؛
• Issue/Change trace؛
• review request log؛
• respectful follow-up و exit؛
• outcome و release distinction؛
• maintenance، correction و withdrawal.

برنامه ۳۰ روزه بدون هدف واقعی

روزهای ۱ تا ۵: فقط مخزن محلی ساختگی، community files و سه Candidate بسازید. روزهای ۶ تا ۱۰: reproduction matrix و docs test را با fixture synthetic اجرا کنید. روزهای ۱۱ تا ۱۵: translation/RTL و accessibility review محدود انجام دهید. روزهای ۱۶ تا ۲۰: Issue/Change/Review را محلی شبیه‌سازی کنید. روزهای ۲۱ تا ۲۵: privacy/security/rights/AI preflight و artifact verification را اجرا کنید. روزهای ۲۶ تا ۳۰: decline، revision، accepted، stale و correction را مدل کنید و Contribution Record نهایی را مستقل بازبینی کنید.

سؤالات متداول

آیا واقعاً بدون بلدبودن Git می‌توان مشارکت کرد؟

گاهی بله؛ بعضی پروژه‌ها فرم Issue، edit-in-browser، translation platform، forum یا CMS دارند. اما پروژه موظف نیست workflow جدا بسازد و بعضی taskهای غیرکدی همچنان Git، Markdown، build یا lint می‌خواهند. policy همان پروژه تعیین‌کننده است.

برای اولین مشارکت، typo fix بهتر است یا Bug Report؟

هیچ پاسخ عمومی ندارد. نیاز جاری، policy، duplicate، scope، evidence و توان نگهداری را بسنجید. typo ناخواسته یا generated file می‌تواند نامناسب باشد؛ Bug Report مبهم هم burden می‌سازد. کوچک‌ترین Candidate معتبر را انتخاب کنید.

اگر maintainer پاسخ نداد چه کنم؟

بازه و روش follow-up پروژه را رعایت کنید، وضعیت، duplicate و linked change را دوباره ببینید و یک یادآوری کوتاه در همان کانال بدهید. پس از آن می‌توانید Hold یا Drop کنید. سکوت approval نیست و پیام خصوصی یا ping انبوه توجیه نمی‌شود.

آیا می‌توانم contribution را در رزومه یا پورتفولیو بگذارم؟

فقط پس از بررسی permission، license یا terms، محرمانگی، داده، contribution فردی و نحوه بازنمایی. به outcome دقیق پیوند دهید و ادعای بزرگ‌تر نسازید. اگر authority نامعلوم است، نمونه موجود را Hold کنید و یک artifact کاملاً ساختگی مستقل بسازید.

آیا گزارش باگ امنیتی هم مشارکت بدون کدنویسی است؟

ممکن است گزارش‌نویسی کد نخواهد، اما activity و disclosure پرریسک‌اند. authorization و SECURITY یا private channel را پیش از اقدام بررسی کنید؛ exploit، scan یا داده را عمومی نکنید. «کمک به پروژه» مجوز تست امنیتی ایجاد نمی‌کند.

جمع‌بندی: مشارکت مفید از احترام به مرز پروژه شروع می‌شود

مشارکت غیرکدی موفق نه با تعداد Issue و PR، بلکه با تناسب نیاز، رعایت policy و permission، evidence قابل بررسی، artifact امن، ارتباط محترمانه و چرخه اصلاح سنجیده می‌شود. ابتدا Project Snapshot و Candidate بسازید؛ سپس کوچک‌ترین مسیر مجاز را verify و submit کنید؛ outcome را بدون اغراق ثبت کنید و برای maintenance، correction یا withdrawal آماده بمانید.