Здравствуйте, спасибо за ваш комментарий - текст поправили.
Насчет вашего вопроса:
В методологии KCS это решается следующим образом:
Разграничением ролей. Опубликованную статью могут исправлять и перепубликовать только сотрудники с выделенной ролью Редактор. Все остальные могут только вносить предложения на исправление, которые редактор (а за статьей закреплен только один) может принимать или отклонять.
До того, как черновик статьи доходит до редактора он также проходит "проверку боем" - должен набрать определенное количество переиспользования в разных клиентских тикетах. Если это произошло, то статья проходит премодерирование технического решения и для оформления передается редактору.
Если все же в правках допустили ошибку на этапе черновика и надо вернуться назад, то тут сравнение и версионность решают проблему.
На этапах выше у каждого сотрудника еще и KPI присутствуют - для тех, кто добавляет или создает черновики - это оценка релевантности решения в статье и запросу в тикете - т.е. человек заинтересован , чтобы там билось все. Для редакторов - это оценка качества статьи, которая помимо актуальности решения уже и включает в себя аспекты оформления.
Еще есть правило , чтобы не миксовать схожие решения в "статьи-хабы" и поддерживать кейсовую чистоту статьи - например на разные симптомы может быть одно решение - и здесь будет две статьи.
Здравствуйте, спасибо за ваш комментарий - текст поправили.
Насчет вашего вопроса:
В методологии KCS это решается следующим образом:
Разграничением ролей. Опубликованную статью могут исправлять и перепубликовать только сотрудники с выделенной ролью Редактор. Все остальные могут только вносить предложения на исправление, которые редактор (а за статьей закреплен только один) может принимать или отклонять.
До того, как черновик статьи доходит до редактора он также проходит "проверку боем" - должен набрать определенное количество переиспользования в разных клиентских тикетах. Если это произошло, то статья проходит премодерирование технического решения и для оформления передается редактору.
Если все же в правках допустили ошибку на этапе черновика и надо вернуться назад, то тут сравнение и версионность решают проблему.
На этапах выше у каждого сотрудника еще и KPI присутствуют - для тех, кто добавляет или создает черновики - это оценка релевантности решения в статье и запросу в тикете - т.е. человек заинтересован , чтобы там билось все. Для редакторов - это оценка качества статьи, которая помимо актуальности решения уже и включает в себя аспекты оформления.
Еще есть правило , чтобы не миксовать схожие решения в "статьи-хабы" и поддерживать кейсовую чистоту статьи - например на разные симптомы может быть одно решение - и здесь будет две статьи.