WebStorm❤️ — покрывает почти все мои потребности как техписа

А мне хотелось бы задать немного другой вопрос. Почему JetBrains пользовался Confluence на протяжении более 10 лет и не отказывался от него вплоть до последнего времени (насколько я понимаю, отказ произошел только в 2017-2018 году)? В то время, как уже давно существовали markup languages (в данном случае, неважно, речь идет о lightweight или xml-based markups), которые позволяют хранить контент в репозитории (svn, git, mercurial, etc).

Отвечаю, как представитель JetBrains. Confluence использовался в недавнем прошлом как инструмент написания документации только небольшим количеством команд, где помимо писателей в документацию контрибьютили разработчики и не хотели заморачиваться ничем более продвинутым. Сейчас документация вся в едином формате и на confluence не пишется. Если остались какие-то туториалы, это legacy, которое постепенно должно исчезнуть

я бы вообще сказала, что Confluence и языки разметки - это подходы, которые решают разные задачи в зависимости от целей конкретного проекта

и сравнивать их в плане "что лучше" не стоит

Markdown + GitHub?

Git + движок для html и другие надстройки

не обязательно ипользовать GitHub в таком случае

Вопрос был задан немного в другом русле. Как известно, разработчики очень любят работать с системой контроля и с src-файлами. С учетом того, что в JetBrains достаточно продвинутые разработчики (и не только разработчики :), вопрос и был в том, почему они _изначально_ не использовали src-based documentation (назовем ее так), а использовали именно Confluence.

Если это правда так интересно, могу попробовать узнать у выживших динозавров :) когда я пришла 5.5 лет назад, мы пользовались Perforce, потом перешли на git

Да, да, это было бы очень интересно. И вот почему. В бытность работы в одной из компаний я был идеологом создания системы документирования, где все собиралось из исходников. Мы с коллегами из отдела сделали inhouse-систему, которая хранила все в системе контроля и собирала в режиме on-fly, on-demand. Т.е. это даже не SSG - это динамическая (!) сборка документации на основе конвейеров Apache Cocoon. Эта система была создана в 2008 (!!!) году. Когда я в то время смотрел на документацию jetbrains (а она была в Confluence), меня занимал вопрос, почему Jetbrains не использует преимущества систем контроля для документации с его diff, merge и т.п.? Для интересующихся стек технологий этого in-house решения: DocBook/XML 4.5 (doc-src), XMLMind (WYSIWYM-редактор), subversion (scm), проверка содержимого и информирование авторов с помощью email при каждом commit, сообщения об ошибках - только на валидность и well-formеdness (cхематрон на использовался), XInclude (content reuse), препроцессинг и генерация olink db (при помощи простейшего bash скрипта),  динамическая генерация представления (html, PDF, txt) по http GET (в зависимости от устройства пользователя) с помощью Apache Cocoon (XML Publishing Framework), логика отображения и адаптивное представление (на основе конвейеров Cocoon), кэширование (внутренние механизмы Cocoon).

поделитесь примером технического отчета на английском языке и описание API. может попадался в открытом доступе🙏🏻

описаний API в инете куча, берете и гуглите любой серьезный проект с аудиторией из разработчиков и добавляете аббревиатуру API. что имеется в виду под “техничским отчетом”?

мне вот нравится https://stripe.com/docs/api. интересно, какой у них стек…

В этом курсе был где-то список из порядка 100 сайтов с документацией на различные api
https://github.com/docops-hq/learnapidoc-ru/blob/master/testing-api-doc/README.md

о, спасибо! а по отчетам?

В продолжение вчерашнего разговора про инструменты: