راهنمای نگهداری از بازل,راهنمای نگهداری از بازل

این یک راهنمای برای نگهبانان پروژه منبع باز Bazel است.

اگر به دنبال مشارکت در بازل هستید، لطفاً به جای آن مشارکت در بازل را بخوانید.

اهداف این صفحه عبارتند از:

  1. به عنوان منبع حقیقت نگهبانان برای فرآیند مشارکت پروژه خدمت کنید.
  2. انتظارات را بین مشارکت کنندگان جامعه و نگهبانان پروژه تنظیم کنید.

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

  • فرآیند انتشار: فرآیند انتشار Bazel را مدیریت کنید.
  • تیم سبز : یک اکوسیستم سالم از قوانین و ابزارها را رشد دهید.
  • باغبانان تجربه توسعه‌دهنده : مشارکت‌های خارجی را تشویق کنید، مسائل را بررسی کنید و درخواست‌ها را جلب کنید و گردش کار توسعه ما را بازتر کنید.

منتشر شده

یکپارچه سازی مداوم

راهنمای تیم سبز برای زیرساخت CI Bazel را در مخزن bazelbuild/continuous-integration بخوانید .

چرخه حیات یک مسئله

  1. یک کاربر با استفاده از الگوی Issue یک مشکل ایجاد می کند و وارد مجموعه مسائل باز بررسی نشده می شود.
  2. یکی از اعضای چرخش تیم فرعی Developer Experience (DevEx) این مشکل را بررسی می کند.
    1. اگر مشکل یک اشکال یا یک درخواست ویژگی نباشد، عضو DevEx معمولاً مشکل را می بندد و کاربر را به StackOverflow هدایت می کند و برای مشاهده بیشتر سؤال، bazel -discuss را انجام می دهد.
    2. اگر مشکل در یکی از مخازن قوانین متعلق به انجمن باشد، مانند rules_apple ، عضو DevEx این مشکل را به مخزن صحیح منتقل می‌کند.
    3. اگر مشکل مبهم باشد یا اطلاعات گم شده باشد، عضو DevEx آن را به کاربر محول می‌کند تا قبل از ادامه، اطلاعات بیشتری را درخواست کند. این معمولا زمانی اتفاق می‌افتد که کاربر از الگوی مشکل پیروی نمی‌کند.
  3. پس از بررسی مشکل، عضو DevEx تصمیم می گیرد که آیا مشکل نیاز به توجه فوری دارد یا خیر. اگر این کار را کرد، آنها برچسب اولویت P0 و یک مالک را از لیست رهبران تیم اختصاص می دهند.
  4. عضو untriaged برچسب بدون تریاژ و دقیقاً یک برچسب تیم را برای مسیریابی اختصاص می دهد.
  5. عضو DevEx نیز دقیقاً یک type: برچسب، مانند type: bug یا type: feature request ، با توجه به نوع مشکل.
  6. برای مسائل مربوط به پلتفرم، عضو DevEx یک platform: برچسب، مانند platform:apple برای مسائل خاص Mac. در این مرحله، موضوع وارد مخزن مسائل باز نشده می شود .

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

وقتی مشکلی حل شد، می توان آن را بسته کرد.

چرخه حیات یک درخواست کشش

  1. یک کاربر یک درخواست کشش ایجاد می کند.
  2. اگر عضو یک تیم بازل هستید و یک PR را علیه منطقه خود ارسال می کنید، مسئول اختصاص برچسب تیم خود و یافتن بهترین بازبین هستید.
  3. در غیر این صورت، در طول تریاژ روزانه، یکی از اعضای DevEx یک برچسب تیم و سرنخ فنی تیم (TL) را برای مسیریابی اختصاص می دهد.
    1. TL ممکن است به صورت اختیاری شخص دیگری را برای بررسی PR تعیین کند.
  4. بازبین تعیین شده روابط عمومی را بررسی می کند و تا زمانی که تایید یا حذف شود با نویسنده کار می کند.
  5. در صورت تایید، بازبین تعهد(های) روابط عمومی را برای آزمایش‌های بیشتر به سیستم کنترل نسخه داخلی Google وارد می‌کند. از آنجایی که Bazel همان سیستم ساختی است که به صورت داخلی در Google استفاده می شود، باید همه تعهدات روابط عمومی را در برابر مجموعه تست داخلی آزمایش کنیم. این دلیلی است که ما PR را مستقیماً ادغام نمی کنیم.
  6. اگر commit وارد شده تمام تست های داخلی را پشت سر بگذارد، commit له شده و به GitHub صادر می شود.
  7. هنگامی که commit در Master ادغام می شود، GitHub به طور خودکار PR را می بندد.

تیم من صاحب یک برچسب است. باید چکار کنم؟

تیم‌های فرعی باید همه مسائل موجود در برچسب‌های خود را ترجیحاً به صورت هفتگی تریاژ کنند.

مسائل

  1. لیست مشکلات را بر اساس برچسب تیم خود و برچسب untriaged کنید.
  2. موضوع را مرور کنید.
  3. یک سطح اولویت را شناسایی کنید و برچسب را اختصاص دهید.
    1. اگر P0 باشد، ممکن است این مشکل قبلاً توسط تیم فرعی DevEx اولویت بندی شده باشد. در صورت نیاز دوباره اولویت بندی کنید.
    2. هر موضوع باید دقیقاً یک برچسب اولویت داشته باشد. اگر مشکلی P0 یا P1 باشد، فرض می کنیم که به طور فعال روی آن کار شده است.
  4. برچسب untriaged را بردارید.

توجه داشته باشید که برای اینکه بتوانید برچسب ها را اضافه یا حذف کنید باید در سازمان bazelbuild باشید.

درخواست های کششی

  1. لیست درخواست های کشش را بر اساس برچسب تیم خود فیلتر کنید.
  2. درخواست‌های کشش باز را بررسی کنید.
    1. اختیاری : اگر برای بازبینی منصوب شده‌اید اما مناسب آن نیستید، بازبینی‌کننده مناسب را مجدداً برای بررسی کد تعیین کنید.
  3. برای تکمیل بررسی کد، با ایجاد کننده درخواست کشش کار کنید.
  4. PR را تصویب کنید.
  5. اطمینان حاصل کنید که همه آزمون ها قبول می شوند.
  6. پچ را به سیستم کنترل نسخه داخلی وارد کنید و پیش ارسال های داخلی را اجرا کنید.
  7. پچ داخلی را ارسال کنید. اگر پچ با موفقیت ارسال و صادر شود، PR به طور خودکار توسط GitHub بسته می شود.

اولویت

تعاریف زیر برای اولویت توسط نگهبانان برای تریاژ مسائل استفاده خواهد شد.

  • P0 - عملکرد خراب عمده که باعث می شود یک نسخه Bazel (منهای کاندیدهای انتشار) غیرقابل استفاده باشد، یا یک سرویس از کار افتاده که به شدت بر توسعه پروژه Bazel تأثیر می گذارد. این شامل رگرسیون های معرفی شده در نسخه جدید می شود که تعداد قابل توجهی از کاربران را مسدود می کند، یا تغییر شکست ناسازگاری که با خط مشی Breaking Change مطابقت ندارد. هیچ راه حل عملی وجود ندارد.
  • P1 - نقص یا ویژگی مهمی که باید در نسخه بعدی برطرف شود، یا یک مشکل جدی که بر بسیاری از کاربران تأثیر می گذارد (از جمله توسعه پروژه Bazel)، اما یک راه حل عملی وجود دارد. به طور معمول نیازی به اقدام فوری ندارد. تقاضای بالایی دارد و در نقشه راه سه ماهه جاری برنامه ریزی شده است.
  • P2 - نقص یا ویژگی که باید برطرف شود اما در حال حاضر روی آن کار نمی کنیم. رفع مشکل زنده در نسخه منتشر شده Bazel که برای کاربری که باید در نسخه بعدی به آن رسیدگی شود ناخوشایند است و/یا راه حل آسانی وجود دارد.
  • P3 - رفع اشکال جزئی یا ارتقاء مطلوب با تأثیر کوچک. در نقشه های راه Bazel یا هر نسخه قریب الوقوع اولویت بندی نشده است، با این حال مشارکت های جامعه تشویق می شود.
  • P4 - نقص با اولویت پایین یا درخواست ویژگی که بعید است بسته شود. همچنین در صورت تحت تاثیر قرار گرفتن کاربران بیشتر، می توان برای اولویت بندی مجدد احتمالی باز نگه داشت.
  • جعبه یخ
    • مسائلی که در حال حاضر نه زمانی برای پرداختن به آنها داریم و نه زمانی برای پذیرش مشارکت. ما این موضوعات را می بندیم تا نشان دهیم که هیچ کس روی آنها کار نمی کند، اما در طول زمان به نظارت بر اعتبار آنها ادامه می دهیم و اگر افراد به اندازه کافی تحت تأثیر قرار گرفتند و اگر منابعی برای مقابله با آنها داشته باشیم، آنها را احیا خواهیم کرد. مثل همیشه، در نظر داشته باشید یا واکنش هایی را به این موضوعات اضافه کنید، حتی در صورت بسته بودن.

برچسب های تیم

برای مسائل جدید، ما این category: * برچسب ها به نفع برچسب های تیم.

لیست کامل برچسب ها را اینجا ببینید .

،

این یک راهنمای برای نگهبانان پروژه منبع باز Bazel است.

اگر به دنبال مشارکت در بازل هستید، لطفاً به جای آن مشارکت در بازل را بخوانید.

اهداف این صفحه عبارتند از:

  1. به عنوان منبع حقیقت نگهبانان برای فرآیند مشارکت پروژه خدمت کنید.
  2. انتظارات را بین مشارکت کنندگان جامعه و نگهبانان پروژه تنظیم کنید.

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

  • فرآیند انتشار: فرآیند انتشار Bazel را مدیریت کنید.
  • تیم سبز : یک اکوسیستم سالم از قوانین و ابزارها را رشد دهید.
  • باغبانان تجربه توسعه‌دهنده : مشارکت‌های خارجی را تشویق کنید، مسائل را بررسی کنید و درخواست‌ها را جلب کنید و گردش کار توسعه ما را بازتر کنید.

منتشر شده

یکپارچه سازی مداوم

راهنمای تیم سبز برای زیرساخت CI Bazel را در مخزن bazelbuild/continuous-integration بخوانید .

چرخه حیات یک مسئله

  1. یک کاربر با استفاده از الگوی Issue یک مشکل ایجاد می کند و وارد مجموعه مسائل باز بررسی نشده می شود.
  2. یکی از اعضای چرخش تیم فرعی Developer Experience (DevEx) این مشکل را بررسی می کند.
    1. اگر مشکل یک اشکال یا یک درخواست ویژگی نباشد، عضو DevEx معمولاً مشکل را می بندد و کاربر را به StackOverflow هدایت می کند و برای مشاهده بیشتر سؤال، bazel -discuss را انجام می دهد.
    2. اگر مشکل در یکی از مخازن قوانین متعلق به انجمن باشد، مانند rules_apple ، عضو DevEx این مشکل را به مخزن صحیح منتقل می‌کند.
    3. اگر مشکل مبهم باشد یا اطلاعات گم شده باشد، عضو DevEx آن را به کاربر محول می‌کند تا قبل از ادامه، اطلاعات بیشتری را درخواست کند. این معمولا زمانی اتفاق می‌افتد که کاربر از الگوی مشکل پیروی نمی‌کند.
  3. پس از بررسی مشکل، عضو DevEx تصمیم می گیرد که آیا مشکل نیاز به توجه فوری دارد یا خیر. اگر این کار را کرد، آنها برچسب اولویت P0 و یک مالک را از لیست رهبران تیم اختصاص می دهند.
  4. عضو untriaged برچسب بدون تریاژ و دقیقاً یک برچسب تیم را برای مسیریابی اختصاص می دهد.
  5. عضو DevEx نیز دقیقاً یک type: برچسب، مانند type: bug یا type: feature request ، با توجه به نوع مشکل.
  6. برای مسائل مربوط به پلتفرم، عضو DevEx یک platform: برچسب، مانند platform:apple برای مسائل خاص Mac. در این مرحله، موضوع وارد مخزن مسائل باز نشده می شود .

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

وقتی مشکلی حل شد، می توان آن را بسته کرد.

چرخه حیات یک درخواست کشش

  1. یک کاربر یک درخواست کشش ایجاد می کند.
  2. اگر عضو یک تیم بازل هستید و یک PR را علیه منطقه خود ارسال می کنید، مسئول اختصاص برچسب تیم خود و یافتن بهترین بازبین هستید.
  3. در غیر این صورت، در طول تریاژ روزانه، یکی از اعضای DevEx یک برچسب تیم و سرنخ فنی تیم (TL) را برای مسیریابی اختصاص می دهد.
    1. TL ممکن است به صورت اختیاری شخص دیگری را برای بررسی PR تعیین کند.
  4. بازبین تعیین شده روابط عمومی را بررسی می کند و تا زمانی که تایید یا حذف شود با نویسنده کار می کند.
  5. در صورت تایید، بازبین تعهد(های) روابط عمومی را برای آزمایش‌های بیشتر به سیستم کنترل نسخه داخلی Google وارد می‌کند. از آنجایی که Bazel همان سیستم ساختی است که به صورت داخلی در Google استفاده می شود، باید همه تعهدات روابط عمومی را در برابر مجموعه تست داخلی آزمایش کنیم. این دلیلی است که ما PR را مستقیماً ادغام نمی کنیم.
  6. اگر commit وارد شده تمام تست های داخلی را پشت سر بگذارد، commit له شده و به GitHub صادر می شود.
  7. هنگامی که commit در Master ادغام می شود، GitHub به طور خودکار PR را می بندد.

تیم من صاحب یک برچسب است. باید چکار کنم؟

تیم‌های فرعی باید همه مسائل موجود در برچسب‌های خود را ترجیحاً به صورت هفتگی تریاژ کنند.

مسائل

  1. لیست مشکلات را بر اساس برچسب تیم خود و برچسب untriaged کنید.
  2. موضوع را مرور کنید.
  3. یک سطح اولویت را شناسایی کنید و برچسب را اختصاص دهید.
    1. اگر P0 باشد، ممکن است این مشکل قبلاً توسط تیم فرعی DevEx اولویت بندی شده باشد. در صورت نیاز دوباره اولویت بندی کنید.
    2. هر موضوع باید دقیقاً یک برچسب اولویت داشته باشد. اگر مشکلی P0 یا P1 باشد، فرض می کنیم که به طور فعال روی آن کار شده است.
  4. برچسب untriaged را بردارید.

توجه داشته باشید که برای اینکه بتوانید برچسب ها را اضافه یا حذف کنید باید در سازمان bazelbuild باشید.

درخواست های کششی

  1. لیست درخواست های کشش را بر اساس برچسب تیم خود فیلتر کنید.
  2. درخواست‌های کشش باز را بررسی کنید.
    1. اختیاری : اگر برای بازبینی منصوب شده‌اید اما مناسب آن نیستید، بازبینی‌کننده مناسب را مجدداً برای بررسی کد تعیین کنید.
  3. برای تکمیل بررسی کد، با ایجاد کننده درخواست کشش کار کنید.
  4. PR را تصویب کنید.
  5. اطمینان حاصل کنید که همه آزمون ها قبول می شوند.
  6. پچ را به سیستم کنترل نسخه داخلی وارد کنید و پیش ارسال های داخلی را اجرا کنید.
  7. پچ داخلی را ارسال کنید. اگر پچ با موفقیت ارسال و صادر شود، PR به طور خودکار توسط GitHub بسته می شود.

اولویت

تعاریف زیر برای اولویت توسط نگهبانان برای تریاژ مسائل استفاده خواهد شد.

  • P0 - عملکرد خراب عمده که باعث می شود یک نسخه Bazel (منهای کاندیدهای انتشار) غیرقابل استفاده باشد، یا یک سرویس از کار افتاده که به شدت بر توسعه پروژه Bazel تأثیر می گذارد. این شامل رگرسیون های معرفی شده در نسخه جدید می شود که تعداد قابل توجهی از کاربران را مسدود می کند، یا تغییر شکست ناسازگاری که با خط مشی Breaking Change مطابقت ندارد. هیچ راه حل عملی وجود ندارد.
  • P1 - نقص یا ویژگی مهمی که باید در نسخه بعدی برطرف شود، یا یک مشکل جدی که بر بسیاری از کاربران تأثیر می گذارد (از جمله توسعه پروژه Bazel)، اما یک راه حل عملی وجود دارد. به طور معمول نیازی به اقدام فوری ندارد. تقاضای بالایی دارد و در نقشه راه سه ماهه جاری برنامه ریزی شده است.
  • P2 - نقص یا ویژگی که باید برطرف شود اما در حال حاضر روی آن کار نمی کنیم. رفع مشکل زنده در نسخه منتشر شده Bazel که برای کاربری که باید در نسخه بعدی به آن رسیدگی شود ناخوشایند است و/یا راه حل آسانی وجود دارد.
  • P3 - رفع اشکال جزئی یا ارتقاء مطلوب با تأثیر کوچک. در نقشه های راه Bazel یا هر نسخه قریب الوقوع اولویت بندی نشده است، با این حال مشارکت های جامعه تشویق می شود.
  • P4 - نقص با اولویت پایین یا درخواست ویژگی که بعید است بسته شود. همچنین در صورت تحت تاثیر قرار گرفتن کاربران بیشتر، می توان برای اولویت بندی مجدد احتمالی باز نگه داشت.
  • جعبه یخ
    • مسائلی که در حال حاضر نه زمانی برای پرداختن به آنها داریم و نه زمانی برای پذیرش مشارکت. ما این موضوعات را می بندیم تا نشان دهیم که هیچ کس روی آنها کار نمی کند، اما در طول زمان به نظارت بر اعتبار آنها ادامه می دهیم و اگر افراد به اندازه کافی تحت تأثیر قرار گرفتند و اگر منابعی برای مقابله با آنها داشته باشیم، آنها را احیا خواهیم کرد. مثل همیشه، در نظر داشته باشید یا واکنش هایی را به این موضوعات اضافه کنید، حتی در صورت بسته بودن.

برچسب های تیم

برای مسائل جدید، ما این category: * برچسب ها به نفع برچسب های تیم.

لیست کامل برچسب ها را اینجا ببینید .