Как управлять проблемами GitHub (приоритет и т. Д.)? [закрыто]

Я новичок в GitHub, и я ищу советы о том, как решать проблемы. Я привык иметь приоритет и другие варианты заказа, но вижу, что ни один не существует.

Как другие решают проблемы в течение жизненного цикла ошибки / функции?

Заранее спасибо.

Можно определить различные группы меток , такие как типы выпуска , приоритеты выпуска , выпуск статусы , версия теги , и , возможно , больше. Чтобы сразу увидеть, к какой группе принадлежит метка, вы можете использовать соглашение об именах, например <label-group>:<label-name>.

Использование такого соглашения об именах должно значительно упростить управление проблемами Github и помочь другим «быстрее понять» проблемы. Обратите внимание, что вы также можете назначать цвета меткам, что может добавить еще больше читабельности (я бы использовал определенный цвет для каждой группы меток). Но поскольку вам по-прежнему приходится назначать / отменять назначение этих ярлыков для / из проблем вручную, возможно, вы захотите сохранить общий список групп / ярлыков небольшим.

Согласно предложенной выше схеме вы можете определить группы и соответствующие метки следующим образом.

группа «тип проблемы»

• Тип: ошибка
• Тип: функция
• тип: идея
• Тип: недействительный
• тип: поддержка
• Тип: задача

группа «приоритет вопроса»

• ПРИО: низкая
• ПРИО: нормальный
• ПРИО: высокая

группа «статус вопроса»

(Эти метки описывают состояние проблемы в определенном рабочем процессе.)

• Статус: подтверждена
• Статус: отложено
• Статус: фикс-совершенный
• Статус: в стадии разработки
• Статус: неполное
• Статус: отклонен
• Статус: разрешено

группа «информация о проблеме»

• Информация: обратная связь необходимо
• информация: помощь необходимой
• информация: прогресс-25
• информация: прогресс-50
• информация: прогресс-75

группа 'версия тега'

• версия: 1.x
• версия: 1.1

Система отслеживания ошибок GitHub довольно гибкая. Здесь действительно нет ни приоритета, ни порядка. Он вращается вокруг трех основных столпов: назначения , метки и вехи .

• Вы можете пометить проблемы с созданными вами ярлыками (аналогично ярлыкам Gmail). Например: «bug», «feature-request», «todo», «question», ... Одна проблема может быть помечена разными метками.

• Вы можете «упаковать» несколько вопросов в веху . Веха состоит из заголовка (например, номера версии) и дополнительной даты доставки.

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

В конце концов, благодаря боковой панели, вы можете «отфильтровать» список проблем, чтобы помочь вам управлять им.

Полный пост в блоге "Issues 2.0" на эту тему даст вам более подробное представление о возможностях.

Я использую huboard.com для представления проблем github на доске Kanban, а затем сортирую их, перетаскивая в huboard. Это работает довольно хорошо, если вам интересно только визуализировать приоритет и знать, что делать дальше.

Фактически он сохраняет приоритет в самой проблеме, как комментарий HTML:

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

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

Ярлыки категории (также можно использовать все заглавные буквы для визуального разделения)

• задача
• ошибка
• Характерная черта
• обсуждение

Приоритетная Метка

• СРОЧНО

Мы считаем, что все имеет нормальный приоритет и на самом деле не видим необходимости в «низком». Так что остается только один ярлык, чтобы пометить вещи, которые требуют немедленного внимания.

Ярлыки статуса

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

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

Pull-Requests предназначены для обзоров кода и обсуждения возможностей, если они являются частью ветки

С некоторым творческим использованием фильтрации мы можем найти любую работу, которую нам нужно сделать в течение дня. «Task + URGENT» или «Bug + URGENT» всегда рассматривают проблемы, помеченные как «Нужна обратная связь», и оставляют комментарий, даже если вам нечего добавить. Конечно, это работает с нашей командой из пяти человек, но, вероятно, не намного больше.

Я обращаюсь к двум видам ярлыков в вопросах GH - первый относится к типу проблемы, а второй относится к приоритету:

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

Вопрос / обсуждение может не понадобиться, если вы хорошо используете Wiki. Но мне это нравится, потому что это позволяет мне направить вопрос или идею конкретному человеку.

Тогда есть три действительно простых приоритетных ярлыка:

• в настоящее время
• скоро
• потом

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

В дополнение к предложенным выше решениям по тегированию у нас есть blockingи blockedэтикетки.

Проблема должна быть сначала назначена правильному человеку, но если этот человек не может работать над проблемой до тех пор, пока не будет решена другая проблема, проблема помечается как blocked. И другая проблема упоминается с использованием хэш-тега.

Точно так же, если задача блокирует кого-то еще от работы над чем-либо, она должна быть помечена как blockingссылка на другую проблему.

Мне было немного сложно понять, как составлять список предметов, назначенных конкретному человеку;

Решение состоит в том, чтобы щелкнуть значок «поиск» (без введенных критериев поиска), и на странице результатов слева есть раскрывающийся список.