У нас есть множество руководств, и иногда @dax или @jomaxro делятся руководством howto, о котором я даже не знал, и я в восторге!
Я также заметил, что это актуально для многих новых пользователей и администраторов сообществ на Discourse здесь, на Meta. Поэтому, чтобы решить эту проблему, @justin придумал отличную идею: сгруппировать наши руководства howto и дать всем более удобную отправную точку, чтобы в итоге получить что-то похожее на https://support.teams.discourse.com/docs
Ха-ха, да, их действительно много! В идеале, если бы нам удалось разместить от 6 до 12 инструкций в каждой категории, это было бы замечательно. Мы не планируем категоризировать все, а только самые лучшие, которые могут искать пользователи.
@osioke — один из способов подойти к этому — найти самые просматриваемые инструкции, связанные с этими категориями, и выбрать топ-6–12 по просмотрам, чтобы добавить им соответствующие теги. Это будет отличным началом, особенно в сочетании с предложениями @Benjamin_D!
Прелесть тегов в том, что мы можем легко редактировать их по ходу дела.
Спасибо, что поделились этим, @Benjamin_D! Одной из проблем, с которой я сталкивался, было то, как представить и как мыслить в отношении структуры; ваша таблица здесь очень помогла.
Сейчас я планирую расширить группировку с 3 до 6 разделов:
Начало работы
Настройка
Продвинутая настройка
Участие в разработке
Конфигурация
Продвинутая конфигурация
И, как отметил @justin, глядя на самые просматриваемые темы, я выбрал первые 20:
Хм, статьи по настройке входа, вероятно, могли бы составлять отдельную категорию. Это подраздел раздела «Начало работы», так как это одно из первых действий, которые вы хотите выполнить на новом сайте, если вообще планируете это делать.
Не уверен, что здесь нужно упоминать multisite , или, возможно, группу продвинутой конфигурации стоит дополнить предупреждением, поиск по мета! Например, этот пост очень полезен pros-and-cons-of-a-multisite-installation.
Да-да, список основан на топ-20 самых просматриваемых, и я поделился им, чтобы показать ход своих мыслей относительно структуры. Это никоим образом не окончательный список, мне следовало быть немного понятнее
Хотелось бы видеть категорию «Администрирование» или «Эксплуатация» для текущих административных и модераторских задач. Она не вписывается в разделы настройки/конфигурации и не относится к разработке/документации (вклад в развитие).
Я предполагаю, что документация Discourse for Teams использует сам Discourse для всех материалов. Проблема такого подхода для сайта с инструкциями по Discourse, где может участвовать любой член сообщества, — это версионирование и отслеживание всех изменений. Я уверен, что использование Discourse для этой цели было бы предпочтительным методом, но могу ли я предложить, возможно, сайт на Hugo или сайт на Jekyll, где документы будут файлами в GitHub, к которым любой может отправить pull request. Если ни один из этих вариантов вам не подходит, существует множество других систем документации для репозиториев GitHub, представленных в самых разных вариантах.
О, версионирование в Discourse работает довольно хорошо, даже очень хорошо. А если добавить к этому контроль доступа к категориям, получится то, чем мы гордимся и что используем
Кстати, я постепенно занимаюсь очисткой раздела #howto:sysadmin, проверяю, что каждая статья актуальна и релевантна, а затем перемещаю их в категорию auto-delete-posts-after. Похоже, большинство из них здесь уже классифицированы как advanced config.
Полностью согласен. Мультисайт — это сверхсверхпродвинутая конфигурация, и мы не особо поддерживаем её на Meta.
Да, именно так. Discourse + плагин Docs + некоторые дополнительные настройки. Использование Discourse — наш предпочтительный вариант, но я вижу преимущества использования вики или сайта на SSG.
Было бы отлично, если бы темы, по которым поддержка «ограничена», были вынесены в отдельную категорию с четкой маркировкой.
Похоже, сейчас существует убеждение, что если что-то написано здесь, то поддержка в той или иной форме положена.
Это также упрощает аргументацию в пользу того, чтобы пользователи тестировали решения перед обновлением, поскольку такие функции обычно более хрупкие или реже проходят всестороннее тестирование между выпусками.
Я думаю, что мультисайты в целом «поддерживаются», но предполагается, что если вы идёте по этому пути, вы понимаете, что от вас потребуется больше усилий (например, вам нужно подумать, что означает rebuild app в различных контекстах). Я бы сказал, что это «продвинуто», но не «супер-супер продвинуто».
Согласен, что третичные категории и подпапки — это «супер-супер продвинуто».
Возможно, я больше думаю о мультисайтах с Let’s Encrypt, которые на протяжении многих лет неоднократно ломались, а обновленная документация иногда появлялась лишь через недели или месяцы.
Ах, да. Я думаю, что сейчас это, вероятно, довольно стабильно (последнее изменение, как мне помнится, касалось обработки перенаправлений в nginx), и у меня есть статья Multisite Configuration with Let's Encrypt and no reverse proxy - Documentation - Literate Computing Support, которую я планирую опубликовать здесь «очень скоро» (я написал и в последний раз протестировал её 2 декабря 2020 года). Однако multisite — это определённо «вы в основном сами по себе». Я не думаю, что это имеет смысл, если у вас нет хотя бы 3 (возможно, 10?) сайтов, поскольку кажется, что большинство людей, которые думают, что хотят это, пытаются обойтись одним дроплетом на 1 ГБ.
Самым полезным для меня было бы, если бы вы не тратили больше усилий на структурирование категории (how-to) как таковой, а сосредоточились на улучшении структуры документации.
Я действительно ценю, что форум остается свободным и удобным для пользователей, чтобы они могли публиковать сообщения. Я считаю, что для этого критически важно иметь четкие категории верхнего уровня, чтобы пользователи размещали свои сообщения в нужной из них. Однако когда подкатегории становятся сложными, когда для пользователей важно публиковать сообщения именно в правильной подкатегории или знать, в какой подкатегории искать информацию, это, на мой взгляд, несколько нарушает удобство использования.
В настоящее время вы фактически просто дублируете структуру форума в документации:
Почему бы сотрудникам не использовать специальные теги, доступные только им, для курирования и структурирования документации, например, ‘docs-getting-started’, ‘docs-setup’, включая контент из любых разделов форума? Тогда вы могли бы создать страницу документации, которая была бы не просто зеркалом форума, а имела бы правильно отформатированное оглавление, например:
В этом и заключается идея, @manuel! Мы планируем создать способы удобной фильтрации по таким инструкциям, сохранив при этом фильтры, уже существующие в плагине Docs. Организация этих инструкций по конкретным тегам — это первый шаг.
, или, возможно, группу продвинутой конфигурации стоит дополнить предупреждением, поиск по мета! Например, этот пост очень полезен 
), а 
.
