Так мы же здесь про эталон говорим. Если я нашёл это за две (!) минуты, на эталон документации "в целом" не похоже.

Смотря для чего вам. Если речь об эталоне технического стиля... Ну, попробуйте, например, посмотреть документацию docker.

Вне языка: открывала на телефоне, вёрстка жутко поехала.

Еще можете посмотреть на https://stripe.com/docs Это то, что по мнению участников WTD Portland - выше всяких похвал (ну, опять же это субъективное мнение).

Если хочется пример небюрократизированной, модной-молодежной доки, то можно глянуть cypress: https://docs.cypress.io/guides/getting-started/writing-your-first-test#Write-your-first-test

Если с языком посерьезнее, то очень рекомендую простую и наглядную доку mongodb: https://docs.mongodb.com/manual/crud/

Олдскульнее, но с приличным английским - майкрософт. https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-setup-guide/organize-resources?tabs=AzureManagementGroupsAndHierarchy

Жила свою техписательскую жизнь с убеждением, что это ориентир для API доки. А вот сейчас разрабы вокруг меня ее используют, ииии... не сказать, что довольны. Их оценка — medium shitty. Все равно бесконечные синки с представителями страйпа. Все они видели не раз доку хуже, да. Но все равно не готовы назвать страйп достойным примером для подражания.

Я всего лишь озвучил мнение сообщества WTD :)

Да-да, я поняла) Просто поделилась мнением нашей целевой аудитории, которое стало для меня открытием 🙂

Создал чатик, кому интересно - присоединяйтесь :)

https://t.me/joinchat/Zxo5ioJlnf80OTVi

Могу предложить небольшую техписательскую сессию небольшой толпой в zoom-e. Наверняка будет интересно новичкам.

Хотелка такая:
- создаем созвон в зуме, я шарю экран.
- открываем опенсорсную доку на гитхабе (например, доку мозилы)
- все присутствующие читают текст, смотрят как выглядит маркдаун, смотрят как пишут другие люди и предлагают правки.
- я помогаю вам с редактурой текста, показываю как это всё коммитится, зрители постигают азы работы с гитхабом.

Дока на английском, обсуждения на русском. Кому интересно?

Коллеги!
Возник вопрос:
Как определить объем работы по проекту (РП для ПО)?

В нормативной документации встречал только нормы на раб. день. А ля 3 страницы нового текста или странниц для проверки и редактирования на раб день (8 часов).

Заранее спасибо!

#tw_wanted
Всем доброго дня!

Университет Иннополис стартует новый федеральный проект для школьников и ищет технического писателя.

Нужно будет:

вычитывать и редактировать тз,

наполнять внутреннюю базу знаний для команды разработки,

составлять пользовательские инструкции.

Из навыков: важно понимать процесс разработки и уметь разобраться в нормативных документах. Поэтому ожидаем, что это не первое знакомство с миром технической документации.

Готовы удовлетворить зарплатные ожидания успешно прошедшего собеседование кандидата.

Резюме присылать личными сообщениями @serochudinov.

Видела расчёт по количеству экранов - но там, видимо, не столько РП, сколько описание интерфейса хотели :)
Видела расчёт по количеству функций в ТЗ с множителем на сложность - но да, там ТЗ было очень детальное.
Ну и прежде всего рабочая оценка может быть только после уточнений, какое именно РП хотят получить (стандарты и образцы), чо по инструментарию и доступности ресурсов - от стендов до живых людей.

Не могли бы Вы поделиться примерами этих расчетов?
Это бы очень помогло моему делу!

за раб.день в 8 часов:
60-80 л на форматирование-корректирование; 6-10 л на разработку нового документа при условии, что у техписа есть все необходимые данные для описания

Нет, это было очень давно. Но расчёт по экранам точно не советую :))

Я прошу прощения, но "л" - это лет или литров? :)))) Извините, я правда никак не догадываюсь и очень смеюсь )

Листов?

да

правильно пишется «листьев»