ГКЧП - Где, Как, Что Править?

Команда разрабатывает несколько десктопных продуктов с некоторыми едиными модулями, какие-то продукты являются как самостоятельными, так и частью других, собственный сайт для поддержки продуктов как самостоятельный продукт тоже имеет тесные связки с десктопными.
Самописная система ведения задач была удобна, но недостаточна для распределённой команды. Поэтому был выполнен переход на Jira. Каждому продукту было присвоено своё имя в BTS (Bug Tracking System), а несколько глобальных модулей (код исправляется в одном скрипте, а при компиляции каждого продукта исправления автоматически попадают в билды) были перенесены из старой BTS в новую в продукт Global Modules, также задачи по сайту были импортированы в отдельный продукт Jira.
В старой BTS возможно было использовать единый список версий продуктов, а для закрытия багов приписали небольшой интерфейс. В Jira, к сожалению, нет возможности использовать сквозной список версий продуктов, поэтому в продукте Global Modules приходится создавать дубликаты номеров билдов по каждому скомпилированному продукту (но этот утомительный ручной труд был автоматизирован спустя 3 года мучений).
Пока команда состояла из 7 программистов и одного тестировщика, то проблем с описанием и пониманием задач не случалось. Когда же команда разработчиков сменилась на 70% и вдвое увеличилась, то появилась необходимость расшифровывать устоявшиеся понятия и правила. А чтобы не тратить на каждую задачу драгоценное время старожил, создавались документы с описанием корпоративных правил. Для более быстрого и эффективного запоминания всех сложностей, придуманных PM, мной была предложена мнемоника.

ГКЧП
или Как Правильно Читать баГ/импрув?
Где, Как, Что Править?

ГДЕ
* Определяем продукты, в которых надо фиксить. Это видно из номера:
     Prod_1-[issuenumber] - только в Product_1;
     Prod_2-[issuenumber] - в Product_2 и может быть в Product_3;
     Prod_3-[issuenumber] - в Product_3 и скорее всего в Product_2;
     GM-[issuenumber] - в Product_1, Product_2, Product_3 и может быть на сайте;
     WEB-[issuenumber] - на сайте и может в Product_1, Product_2, Product_3
* Определяем модуль или функционал, как часть продукта. Это видно из поля Component.
* Определяем список версий, в которых нужно внести исправления. Для этого на сайте смотрим номер текущей версии (Support -> Release History -> [ProductName]) и сравниваем его с номером билда, в котором выявлен баг/импрув. Это видно по значению поля Affect Versions. Если баг/импрув из числа GM, то номер Affects Versions префиксован кратким наименованием продукта. Если номер версии совпадает с точностью до релиза, то правку вносим только в текущие поддерживаемую и разрабатываемую. Если версия отлична по Мажору/Минору, то сверяемся в поле Label по наличию значений FIX_IN_PREV_VER и/или FIX_IN_OFFICIAL_VER.
* О том, нужен ли фикс в предыдущей версии или в будущей-разрабатываемой версии говорит поле Label со значениями FIX_IN_PREV_VER и/или FIX_IN_OFFICIAL_VER.

ЧТО
* Определяем объём работ по совокупности значений полей Summary, Description, Attachments. Обычно структура Description нижеследующая:
     [Шаг / Модуль]
     [Пункт / Страница]
     [Что не так?]
     [При каких условиях?]
     Как должно быть?]
         example:
         [Шаги примера]
* Пояснительный скриншот или лог бага, или длинный пример хранится в поле Attachments (атач).
* У кого уточнить детали бага/импрува видно из полей BUG_HUNTER или Reporter.

ПРАВИТЬ/ПРОВЕРЯТЬ
* Если фикс был возвращен на доработку, то в поле Comments имеется причина.
* Проверять фикс надо как с default настройками, так и с описанными в Description или Environment.