О правке бага вендором

Более трёх лет назад у меня появилась операционная система Windows 10, одним из элементов которой является текстовый редактор Notepad (в простонародье - Блокнот). Поскольку скорость его открытия для создания новых документов (логи при сбое проги, мелкие сообщения без надобности форматирования) очень нравилась мне для регулярной работы - тестирования ПО, то меня сильно огорчил баг в Блокноте Win10. Окно редактора не закрывалось, если новый документ сохранялся по нажатию крестика в верхнем правом углу. Меня сильно раздражало обязательное двухступенчатое закрытие окна, поскольку это удлиняло мои действия и крало столь полезные рабочие минуты.
И, о чудо! Спустя три года моих жалоб в разные инстанции, наконец-то функционал вернулся к привычному и удобному. Теперь не надо отдельно сохранять новый файл и отдельно закрывать окно редактора.
Спасибо, конечно, инженерам по качеству Microsoft, но срок избавления от бага таким крупным вендором никак его не красит. QA и техподдержка более рядовых компаний работают намного быстрее, и в этом плане нам не стоит брать пример с подобного монополиста.

Размышлизмы

Многие великие писатели приходят к одной мысли: "Живи так, как хочется тебе здесь и сейчас, а не по велению других. Только тогда почувствуешь счастье. А иначе, будешь лишь существовать." (читай "Чёрный монах" А.П. Чехова, "На дне" М. Горького).
Другие же сами хотят себе счастья, потому и требуют от тебя своего желаемого.
Вот взять, например, советчика. Кого вы себе предпочтёте: старшего брата (СБ), младшую сестру (МС) или собственный ум (СУ)?
СБ
Если у вас возник сложный жизненный вопрос, и вы обращаетесь к старшему брату с просьбой его разрешить, то СБ, обладающий большими жизненными знаниями и опытом станет предлагать вам такие решения, которые потребуют значительных разъяснений. В этом случае вы будете лишь слушателем, учеником, вынужденным принимать чужую точку зрения. А поскольку СБ придётся много аргументировать, то вы заметите своё низкое положение молчаливого незнайки. Говорить будет в основном СБ, а значит ваша потребность в представлении себя миру будет отвергаться. Тем самым ваша самооценка будет снижаться. Если же в конце концов дело разрешиться благополучно, то ваше самомнение повысится только в вашем собственном мирке, хоть и будут в голове бродить мысли: "Правильную идею подсказал СБ. Я - молодец, что её осуществил(а).". Но если ситуация усугубилась от советов СБ, то вам легко и просто скинуть вину  на СБ. Только тогда ваши отношения с СБ вряд ли станут ещё теплее и доверчивее. Обелив себя, потеряете наставника, который может быть в другой раз окажется более прав.
МС
Когда же в качестве свободных ушей вы используете МС, то однозначно ваше самомнение зашкаливает. Вы обеспечите себе  один из пунктов счастья - рассказ о себе любимом кому-то. Да, МС будет внимать все ваши сказки с открытым ртом. Но вот совет от неё вы врядли получите толковый. Может она и выберет что-то, но наугад, без толковых аргументов. И опять в результате негативного исхода дела вы сможете обвинить МС, а не себя. А за положительное разрешение жизненной ситуации будете гордиться лишь собой. Ведь оба варианта были предложены самостоятельно, а МС послужила по-сути лишь жребием. Укрепит ли такой случай семейные узы? Сомневаюсь. Ваше мнение о себе любимом останется при вас и даже может возрастёт, а любовь к ближним врядли увеличится.
СУ
Частично в обоих вариантах уже была затронута золотая середина - разбирать условия и искать выход, опираясь лишь на собственные знания. Да, только в вашей одной голове умещается вся информация о ситуации, требующей решения. И только вы знаете, чего желаете от всего имеющегося положения дел. Рассматривая задачу сам на сам вы обязательно найдёте единственный верный путь, за который никого не будете винить. А значит ваше мнение об окружающих не ухудшится. О, да - самомнение зашкалит! Но разве не это и есть счастье осознания себя в мире? Только с собой вы можете быть откровенно честным и правдивым, ведь никто не узнает вашей тайны. А точное взвешивание положительного и отрицательного исходов дела, желаемого и ненавистного разрешений ситуации однозначно покажет вам узкие места, где приложив усилия вы развернёте ход в нужную вам сторону.

Эпитет "одиночество" присущ тем, кто живёт по первому или второму варианту. А те, кто опирается на третий вариант, не страдают от одиночества, поскольку всегда считают себя "самостоятельными".
Самостоятельные люди не страдают от одиночества.

Контрасты

Универсальный актёр по щелчку может менять образ и настроение. Любому сотруднику группы разработки ПО важно умение держать себя в руках, особенно тестировщику во время обсуждений нужна принципиальность взглядов для отстаивания баговой стороны дела.
Предлагаю игрой "Контрасты" развивать и укреплять способности:
- умение держать себя в руках во время конфликта;
- отвечать спокойно на грубость;
- быстро менять положительные и отрицательные эмоции;
- адекватно воспринимать критику.
Игра проводится попарно или двумя группами.
Этап 1. Оппоненты встают друг против друга на расстоянии вытянутой руки. Глядя друг другу в глаза говорят 2-3 раза поочерёдно первый - "Милашка", второй - "Лапушка". Делают по шагу назад, расходятся. Повторяют 2-3 раза поочерёдно первый - "Милашка", второй - "Лапушка". Количество шагов ограничено стенами помещения. Энергетика положительных слов должна усиливаться с удалением игроков друг от друга.
Этап 2. Оппоненты встают друг против друга на самом большом расстоянии, у противоположных стен помещения. Глядя друг другу в глаза говорят 2-3 раза поочерёдно первый - "Грязь", второй - "Помои". Делают по шагу навстречу, сходятся. Повторяют 2-3 раза поочерёдно первый - "Грязь", второй - "Помои". Количество шагов ограничено стенами помещения, до минимального расстояния друг против друга в 50-70см (вытянутая рука). Энергетика отрицательных эмоций должна ослабевать с приближением игроков друг к другу.
Этап 3. Оппоненты встают друг против друга на самом большом расстоянии, у противоположных стен помещения. Глядя друг другу в глаза говорят по одному разу поочерёдно первый - "Грязь", второй - "Лапушка". Делают по шагу навстречу, сходятся. Повторяют по одному разу поочерёдно первый - "Грязь", второй - "Лапушка". Количество шагов ограничено стенами помещения, до минимального расстояния друг против друга в 50-70см (вытянутая рука). Энергетика отрицательной и положительной эмоций должна ослабевать с приближением игроков друг к другу.
Этап 4. Оппоненты встают друг против друга на расстоянии вытянутой руки. Глядя друг другу в глаза говорят по одному разу поочерёдно первый - "Милашка", второй - "Помои". Делают по шагу назад, расходятся. Повторяют по одному разу поочерёдно первый - "Милашка", второй - "Помои". Количество шагов ограничено стенами помещения. Энергетика отрицательной и положительной эмоций должна усиливаться с удалением игроков друг от друга.
Этапы 1 и 2 развивают энергетику эмоций, этапы 3 и 4 учат владеть собой и отвечать улыбкой на грубость.
Усложнить игру можно сменой эмоций по хлопку ведущего, рандомно. При этом не стоит менять расстояние между оппонентами.
Негативные слова "Грязь", "Помои" и положительные "Милашка", "Лапушка" можете заменить любыми другими, но ассоциации должны соответствовать эмоциям.
Завершение игры должно быть на позитивной волне для обеих сторон.
Актёры используют подобное упражнение на тренингах. А когда и где играть сотрудникам группы разработки? Времени на исполнение вполне достаточно пока заваривается чай или смешивается капучино. Так что смело ходите парами в буфет и заражайте своим оптимизмом там сотрудников соседних отделов.

Балловая связь

Чиновники для народа

Общественность постоянно сетует на работу чиновников: и не слышат они народ, и взятки берут. Уж и законы об обращениях граждан на них насылали, и штрафы взяточникам взвинтили, а они всё равно рвутся занять должность "слуги народа", чтобы жить по-царски. А может сами подчинённые и избиратели виноваты в том, что продвигаются не те проекты, которые нужны? Как повысить активность граждан? А может подношения вышестоящие воспринимают как необходимую благодарность, которую не получают после окончания дела? Как воспитать всех отзывчивыми? Почему же власть портит людей? Даже мелкую сошку, бригадира или начальника подотдела не узнать через несколько месяцев верховенства. Может они всё время ждут благодарности за свой труд и грустят от неблагодарности "свиты"? Или гордыня затмеваем им основную идею лидерства - вести за собой и опекать подчинённых от неприятностей? А ведь даже родители взращивают своих детей, чтобы в старости было кому поднести стакан воды. Значит и руководитель всегда ждёт своей доли благодарности, и не в виде зарплаты, а чисто по-человечески.
Можете ли вы представить себе, что цифровая экономика и демократия способны воспитывать общество в целом и каждого в частности? При этом можно искоренить кумовство и взяточничество, снизив до нуля человеческий фактор ошибок. И решается проблема довольно просто: небольшое дополнение к закону об обращениях граждан и введение автоматической аттестации для всех уровней руководящего состава.
Техническая реализация заключается в следующем. Дополняем закон об обращениях граждан обязательным завершающим пунктом для выставления отметки об исполнении запроса обратившегося. Для этого предварительно дублируем (переводим) весь оборот обращений и ответов в электронный вид. К сожалению, на этом этапе нет полной автоматизации, так как кроме электронных писем и специализированных форм обратной связи на сайтах существуют очные письменные и устные способы общения, телефонные звонки и смс, посты в соц.сетях и публикации в СМИ.  Но любой разговор всегда можно записать и оцифровать, а бумажные формы отсканировать в цифровой вид. Поэтому будем считать, что все входящие реально регистрировать в электронной базе. Объём обращений можно лимитировать, автоматически рассчитывая пропорцию рабочего времени руководителя и количества подопечных. Например, при 40-часовой рабочей неделе и минимуме в 15 минут на визит мэр города с 5 тысячами полноправных жителей сможет максимально обработать около полутора (4*40*52/5000=1,664) обращений в год от каждого, но не более 8320 (=4*40*52, где 4 - количество обращений в час, 40 рабочих часов в неделе, 52 недели в году без отпуска) всего в год. Соблюдать уникальность обращений и их инициаторов объективно может только электронная база данных. Она же станет и беспристрастным оценщиком исполнительности. Обязав заявителей отправлять электронно отзыв о выполненности или отказе, можно собирать статистику по каждому начальнику и автоматически выставлять им рейтинг. Эта же система самостоятельно будет контролировать исполнение. Например, гражданин подал срочную заявку, которую зарегистрировали в базе (присвоили уникальный идентификатор, завели данные гражданина - паспортные и телефон, суть обращения, дату обращения и высчитан крайний срок исполнения). Если исполнитель уложился в срок, то система отправляет заявителю СМС (исполнена ли заявка, удовлетворены ли ответом/отказом) с обязательным ответом (0 - нет, 1 - да), или автоматическое электронное письмо, или телеграмму обычной почтой. Если исполнитель не уложился в срок, то система автоматически добавит заявку в отрицательный список рейтинга начальника. Если исполнитель всё исполнил, но заявитель не удовлетворён исходом дела, то отвечает "0" и он влияет на негативный рейтинг начальника. Если дело исполнено благополучно, то заявитель улучшает рейтинг начальника. На этом этапе сами исполнители будут бегать за заявителями с просьбой положительного отзыва. И здесь заявителю придётся проявить собственную гражданскую ответственность и объективность. Такой переворот отношений между заявителем и исполнителем поднимет активность граждан, наладит диалог, будет воспитывать отзывчивость, сблизит общение чиновников и общества, приучит говорить "спасибо" даже столь неприятным до селе чиновникам. Поскольку рейтинг конкретного исполнителя будет зависеть от каждого обращения, то чиновники реже станут перенаправлять заявки на иные инстанции и реализовывать собственными силами в положеный срок. Но поскольку менталитет у всех таков, что "не подмажешь, не поедешь", то вполне возможно исполнители начнут предлагать взятки заявителям за положительные отзывы. Поэтому наказания взяточников неизбежны, если каждый гражданин не перестанет контролировать самого себя, хотя подачки поменяют размер и направление. Таким образом чиновника по факту превратятся в слуг народа.
Современные технологи позволяют разделить базы заявок и отзывов, а агрегированные данные вполне можно опубликовывать. Процент выполненных заявок можно раскрасить их объёмом, как это подсчитывается в спорте (кмс, чемпион, чёрный пояс и т.д.), взяв процент от максимального объёма. И в этом случае объективность будет соблюдена за счёт лимита уникальных обращений от каждого заявителя.
Рейтинг руководителей, опубликованный в общем доступе, регулярно и независимо обновляемый, станет не только мерилом ответственности, но и гарантом доверия. Результаты ежечасной работы сложатся в профиль кандидата на вышестоящий пост, либо вовремя покажут причину снятия с должности или необходимость дотаций, внешней помощи.
Аналогичную систему предлагаю и для аттестации руководителей всех уровней. Очень много в стране компаний, на руководящие должности в которых поставлены работники без знаний КЗоТ или с недостатком навыков управления персоналом. В советские времена профсоюзы повышали такой уровень в спец.школах и на курсах. Но сейчас организациям приходится тратить собственные средства на обучение. И поскольку это дорого, то компании экономят на развитии трудовых ресурсов. Если же руководителей всех уровней можно было бы сертифицировать и регулярно аттестовывать, то такой контроль заставил бы начальников знать законы и уметь применять техники руководства. Аттестацию вполне логично возложить на комиссии по трудовым спорам и центры занятости населения. Комиссии по трудовым спорам могут составлять независимые рейтинги на основе обращений работников, количестве увольнений и предотвращённых сокращений штата. А центры занятости могут проводить экзамены на знание КЗоТ и умение применять техники управления персоналом. Сертификацию руководителей можно сравнить с техосмотром автомобилей - отсутствие грозит штрафами, а наличие гарантирует спокойствие подчинённых. Если в этой системе обращения работников в комиссии по трудовым спорам будут бесплатны, а расходы на рассмотрение споров будут оплачивать начальники, то задержки зарплат, сокращение штата и беспричинные увольнения уйдут в небытие. А значит у центров занятости уменьшится объём работ по подбору вакансий и это время распределится на аттестации, организацию курсов. Главным плюсом сертификатов воспользуются кандидаты на замещение вакансий.

Offside outsourcer

Бесправие голосового найма

(примеры обходных схем)

Банк заключает договор с клиринговой компанией. Компания нанимает уборщиц, работающих в банке. Договор об оказании услуг подписывается между банком и компанией. Банк переводит деньги в компанию. Компания выдаёт зарплату уборщице.
Если объём работ увеличивается банком без согласования с управляющей компанией, то возмущения уборщицы банк и компания воспринимают за отказ от работ и прекращают всю оплату. Слабое звено описанной цепи отношений - компания, не соблюдающая КЗоТ и составляющая договор с банком так, что виновной всегда оказывается уборщица. Для решения таких спорных случаев необходимо обращаться в коммисию по трудовым спорам, поскольку у мелких компаний нет юристов и профсоюзов.

 
Строительная компания нанимает инженера и строителей. Для заключения договора с домовладельцем компания действует при помощи инженера, получая деньги напрямую от домовладельца, а объём работ через инженера. Часть полученных денег от домовладельца уходит на зарплату инженера. Компания с домовладельцем обменивается договором и оплатой. Объём работ строителям поставляет компания выдержкой из условий договора, оплату работ строителям производит компания после исполнения договора. Строители поставляют домовладельцу работу, а домовладелец предварительно оговаривал с инженером объём работ.
В случае дополнительных работ домовладелец оплачивает их обходя контракт. Если работы затрагивают качество общих работ, то при их сдаче возможен конфликт от якобы неисполнительности строителей или непродуманности сметы инженером. Деньги строителям в конверте не облагаются налогом - работники (и компания в том числе) теряют доход. Домовладелец, доказавший по контракту урон от выполненных работ, может потребовать возмещения убытков за счёт компании. Если штраф выплачивается из кармана строителей, то им следовало застраховаться от подобных ситуаций поддержкой инженера. Но он не работает напрямую со строителями, и им некуда жаловаться: подписанный контракт, имеющий силу у юристов, существует только с компанией. Устные запросы домовладельца трактуются как самоуправство строителей.
В описанной ситуации строители взяли на себя исполнение, но не оформили условия письменно. Поэтому и отвечать за риск пришлось им же.

 
Рассмотрим распределённую команду, состоящую из владельца продукта, управляющего производством и разработчиков в офисе с частичным официальным оформленнием. В таком случае компанию обычно регистрируют где-нибудь в офшоре. Владелец нанимает офис и мелкую компанию для размещения аппаратуры и даже офицально оформляет на минимальный оклад разработчиков. В офшорную компанию нанимает управленца, которому заказывает продукт. Устный договор о подчинении разработчиков управленцу оплачивается клнвертами  через управленца.
В случае превышения полномочий управленцем (овертайм без доп.оплаты, замашки рабовладельца, крик и унижение) у разработчиков нет инстанции для предъявления жалоб. Между владельцем и управленцем имеется двусторонняя связь (контракт-оплата), разработчик с управленцем связан устной договорённостью подчинения и получает б`ольшую часть оплаты нелегально. Но неподчинение управленцу для разработчика откликается увольнением из офицального офиса и проекта вообще. В коммисию по трудовым спорам разработчик не имеет права пожаловаться на управленца, так как управленец не является сотрудником официального офиса. Владельцу более важен управленец, нежели разработчики, которых за воротами полным полно желающих. При попытке усовестить управленца разработчик выкидывается из компании через владельца. Отсутствие договора на продукт в офисе вынуждает разработчика привлекать международную прокуратуру, которой мало-интересны мелкие компании. А в суде по делу унижения достоинства разработчику придётся представить доказательства, поэтому всё общение (переписка, аудио-видео записи) хранить стоит не менее трёх лет.

Uncorrectly correction

Практикум корректности

Есть ряд слов и фраз, употребление которых в описании багов, в том числе и исправленных, не уместно. Эти слова могут быть восприняты пользователем продукта двояко. Сегодня покажу на конкретных примерах неоднозначность слова "корректно".
Для тестирования возьмём Release Notes для продукта ClearSQL 7.1.2.181.

Пример 1

Окно "Select Code Review Rules to Suppress Violations" можно открыть из области редактора кода через одноимённый пункт контекстного меню. Оно является дочерним только для редактора кода, но модальным для основного окна приложения. С точки зрения usability возможность сдвига вспомогательного окна и последующее его переоткрытие на том же самом месте - это удобство и очевидное ожидание пользователя. Но с программистской стороны имеется просчёт - позиция и размер дочернего окна не зависит от координат родительского. Если пользователь работает на нескольких мониторах, то рабочее пространство продукта не ограничивается координатами основного окна приложения, что часто приводит к проблемам при открытии приложения после отключения одного из мониторов: окно фактически открывается, но не доступно в видимой области активных экранов.
В предыдущей версии окно переоткрывалось центрировано по активному монитору, а размер устанавливался ни последний пользовательский, ни минимальный стандартный (интерфейсные приложения компании Conquest Software Solutions разрабатываются в Delphi и используют настройки по-умолчанию в среде разработки от Embarcadero), к тому же уменьшение размеров окна не имело предела.
Ошибками тех-писателя, составлявшего Release Notes, считаются:
- отнесение данного пункта к модулю "Code Analyzer Options", поскольку окно "Select Code Review Rules to Suppress Violations" является самостоятельным и всего лишь клоном части окна "Code Analyzer Options";
- употребление слова "restart" вместо "reopening", поскольку имеется ввиду переоткрытие окна, а не перезапуск приложения.
Таким образом пользователь остаётся в недоумении о "корректности" правки:
- впервые появившись в продукте окно открывалось каждый раз центрировано по основному окну приложения, поэтому новое позиционирование по координатам монитора может исказить ожидания пользователя;
- впервые появившись в продукте окно открывалось каждый раз одного и того же размера, установленного программистом, поэтому восстановление "пользовательского" размера при каждом переоткрытии окна может быть воспринято и как удобство, и как неожиданность;
- не уточнённое "restart" относительно переоткрытия окна или приложения вводит в заблуждение пользователя.
Если программист не счёл нужным ориентироваться в разработке новой фичи на чит-лист, то это действительно баг. А если первоначальное поведение было задумано разработчиком, то подобный пункт в Release Notes стоит оформлять улучшением интерфейса, а не багом.

Пример 2
 
Сразу в трёх пунктах блока Call Tree диаграмм использовано слово "корректно". Но, как и в предыдущем примере, правильность исправлений не может быть единственно объективной как для заказчика, так и для исполнителя, поскольку продукты в Conquest Software Solutions разрабатываются по методу Research&Develop, а общепринятых стандартов для отображения Call Tree никто не вводил.
Экспорт диаграмм не изменился по сравнению с предыдущей версией продукта, кроме излишнего формирования map-файла. Но об этом имеется отдельный пункт в Release Notes. Так что пункт об имени экспортируемого файла можно считать очковтирательством в списке исправленных багов. Но не будем столь строго относится к некомпетентному тех-писателю, а попросим разработчиков уточнить исправления. Возможно, что-то было подправлено для особых типов объектов или только в одном из множества типов экспорта. Ещё возможный вариант правки - иной тип диаграмм, а тех-писатель опечатался в имени блока Release Notes. Либо правка на самом деле была в пред-предыдущей версии, а про баг написали только в этот раз.
Во втором и третьем пунктах говорится о Call Tree диаграммах, автоматически открываемых из CRUD матриц по клику на имена связанных объектов. Согласно чит-листу для тестирования новой фичи приоритетными параметрами статуса, размера и позиции окна считаются пользовательские. То есть наиболее ожидаемое поведение - это когда окно открывается на том же месте и того же размера, каким оно было закрыто в текущей сессии приложения и после перезапуска приложения. А центрирование дочернего окна основывается на координатах родительского. Поэтому, если фикс о центрировании актуален лишь в случае показа всех объектов на одной лишь закладке CRUD2, то фикс статуса окна легенд слишком сомнителен. Дело в том, что CRUD1 матрицы формируются в разрезе скрипта и для Call Tree диаграмм разворачивается дополнительная панель, а не модальное окно. При этом о центрировании панели не может быть и речи, а легенда диаграммы Call Tree скорее всего переформировывается из-за включенной опции "Preferences / Project Analysis / Keep diagram/matrix local settings".

Пример 3
 
В предыдущих выпусках копирование диаграмм в память вообще не происходило, если Flowchart или Call Tree были сформированы в формате GIF. Поэтому приписка "correctly" в данном случае просто излишняя, ведь никаких стандартов по копированию картинок в память у ConquestSS нет, а дополнительные индикаторы операционной системы и оперативной памяти в приложение не встроены. 

Пример 4
 
В блоке Отчёта Проекта нашлось сразу два пункта с запрещённым словом.
Для подтверждения, а вернее доказательства от противного первого пункта сформируем проект с диаграммами в предыдущем билде и текущем. На основе диаграмм всех форматов сформируем отчёты аналогичных проектов в обеих версиях. Проверяя кликабельность из диаграмм в код в рамках отчётов, получаем возможность позиционирования кода из GIF, JPEG, PNG диаграмм в текст кода в рамках проекта из предыдущей версии продукта. А в текущей версии позиционирование перестало выполняться для перечисленных форматов, но стало благополучно выполняться для SVG формата. Так сказать "за уши притянуть" корректность к описанной правке фактически невозможно. Поэтому употребление недопустимого слова не только искажает смысл, а просто напросто противоречит элементарной логике как пользователя, так и разработчика.
Для второго пункта аналогично генерим отчёты, выбирая одинаковые параметры фильтров и группировки для данных на Summary страницах отчётов. Отметим, что параметры касаются только двух таблиц на Summary страницах отчёта всех уровней (проект/папка/скрипт). После сравнения отчётов получается, что раньше данные в таблице "Top Violated Code Review Rules" фильтровались по условию из интерфейса закладки "Project Analyzer Results / Summary", а в новой версии приложения группировка применяется из настроек Project Report Assistant, но никаких пометок в самом отчёте о применённой группировке нет. Так в чём же "корректность" правки? С таблицей "Code Metrics" дела обстоят немного лучше, так как в заголовке таблицы и ранее имелась информация о фактически применённых группировке и фильтрации. Но о корректности правки стоило говорить намного раньше, когда переименовали опцию "Project Report Assistant / New Report / Summary Options / Panels Size and Position / As in the Analyzer View Summary Page". Стоит напомнить, что группировка и фильтрация двух таблиц устанавливаются в трёх-пяти местах - в уже упомянутом окне Project Report Assistant и его аналоге для Job and Schedule Manager, на закладке "Project Analyzer Results / Summary" и дублируются в Preferences, на "Preferences (Job) / Export" странице настроек для автоматического экспорта. Какие из этих настроек стоит считать эталонными, какова территория их применения и отображения - ответы  на перечисленные вопросы не очевидны и их невозможно найти в Online Help продукта. Значит очередной пример подтверждает запрет на использование слова "correctly" в описании фиксов.

Пример 5
 
Хотя в примере и видны два пункта, но на самом деле они об одном и том же. Пользователю заметно лишь изменение в подсчёте объёма отчёта, но не одного файла, как это сказано, а всех составляющих html-документ. Вероятно программист изменил структуру хранения информации об отчётах, а тех-писатель не смог пояснить внутренних процессов. На самом деле вместо приписывания одного слова "correctly" необходимо было перефразировать баг в улучшение или хотя бы переименовать file в document для большей правдивости. Отсутствие достаточной коммуникации между тех-писателем и разработчиками, низкая квалификация и нежелание повышать уровень знаний замещаются шаблонной отпиской, которая оборачивается для пользователя непониманием и последующим недоверием к поставщику продукта.

Пример 6
 
Обновление дерева файловой системы после импорта визуально ничем не изменилось в новой версии. Возможно что-то было оптимизировано в алгоритме или коде. И чтобы скрыть отсутствие обмена информацией в команде разработки тех-писатель вынужден заполнять свои пробелы в знаниях пустословием.

Пример 7
 
Визуально фикс заключается в стабилизации позиционирования на скриптах в дереве проекта. Неумение выразить техническое изменение доступным для пользователя языком - это прямое несоответствие занимаемой должности тех-писателем. А в итоге страдает конечный пользователь, который перестаёт доверять компании, фальсифицирующей правки.

Пример 8
 
Элементарный smoke-test не может показать произведённых изменений. Поэтому можно заключить, что фикс касается некоторого частного случая, для описания которого у специалистов не хватило профессионализма. В результате пользователь вполне имеет право считать, что никакого исправления не было.

Пример 9
 
Данный случай вполне обошёлся бы просто без слова "correctly". Поскольку активация окна не подразумевает вариаций. Или же разработчики компании Conquest Software Solutions ввели стандарт активации окна без предупреждений или подтверждений? Не очень похоже на них, так как в ClearSQL и других их продуктах очень много мест с излишними подтверждениями. Так почему же по их меркам в этом случае смена рабочей области происходит автоматически и без пользовательского согласия?

Пример 10
 
В этом примере к одному запрещённому слову добавили ещё и always, забыв постулат тестировщиков о порождении двух новых багов на основе одного фикса. Но это не удивительно, поскольку шеф группы разработки любит добавлять к описанию задачи фразу "исправить везде". Это следствие неумения и нежелания применять декомпозицию и конкретизировать планирование.
По существу правки. Можно ли считать правильным обрезание имени подпрограммы? В предыдущем билде имелась приставка из имени объектного типа, которая позволяла не теряться в списке подпрограмм таблицы Code Metrics, особенно на закладке Summary. Но половинчато всё же фикс был - overloaded подпрограммы теперь показываются с цифровым индексом, но без перечисления параметров. В чём корректность правки? Вопрос весьма не риторический.

Надеюсь, вышеописанные исследования доказали неуместность использования слова "correctly" в описании исправленных багов.