Таски и сабтаски в JIRA (и как найти их в ответе API)

У меня на курсах по тестированию REST API и автоматизации в Postman есть задание — получить задачу из Jira (метод Get issue) и вывести на консоль некие поля, например:

• флаг, является ли связанная задача сабтаском
• имя автора аттача

Так вот. Не все до этого работали с Jira, и уж тем более не щупали её api. Описание в целом неплохое, но там нет перечисления всех полей, которые возвращаются в ответе, с их описанием. Поэтому я немного поясню.

JIRA: как найти задачу, где когда-то был исполнителем

Для меня тут наш разработчик открыл Америку. А вы знаете, что в джире можно использовать слово «was»? 

assignee was olgak — olgak был хоть раз назначен исполнителем по задаче. И можно найти свои задачи, которые через тебя проходили. Например, задачу сначала делал Ваня, потом Коля, потом вообще Никита. А ты помнишь, что Ваня ею занимался, как найти?

Потестила на одной из задач, забрала себе, вернула исполнителю:

text ~ "Часть из названия" and assignee = olgak  — Пусто, сейчас задача не на мне

text ~ "Часть из названия" and assignee was olgak — Работает 🙈😃

Как достучаться к JIRA через API токен

У меня есть бесплатная JIRA, которую можно всячески щупать и тыкать. По логину и паролю раньше можно было работать в графическом интерфейсе и отправлять запросы через REST API.

См также:
Тут можно потыкать JIRA и Confluence — данные для входа в GUI
Jira Cloud REST API — документация для REST интерфейса

К сожалению, JIRA прикрыла лавочку авторизации по ресту через логин-пароль. Теперь нужно использовать API Token.

API Token

Для нашей тестовой джиры:

• логин — mail.for.testbase@gmail.com
• пароль, он же токен — ATATT3xFfGF0rTZ1PQBTnOwwEyiLVZDM_2IT6hHQD731TyM-KeOOJ6AZi8WZfqIvID9oUHh3WWBjhOs0XC9xEDCQVPHlEyhiUvPmaE9Xr7db5ye46wf4A6dd7p_T_U1Ef_rIhE-GxCEsEehbAxhqgXc2CE0RLbns1ZpuEBiED_zb_fyfsIAkPLg=3E5D3FDA

Как использовать токен в Postman-e

Точно также, как вы использовали простой пароль!

Вкладка авторизации — Basic Auth

• Username — email пользователя
• Password — токен

Для проверки лично я использовала запрос гет https://testbase.atlassian.net/rest/api/3/issue/TV-2.

Работает!

Жизненный цикл (Workflow) задач

Жизненный цикл задачи — это то, по каким статусам она проходит от момента заведения до полного исправления, проверки и закрытия. В каждом баг-трекинге есть стандартный Workflow, но его всегда можно поменять под свои нужды. Рассмотрим типовые жизненные циклы

Open — Closed

Самый простой жизненный цикл содержит всего два состояния:

• Открыто (Open)
• Закрыто (Closed)

Как это выглядит в реальном мире:

• Тестировщик нашел баг, заводит задачу и вешает ее на разработчика. Задача находится в статусе Open
• Разработчик исправил баг и перевешивает на тестировщика для проверки — делает Assign to (назначить на), задача остается открытой (Open)
• Тестировщик проверяет исправление:
• Если все ок — закрывает, статус Closed
• Если не ок — снова вешает на разработчика, статус остается Open
• Повторить N раз, пока задача не будет закрыта

Схема 1. Open — Open — Close

Ладно, ладно! Разумеется, это не самый простой сценарий. Самый простой сценарий более топорный:

• Тестировщик нашел баг и повесил его на разработчика — задача в статусе Open
• Разработчик исправил и... Закрыл! Статус Closed

Как видеть только свои задачи в Джире

Инструкция подходит для тех случаев, когда у вас один аккаунт на несколько человек. Как видеть только свое? У нас в школе для начинающих в JIRA один аккаунт на всю группу, так что статья написана для них.

Но вы тоже можете поэкспериментировать на нашей тестовой площадке! Итак, наблюдаем за своими задачами:

1. При создании задачи промотать поле до поля Label (Метки) и внести там свое имя и фамилию без пробелов. В моем случае OlgaNazina:

Добавляем метку при создании задачи

Если такого поля нет, добавляем его: Настроить поля → Метки (ставим галку, поле появляется)

Если поля нет, настраиваем

Тут можно потыкать JIRA и Confluence

Связка JIRA + Confluence — довольно популярная, но стоит денег. Как понять, хотите вы этот баг-трекер или нет? Удобно ли будет работать в конфлюенсе? А если вы — начинающий? Здорово заранее потыкать инструмент, чтобы не бояться им пользоваться ✌

Можно взять у Atlassion месяц триальной версии, а можно зайти на мою облачную версию и резвиться там сколько влезет!

Ссылки

• JIRA — баг-трекер
• Conlfuence — вики система, обычно используется для документации.

Данные для входа:

• логин — mail.for.testbase@gmail.com
• пароль — Nazina617701
• для rest api нужен токен, ищите его в этой статье

В JIRA у вас есть проект Test, а конфлюенсе — тестовая площадка. Welcome 😀

См также:

Тут можно потыкать Redmine — основной конкурент

Тут можно потыкать Youtrack — тоже неплох

Тут можно потыкать Bugzilla — она вообще не конкурент, но если не верите...

PS: чуть позже будут обучающие статьи / видеоролики. Пока смотрю на своих студентов, что именно им непонятно ツ

PPS: а если не хочется ждать статей, но хочется потыкать эти и другие инструменты под присмотром тренера, приходите в нашу Школу для начинающих тестировщиков!

PPPS: ссылка добавлена на Testbase в раздел «Test it — бесплатные тестовые площадки». Теперь не потеряется!

Шаблон бага

Вариант для JIRA

h3. Шаги для воспроизведения
#
#
#
#
#

h3. Результат

h3. Ожидаемый результат

+ Аттач в виде скриншота.


Иногда еще нужна доп инфа, внизу добавляем:

h5. Дополнительная информация

******************************************************

В другом баг-трекере:
— Выделяем жирным заголовки (шаги, результат, ожидаемый результат).
— Нумеруем шаги. Единственный шаг нумеровать не надо.
— Отделяем шаги от результата и ожидаемого пустой строкой, дабы не получилась нечитабельная простыня текста.

В баге всегда пишется сначала результат, потом ожидаемый результат. Потому что менеджер или разработчик читают задачу, чтобы понять, в чем проблема. Читают читают шаги и тут бац, нормальный результат. Так в чем проблема? А потом зато фактический идет, это сбивает с толку.

В баге всегда пишется ожидаемый результат. Даже если он кажется вам очевидным.
— Он может быть очевидным только для вас. Другие члены команды не понимают, что нужно сделать.
— Он может быть очевидным для всех, но только сейчас. Если баг отложить на полгода, можно долго вспоминать, «что же тут ожидалось?»

На одном из курсов студентка написала с разницей в N времени:.

— А в багрепортах надо писать ожидаемый результат и фактический? оО
...
— Пока не попробовала пройти по некоторым чужим багам без результата и ожидаемого, и не попала в замешательство — не поняла, нафиг это надо.

Наглядность — наше все 

Пример

Шаги для воспроизведения

Перейти в раздел «Статистика» в личном кабинете Дадаты — https://dadata.ru/profile/#stat (данные для авторизации: логин abc, пароль 1)

Результат

500 ошибка сервера, см скриншот «Ошибка 500 в ЛК». (названия у скриншотов должны быть «говорящими», потому что их со временем может накопиться много)

Ожидаемый результат

Открылась статистика обработки данных

* Не пытайтесь воспроизвести проблему, разумеется, никакой ошибки в Дадате нет :)

------------------------------------------------------------------------------------------------------------------

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

Пока просто шаблон для бага — бери и используй!

См также:

Шаблон улучшения — Такой же шаблон, только для улучшения =)
Как заводить задачи в баг-трекер → подробнее о том, как ставить задачу и заполнять обязательные поля.
Пример локализации бага в игре «Паук» для iPad → применяем шаблон на практике!
Неправильный ярлык, угадай почему → и снова применяем, но тут с разбором описания, на что обратить внимание

PS: Статья написана в помощь студентам моих курсов по тестированию:

• Интенсив для начинающих
• Школа для начинающих тестировщиков
• Техники и инструменты поиска и оформления дефектов

и уже доступна на Testbase в навыке описания баг-репортов.

JIRA. Обратный отсчет — до релиза осталось...

Мы попробовали у себя на работе подключить JIRA Agile, но как-то не пошла идея... Из всех возможностей мы использовали в итоге только календарик Greenhopper Days Remaining.

Платить много денег за один лишь календарик смысла не имеет, сидеть на триальной версии тоже...

Но без календарика грустно! 

Поэтому мы создали свой 

Он даже умнее! Greenhopper писал большую красную 0, когда время истекало, а наш плагин ищет последнюю незакрытую версию и показывает, на сколько дней мы просрочили выпуск (минус один, минус два и т.д.)

Подключение календарика

1. Создать портлет типа Text

2. В поле "Заголовок" написать "До релиза осталось".

3. В поле HTML вставить

<html>

<style>

h1 { background-color: #e0f0ff;

     color: forestgreen;

     text-align: center; 

     font-size: 15em;

     font-weight: normal;

}

</style>

<body>

<h1 id="toRelease" />

<script language="javascript" type="text/javascript">

var minDate = new Date("2099-01-01");

var today = new Date();

var xhr = new XMLHttpRequest();

xhr.open("GET", "http://jira.hflabs.ru/rest/api/2/project/YourName/versions/", false);

xhr.send();

var versions = JSON.parse(xhr.responseText);

for (i = 0; i < versions.length; ++i) {

    if (new Date(versions[i].releaseDate) < minDate && versions[i].released === false ) {

      minDate = new Date(versions[i].releaseDate);

    }

}

diff = Math.ceil((minDate - today) / (24 * 60 * 60 * 1000));

if (diff < 0) {    

    for (i = diff; i < 0; ++i) {

        date = new Date();

        date.setDate(today.getDate() + i);

        if (date.getDay() === 0 || date.getDay() === 6) {

            diff = diff + 1;

        }

    }     

    diff = diff.toString().fontcolor("firebrick");

}

else {

    for (i = 0; i < diff; ++i) {

        date = new Date();

        date.setDate(today.getDate() + i);

        if (date.getDay() === 0 || date.getDay() === 6) {

            diff = diff - 1;

        }

    }

}

document.getElementById("toRelease").innerHTML = diff;

</script>

</body>

</html>

4. Заменить во фразе "project/YourName/versions/" YourName на название своего проекта.

5. Сохранить и наслаждаться! 

PS - календарик писался на коленке во внерабочее время. Так что код не идеален, но работает же! =)

JIRA. Стандартный workflow задач

Теперь, когда мы знаем:

• Создаем проект, с чего начать?
• DashBoards - что это такое?

Перейдем к следующему вопросу - вот создали мы задачу / ошибку / запрос на улучшение.

А дальше то что с ним делать? Какое Workflow есть у данной задачи, когда назначать на разработчика, когда - на тестировщика?

Давайте посмотрим на стандартный workflow. Для этого заходим в админку...
Облачная JIRA обновилась, теперь, чтобы зайти в админку, надо поплясать с бубном. По крайней мере, первый раз, пока ты еще ищешь админку в шестеренке...

В общем, нажимаем "." и вводим Workflow. Открываем

Видим такую табличку и в ней, скорее всего, будет только стандартная (отмеченная как default) схемка. Открываем ее.

И вот, пожалуйста, можно смотреть в текстовом виде (так ее удобнее редактировать), а можно в графическом (так ее удобнее читать и осознавать).

JIRA. DashBoards

Итак, мы создали задачку в нашем проекте. Как нам найти информацию по тому, кто какие активности по этой задаче проводил, пока нас не было?

Можно посмотреть в проектах. Projects - название проекта.

Что мы видим, перейдя по этом ссылке? Изначально мы находимся на закладке Summary, справа в которой имеется удобный гаджет под названием Activity Stream. В нем отображается, что происходит на проекте.

Еще мы можем перемещаться по закладкам, сортируя, таким образом, информацию. Например, перейдя на закладку Versions, мы можем посмотреть все баги, поставленные и исправленные в релизе 1.0, 2.0 или любом другом. Перейдя на закладку Components, можно посмотреть задачи по определенному компоненту, например, "отчеты" или "логи".

JIRA. Создаем проект, с чего начать?

Казалось бы. при чем тут тестирование?

А с другой стороны, почему бы и нет? Тестировщик вполне может быть админом JIRA или любого другого инструмента для ведения ошибок. Ведь это место (скопление багов) - наша стихия. Конечно же, мы хотим уметь настраивать ее под себя.

Чем мы с Вами и займемся. Показывать администрирование я буду на примере облачной JIRA, поэтому, если у Вас она обычная - может быть немного другой вид. Но это ничего, принцип не меняется.

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

Открывается примерно такой вид.

Отчеты об ошибках, правильно заполнять - легко?

На первый взгляд кажется, что формировать отчеты об ошибках - это легко. А что тут сложного? Описал проблему и свободен, тестируй дальше!

Ранее я уже писала о том, что мы открыли двери своей JIRA для Заказчика. И, в принципе, не мы первые, не мы последние. Но, обычно, тут то и приходит понимание - сообщения об ошибках тоже нужно уметь составлять. Ведь ты пишешь его не для себя, а для других людей!

Я это к чему - по долгу службы я все равно смотрю с точки зрения конечного пользователя. Удалось разработчику проблему воспроизвести или нет, мне стоит проверить.

И вот я за собой отметила в последнее время, что неплохо "перевожу" с языка пользователя на язык разработчика.

Например, приходит письмо на почту администратора - "Не могу попасть в JIRA, щелкаю на поле ввода логина или пароля - а попадаю на форму отправления заявки администратору!".

Админ приходит ко мне, разводя руками - и как он умудрился? Все же работает. Открываю IE, так как из хрома лениво разлогиниваться, захожу по прямой линке и вожу мышкой между полями ввода. Замечаю странную вещь - между полями мышка из стрелочки превращается в маленькую ручку "нажми сюда". Щелкаю - ба, а вот и форма помощи администратора 

И двух минут не прошло :))) Прихожу к админу - разлогинивайся! Он разлогинился, смотрю - что-то не то. Мало того, что все работает, но у меня еще сообщение об ошибке сверху было. Возвращаемся ко мне, читаем сообщение - оно предупреждает, что нам стоит войти в систему, чтобы получить доступ к той ссылке, на которую мы хотим попасть.

И вот именно когда есть такое сообщение об ошибке - есть и бага. Попробуйте, если еще не исправили - разлогиньтесь и вбейте в строку URL с прямой ссылкой на конкретную задачу. Вы увидите форму логина с ярко-желтым предупреждением о том, что вам необходимо войти в систему, чтобы попасть на нужную вам форму. Перемещаем мышку от формы ввода логина к форме ввода пароля.... И щелкаем между ними!

А ведь мне, как тестировщику, это было просто - встать на место пользователя и попробовать воспроизвести его шаги. Так бывало и раньше, на прошлых работах. Например, создает Заказчик багу. Разработчик посмотрел посмотрел и закрывает как "не воспроизводится". Типа, все хорошо, все работает.

Агащаз. В дело вступает тестировщик. Так. Формочка 1 - не работает ссылка. Открываем формочку 1 - все работает. Но! Ведь эта формочка открывается не только отсюда... Переходим во второе место - бац! Не работает ссылка. Reopen с более точными шагами и удивление разработчика:

- А, так вот что вы имели в виду...

К чему это я все? Просто вчера увидела в ленте твиттера, который транслируется на http://software-testing.ru/ сообщение о том, что программа Fun ConfetQA практически укомплектована.

Зашла почитать. А там - первый же доклад! Отчеты об ошибках, или как просто встать на путь постоянного совершенствования.

На самом деле - очень важная и интересная тема! Очень всем рекомендую, чтобы между вами и вашими разработчиками не приходилось вставлять "среднее звено", связующее, без которого никто никого не понимает, хотя каждый и уверен в своей правоте...

Давай, Серега, жги! Расскажи людям о том, как сделать мир лучше с понятным отчетом о найденных ошибках. И вдохнови всех писать так... Так... Чтобы разработчик, работающий на проекте первый день, смог воспроизвести проблему по одному лишь тексту!

А всем остальным я крайне рекомендую поскорее зарегистрироваться и успеть услышать эту вдохновляющую речь! 

Этот ворклог не нужен тебе... Джедаи-тестировщики

В продолжение темы о том, чтобы пустить Заказчиков в джиру.

Задачу в helpdesc поставили, админ сделал свой magic и появилась у Заказчиков возможность писать нам в общий доступ, так сказать. Чтобы каждый вопрос видела вся команда, а не только ее часть, подписанная на customer@support.

В итоге мы начали активно использовать галочку "Restriction to Workers", дабы попрятать комменты, не имеющие смысла для Заказчика. И даже скрыли от него закладку "Журнал работ" (где ты пишешь, сколько времени потратил и на что, и было ли это интересно), зачем ему смотреть наши ворклоги?

Однако я ходила и думала... Вот, скрыли мы свои комменты "Ага! А я говорил - потестить внимательно!!", "Да тестила я!!!". В джире их не видно будет... А вдруг email нотификации придут? о_О

Не доверяю я задачкам, закрытым без тестирования ))))
В общем, думала, думала, пошла к админу, докопалась - проверял? Нет.

- Давай Никите доступ.

Прихожу к Никите:

- Поздравляю, ты - Заказчик! Ставь мне таск.
- Ок, не вопрос, под кем логиниться?

Создали таску, я пошла ее покомментила, что-то простым комментарием, что-то "спрятанным". Ну и ворклоги заполнила. Посмотрели на пришедшую почту - уф, с комментариями все хорошо. А ворклоги приходят! Кхе кхе кхе. "1 час, нейтрально, пыталась воспроизвести проблему". Ну бывает же такое, когда не воспроизводится? А представьте, такое сообщение Заказчику уйдет?

Таааак, бегом к админу! Снова magic, снова я химичу с тестовой задачкой и иду к нашему "Заказчику", который коллега.

- Ну, что пришло?
- А что, должно было что-то?
- Ага.

Смотрим. Пришло только "этот коммент будет виден" и "этот тоже".

- Ура, закрываем!
- А что, ты что-то еще писала?
- А ты под собой зайти и посмотри Activity Stream :)

Зашел... Похихикал :))
Читается оно снизу вверх, если что...

Мораль сей басни такова - не доверяй сторонним программам! Их тоже надо тестить...

Support Request - "Прежде всего сядь и ПОДУМАЙ!"

Как обычно происходит support, или поддержка пользователей?

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

Кто же общается с Заказчиком?

1. Аналитики

Ну, казалось бы, а кто еще? Аналитики пишут ТЗ, согласовывают его с Заказчиком, рассказывают разработчикам, что им надо сделать... Дают ответы на бесконечные вопросы тестировщиков, утрясают проблемы со сроками и многое, многое другое...

Но бывают и другие варианты...

2. Тестировщики

Ну а кто еще так знает продукт, как тестировщик? :) Логика опять налицо. Тестировщик - последняя стадия продукта, его последний этап. Он знал его на этапе требований, а теперь он докапывается до сути реализации. Ну кому еще отвечать на вопросы "а какие параметры можно отправлять через soap-запрос в этом методе?"...

Разумеется, бывают и другие варианты. Особенно в agile - командах, где нет четко выраженных аналитиков или тестировщиков. Но нас то интересует именно второй вариант, правда ведь?

Чем хорош такой подход?

• Разнообразие - ты не ограничиваешься рамками "сел и потыкал", ты порой сам пишешь и согласовываешь ТЗ (ну а что делать, если оно непонятно написано?). Спектр твоих обязанностей расширяется и разнообразия в работе хватает с головой.
• Быстрый feedback - обратная связь всем нужна, всем важна. Как иначе узнать, понятное у вас описание в википедии или не очень? У Заказчика нет Аналитиков/разработчиков под рукой, ему похуже будет...
• Рука на пульсе - ты всегда знаешь, какие баги есть на предпродукционной платформе, удачно ли прошел релиз? Ведь кто "яйца на бочку" кладет ((c)Андрей Мясников), подтверждая, что ошибок в релизе нет, он - готов? Тестировщик! Кому, как не ему, первому узнать о проблемах пользователя?
• Быстрый ответ - Заказчик тоже хочет быстрой обратной связи. И если у него есть проблема, он хочет знать, откуда она и когда ее поправят. Уверена, что тестировщик тоже очень хочет это знать, тут их интересы совпадают.
• Соответствие ожиданиям - вы сталкивались с ситуацией "сломанного телефона"? Когда реализовали одно, а выяснилось, что нужно было совсем другое? Ситуация была очень ярко показана в ролевой игре в летней школе тестировщиков. А, чтобы такой ситуации не было, тестировщику надо знать, что нужно Заказчику. Какие у него возникают вопросы и пожелания. Как он пользуется системой...

В общем, сплошные плюсы. Назначаем тестировщика ответственным за customer@support и радуемся жизни. У менеджеров появляется время на более важные дела, а тестировщики держат руку на пульсе.

Казалось бы, все хорошо? НО! Подумайте сами о минусах такой почты...

1. Как обрабатывается заявка? Чтобы она не потерялась "где-то в почте у коллег", создается task в баг-трекере. В который аттачатся письма, в котором идет обсуждение, что ответить, что сделать итд.

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

2. А если тестировщик забыл приаатачить письмо? Дел много, главное - ответил, остальное ерунда. По прошествии времени сидит, смотрит на задачу - "блин, что-то же делал,а что?". Лезет в почту, ищет, аттачит... Время - деньги!

3. Тестировщик заболел / ушел в отпуск. Его Заказчика радостно передают другому. У этого другого информации - все, что в джире было. А ведь половины и не было (чтобы не раздувать комменты). Что делать? Куда бежать?

В общем, так подумаешь, подумаешь... И поймешь - надо Заказчиков в баг-трекер переводить!

Создать специальный тип задач - Support Request. И пусть пишут вопросы туда. А ответственные (читай - тестировщики) будут отвечать. Но одно дело - ответить на 2 строчки, а другое дело, переслать письмо, где эти самые две строчки окаймляют "Кто? Кому? Кто в копии? Тема письма", а также подписи.

Всем хорошо! Все плюшки подхода остались, а минусы решились! Добавилась информативность - теперь вы всегда в курсе, что происходит на проекте, даже если не входите в почту его support-a. И легко можете заменить коллегу.

Но! Опять это "но", будь оно неладно.

Ребята! Подумайте заранее. Ну если у вас уже есть такая почта. И в джире (возьмем как пример баг-трекера) уже есть куча тасков, созданных по этим письмам. Подумайте заранее о возможном переходе Заказчика в джиру!

А если не подумать? Зачем Заказчику вообще этот переход? Все за тем же - чтобы можно было следить, решают ли твои проблемы, чтобы можно было ссылаться на "а вот в этом письме (в этой задаче) мы говорили о том, что...", чтобы можно было отслеживать ход работ, в конце концов.

Так вот. Все Заказчику видеть явно не надо. Только свой проект и только такие запросы. Но старые запросы ему видеть интересно. А иначе какой смысл? Часть переписки - в джире, а часть - в почте.

Итак! Добавили права, открывать доступ к багам. В принципе, в той же джире это сделать несложно. Казалось бы. Особенно, если в заголовке задачи честные тестировщики указывали магические буковки "CR", ну или что-то похожее, чтобы можно было найти махом все задачи с приаттаченными письмами. В той же джире можно выделить все эти таски и парой щелчкой мышки поменять им уровень доступа.

Ура? Агащаз. Сначала багу открой и почитай комменты.
А что мы пишем в комментах?

"Хихи, наконец-то они поняли, что это неудобно"
"Да вы что? Это нереализуемо! Нафик всех!"
"Ма-а-а-а-аш, посмотри, плиз, тут можно что-то сделать?"
"По-моему, они нас динамят..."
...

Ну и всякие мелочи аля "Закрывающему потестить то-то" или "пофиксил тут-то", которые Заказчику, опять же, не нужны.

Так вот. Вместо того, чтобы потом отслеживать все эти комменты и выставлять на них ограничения (видят только коллеги), подумайте об этом заранее. И в тасках, в которые аттачите переписку с Заказчиком, весь флуд сразу ограничивайте на видимость. На всякий случай. На будущее. Пригодится.

PS - Начитавшись Демарко, вдохновившись мистером Томпсоном, я решила если не каждый день, то хоть иногда находить умные и/или полезные идеи в течение рабочего дня и записывать их...

PPS - А пряча в джире флуд 6 часов подряд, я не могла промолчать...