Як керувати проблемами github для (пріоритет тощо)? [зачинено]

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

Як інші керують проблемами протягом життєвого циклу помилки / функції?

Заздалегідь спасибі.

Можна визначити різні групи міток , такі як типи випуску , пріоритети випуску , випуск статуси , версія теги , і , можливо , більше. Для того, щоб ви змогли миттєво побачити, до якої групи належить мітка, ви можете скористатися умовою іменування типу <label-group>:<label-name>.

Використання такої угоди про іменування повинно значно полегшити управління проблемами Github та допоможе іншим "зрозуміти" проблеми набагато швидше. Зауважте, що ви також можете призначити кольори міткам, які можуть ще більше додати читабельності (я б використовував певний колір для кожної групи міток). Але оскільки вам все одно доведеться призначати / скасовувати ці ярлики в / з проблем вручну, можливо, ви хочете зберегти загальний список груп / міток невеликим.

Відповідно до запропонованої схеми, ви можете визначити групи та відповідні мітки наступним чином.

група "тип випуску"

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

група «питання пріоритету»

• пріо: низький
• пріор: нормальний
• пріо: високий

група "статус видачі"

(Ці мітки описують стан проблеми у визначеному робочому процесі.)

• статус: підтверджено
• статус: відкладено
• статус: виправлено-вчинено
• статус: незавершене
• статус: неповний
• статус: відхилено
• статус: вирішено

група "видавати інформацію"

• інформація: зворотній зв'язок потрібен
• інформація: потрібна допомога
• інформація: прогрес-25
• інформація: прогрес-50
• інформація: прогрес-75

група 'тег версії'

• ver: 1.x
• вер .: 1.1

Відстежувач випусків GitHub досить гнучкий. Дійсно, ні пріоритету, ні впорядкування немає. Він обертається навколо трьох основних стовпів: призначення , етикетки та віхи .

• Ви можете "помітити" проблеми з створеними мітками (аналогічно, ніж мітки Gmail). Наприклад: "помилка", "особливість-запит", "todo", "питання", ... Одне питання можна позначати різними мітками.

• Ви можете «упакувати» декілька випусків у віху . Етап складається із заголовка (наприклад, номер версії) та необов'язкової дати доставки.

• Кожен випуск може бути призначений співпрацівнику (учаснику чи члену організації) сховища. Ви навіть можете викликати співрозмовника в коментарі, використовуючи @наступний логін GitHub.

Зрештою, завдяки бічній панелі, ви можете «відфільтрувати» список проблем, щоб допомогти вам керувати ним.

Повна публікація в блозі "Випуски 2.0" на цю тему дасть вам більш детальний огляд функцій.

Я використовую huboard.com для представлення випусків github на дошці Kanban, а потім сортую їх, перетягуючи та опускаючи всередину huboard. Це працює досить добре, якщо вам цікаво лише візуалізувати пріоритет та знати, що робити далі.

Він фактично зберігає пріоритет у самій проблемі, як коментар HTML:

Your normal issue text here...
<!---
@huboard:{"order":465.0}
-->

Приклад того, як ми використовуємо мітки на github для управління нашими проектами

Етикетки категорій (також можна використовувати всі шапки для візуального розділення)

• Завдання
• Помилка
• Особливість
• Обговорення

Мітка пріоритету

• НЕОБХІДНО

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

Мітки статусу

• переглянуто (правонаступник прочитав його)
• у черзі (одержувач працюватиме над цим незабаром)
• незавершена робота (правонаступник зараз працює над цим)
• недійсний (якщо помилка не відтворюється)
• потрібен зворотний зв'язок (сигнал битою, щоб люди могли читати та коментувати чи надавати допомогу)

Ми зберігаємо всю документацію у вікі, яка включає в себе практику, архітектуру, інфраструктуру, тематичні дослідження, планування та вимоги.

Отримати запити призначені для огляду коду та обговорення особливостей, якщо він є частиною гілки

Завдяки творчому використанню фільтрації ми можемо знайти будь-яку роботу, яку нам потрібно зробити протягом дня. "Завдання + НЕПРАВНО" або "Помилка + НЕПРИЄМНО" завжди переглядайте проблеми, позначені як "потрібен зворотній зв'язок", і залишайте коментар, навіть якщо у вас немає чого додати. Звичайно, це працює з нашою командою з п'яти, але, мабуть, не набагато більше.

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

• помилка
• особливість - (нові речі)
• удосконалення - (покращення існуючих речей)
• питання / обговорення - (обговорення матеріалів)

Питання / обговорення можуть не знадобитися, якщо ви добре використовуєте Wiki. Але мені це подобається, тому що це дозволяє мені направити питання чи ідею на конкретну людину.

Тоді є три дійсно простих мітки пріоритету:

• зараз
• скоро
• пізніше

Легко, правда?

Окрім запропонованих вище рішень для маркування, ми маємо blockingі blockedяк мітки.

Спочатку питання потрібно призначити правильній особі, але якщо ця людина не в змозі працювати над цим питанням до тих пір, поки інша проблема не буде закінчена, питання позначається як blocked. А на іншу проблему посилається хеш-тег.

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

Мені було трохи складно розібратися, як перелічити предмети, призначені конкретній людині;

Рішення полягає в натисканні на піктограму "пошук" (без введених критеріїв пошуку), а на сторінці результатів розташоване спадне меню зліва.