что такое issues в github
Как эффективно работать с тикетами (issues) на GitHub
Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.
Содержание:
Что такое тикет?
Для многих команд «тикет» — это общий термин, который может означать:
Публичный или приватный?
Для проектов можно создавать публичные и приватные тикеты. Публичные, как правило, предназначены для пользователей, клиентов, агентов и т. д. Приватные — для разработчиков, подрядчиков, партнёров и т. д.
Для публичных тикетов
Для приватных тикетов
Оценка
Все тикеты надо оценивать таким образом, чтобы иметь возможность сравнить их друг с другом и понять, над чем именно нужно работать. Есть разные способы оценки, и на практике хорошо работают следующие.
Оценка по приоритетности
Оценка по степени влияния
Оценка по степени ущерба
Оценка по размеру
Оценка по критерию MoSCoW
Оценка по частоте
Совокупная оценка
Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.
Допустим, в офис приехал важный клиент, чтобы в течение часа подписать договор, а команда продавцов обнаружила на сайте опечатку в названии компании клиента.
Обсуждение оценок
Здесь приведены примеры обсуждения оценок тикетов.
— Обычно кроме опасности независимо оценивается и частота. Если баг вряд ли проявится при обычном использовании, то даже при высокой опасности приоритетность может быть понижена. Обычно так управляют рисками.
— Разработчик или тестировщик может хорошо оценивать опасность бага, но он не знает, столкнутся с этой проблемой все пользователи или только некоторые из них. Частота — это другое измерение. Приоритетность можно вычислить, умножив опасность на частоту.
— Форма должна быть такой: опасность * частота — лёгкость обходного решения = приоритет. Если какой-то из членов уравнения меняется (например, найдено новое обходное решение, или выясняется, что на падающую веб-страницу почти никто не заходит), тогда приоритет скорректируется. Одна лишь опасность без «оценки количества людей, на которых это повлияет» и «насколько сильно это на них повлияет?» выглядит лишь частью общей картины.
— QA-инженер в ходе начального исследования задал опасность на основе технических критериев. Это лишь один из факторов, которые продуктолог использует при определении приоритетности, которая с этого момента становится ключевым параметром.
— У некоторых пользователей программа иногда вылетает, они теряет всю сделанную работу и очень сильно злятся. Они присваивают тикету высочайшую опасность. Но если с проблемой сталкивается только один человек, и это происходит периодически, причём пользователь уже приспособился чаще сохраняться, тогда продуктологу следует задать тикету более низкую приоритетность.
— Опасность характеризует восприятие проблемы человеком: если он сталкивается с ней в определённом случае, то он оценит опасность как максимальную. Приоритетность описывает, как воспринимает баг команда управления проектом: более высокое значение получают баги, о которых сообщают наиболее ценные жалобщики — приносящие много денег клиенты, столкнувшийся с затруднениями директор и т. д. Не используйте опасность багов для оценки приоритетности, потому что они взаимосвязаны опосредовано.
— Опыт использования приоритетности и опасности подсказывает, что в теории различие между ними может быть, но в реальности большинство его не видят. Эти термины так часто путают, что они стали неразделимы.
— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).
— Мы используем только приоритетность. Тестировщик присваивает на основании эвристик начальное значение (например, падениям — П1, косметическим улучшениям — П5). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.
Шаблон тикета
Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.
В нем могут использоваться:
Запуск постмортемов
Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.
Запустить разбор можно:
Quickstart for GitHub Issues
In this article
Follow this brief interactive guide to learn about GitHub Issues.
This guide demonstrates how to use GitHub Issues to plan and track a piece of work. In this guide, you will create a new issue and add a task list to track sub-tasks. You’ll also learn how to add labels, milestones, assignees, and projects to communicate metadata about your issue.
To create an issue, you need a repository. You can use an existing repository that you have write access to, or you can create a new repository. The repository must have issues enabled. For more information about creating a repository, see «Creating a new repository.» For more information about enabling issues if they are disabled in your repository, see «Disabling issues.»
Opening a blank issue
First, create an issue. There are multiple ways to create an issue; you can choose the most convenient method for your workflow. This example will use the GitHub UI. For more information about other ways to create an issue, see «Creating an issue.»
On GitHub.com, navigate to the main page of the repository.
Under your repository name, click
Issues.
In this example, we will start with a blank issue. Your repository may use issue templates and issue forms to encourage contributors to provide specific information. If your repository uses issue templates, click Open a blank issue.
Filling in information
Give your issue a descriptive title. The title should convey at a glance what the issue is about.
Add a description that explains the purpose of the issue, including any details that might help resolve the issue. For example, if this is a bug report, describe the steps to reproduce the bug, the expected result, and the actual result.
You can use markdown to add formatting, links, emojis, and more. For more information, see «Writing on GitHub.»
Adding a task list
Add a label to categorize your issue. For example, you might use a bug label and a good first issue label to indicate that an issue is a bug that a first-time contributor could pick up. Users can filter issues by label to find all issues that have a specific label.
You can use the default labels, or you can create a new label. For more information, see «Managing labels.»
You can add a milestone to track the issue as part of a date based target. A milestone will show the progress of the issues as the target date approaches. For more information, see «About milestones.»
Assigning the issue
To communicate responsibility, you can assign the issue to a member of your organization. For more information, see «Assigning issues and pull requests to other GitHub users.»
Adding the issue to a project
You can add the issue to an existing project. If you are using projects (beta), you can also populate metadata for the project. For more information about projects, see «About projects (beta)» and «Organizing your work with project boards».
Submitting your issue
Click Submit new issue to create your issue. You can edit any of the above fields after creating the issue. Your issue has a unique URL that you can share with team members, or reference in other issues or pull requests.
After your issue is created, continue the conversation by adding comments to the issue. You can @mention collaborators or teams to draw their attention to a comment. To link related issues in the same repository, you can type # followed by part of the issue title and then clicking the issue that you want to link. For more information, see «Writing on GitHub.»
You can use issues for a wide range of purposes. For example:
Here are some helpful resources for taking your next steps with GitHub Issues:
Help us make these docs great!
All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.
Термины Гита и Гитхаба #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 •
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:
Функции GitHub : Issues, Projects, Pull Requests
Здравствуйте! Помогите, пожалуйста, разобраться с такими функциями GitHub как Issues, Projects, Pull Requests. Для чего они нужны и как правильно с ними работать. У меня есть репозиторий, в котором 2 текстовых файла. И к этому репозиторию надо применить эти функции. Заранее, огромное спасибо!
1 ответ 1
Issues — это система учёта ошибок, по-английски bugtracker.
Конечно, она не такая навороченная, как, к примеру Jira. Однако разработчики Github-а считают эту простоту преимуществом благодаря гибкости и отсутствию визуального мусора.
Так как у Github Issues отсутствуют такие важные поля, как «Категория», «Серъёзность», «Статус» и «Компонент», их приходится заменять проставлением различных меток. Вот как это предлагает делать некто Zach Dunn:
Интересной особенность GitHub является то, что нумерация сообщений в Issue Tracker-e является общей с Pull Requests, хотя эти два понятия не пересекаются и находятся в разных категориях.
Более подробно о Github Issues можно прочитать в официальной справке.
Projects — это хранилище заметок. Больше о нём и сказать нечего, кроме упоминания возможности упорядочивать заметки по столбцам (категориям) и строкам. Вот, собственно, и всё. Можете хоть хранить напоминания, хоть организовать доску для канбана.
Pull Requests — это заявка на принятие ваших изменений в центральный репозиторий. Является неотъемлемой частью Github Flow.
Предполагается, что вы вели разработку в своей, публично доступной копии репозитория — форке. Публичность нужна для возможности улучшения вашей копии другими пользователями перед окончательным включением ваших изменений в центральный репозиторий.