Вот почему вы позволяете им подавать заявку. При необходимости доступ можно отозвать. Что касается доверия? Ну, это зависит от сообщества. ![]()
Что позволяет им подавать заявки? Не нужно мыслить старыми категориями. Все должны быть равны. Если кто-то замечает ошибку в тексте и решает её исправить, должен ли он подавать заявку? Я не знаю этого пользователя, я не хочу давать ему доступ ко всему контенту. И зачем? Обычная модерация решает все проблемы с качеством контента. Более того, при изменении контента с использованием Markdown у пользователя возникнут трудности по сравнению с обычным визуальным редактором — легко допустить ошибку. Никто не может гарантировать, что пользователи не допустят ошибок.
Это должно быть как на GitHub. Любой может предложить изменения, но не у всех есть полный доступ.
Если кто-то заметит ошибку, он может написать в группу, отвечающую за базу данных. Это снижает необходимость в строгой модерации базы знаний. Если кто-то хочет стать активным участником поддержки, он может это сделать; если нет, он может отправить изменение в группу, поддерживающую вики.
По моему опыту, никто не будет сообщать об ошибках. Это слишком много действий для обычного пользователя. Исправить или добавить контент довольно просто. Пользователь не хочет вступать в группы или становиться модератором, он просто хочет исправить или добавить контент. Он хочет сделать это один раз. Исходите из этой логики. Не все пользователи хотят быть активными участниками сообщества. Но они могут внести свой вклад. Я уже упоминал GitHub в качестве примера.
Тогда это проблема самого сообщества. Очень легко добавить кнопку или ссылку для «обычного пользователя», чтобы он мог предложить изменение к соответствующему посту или теме, а также вторую кнопку или ссылку, если этот пользователь хочет присоединиться к команде мейнтейнеров.
Суть в том, что если есть проблема с людьми, которые портят вашу базу знаний, и вы не хотите прибегать к жесткой модерации, то наличие группы мейнтейнеров, способных вносить изменения, имеет смысл. В идеальном мире не пришлось бы беспокоиться о недобросовестных людях, создающих ненужные проблемы. ![]()
![]()
![]()
На данный момент уведомление об редактировании отправляется владельцу темы, а также всем, кто следит за вики, при каждом изменении, поэтому, на мой взгляд, отслеживать изменения достаточно легко в зависимости от ваших настроек уведомлений.
Хотя лично я не против идеи отправлять правки в очередь на проверку или какую-либо групповую очередь на проверку перед публикацией. Не знаю, сколько времени займёт разработка такой функции?
Спасибо за понимание. Я создаю техническое сообщество, и никто не хочет, чтобы пользователи случайно писали какую-то ерунду. Самое главное, что характеризует любую базу знаний, — это точность информации. Это основа всего. В противном случае нет смысла это делать. Правильная модерация базы знаний так же важна, как и сам контент.
На самом деле, вам нужны общие правки. Потому что, если вы не знаете редактора заранее и не проводите премодерацию, а вики работает с постмодерацией, вам будет довольно трудно этого добиться:
Нет. Это совершенно другое.
Чем это отличается? Вы не хотите разрешать свободное редактирование, потому что не доверяете случайному посетителю, что он знает и может. Вот почему вы хотите использовать фактически ограниченные права на редактирование через предварительную модерацию. У вас есть требования к качеству и знаниям.
Вы называете это вики с утверждением материалов сотрудниками. И всё же это совместное редактирование для группы — и для этого у вас уже есть инструменты и настройки.
Вы исказили мои слова. Я хочу, чтобы каждый мог редактировать базу знаний, включая как обычных, так и случайных пользователей. Для этого достаточно одного функционала: одна функция — принять или отклонить изменения. Этого хватит.
На практике, как бы выглядело состояние очереди, если бы ожидалось более одного редактирования? В данный момент редактирование сохраняется в момент времени, и вики готова к тому, чтобы следующий человек мог внести свои правки (и если два человека пытаются редактировать одновременно, вы видите сообщение «x набирает текст» и некоторые предупреждения при сохранении, насколько я помню). Пришлось бы блокировать вики до тех пор, пока одно из правок не будет одобрено или отклонено?
Это не так. Вы сами это написали.
Вам не нравится ответ, потому что вы решили, что он должен пройти через вики. Это совершенно другая ситуация, чем искажение.
Поскольку это мета-обсуждение вики, я в целом против более строгой премодерации, так как уже есть подходящие инструменты. Если вики не следует общим правилам, то это должно быть исправлено, если это возможно. Вики — это просто ещё одна тема. Но для вики не нужны более строгие инструменты модерации, чем для других тем.
Идея вики не сводится к ограничению прав на редактирование. Она должна быть открытой для всех, но без «дикого запада», поэтому базовый контроль необходим. И он уже есть.
Я думаю, вы, возможно, неправильно поняли. Он действительно поддерживает пост-модерацию Free-4-All.
Простая истина: Discourse Meta поддерживает оба метода, и каждое сообщество должно решить, какой метод подходит лучше всего. Будь то пост-модерация после исправлений или превентивный процесс утверждения заявок с использованием прав группы и опций безопасности категорий для выделенных категорий базы знаний вики.
Оба метода работают отлично, и, согласно открытой кастомизации Discourse Meta, это выполнимо.
База знаний и открытые обсуждения — это совершенно разные вещи. В базе знаний на первом месте стоит точность информации, а в обсуждениях можно писать что угодно.
По сути, за этим должна стоять какая-то форма ветвления версий, слияния и т. д. Альтернатива, как вы верно заметили, — блокировка, что действительно нежелательно.
Может ли быть реализовано иначе: редактируемая версия отправляется автору в личные сообщения (ЛС), и именно автор решает, принять или отклонить правку? Процесс мог бы выглядеть так:
- Я редактирую вики.
- Нажимаю «Отправить».
- Владелец получает в ЛС новую версию вики.
- Владелец может принять новую версию — в этом случае оригинал заменяется версией из ЛС.
Владелец также может ответить на заявку в ЛС, предложить изменения или полностью отклонить её. Пользователь по-прежнему может изменить свою заявку, отредактировав ЛС — это остаётся своего рода «ветвью» и «сливается» только тогда, когда первоначальный автор принимает её. После принятия ЛС архивируется (возможно, также конвертируется в какой-то более прозрачный формат?)
Я заметил, что пользователи Invision с 2015 года также просят разработчиков добавить аналогичный функционал. Таким образом, эта проблема касается не только пользователей Discourse.
https://invisioncommunity.com/forums/topic/423493-wiki-like-editing-is-useless-at-this-moment/?tab=comments
Поднимаю эту тему. @SystemZ, думаю, это важная функция для лучшей поддержки гибридной структуры, сочетающей сообщество и вики. Также готов внести вклад в код, чтобы довести это до реализации.
Я использую Discourse в качестве основы для сообщества, посвящённого изучению языков. У нас есть раздел статей, куда участники могут вносить свой вклад, однако даже учащиеся среднего уровня иногда излишне уверены в оценке своих навыков и в итоге распространяют недостоверную информацию.
Подобная функция была бы невероятно полезна: она позволила бы нам демократизировать процесс редактирования вики-контента на нашем сайте, одновременно обеспечивая точность информации. Кроме того, это предотвратит возможное некорректное использование функции редактирования.
Если бы я был богатым человеком с загородным домом, то отправлял бы Discourse взятки за внедрение этой функции. К сожалению, я просто случайный человек в случайном месте. ![]()
Я тоже считаю, что это может быть хорошей функцией. Мы перенесли нашу документацию с Docusaurus на Discourse, и там мы использовали git для контроля версий и утверждения изменений. Сейчас мы не хотим, чтобы каждый мог редактировать первый пост. Но для утверждения мы, модераторы, хотим проверять правки, которые делают писатели (пользовательская группа).
В данный момент я просто доверяю писателям публиковать свои изменения, а позже проверяю уведомления об «изменениях», которые я получаю по этой теме.
