• Значення пріоритетів
• Значення оцінки
• Правила репозиторію
• Правила гілок
• Коміти
• Правила завдань
• Правила запитів на злиття (PR)
• Правила форматування коду
• Додаткові конвенції коду

Ключові слова “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” та “OPTIONAL” у цьому документі слід трактувати так, як описано у RFC 2119.

Значення пріоритетів

• Low - низький пріоритет (невеликі точкові вдосконалення).

• Normal - звичайний пріоритет (основні функції, виправлення).

• High - високий пріоритет (важлива основна функція, виправлення).

• Blocker - інші завдання не можуть бути виконані, поки це питання не буде вирішено.

Значення оцінки

• Години - завдання може зайняти від 1 до 8 годин.

• Дні - завдання може зайняти від 1 до 7 днів.

• Тижні - завдання може зайняти від 1 до 2 тижнів.

Якщо оцінка перевищує 2 тижні, завдання ОБОВ’ЯЗКОВО слід розбити на менші частини.

Правила репозиторію

• Репозиторій ОБОВ’ЯЗКОВО повинен дозволяти або злиття комітів або злиття rebase.

• Репозиторій ОБОВ’ЯЗКОВО не повинен дозволяти злиття squash.

Правила гілок

• Назва головної гілки ОБОВ’ЯЗКОВО повинна бути main.

• Назва головної гілки main ОБОВ’ЯЗКОВО повинна бути захищена.

• Назву гілки main ОБОВ’ЯЗКОВО не можна форсувати.

• Для кожного завдання чи функції ОБОВ’ЯЗКОВО повинна створюватися нова гілка.

• Назва нової гілки ОБОВ’ЯЗКОВО повинна відповідати наступному шаблону <тип>/PR-НОМЕР/додаткова-інформація>, де <тип> взято зі стандарту Conventional Commits v1.0.0

  наприклад:

  fix/#9

  feat/#883/hatsune-miku-the-real-one

  docs/#1/me-and-waifu

Коміти

• Повідомлення коміту ОБОВ’ЯЗКОВО повинно відповідати стандарту Conventional Commits v1.0.0

• Повідомлення коміту ОБОВ’ЯЗКОВО повинно містити номер pull request (наприклад, #54) у зоні видимості.

  наприклад: fix(#53): змінити колір кнопки на червоний

• Коміт ОБОВ’ЯЗКОВО повинен бути підписаний.

Правила завдань

• Якщо завдання не перебуває в Беклогу, то воно ОБОВ’ЯЗКОВО повинно мати заголовок, опис, пріоритет, оцінку та принаймні один мітку.

• Тіло завдання НЕ ПОВИННО бути порожнім.

Правила запитів на злиття (PR)

• Заголовок PR ОБОВ’ЯЗКОВО повинен відповідати стандарту Conventional Commits v1.0.0

• Тіло PR НЕ ПОВИННО бути порожнім.

• PR ОБОВ’ЯЗКОВО повинен бути пов’язаний з проектом.

Правила форматування коду

• У репозиторії ОБОВ’ЯЗКОВО повинен бути визначений стиль форматування у проекті.

• У репозиторії ОБОВ’ЯЗКОВО повинен бути README, який описує, як локально налаштувати лінтер та форматер, використовуючи стиль, визначений у файлі (Якщо є які-небудь конкретні виклики y процесi налаштування).

Додаткові конвенції коду

Відступи: слід використовувати 4 пробіли.

Описові назви: використовуйте описові назви для функцій або класів.

Коментарі: уникайте коментарів у коді; старайтеся робити код самоексплікаційним.

Мовні конвенції: дотримуйтеся стилю мовних конвенцій.

Принцип KISS: завжди намагайтеся тримати все простим (KISS).

Принцип DRY: не повторюйте код (DRY), якщо є більше 3 повторень.

Використання бібліотек: не пишіть нову версію; шукайте, чи вона вже існує, і вивчайте, як її використовувати (нам не потрібна ще одна бібліотека JSON для JS).

Тестування: завжди приємно, коли у проекті є одиниці тестування або інші типи тестів. Таким чином, принаймні, потрібні модульні тести, і вони ОБОВ’ЯЗКОВО повинні охоплювати якнайбільше можливо.

Документація: підкресліть важливість гарної документації. У кожному репозиторії, модулі, класі та методі повинна бути чітка та стисла документація.

Версіювання: у відповідності до кращих практик ми використовуємо Семантичне Версіювання (SemVer)

Власність коду: завжди роз’яснюйте концепцію власності коду. Вкажіть, хто відповідальний за підтримку різних частин кодової бази.

Постійна інтеграція (CI) та постійна доставка (CD): Намітте практики CI/CD, включаючи автоматизоване тестування, конвеєри розгортання та стратегії версіонування. Завжди намагайтеся автоматизувати.

Доступність та інтернаціоналізація: У разі необхідності включіть вказівки щодо забезпечення доступності вашого програмного забезпечення та підтримки інтернаціоналізації (i18n) та локалізації (l10n).

Норми спільноти: Якщо ваш проект включає у себе спільноту з відкритим кодом, включіть норми для участі спільноти, звітів про проблеми та кодексу поведінки.