enumی که دقیقاً برای هیچکس جور در نمیآمد
To Do، In Progress، Test، Pending، Done — یک پیشفرض معقول، و همزمان دقیقاً فرآیند واقعیِ هیچکس هم نبود. یک تیم پر QA یک «In Review» جدا قبل از «Test» میخواهد. یک تیم پشتیبانی «Waiting on Customer» میخواهد. یک کسبوکار با فرآیند مطابقتِ خودش یک قدم «Needs Sign-off» میخواهد که هیچ ربطی به هیچکدام از آن پنج داخلی ندارد. سالها راهحل تغییرنامدادن در صفحهگسترده یا صرفاً تحمل یک ستون وضعیت که با واقعیت جور نبود بود. مجموعهی وضعیت یک enum ثابتِ Go بود، سختکدشده در فرانتاند — تغییرش یعنی تغییر محصول، نه پیکربندیش.
چهچیزی تغییر کرد: حالا وضعیتها دادهاند، نه کد
// TaskStatus is an organization-scoped, user-configurable per-assignee status.
//
// Historically the per-assignee status (user_tasks.status) was a fixed enum
// hardcoded in the frontend: TODO / IN_PROGRESS / TEST / PENDING / DONE. This
// model makes that set dynamic per organization while preserving full backward
// compatibility.
حالا هر سازمان مجموعهی TaskStatus خودش را دارد — یکی اضافه کنید، یکی حذف کنید، بازچینی کنید، رنگش را عوض کنید، بدون لمسکردن حتی یک خط کد. مسیر مهاجرت طوری طراحی شده که هیچچیز از قبل در پایگاهداده لازم نبود عوض شود: پنج وضعیت پیشفرض دقیقاً همان کلیدهایی را نگه داشتند که enum قدیمی استفاده میکرد (TODO, IN_PROGRESS, TEST, PENDING, DONE)، پس همان لحظه که سیستم جدید روشن میشود، وضعیت هر تسک موجود همچنان معتبر است.
تنها وضعیتی که نمیشود از معنیِ «انجامشده» تغییرنامش داد
// The terminal "completed" status keeps the reserved key "DONE" forever (only
// its label is editable). Every done-detection path in the backend that
// compares against 'DONE'/'done'/'completed' therefore keeps working.
میتوانید برچسبش را تغییر نام دهید — «تحویل شد»، «بسته شد»، هرچه با زبان تیمتان جور دربیاید — اما کلیدِ زیرینِ DONE محافظتشده است: نمیشود حذفش کرد، و پرچمِ IsDoneاش نمیشود غیرفعال شود. این یک محدودیت دلبخواهی نیست؛ هر بخش از منطق بکاندی که باید بداند «آیا این تسک واقعاً تمام شده» — گزارشگیری، نمودار برنداون، داشبورد تحویل — در برابر همان یک کلیدِ ثابت چک میکند. وضعیتهای سفارشیِ آزاد بدون یک وضعیت پایانیِ محافظتشده، همهی آنها را همان اولین باری که کسی «Done» را به چیزی که کدِ تشخیصِ انجامشدن نمیشناسد تغییرنام میداد، خراب میکرد.
پیشفرض ترجمهشده، نه بعداً بهفکرافتاده
Labels datatypes.JSON `json:"labels"` // {"en":"To Do","fa":"انجام نشده",...}
var SupportedLangs = []string{"en", "fa", "es", "fr", "de", "ar", "zh"}
یک وضعیت یک رشته نیست — یک نگاشتِ برچسب است، یک ورودی بهازای هر زبان UI پشتیبانیشده. اضافهکردن یک وضعیت سفارشی یعنی فراهمکردن یک ترجمه برای هرکدام از هفت زبانی که ویکیافگو با آنها میآید، که کار اولیهی بیشتری از تایپکردن یک کلمهی انگلیسی است، اما همان چیزی است که جلوی دیدن یک کلید ترجمهنشدهی خام روی نیمی از بوردهای یک تیم دوزبانه (یا هفتزبانه) را میگیرد. این همان انضباطی است که بقیهی سیستم i18n ویکیافگو اجرایش میکند.
راهاندازیش
۱. تنظیمات وضعیت سازمانتان را باز کنید. هر وضعیت یک کلید، یک موقعیت (با کشیدن بازچینی میشود)، یک رنگ، و یک برچسب بهازای هر زبان دارد.
۲. یک وضعیت برای یک شکاف واقعی در فرآیندتان اضافه کنید — آزمون این است که آیا با یک نقطهی تصمیمِ واقعی که تیمتان میگیرد جور در میآید، نه اینکه آیا رسمی بهنظر میرسد. «Needs Sign-off» جایگاهش را وقتی بهدست میآورد که واقعاً کسی باید پیش از ادامهی کار تأیید کند؛ وضعیتی که هیچکس هرگز انتخابش نمیکند شلوغی است.
۳. DONE را دست نزنید. اگر دوست دارید برچسبش را با واژگان تیمتان تطبیق دهید — کلید و پرچم «انجامشده» را همانطور که هست بگذارید.
اشتباهات رایج
ساختنِ یک وضعیت که یک وضعیت موجود را با اسمی متفاوت تکرار میکند. حضورِ همزمانِ «In Review» و «Pending Review» روی همان بورد فقط جایی که کار واقعاً هست را پراکنده میکند — یکی را انتخاب کنید.
فراموشکردن یک زبان هنگام اضافهکردن یک وضعیت سفارشی. یک برچسبِ ترجمهنشده برای کاربران آن زبان به کلید خام یا یک رشتهی خالی برمیگردد — دقیقاً همان مشکل مسیرِ نقطهای خامی که تست کاملبودنِ i18n ویکیافگو جای دیگر در اپ جلویش را میگیرد.
تلاش برای ساختنِ یک وضعیت پایانیِ دوم. فقط DONE منطق تشخیصِ انجامشدن را هدایت میکند؛ یک وضعیت سفارشی با رنگ سبز و آیکون تیک همچنان برای هیچ گزارشی که کارِ تکمیلشده را میشمارد «انجامشده» نیست — اگر یک حالتِ تکمیلِ دوم لازم دارید، احتمالاً یعنی جریان کار زیرین به چرخهی عمرِ جدای خودش نیاز دارد، نه یک پرچمِ وضعیت.
سؤالات متداول
آیا تسکهای موجود با سفارشیسازیِ وضعیتها خراب میشوند؟
نه — پنج پیشفرض کلیدهای اصلیشان را نگه میدارند، پس دادهی تاریخی و هر اتوماسیونی که در برابر TODO/IN_PROGRESS/و غیره ساخته شده بدون تغییر همچنان کار میکند.
آیا پروژههای مختلف در همان سازمان میتوانند وضعیتهای متفاوت استفاده کنند؟ وضعیتها مخصوص سازماناند، نه مخصوص پروژه — مجموعه بین همهی پروژههای یک سازمان مشترک است، تا گزارشگیریِ بینپروژهای یکنواخت بماند.
برای تسکهایی که در یک وضعیتِ حذفشده هستند چه اتفاقی میافتد؟
فقط DONE از حذفشدن محافظت شده است؛ حذف هر وضعیت دیگری اول نیاز دارد تسکهای فعلاً درونش را به وضعیتی دیگر مهاجرت دهید.