Как эффективно работать с тикетами (issues) на GitHub
Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.
Содержание:
Что такое тикет?
Для многих команд «тикет» — это общий термин, который может означать:
Публичный или приватный?
Для проектов можно создавать публичные и приватные тикеты. Публичные, как правило, предназначены для пользователей, клиентов, агентов и т. д. Приватные — для разработчиков, подрядчиков, партнёров и т. д.
Для публичных тикетов
Для приватных тикетов
Оценка
Все тикеты надо оценивать таким образом, чтобы иметь возможность сравнить их друг с другом и понять, над чем именно нужно работать. Есть разные способы оценки, и на практике хорошо работают следующие.
Оценка по приоритетности
Оценка по степени влияния
Оценка по степени ущерба
Оценка по размеру
Оценка по критерию MoSCoW
Оценка по частоте
Совокупная оценка
Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.
Допустим, в офис приехал важный клиент, чтобы в течение часа подписать договор, а команда продавцов обнаружила на сайте опечатку в названии компании клиента.
Обсуждение оценок
Здесь приведены примеры обсуждения оценок тикетов.
— Обычно кроме опасности независимо оценивается и частота. Если баг вряд ли проявится при обычном использовании, то даже при высокой опасности приоритетность может быть понижена. Обычно так управляют рисками.
— Разработчик или тестировщик может хорошо оценивать опасность бага, но он не знает, столкнутся с этой проблемой все пользователи или только некоторые из них. Частота — это другое измерение. Приоритетность можно вычислить, умножив опасность на частоту.
— Форма должна быть такой: опасность * частота — лёгкость обходного решения = приоритет. Если какой-то из членов уравнения меняется (например, найдено новое обходное решение, или выясняется, что на падающую веб-страницу почти никто не заходит), тогда приоритет скорректируется. Одна лишь опасность без «оценки количества людей, на которых это повлияет» и «насколько сильно это на них повлияет?» выглядит лишь частью общей картины.
— QA-инженер в ходе начального исследования задал опасность на основе технических критериев. Это лишь один из факторов, которые продуктолог использует при определении приоритетности, которая с этого момента становится ключевым параметром.
— У некоторых пользователей программа иногда вылетает, они теряет всю сделанную работу и очень сильно злятся. Они присваивают тикету высочайшую опасность. Но если с проблемой сталкивается только один человек, и это происходит периодически, причём пользователь уже приспособился чаще сохраняться, тогда продуктологу следует задать тикету более низкую приоритетность.
— Опасность характеризует восприятие проблемы человеком: если он сталкивается с ней в определённом случае, то он оценит опасность как максимальную. Приоритетность описывает, как воспринимает баг команда управления проектом: более высокое значение получают баги, о которых сообщают наиболее ценные жалобщики — приносящие много денег клиенты, столкнувшийся с затруднениями директор и т. д. Не используйте опасность багов для оценки приоритетности, потому что они взаимосвязаны опосредовано.
— Опыт использования приоритетности и опасности подсказывает, что в теории различие между ними может быть, но в реальности большинство его не видят. Эти термины так часто путают, что они стали неразделимы.
— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).
— Мы используем только приоритетность. Тестировщик присваивает на основании эвристик начальное значение (например, падениям — П1, косметическим улучшениям — П5). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.
Шаблон тикета
Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.
В нем могут использоваться:
Запуск постмортемов
Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.
Запустить разбор можно:
Project planning for developers
Create issues, break them into tasks, track relationships, add custom fields, and have conversations. Visualize large projects as spreadsheets or boards, and automate everything with code.
Bored of boards?
Switch to tables.
Built like a spreadsheet, project tables give you a live canvas to filter, sort, and group issues and pull requests. Tailor them to your needs with custom fields and saved views.
Break issues into actionable tasks
Tackle complex issues with task lists and track their status with new progress indicators. Convert tasks into their own issues and navigate your work hierarchy.
Move conversations forward
Express ideas with GitHub Flavored Markdown, mention contributors, react with emoji, clarify with attachments, and see references from commits, PRs, releases, and deploys. Coordinate by assigning contributors and teams, or by adding them to milestones and projects. All in a single timeline.
Upload and attach videos to comments
Dive into work faster with issue forms and templates
Upload and attach videos to comments
Dive into work faster with issue forms and templates
Create views
for how you work
Save views for sprints, backlogs, teams, or releases. Rank, group, sort, and filter issues to suit the occasion. Choose between tables, boards, and timelines (coming soon).
Work at keyboard speed
No mouse? No problem. Every action you can take with the mouse has a keyboard shortcut or command. Filter, sort, group, and assign issues. Your hands never leave the keyboard.
Extend issues
with custom fields
Track metadata like iterations, priority, story points, dates, notes, and links. Add custom fields to project tables and edit from the issue sidebar.
Now with iteration cycle planning
Tailor reports from any field
Make any field reportable. Track the progress of your current iteration cycle, milestone, or visualize bottlenecks and issues blocking the team with the new project insights.
Manage work automatically
Accelerate your project planning with automations. Automatically triage issues, set values for custom fields, react to changes, or schedule something. You can even tee them up to run an Action.
Issues, wherever you look
Issues can be viewed, created, and managed in your browser, your favorite terminal, or on your phone or iPad.
GitHub CLI
View, update, and create issues without ever leaving your terminal.
GitHub Mobile
Create and manage issues on the go with our native iOS and Android mobile apps.
“ The new planning and tracking functionality keeps my project management close to my code. I no longer find myself needing to reach for spreadsheets or 3P tools which go stale instantly.
Frequently
asked questions
Why GitHub Issues?
We all need a way to plan our work, track issues, and talk about the things we build. Our answer to this universal question is GitHub Issues, and it’s built-in to every repository. GitHub’s issue tracking is special because of our focus on simplicity, references, and elegant formatting.
With GitHub Issues you can express ideas with GitHub Flavored Markdown, assign and mention contributors, react with emoji, clarify with attachments and videos, plus reference code like commits, pull requests, and deploys. With task lists you can break big issues into tasks, and then further organize your work with milestones and labels, and track relationships and dependencies.
We built GitHub issues for developers. It is simple, flexible, and powerful.
Why project tables and boards?
As teams and projects grow, how we work evolves. Tools that hard-code a specific methodology are too specific and rigid to flex to whatever the moment demands. Often, we find ourselves creating a spreadsheet or pulling out a notepad, just to have the space to think. But then our planning is disconnected from where the work happens and quickly goes stale.
The new Projects connect your planning directly to the work your teams are doing, and flexibly adapt to whatever your team needs at any point. Built like a spreadsheet, project tables give you a live canvas to filter, sort, and group issues and pull requests. You can use it, or the accompanying project board, along with custom fields, to track a sprint, plan a feature, or manage a large-scale release.
I am in the Beta, where do I share feedback?
How much will the new GitHub Issues cost?
Our plan is to continue to bundle GitHub Issues and its new project planning capabilities in our Free, Pro, Team, and Enterprise plans at no additional cost.
Will the Beta be available in GitHub Enterprise Server?
GitHub Enterprise Server support follows our normal cadence of one to two quarters before we enable the functionality on-premises.
How does this co-exist with other features like the existing kanban boards?
Once the Beta is enabled on your account, the organization’s projects page will display both projects (classic kanban) and the new beta projects (with table and custom field) side by side. They will coexist through the beta period, with classic projects automatically updating to leverage the new features prior to general availability.
It is important to note that at this time there are no migration tools available, both from existing projects or other planning and tracking tools.
How can I create a new project at the repo level?
Repo level projects are not currently supported, but is high on our roadmap and coming soon.
What is on the roadmap for the new GitHub Issues?
We are really excited to start this journey with all of you.
Our roadmap towards general availability (GA) will evolve, but expect improvements to the core flows and new functionality to be continuously added. Top features include:
Термины Гита и Гитхаба #234
Comments
meritt commented Apr 23, 2016
Мы для Академии подготовили небольшой список терминов Гита и я хотел бы его внести в словарь. Я не уверен, что все они подойдут, поэтому скажите, что точно надо выкинуть и я оформлю пулреквест. Я предлагаю сделать отдельный файл git.md и туда добавить следующее:
The text was updated successfully, but these errors were encountered:
pepelsbey commented Apr 23, 2016
Обновиться из апстрима
Обновиться из ориджина
Я бы просто «апстрим» и «ориджин» ввёл, как термины. А потом примеры использования.
pepelsbey commented Apr 23, 2016
Код-ревью писал бы через дефис, т.к. есть слово ревью и можно сказать «ревью кода»
pepelsbey commented Apr 23, 2016
Также комит и мёрж. @tachisis, что думаешь?
jucke commented Apr 23, 2016
tachisis commented Apr 23, 2016
@pepelsbey а по какой причине у тебя буква м выпала? Я пишу оба так, как у Леши
pepelsbey commented Apr 23, 2016
@tachisis, ладно «коммит», но вот мёрдж (три согласные подряд) я совсем не могу читать, всё равно «д» выскакивает при произнесении. С ориджином проще, там ридж, а не рдж. Тут приводили в пример Джорджию, но почему-то не убедили.
tachisis commented Apr 23, 2016
Это такая традиция. Но в целом можно и выкинуть д, я чаще встречаю, что все пишут «мержить»
Nakleikoff commented Apr 25, 2016
igoradamenko commented Apr 25, 2016
@Nakleikoff ну тут спорный момент. в этом слове в начале идёт гласная и потому дальше читать легче. попробуйте же прочитать: «смерджить» и «смержить». Второй вариант читается значительно легче, да и даже первый вариант вы будете произносить как второй. «Д» определённо выпадает. Даже гугл об этом говорит:
«смерджить»
Возможно, вы имели в виду: «смержить»
pepelsbey commented Apr 25, 2016 •
Перевес в сторону без «д» в поиске от 2/1 до 3/1.
Гугл ищет слова с «ё» и «е» как два разных, результаты суммировал.
igoradamenko commented Apr 25, 2016
На Гитхабе есть объяснение основных терминов, поэтому можно что-то ещё оттуда взять, дополнить.
meritt commented May 19, 2016
Curiouslynx commented Jul 12, 2018 •
Введение в GitHub от разработчика
Перевод статьи Флавио Копеса «A developer’s introduction to GitHub».
GitHub это сайт, где размещаются миллиарды строк кода. Это сайт, ежедневно собирающий миллионы разработчиков для сотрудничества и решения проблем с open source-программами.
Короче говоря, это платформа для разработчиков ПО и построена она на основе Git.
Разработчику не избежать в своей работе ежедневного использования GitHub или какого-нибудь другого инструмента на основе Git. С помощью подобных сервисов вы можете размещать в сети собственный код, а также принимать участие в работе с чужими проектами. В данной статье поясняются некоторые ключевые вопросы, касающиеся GitHub, и рассказывается, как использовать его функционал для улучшения своей работы.
Почему GitHub?
Поскольку вы уже знаете, что такое GitHub, вам может быть интересно, зачем вам лично им пользоваться.
Ведь этим проектом, в конечном итоге, рулит частная компания (статья написана до того, как этой частной компанией стал Microsoft, — прим. перев.), получающая доход от размещения чужого кода. Так есть ли причины использовать именно его, а не похожие платформы, например BitBucket или GitLab?
Кроме личных предпочтений и резонов технического плана, есть веский довод в пользу использования GitHub: им пользуются все, а значит, сетевой эффект огромен.
Большинство кодовых баз со временем перешли с других систем контроля версий на Git из-за его удобства. А GitHub, так уж исторически сложилось, вложил много сил в удовлетворение нужд open source-сообщества.
Поэтому сегодня, какую бы библиотеку вы ни искали, чаще всего вы найдете ее на GitHub.
Кроме open source-проектов многие разработчики размещают на GitHub приватные репозитории. Они делают это из-за удобства платформы.
Рассмотрим важные вещи, касающиеся GitHub, которые нужно знать разработчику.
GitHub Issues
GitHub issues это один из популярнейших баг-трекеров (систем отслеживания багов) в мире.
С его помощью собственники репозиториев могут организовывать, размечать и привязывать проблемы к меткам.
Если вы откроете issue (вопрос по проблеме) в чьем-то проекте, то он останется открытым, пока вы сами его не закроете (например, если вам удалось разобраться с этой проблемой), или пока собственник репозитория его не закроет.
Иногда вы получаете определенный ответ, в других случаях вопрос (с проставленными метками относительно его категории) будет оставаться открытым. Разработчик может вернуться к этому вопросу позже, чтобы исправить проблему или усовершенствовать свою кодовую базу на основе вашего отзыва.
По большей части разработчики не получают денег за поддержку своего кода, выпущенного на GitHub, так что не стоит ожидать немедленных ответов. Однако некоторые репозитории с открытым кодом публикуются компаниями, которые предоставляют услуги, основанные на этом коде, предлагают его коммерческие версии с большим функционалом или используют архитектуру на основе плагинов. И поэтому у них есть штатные разработчики, занимающиеся работой с open source-проектами.
Social coding (социальное программирование)
Несколько лет назад логотип GitHub содержал пометку «social coding». Что это означало и действует ли это до сих пор? Определенно действует.
Подписка
На GitHub вы можете подписаться на определенного разработчика или репозиторий. Для этого нужно пройти в профайл пользователя и кликнуть «follow» или нажать кнопку «watch» на репозитории.
В обоих случаях вы будете видеть активность по этим темам на своей панели инструментов. Подписка на пользователя или репозиторий отличается от подписки в Twitter. Здесь вы будете видеть, что люди делают, а не что они говорят.
Звезды
Одно из важных свойств GitHub это возможность дать звезду репозиторию. Это действие помещает его в список репозиториев, которые вы отметили звездами («starred repositories»). Благодаря этому вы можете отслеживать проекты, которыми заинтересовались, и находить похожие проекты.
Это также один из самых важных рейтинговых механизмов. Чем больше звезд у репозитория, тем он популярнее и в целом важнее. Это приводит к тому, что репозиторий становится более заметен в результатах поиска.
Крупные проекты могут набирать десятки тысяч звезд.
На GitHub также есть страница с трендами, куда попадают репозитории, получившие больше всего звезд за ограниченное количество времени (например, сегодня, на этой неделе, в этом месяце).
Попадание на страницу трендов тоже может повлечь за собой сетевой эффект, например, в виде упоминания на других сайтах. Это происходит просто потому, что вы стали более заметны.
Fork (ответвление)
Последний заметный сетевой показатель проекта это количество ответвлений (форков).
Это ключ к работе GitHub, поскольку форк это основа пул-реквеста (Pull Request, PR) – предложения внесения изменений. Любой человек может сделать форк вашего репозитория, внести какие-то изменения, а затем создать пул-реквест, чтобы попросить вас смерджить, слить воедино эти изменения.
Иногда человек, сделавший форк, может так никогда и не попросить вас мерджить что-нибудь. Он может сделать форк просто потому что ему понравился ваш код и он решил добавить что-нибудь поверх него. Ему не нужно, чтобы эти изменения коснулись оригинального репозитория. Также пользователь мог исправить баги, с которыми столкнулся и которые проявились только у него.
Популярный значит лучший
В общем, это все основные показатели популярности проекта. Помимо них полезными сведениями являются также дата последнего коммита и степень участия автора в отслеживании проблем. Основываясь на этих показателях, вы можете определить, стоит ли полагаться на данную библиотеку или программу.
Пул-реквесты (Pull requests)
В предыдущем разделе уже говорилось о том, что такое пул-реквест. Повторим. Человек может сделать форк вашего репозитория, внести изменения, а затем создать пул-реквест (запрос), чтобы попросить вас включить эти изменения в свой репозиторий (смерджить).
В проекте могут быть сотни PR. Обычно, чем популярнее проект, тем больше пул-реквестов в нем будет. Вот пример React:
Когда человек делает пул-реквест, он просматривается основными лицами, занимающимися поддержкой этого проекта.
Количество времени, которое потребуется тому, кто занимается поддержкой проекта, на рассмотрение вашего пул-реквеста, может варьироваться. Оно зависит от масштаба вашего запроса: количества изменений, количества вещей, на которых отразятся эти изменения, сложности затрагиваемого кода. Человек должен убедиться, что предлагаемые вами изменения совместимы с этим проектом.
У проекта может быть четкое расписание изменений, которые должны быть представлены. Люди, занимающиеся его поддержкой, возможно, хотят придерживаться простоты, а вы в своем пул-реквесте предлагаете сложную архитектуру.
Таким образом, пул-реквест не всегда может быть принят быстро, и вообще нет гарантий, что он будет принят.
В приведенном примере React есть пул-реквест, сделанный еще полтора года назад. Это случается во всех проектах. Это нормально и для этого могут быть свои причины (из упомянутых выше).
Управление проектами (менеджмент проектов)
Кроме раздела issues, где разработчики получают обратную связь от пользователей, интерфейс GitHub предоставляет и другой функционал, предназначенный для менеджмента проектов.
Например, Projects (Проекты). Это новинка в экосистеме и довольно редко используется, но это доска Kanban, которая помогает упорядочивать возникшие проблемы и необходимые работы.
Wiki представляет собой документацию для пользователей. Один из самых впечатляющих вариантов использования Wiki, которые мне доводилось видеть, это Go Programming Language GitHub Wiki – справка по языку Go.
Еще одним вспомогательным инструментом для менеджмента проектов является система отметок этапов (milestones). Это часть раздела issues. Вы можете привязать вашу проблему к определенной метке (например, номеру релиза), что сужает круг поисков.
Раз уж речь зашла о релизах, GitHub усовершенствовал функционал тегов Git, введя релизы (releases).
Тег Git это указатель на определенный коммит. Если все сделано последовательно, то это помогает вам откатиться на предыдущую версию вашего кода, не ссылаясь на конкретные коммиты.
Релиз GitHub основывается на тегах Git и представляет собой полный релиз вашего кода, вместе с Zip-файлами, примечаниями и бинарными цифровыми объектами, которые могут представлять полностью рабочую версию конечного продукта вашего кода.
Теги Git могут создаваться программными средствами (например, с использованием командной строки программы git). Но GitHub-релиз создается вручную с помощью пользовательского интерфейса GitHub. В общем, вы говорите GitHub создать новый релиз и указываете, какие теги вы хотите применить к этому релизу.
Сравнение коммитов
GitHub предлагает много инструментов для работы с вашим кодом. Сравнение одной ветки с другой это одна из самых важных вещей, которые вам могут понадобиться. Или вы можете захотеть сравнить последний коммит с той версией, которую вы используете на данный момент, чтобы увидеть, какие изменения были внесены.
GitHub дает вам возможность делать это с помощью compare view (просмотра изменений). Просто добавьте /compare в конце адреса, после названия репозитория.
В этом примере я сравнил React v15.x с v16.0.0-rc, последней версией на момент написания этой статьи, чтобы посмотреть, что изменилось:
С помощью этой функции вы можете видеть коммиты, сделанные между двумя релизами (или теги, или ссылки на коммиты), и существующую разницу, если число изменений меньше разумного количества.
Вебхуки и сервисы
GitHub предоставляет много вспомогательных функций для процесса разработки, например, вебхуки и сервисы.
Вебхуки (Webhooks)
Вебхуки позволяют пинговать внешние сервисы, когда в репозитории происходят определенные события, например, когда пушится код, делается форк или создается/удаляется тег.
Когда происходит событие, GitHub отсылает запрос POST на указанный нами URL.
Распространенным вариантом использования этой функции является пингование удаленного сервера для доставки последнего кода с GitHub, когда мы пушим обновление с нашего локального компьютера.
Мы делаем пуш на GitHub, GitHub сообщает об этом серверу, а сервер забирает его с GitHub.
Сервисы
Сервисы GitHub, а также новые GitHub-приложения, являются сторонними сборками, которые улучшают опыт разработчика или предоставляют какие-то услуги.
Например, вы можете настроить test runner, чтобы тесты запускались автоматически каждый раз, как вы запушите какие-то новые коммиты (используется TravisCI).
Вы можете настроить непрерывную интеграцию с использованием CircleCI.
Можно создать интеграцию Codeclimate для анализа кода и предоставления отчетов о «техническом долге» и покрытии тестами.
Выводы
GitHub это потрясающий инструмент и сервис, настоящая жемчужина в сегодняшнем наборе инструментов разработчика. Это руководство поможет вам начать его использовать, но, конечно, не может заменить настоящего опыта работы над open source-проектами на GitHub.
