не видел, спасибо за инфо, посмотрю подробнее

он поклазывает содержимое стати в виде карты

Такое и для вскода есть, FYI

См. на крайне правую  точку  «онтология и графы» - прямо что-то входящее в долину смерти ….

Коллеги, а как вы работаете с контактами?
Мне приходится коммуницировать с людьми на нескольких платформах (google drive, office 365, slack, telegram) и зачастую я впадаю в ступор вида "а на какой е-мэйл мне надо пошарить этот документ?" и идти переспрашивать человека.
Может есть какой-то хороший софт для ведения базы контактов?

вообще переспрашивать это правильно в таких случаях,  софт тут не поможет и иногда общая база может внести только путаницу, ког когда ты отправляешь человеку туда где он не ждет, когда у тебя все его каналы есть

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

День добрый, коллеги. может кто-то сталкивался. Нужна подсказка.  в PlantUml при использовании skinparam linetype ortho  - съезжают подписи к связям.  Есть ли возможность как то исправить?

О вчера как раз поймала этот баг, справиться пока не смогла но нашла Тикет https://github.com/plantuml/plantuml/issues/149 буду искать дальше

Ребята всем привет, меня зовут Женя, я пресейл в компании Экзамус, благодарю @Lananovikova за ссылку на группу. Сейчас наша компания озадачилась вопросом ведения документации, поэтому прошу вашей помощи по моим вопросам.
1-ый вопрос:
Задача:
Прокторинговая компания (проктор проверяет, что студент сдает честно экзамен).
Инструкции двух видов: синхрон, асинхрон.
Эти виды подразделяются еще на три вида каждая: студенту, проктору, заказчику.
Эти три вида подразделяются еще на пять видов: по форме используемого приложения.
Некоторые инструкции совпадают на 80%, такие например как синхрон студенту и асинхрон студенту.
Вопрос: в каком софте лучше это все держать/манагерить, учитывая что инструкции на англ и др.языке, возможно будут переводиться на другие языки в будущем?

Хотелось бы:
- мультиязыковую.поддержку (в идеале переводческую память+встроенный переводчик)
- возможность манагерить блоки инструкций и собирать из блоков инструкции
- установка и настройка не на сервер, а как-то попроще.

Что рассматривали:
Madcap (дорого, а крякнутый чет стремно скачивать с непонятных сайтов)
Dr.Explain (юзер не френдли, не оч понравился, пока тестим)
Dokuwiki (понравился, но его надо ставить на сервер, есть опасения, что нажимается что-то не то и все пропадает)

Что используют:
Google docs

Светлана обозначила свое экспертное мнение и посоветовала нам Sphinx docs, хотелось бы по возможности услышать еще мнения, заранее спасибо!
2-ой вопрос:
У нас еще сложности с организованностью документации, так как мы стартап, у нас в основном, все в головах, а не на бумаге, можете посоветовать какое-нибудь решение? Мы в сегменте IT и образования, разрабатываем софт под образовательные услуги. Заранее спасибо.

Про инструменты можете спросить в чате тех писателей: https://t.me/technicalwriters

да, про инструменты документации точно не сюда, сюда про упаковку и шаринг знаний, давайте что-нибудь посоветуем по этой части

Кейс. Есть функциональный лидер, пусть для определенности будет руководитель всех ios разработчиков. Каждый разработчик работает в своей команде над своим продуктом. Руководитель организует общие встречи, обмен знаниями, растит культуру, помогает отдельным разработчикам с их задачами. Пока число разработчиков небольшое, около 10.

История не масштабируется. Есть предел времени у руководителя. Есть предел эффективности встреч при росте числа участников и так далее.

Дорогие мои, какие варианты есть для масштабирования? Если задача - продолжать развивать культуру и шарить знания между разработчиками. Что можно посмотреть/почитать?

делегировать эту зону ответственности?
управленческие задачи же делегируют на замов. Ревью, планирование (частично), консультирование коллег — вот это всё чудесно делегируется.

Есть решение влоб, дать руководителю команду тимлидов, где каждый будет отвечать за своих разработчиков.

Мне кажется (могу быть не прав), шаринг между группами пострадает

дык пропиши для старта о чём они должны шарить и как, и оставь себе ретро и периодические случки команд для корректировки

помощь разработчикам оказывается в формате "выпрямления рук", показываются принципы работы. То есть руководитель реально отвечает за культуру. В этом случае что можно делегировать?

То есть, непосредственно в решения для продуктов никто не лезет

Могут коллективно порешать какие фреймворки и подходы использовать, как должен выглядеть проект