не всегда потребность реализуется удобно для всех участников. может так оказаться, что чат в телеграме будет удобнее, чем какое-либо self-hosted решение, и все будут продолжать писать и искать в чате в телеграме

+1

вот сейчас и проверим )

не в смысле что мы хороним вашу идею (будет очень круто, если у вас всё получится, и еще круче, если вы потом об этом расскажете), но это реально гораздо более сложный процесс, чем «установить и настроить Q&A-площадку»

поставил questions for confluence

можно попробовать OneBar, там еще и интеграция со слэком, можно врубить автооответчик в чатах (не обязательно), вся логика именно на вопрос-ответ

Вот такой вариант мне попадался. Рекламируется как улучшенный Slack. Под указанные вами критерии, кажется, подходит.

https://youtu.be/LRUpSYm9Db4

Всем привет)
Простите, что прерываю текущее обсуждение про аналог stackoverflow для тех.писателей, но хотела задать вопрос

Когда вы пишете методику испытаний или инструкцию к продукту, у вас всегда есть доступ к этому продукту? Бывало ли, что  доступа к продукту нет, самому там ничего не посмотреть и не понажимать?

Бывало ли, что процесс идет как-то так:
1) всю информацию надо брать у разработчика/тестировщика/кого-то еще
2) его рассказ переписать в более удобном виде (если нужны скриншоты, а скорее всего нужны, то запросить)
3) отдать свой получившийся документ на согласование тому, кого опрашивали в первом шаге, чтобы он сказал - ок или не ок, если не ок, то указал на какие-то фактические ошибки и сказал, как на самом деле все работает.
?

Уверен, что такое встречается, но описывать чьи-то фантазии это какая-то другая профессия. Лучше тогда быть условным «редактором», который просто поправляет грамматику и стиль изложения, ну или подгоняет под внутренние стандарты повествования/оформления. А изначально описывать должен тот, кто пользуется.

Это примерно как просить написать приложение без возможности собирать и запускать код в процессе разработки

Да, бывает. Я даже как то писал ПМИ на систему, у которой больше половины интерфейсов не было. Лишь бы был документ, чтобы показать заказчику. В итоге у меня получилось придумать систему лучше, чем ее потом реализовали.

Но это ухищрения при работе с крупными гос заказчиками обычно

Или с военкой, как у нас

Мне даже понравилось придумывать как должна работать система. Задумался о перспективах карьеры ux дизайнера или системного архитектора в тот раз

Но конечно же это ларинго-проктология получается. Хотя мне напомнило test-driven development

вот-вот, я тоже чувствую себя максимально странно, что не могу проследовать по своей же инструкции и убедиться, что да, все кнопки на тех местах, где я написала, и что инструкция вообще приводит к своей цели

Ну это же классика ситуации, когда адекватное содержание инструкции и ее подача мало кого интересует, а важны формальные стороны вопроса.
P.S. Вроде это обсуждение не для чата DocOps, если я не ошибаюсь. Есть чат техписателей

а, да, надо было в тот чат написать

Бывало, что нет доступа, не вижу в этом ничего страшного если есть доверие к заметкам, докам разрабов и ТЗ, которое они выполнили.
1) Всю не было, но часто какие-то новые фичи, или свойства, параметры, плагины, которые я физически не смогу запустить спрашивал у тестеровщиков, скрины их смотрел. Частенько даж лень запускать и настраивать приложение, чтобы что-то увидеть, проще у тестировщиков спросить мол глянь, всё так как и написано в ТЗ работает?
2) да
3) да, когда сам не можешь проверить ни его слова, ни свои перефразированные. бывает, что что-то не так понял и описал, ещё бывало оставались открытые вопросы, тип не понятно как система ведёт себя в какой-то ситуации, просишь точно сказать, чтобы закончить доку.
В итоге, при такой ситуации все понимают, что спрос с техписа меньше и помогают

Доступ нужен и очень полезен. Более того, доступ нужен ещё на этапе проектирования интерфейсов, чтобы помочь написать в них нормальные тексты. А уж к готовому продукту так точно нужен.

Наверное, бывают засекреченные продукты, к которым доступа не дают. Но я бы не хотел так работать. По чужим рассказам получится хуже.