В этом и заключается проблема документации Discourse.
Хотя для некоторых может быть «нормально» искать темы, это не документация. Это заставляет пользователей, а что ещё хуже, администраторов и модераторов искать информацию.
Нет, это не так. И это было, и остаётся, самым большим упущением Discourse. Не знаю, слишком ли я груб сейчас или что-то в этом роде, но тенденция здесь слишком ориентирована на разработчиков — если вы не знаете, вы всегда можете прочитать исходный код на GitHub. У CDCK не было большой мотивации начинать создавать хорошую документацию для пользователей — включая администраторов, конечно, — потому что их целевая аудитория — крупные корпорации, использующие хостинг. Поэтому для них было достаточно минимального уровня плюс помощь сообщества для тех, кто пользуется услугами бесплатно (а ведь именно они составляют значительную часть в поиске ошибок и предложениях по UX ;)). Если бы не это, нам бы потребовалось более свободное использование тегов…
Было достаточно — это не просто опечатка или низкий уровень владения английским. Команда CDCK начала создавать более качественную документацию, и я абсолютно уверен, что со временем такие побочные темы, как эта, станут лишь эхом прошлого.
4 лайка
Что касается сообществ разработчиков и пользователей, Discourse значительно превосходит средний уровень. Ошибки исправляются быстро, запросы на новые функции не игнорируются, особенно если есть обоснованное применение для них, а онлайн-персонал (оплачиваемый или волонтеры — я не уверен, как отличить одних от других) довольно хорош и достаточно терпелив в наставничестве для новичков вроде меня.
Да, документация нуждается в улучшении, но создание качественной документации обходится дорого и требует много времени. Более того, разработчики часто пишут плохую документацию, потому что они слишком близки к продукту и не видят его так, как пользователи. Слишком близкое знакомство с кодом также создает проблемы при тестировании продукта, хотя во многих проектах с открытым исходным кодом сообщество пользователей отлично справляется с тестированием.
5 лайков
Конечно, это так. То же самое можно сказать и о написании хорошего кода. Качественная человеческая работа часто бывает дорогой. Но код и документация тесно связаны, и документация становится дорогой только тогда, когда её никто не делает. В противном случае она является столь же критической частью продукта, как и кодирование, включая тестирование, дизайн, UX/UI и так далее. Однако разработчики часто ненавидят документацию, потому что просто не любят её делать: в этом нет ничего «крутого», плюс они часто просто плохо справляются с этим 
Но поскольку владельцы компаний и другие руководители сами бывшие разработчики, им всё равно, что сотрудники выбирают только то, что им нравится делать, а остальное игнорируют.
Но сейчас я ушёл в слишком общие рассуждения, которые совершенно не по теме. Поэтому я отойду от темы и укажу на Documentation, потому что она прямо сейчас развивается.
1 лайк
Я полностью согласен с этим. Я разработчик с более чем 20-летним опытом, хотя в последние годы перешёл в сферу платформенной инженерии.
Это хорошо видно здесь, когда вы просите совета, а разработчики (предполагаю? Я вижу только их участие в самом Discourse по их титулам) приходят и говорят, что это невозможно и не будет реализовано, потому что они так решили.
Далее — оффтоп.
Я уже говорил это: есть разница между тем, чтобы быть предвзятым в выборе технологического стека, и тем, чтобы быть предвзятым в продукте. Ваш продукт должен удовлетворять пользовательским сценариям в разумных пределах, а не быть «моим мячом, и если другим не нравится, пусть идут куда подальше».
Я уже запустил 5 новых проектов, и слава богу, что в нашем сообществе есть кто-то, кто немного знает Ruby. В ближайшие дни он объяснит нам основы работы Discourse, чтобы мы могли начать писать плагины, обеспечивающие необходимые нам функции. Одна из них — прежде всего, сделать так, чтобы модераторы категорий не были просто шуткой.
Тема поддержки Users are receiving emails even when everything is set up to not send email notifications немного изменилась, поэтому я разделил её на несколько новых тем в других категориях, чтобы дать каждой из них немного пространства для развития. 
2 лайка
Я могу вспомнить один проект с открытым исходным кодом, где разработчики склонны работать над тем, что их интересует, а не над тем, что может облегчить жизнь пользователям этого продукта. Сценарий использования всегда зависит от точки зрения: у пользователей продуктов взгляд на сценарии использования отличается от взгляда разработчиков. Разработчики часто воспринимают действия пользователей просто как «ещё одни данные» и нередко не видят, как небольшое изменение может кардинально улучшить удобство использования. (Я сам занимался разработкой систем и уверен, что иногда тоже допускал такое отношение.)
Пока что я не наблюдал подобного отношения в разработке Discourse, но я здесь всего лишь месяц.
Что касается излишней близости к продукту, то сейчас я прохожу упражнения из книги по разработке на Ruby. Простое приложение «Hello World» у меня заняло вчера три часа, в основном потому, что книга предполагала знакомство с облачной средой разработки AWS (Cloud9), которой у меня ещё не было. Поэтому, когда я кликал на что-то, это отменяло изменения, которые я только что потратил 10 минут на ввод.
Кроме того, возникла проблема с отображением предпросмотра работающего приложения в моём браузере. Похоже, это связано с ограничениями безопасности, которые Firefox и Chrome внедрили в свои браузеры после последнего обновления книги. После часа или около того поиска решений в интернете я добавил IP-адреса своего ноутбука и настольного компьютера в белый список, и это сработало, хотя мне всё ещё приходится выполнять дополнительный шаг, чтобы предпросмотр отображался.
1 лайк