Управління

Ці працьовиті бджілки з Основної команди виконують низку обов’язків, щоб забезпечити функціонування вулика під назвою BeeWare. Цей проєкт постійно розвивається, тому інформація на цій сторінці може змінюватися.

Сюди входять, зокрема, вирішення проблем, рецензування та об’єднання коду, наставництво над новими учасниками, а також розробка архітектури проекту BeeWare в цілому.

Є люди, яким ми довіряємо у прийнятті рішень щодо коду; є люди, яким ми довіряємо у прийнятті рішень щодо коду та організаційних питань; і є людина, яка визначає стратегічний напрямок розвитку всієї організації та якій доручено приймати остаточне рішення, якщо спільнота не може дійти консенсусу.

Стаж роботи в команді

У проєкті BeeWare існують такі рівні стажу:

Бджола, або робоча бджола

Будь-який учасник спільноти BeeWare. Оскільки ми працюємо у відкритому доступі на GitHub, кожен може пропонувати зміни до коду та домогтися їхнього включення. Єдиною перешкодою для вашого внеску є необхідність, щоб вашу роботу включив член команди, який має на це відповідні права.

Бджоляр

Користувач, якого визнано надійним учасником. Ці користувачі протягом певного часу продемонстрували свої здібності у конкретній сфері проекту BeeWare. Це може стосуватися як технічних аспектів (знання JavaScript, Python, Objective-C; GTK+, macOS), так і інших сфер (управління спільнотою, рецензування коду). «Апіаристи» також можуть мати права на внесення змін до того проекту, в якому визнано їхню експертизу.

Старші бджолярі

Пасічники, які мають розширені права доступу в GitHub, а також несуть додаткову відповідальність за нагляд за проектом у цілому. Вони можуть приймати архітектурні рішення, але в кінцевому рахунку підзвітні BDFN.

«Поки що доброзичливий диктатор» (BDFN)

Згідно з концепцією «Доброзичливого диктатора на все життя», відповідальність за напрямок розвитку та рішення щодо проєкту в кінцевому рахунку лежить на BDFN. Використання слова «наразі» замість «на все життя» є відсиланням до ідеї Django, згідно з якою обов’язки головного розробника не повинні покладатися на одну людину протягом усього її природного життя. Життя існує поза межами відкритого програмного забезпечення, і дуже важливо пам’ятати про баланс між кодом та особистим життям, а також про загальне благополуччя.

BDFN компанії BeeWare — це Рассел Кіт-Мейгі.

Пасічник-засновник

Людина, яка першою стала на пагорбі й помітила яка, якому потрібно було поголити шерсть. Ця роль залишається незмінною й продовжується нескінченно; однак вона сама по собі не надає жодних додаткових повноважень в організації. Наразі засновник пасіки також є головою BDFN, але з часом це може змінитися.

Рекомендації (а не офіційні правила)

Як і в будь-якому проєкті, де права на коміти мають кілька осіб, існує низка загальних рекомендацій, яких команда повинна дотримуватися:

• Бути гідним представником проекту перед широкою громадськістю
• Ставтеся з повагою до кожного запиту та кожного внеску в будь-який проєкт BeeWare
• Вважайте, що всі мають добрі наміри, навіть якщо вони не дуже влучно підібрали слова
• Припустимо, що якщо хтось зробив щось «неправильно», то це сталося через те, що нам не вдалося чітко пояснити, як саме слід це робити
• Припустимо, що будь-який прояв гніву чи розчарування випливає зі щирого бажання використовувати інструмент чи бібліотеку BeeWare
• Заохочуйте інших учасників спільноти відображати ці ідеали у своїх повідомленнях як у межах спільноти BeeWare, так і за її межами
• Жоден розробник не повинен самостійно додавати свій код
  • Виняток: «Щось серйозно зламалося, і це потрібно негайно виправити»
  • Виняток: BDFN (це може змінитися в майбутньому)
• Весь код, поданий на перевірку членом основної команди, повинен бути перевірений іншим членом команди
  • Виняток: BDFN (це може змінитися в майбутньому)
• Весь код повинен пройти тести безперервної інтеграції перед злиттям
  • Виняток: код, про який відомо, що він містить помилки, але який необхідно внести до репозиторію з інших причин
  • Виняток: код у репозиторії з недостатньою кількістю тестів CI
  • Виняток: Краще бути працьовитим і відданим справі, ніж досконалим, але не
• Процеси прийняття рішень слід автоматизувати, де це можливо
  • Це означає тестування, перевірку коду, перевірку орфографії, аналіз покриття коду та багато іншого

Як стати бджолярем

Прийняття нового учасника-«Apiarist» до команди відбувається виключно на розсуд існуючої основної команди. Хоча на даний момент чітких правил щодо цього немає, як правило, до проекту BeeWare запрошують стати «Apiarist» тих, хто продемонстрував вагомий внесок у проект. Це також може стосуватися осіб із конкретними галузевими знаннями (наприклад, у сфері iOS/macOS), яких, можливо, бракує в існуючій команді. При цьому це не обов’язково має ґрунтуватися на кількості комітів. Будь-хто, хто здатний продемонструвати щирий інтерес до проекту в цілому, може звернутися з проханням надати йому дозвіл на внесення змін до проекту.

Усі нові пасічники пройдуть «орієнтацію» (за браком кращого слова) щодо основних цінностей та принципів проекту. Короткий опис основних цінностей можна знайти на сторінці «Про проект». Від кожного, хто приєднається до команди, очікується дотримання цих цінностей та участь у дискусіях щодо їхнього подальшого розвитку з часом.

Від жодного бджоляра — чи то початківця, чи то досвідченого — не очікується, що він буде єдиним, хто займається якоюсь однією справою. Є багато бджолярів, а також ще більше людей, які можуть запропонувати допомогу, поради та наставництво.

«Біт підтвердження»?

У системах Unix для позначення права на виконання файлу використовується один біт у файлі. У системах управління версіями існує аналогічний біт, що позначає можливість злиття коду. Коли кажуть, що хтось має «біт коміту», це означає, що він має доступ на запис до кодової бази. У термінології GitHub це означає, що ця особа має можливість об’єднувати Pull Requests та комітувати код безпосередньо в проєкт.