چگونه مایکروسافت از راهنماها برای هدایت توسعه منبع باز استفاده می کند

اغلب سخت ترین بخش مشارکت در یک پروژه منبع باز یادگیری از کجا شروع می شود. مایکروسافت برای آن درمان دارد.

تغییر مایکروسافت به مدل‌های توسعه باز یک مطالعه موردی جالب در نحوه مدیریت توسعه منبع باز در مقیاس است. با میلیون‌ها کاربر و هزاران مشارکت‌کننده بالقوه، نگهبانان پروژه شرکت مشکلاتی دارند که اکثر پروژه‌های منبع باز هنوز با آن مواجه نشده‌اند.

در سطح مقیاس مایکروسافت، یک نگهدارنده پروژه بیشتر شبیه یک مدیر محصول یا مدیر پروژه است تا یک مدیر توسعه. آن‌ها با مشارکت‌کنندگان داخلی و خارجی کار می‌کنند، در حالی که سعی می‌کنند تلاش‌ها را برای تحویل موارد موجود در پروژه عقب مانده و همچنین رفع اشکال‌ها و مشکلات هدایت کنند. سپس وظیفه مدیریت درخواست‌های ویژگی وجود دارد، در بسیاری از موارد کار با داوطلبان تازه وارد پروژه و محدودیت‌های ارائه برنامه‌های کاربردی سازمانی.

همکاری در مقیاس در GitHub

در حالی که ممکن است پایگاه های کد در GitHub قابل مشاهده باشند، در دسترس بودن کد منبع جایگزینی برای همکاری نیست. چگونه یک مشارکت‌کننده جدید برای ایجاد تغییرات لازم به بخش مناسب کد راه می‌یابد؟ جستجو در یک مخزن کلون شده و افزودن نقاط شکست در حین اجرای دیباگر یکی از راه های کار است، اما به شدت به آزمون و خطا وابسته است. زمان داوطلبانه کالای ارزشمندی است که نمی‌خواهید هدر دهید. از دست دادن آن نیز بسیار آسان است، زیرا توجه به پروژه های دوستانه تر معطوف می شود.

این باعث شد تیم منبع باز ویندوز آزمایش با یک فرآیند جدید در یکی از پایگاه های کد محبوب تر آن، Windows Terminal. در جایی که به کار نیاز است، نگهبانان پروژه اکنون در حال نوشتن راهنماهای کوچکی برای آنچه ضروری است، و اینکه کد جدید و تغییر یافته باید کجا باشد، می نویسند. این اسناد، راه‌اندازی نامیده می‌شوند. ، از آشنایی آنها با کد و جامعه استفاده کنید تا افراد تازه وارد را به “فضاهای مشکل” در پایگاه کد هدایت کنید که می توانند از کمک آنها استفاده کنند.

راهنمایی‌ها جایی بین داستان‌های کاربر و مستندات پروژه قرار دارند و به‌عنوان اشاره‌گر به جایی هستند که مشارکت‌کننده می‌تواند شروع به افزودن ارزش به پروژه کند، بدون اینکه نیازی به نگهداری قابل توجهی داشته باشد. از این گذشته، اکثر مشارکت کنندگان منبع باز توسعه دهندگان با تجربه ای هستند که تجربه خود را به جامعه گسترده تر اهدا می کنند و بر اساس برنامه زمانی خود و در زمان خود کار می کنند.

راهنمایی چیست؟

توضیحات توضیحات سطح بالایی از مشکل و کدی هستند که به مشارکت کنندگان زمینه لازم برای شروع کار را ارائه می دهند. آنها برای ارائه یک “نقشه ذهنی” از کد مربوطه طراحی شده اند که نشانگرهایی را به پرونده ها، روش ها و تعاریف ارائه می دهد. عناصر دیگر در یک راهنما ممکن است پیوندهایی برای کشیدن درخواست‌هایی باشند که عملکردهای مشابهی را پیاده‌سازی می‌کنند، یا با همان بخش کد کار می‌کنند، همچنین تکه‌های کد یا شبه کد.

در حالی که پیش‌بینی‌ها می‌توانند به خودی خود سند باشند و به عنوان بخشی از مستندات پروژه گنجانده شوند، در عوض می‌توانند چیزی به سادگی یک نظر در بحث یک موضوع. این نباید تعجب آور باشد: رویکرد مایکروسافت به منبع باز به شدت با مدل کدگذاری اجتماعی GitHub مرتبط است. این شرکت از ابزارهای مشابه برای اضافه کردن راهنماهای قالب‌بندی شده با استفاده از ویژگی‌های اساسی Markdown برای برجسته کردن عناصر کلیدی استفاده می‌کند که می‌تواند به توسعه‌دهندگان در پیمایش کد کمک کند. راه‌حل‌ها حتی می‌توانند شامل GIF‌های متحرک برای نشان دادن رفتارهای مورد انتظار رابط کاربری در صورت نیاز باشند.

اگرچه راهنماها رویکردی نسبتاً غیررسمی برای مدیریت پروژه هستند، ساختاری برای نحوه نگارش راهنماها وجود دارد. می‌توانید آنها را به‌عنوان مجموعه‌ای از گام‌های اولیه برای حل یک مشکل در نظر بگیرید، بسیار شبیه به مکالمه با سرنخ توسعه یا یک جلسه طوفان فکری در اطراف یک تخته سفید.

تخصیص مراحل بررسی به تابلوهای پروژه

یک جنبه جالب استفاده از راهنماها در GitHub، امکان اختصاص دادن آنها به یک پروژه است. این به شما امکان می‌دهد آنها را به تابلوهای پروژه اضافه کنید، جایی که می‌توانید متادیتا اضافه کنید به مراحل، مانند یادداشت مشکلات، اختصاص دادن مسائل به کاربران، و جزئیات درخواست‌های کشش حاصل.

آنچه که به عنوان یک روش ساده برای ارائه زمینه برای درخواست ویژگی یا رفع اشکال آغاز شد، اکنون یک ابزار اساسی مدیریت پروژه است، در حالی که هنوز سطح مناسبی از غیر رسمی را حفظ می کند. هیچ الزامی برای یک مشارکت کننده برای ردیابی پروژه نتیجه وجود ندارد. این صرفاً یک ابزار برای نگهدارنده است و به آنها امکان می‌دهد ببینند روی کدام راه‌حل‌ها کار می‌شود و به اطلاعات بیشتری برای کمک به مشارکت‌کنندگان در شروع کار نیاز دارند.

ساخت کد با گفتن داستان

راهنمایی ها نمونه جالبی از داستان سرایی پروژه هستند. مایکروسافت سابقه طولانی در استفاده از تکنیک های روایت در داخل دارد به عنوان روشی ایجاد درک مشترک از یک مشکل و راه حل های ممکن آن. این روایت‌ها در سطح بالاتری نسبت به روش‌های توسعه چابک کار می‌کنند و اغلب حالت‌های نهایی مطلوب و همچنین کاربران احتمالی این ویژگی را توصیف می‌کنند.

با در نظر گرفتن این رویکرد خارج از ساختارهای رسمی توسعه شرکتی، مایکروسافت قصد دارد هم میانبرهایی برای جایی که کد باید در پروژه برود و هم برای مشارکت کنندگان احتمالی ایجاد کند. نگاه کردن به یک مشکل در GitHub بدون درک زمینه مشکل و کد اغلب دلهره آور است. حل مشکلی پیش پا افتاده اغلب به داشتن دانش عمیق از پایه کد، دانستن اینکه با چه ماژولی کار کنید و کدام منابع را تغییر دهید بستگی دارد.

توسعه‌ها یک رویکرد کاملاً غیررسمی و آسان برای درک است که مشارکت‌کنندگان را از خود دور نمی‌کند، در عوض فقط اطلاعاتی را که برای شروع نیاز دارند بدون دست کم گرفتن ابتکار و تخصص آنها ارائه می‌کند. این یک نیاز مهم برای هر ابزاری است که توسط نگهبانان استفاده می شود، زیرا بدترین نتیجه ممکن برای هر پروژه، بیگانگی داوطلبان است.

امیدواریم پروژه‌های منبع باز بیشتری از این تکنیک استفاده کنند، چه در داخل و چه در خارج از مایکروسافت. این تکنیکی است که می تواند به نسل بعدی مشارکت کنندگان کمک کند تا از مانع ایجاد اولین درخواست کشش خود عبور کنند.