RFC و ADR چه فرقی دارند؟ کجا کدام؟

ADR، دفترِ ثبتِ تصمیمهایِ «گرفتهشده» است: کوتاه، بیبحث، آرشیوی (درس ۵۹). RFC، فرایندِ «گرفتنِ» تصمیم است: بلند، بحثخور، اجتماعی. مسیرِ رایج: RFC بحث و جمع میشود → نتیجهاش به شکلِ ADR ثبت میشود. در شرکتِ کوچک، RFC ممکن است همان یکصفحهی design doc باشد؛ در بزرگ، سندِ چندصفحهای با reviewers رسمی. تو همیشه با همان چارچوبِ پنجبندی شروع کن و اندازه را با فرهنگِ جایگذاشتنت تنظیم کن.

اولین RFCام را دربارهٔ چه بنویسم؟

بهترین اولین RFC، کوچک و واقعی است: چیزی که خودت میخواهی در سه ماه آینده بسازی. قالبِ پیشنهادی برای شروع: «ارتقای X از نسخهٔ Y به Z» یا «افزودنِ ابزارِ L به پایپلاین» — زمینهاش دادهپذیر است و بدیلهایش مشخص. از معماریِ کلانِ سیستم شروع نکن: سندِ بزرگِ اول، هم اعتبارت را در گروی تجربه میگذارد هم بازخوردش سخت میشود. RFC موفقِ اول = سندِ هفتصفحهایِ «کوچکِ تمامشده»، نه چهلصفحهایِ «بزرگِ نیمهتمام».

درس ۷۷ از ۹۰ · RFC و پروپوزال فنی؛ متنی که تصمیمِ بزرگ را می‌سازد

در شرکت‌های فنیِ بزرگ، تصمیم‌های معماری در «سند» گرفته می‌شوند نه در جلسه: کسی یک RFC می‌نویسد (Request for Comments — درخواستِ نظر), تیم چند روز کامنت می‌گذارد، و تصمیم با سابقه‌ی مکتوب متولد می‌شود. برای تو، دو دلیلِ یادگیری: اول، نوشتنِ RFC، پلهٔ رهبریِ فنی است — سندِ تو، صدای تو را در اتاق‌هایی می‌برد که درشان نیستی. دوم، خواندنِ RFCهای دیگران، نصفِ درکِ فرهنگِ فنیِ هر شرکت است.

این درس، RFC را با همان چارچوبِ گفتاریِ درس ۶۸ (مخالفتِ فنی) پیوند می‌زند — با این تفاوت که این‌جا همه‌چیز نوشتاری، سرد و داوری‌پذیر است.

ساختارِ پنج‌بندی؛ استخوانِ هر RFC

۱) Summary — یک پاراگراف: "This RFC proposes moving session storage from Redis to DynamoDB, to remove the single-region limit before the EU launch." (این RFC انتقالِ session از Redis به DynamoDB را پیشنهاد می‌دهد تا محدودیتِ تک-ریجن قبل از عرضهٔ اروپا رفع شود.) ۲) Context — چه مسئله‌ای، چرا الان: داده بیاور: "EU users see +180ms; churn in that cohort is up 2%." ۳) Proposal — چی می‌سازیم: بلوک‌به‌بلوک، با شکل. ۴) Alternatives considered — بدیل‌ها و چرا نه: مهم‌ترین بندِ سند (از نظرِ خواننده‌های سنیور!). ۵) Consequences and risks — پیامدها و ریسک‌ها: چه چیزی ساده‌تر و چه چیزی سخت‌تر می‌شود؛ migration و rollback کجاست. و بندِ صفرِ فرهنگی: Status: Draft و author + reviewers + deadline for comments بالای سند.

## Alternatives considered 1. **Redis Global Datastore** — rejected: still a single write region; failover is manual. 2. **Client-side tokens** — rejected: logout-everywhere and revocation become a distributed-systems problem. 3. **Do nothing until EU revenue justifies it** — rejected: the latency is measurable today.بدیل‌های بررسی‌شده — هر کدام با یک خطِ «ردشده» و دلیلِ یک‌جمله‌ای. همین بند، نیمی از کامنت‌های تکراری را قبل از نوشتن‌شدن می‌کُشد.

لحن؛ مستند، فروتن، بیِ «منِ پیروز»

سه قاعدهٔ لحن: ۱) معیار، نه سلیقه: به‌جای "Redis is bad at this" — "Redis single-region writes cap our failover time at ~90s (see load test, appendix A)." ۲) پیروزی را به بدیل هم بده: "Option 1 would be reasonable if our EU traffic stays under 10% — it doesn't (34% and growing)." ۳) نقاطِ نفوذ را اعلام کن: "The strongest objection I anticipate is team X's on-call load; mitigation is in §6." — پیش‌بینیِ مخالفت و پاسخِ مقدماتی‌اش، تو را از دوجنگِ کامنت‌ها نجات می‌دهد. و یک قاعدهٔ طلاییِ متنِ تصمیم: جملهٔ پرسش‌دار در RFC ممنوع — یا می‌دانی و می‌نویسی، یا در بخشِ open questions با پاسخ‌گِ نامزد می‌آورد.

چرخهٔ بازخورد؛ از Draft تا Decision

آیینِ انتشار: پیش‌نمایشِ خصوصی به دو-سه نفرِ کلیدی ("Early feedback welcome — is the framing right?"), بعد انتشارِ عمومی با ضرب‌الاجل: "Comments open until Friday EOD; after that we decide." پاسخ به کامنت‌ها — هنرِ ظریفِ RFC: هر کامنتِ معقول را با نام‌برکردن جواب بده ("Good point — added a mitigation paragraph in §4.2") و مخالفتهای بنیادین را نه با جوابِ تک‌خطی، که با دعوت به گفتگو: "This deserves more than a comment reply — 30 minutes this week?" بندِ پایانیِ تصمیم: "Decision: proceeding with the proposal, with the amendments from the review. Owner: platform team. Revisit: after EU launch metrics, ~3 months." — سندی که این بند را دارد، بسته شده؛ بقیه، پیش‌نویسِ جاودان‌اند.

گرامرِ عمیق‌تر: زبانِ بی‌طرفِ سند و بخش‌های استاندارد

سندِ تصمیم، زبانِ «سوم‌شخصِ بی‌هیجان» دارد: This document proposes… (نهِ «I think we should…»), The system currently… , We considered three alternatives; Option B was rejected because… — فاعلِ «ما/سیستم»، نهِ «من». و ساختارِ سرفصل‌های استاندارد: Summary / Background / Proposal / Alternatives Considered / Consequences / Open Questions — شش‌تایی که خوانندهٔ سنیور، دنبالشان می‌گردد. برای ریسک‌ها: "The main risk is X; mitigation is Y." (ریسکِ اصلی Xئه؛ جبرانش Y.) — ریسکِ بی‌جبران، در سند، یعنی ناتمامی.

## Alternatives Considered 1. **Keep the current queue** — rejected: the p99 doubles every quarter as traffic grows. 2. **Move all events to the streaming platform** — rejected for now: requires a team we don't have until Q3. 3. **Shard the current queue** — chosen: keeps the ops surface familiar while fixing the hot partition.بدیل‌های بررسی‌شده — ۱) نگه‌داشتنِ صفِ فعلی: رد؛ چون p99 هر فصل با رشدِ ترافیک دوبرابر می‌شه. ۲) انتقالِ همه به پلتفرمِ استریم: فعلاً رد؛ تیمی که نداریم تا Q3 رو می‌خواد. ۳) شاردکردنِ صفِ فعلی: انتخاب؛ سطحِ عملیاتی آشنا می‌مونه و پارتیشنِ داغ حل می‌شه.

گفتگو: بازخورد روی RFC و پاسخِ نام‌بر

Reviewer: The consequences section undersells the ops load — sharding isn't free. — Author (you): Fair — adding a paragraph: on-call gets a new runbook and two new dashboards, called out in §5.2.ریلویوئر: بخشِ پیامدها بارِ اپس رو کم‌فروش می‌کنه — شاردکردن مجانی نیست. — نویسنده (تو): درسته — یه پاراگراف اضافه می‌کنم: آن‌کال ران‌بوکِ جدید و دو داشبوردِ جدید می‌گیره، در §5.2 مشخص.

Reviewer: And I'd question the Q3 assumption for option 2 — hiring might slip. — You: Good challenge — softening that line to "pending hiring" instead of a hard Q3. More honest.ریلویوئر: و فرضِ Q3 گزینهٔ ۲ رو زیر سوال می‌برم — استخدام ممکنه بخوره عقب. — تو: چالشِ خوبیه — اون خط رو به «در انتظارِ استخدام» نرم می‌کنم به‌جای Q3ِ قطعی. صادقانه‌تر.

Reviewer: With those two changes, I'm a clear yes. — You: Perfect — updating now, and tagging you in the diff. Decision deadline stands: Friday EOD.ریلویوئر: با همین دو تغییر، جوابم کاملاً بله‌ست. — تو: عالیه — آپدیت می‌کنم و تو دیف تگت می‌کنم. ضرب‌الاجلِ تصمیم سرِ جاشه: جمعه آخرِ روز.

اشتباه‌های رایجِ فارسی‌زبان‌ها در همین درس

این بخش را با یک قرارداد بخوان: هر ❌ یعنی «مغزِ فارسی‌زبانت این را می‌سازد و طبیعی است»، و هر ✅ یعنی «این همان چیزی است که گیرندهٔ انگلیسی‌زبان می‌شنود». خطاها اثرِ مستقیمِ ترجمهٔ ذهنیِ فارسی به انگلیسی‌اند؛ با هر جفت بلند تکرار کن تا شکلِ درست در گوشت نشست کند.

❌ I think we should choose Option B because I believe it is better.❌ «به نظرم / باور دارم» را مثل ادبِ گفتاری همه‌جا می‌چسبانیم؛ اما سندِ تصمیم با زبانِ سوم‌شخصِ بی‌هیجان نوشته می‌شود: فاعل، تصمیم و سیستم است و دلیل، عدد — نه سلیقه.

✅ Option B was chosen because it halves p99 without adding new infrastructure.✅ شکل درست را دو بار بلند بگو؛ حالا یک بار در یک جملهٔ خودت.

❌ This document wants to change the queue system.❌ «این سند در صدد است…» ترجمهٔ صافِ نثرِ اداریِ فارسی است و wants در سندِ انگلیسی بچه‌گونه صدا می‌دهد. فعلِ رسمیِ سند propose است: This document proposes…

✅ This document proposes sharding the current queue.✅ شکل درست را دو بار بلند بگو؛ حالا یک بار در یک جملهٔ خودت.

❌ The system currently has problem with the hot partition.❌ فارسی حرفِ تعریف ندارد؛ انگلیسی اما اسمِ مفردِ شمارش‌پذیر را بی‌ a یا the رها نمی‌کند. همین حرفِ کوچک، مرزِ «متنِ ترجمه‌شده» و «متنِ سنیور» را مشخص می‌کند.

✅ The system currently has a problem with the hot partition.✅ شکل درست را دو بار بلند بگو؛ حالا یک بار در یک جملهٔ خودت.

تمرین‌های این درس — چهار قدم، بی‌عجله

سندنویسی ورزشِ حذف است: حذفِ «من»، حذفِ هیجان، حذفِ ابهام؛ هر پاسخ را اول بلند بگو، بعد باز کن.

این جملهٔ احساسی را به زبانِ بی‌طرفِ سند تبدیل کن: «I really feel the current queue is very slow and it worries me.»
شش سرفصلِ استانداردِ یک RFC را به ترتیب نام ببر.
ریسک را با قالبِ درس بنویس: ریسک = بارِ اضافهٔ آن‌کال (دو داشبوردِ جدید و یک ران‌بوک)؛ جبران = یک آموزشِ یک‌ساعته و دو هفته هم‌راهیِ ناظر.
این جملهٔ ردِ تند را به سبکِ RFC بازنویسی کن: «Option A? No way, nobody wants that.»

پاسخ تمرین‌ها — اول خودت جواب بده، بعد باز کن

پاسخ تمرین ۱

نمونه: "The current queue's p99 doubles every quarter as traffic grows." — احساس حذف شد و جایش عدد نشست؛ سند با داده متقاعد می‌کند، نه با نگرانی.

پاسخ تمرین ۲

Summary → Background → Proposal → Alternatives Considered → Consequences → Open Questions — شش‌تایی که خوانندهٔ سنیور دنبالش می‌گردد؛ نویسندهٔ سنیور هم پیش از سطرِ اول، همین شش را خالی می‌کند.

پاسخ تمرین ۳

نمونه: "The main risk is added on-call load: two new dashboards and a new runbook; the mitigation is a one-hour training and a two-week shadow rotation." — جفتِ «ریسک؛ جبران» همان چیزی است که بازبین می‌خواهد؛ ریسکِ بی‌جبران در سند یعنی ناتمامی.

پاسخ تمرین ۴

نمونه: "Option A was rejected: keeping the current queue doubles p99 every quarter as traffic grows." — فعلِ موردیِ was rejected + دلیلِ عددی؛ ردِ بی‌دلیل در سند فقط یک «نظر» است، نه تصمیم.

چالشِ امروز

🎯 یک تصمیمِ واقعیِ این هفته‌ات را در قالبِ شش سرفصلِ RFC بنویس — حتی با پاراگراف‌های تک‌جمله‌ای؛ قالب را یک بار با دستِ خودت بسازی، برای همیشه مالِ تو می‌شود.

نکات مکالمهٔ واقعی که کتاب‌ها کم می‌گویند

بدیل‌ها را با دلیلِ رد بنویس — «rejected because…» — بخشِ بدیل‌ها، جایی است که سندِ تو «تولی» را جواب می‌دهد؛ نصفِ اعتبارِ RFC همین‌جاست.
پاسخِ کامنت با شمارهٔ بخش — «added in §5.2» — پاسخِ نام‌بر و محل‌دار، بازخورد را از گفتگو به ساختار می‌برد.
ضرب‌الاجلِ تصمیم در خودِ سند — «Decision deadline: Friday EOD» — سندِ بی‌ضرب‌الاجل، پیش‌نویسِ جاودان است.

🔑 جمع‌بندی این درس

RFC = Summary یک‌پاراگرافی + Context با داده + Proposal بلوک‌به‌بلوک + Alternatives با «ردشده: دلیل» + Consequences و rollback. لحن: معیار نه سلیقه، حقِ بدیل، پیش‌پاسخِ مخالفتِ پیش‌بینی‌شده. چرخه: پیش‌نمایشِ خصوصی → انتشار با ضرب‌الاجل → پاسخِ نام‌برده به کامنت‌ها → بندِ Decision. متنِ خوب، جلسه را به داوریِ سرد تبدیل می‌کند — و برنده‌اش، تیم است.

RFC و پروپوزال فنی؛ متنی که تصمیمِ بزرگ را می‌سازد