Size: a a a

technicalwriters

2020 December 29

JM

Jaroslaw Martinow in technicalwriters
Andrei Yemelianov
Какая?!😳
LML - так и называется
источник

JM

Jaroslaw Martinow in technicalwriters
Olga Rodina
Уценку я поняла, а на мерзавце зависла...
Есть ещё "мерзавец, принеси чернослив" 😆
источник
2020 December 30

IK

Ivan Kochurkin in technicalwriters
Кстати, а как часто техписы контрибьютят в опенсорс? Ну вот блуждаете вы вдруг по гитхабу и видите, что доки у проекта написаны плохо или содержат ошибки. Будете ли вы их исправлять и предлагать pull request? Вообще доки - это как правило самое простое что можно поправить в проекте, по крайней мере не нужно ничего билдить, тесты прогонять.
источник

ДС

Денис Старков... in technicalwriters
вероятно, все это по желанию
источник

H

Hartmann in technicalwriters
Ivan Kochurkin
Кстати, а как часто техписы контрибьютят в опенсорс? Ну вот блуждаете вы вдруг по гитхабу и видите, что доки у проекта написаны плохо или содержат ошибки. Будете ли вы их исправлять и предлагать pull request? Вообще доки - это как правило самое простое что можно поправить в проекте, по крайней мере не нужно ничего билдить, тесты прогонять.
Так проведите опрос. Предложите несколько вариантов ответа. Интересно будет посмотреть на результаты.
источник

ET

Elena Tikhomirova in technicalwriters
Ivan Kochurkin
Кстати, а как часто техписы контрибьютят в опенсорс? Ну вот блуждаете вы вдруг по гитхабу и видите, что доки у проекта написаны плохо или содержат ошибки. Будете ли вы их исправлять и предлагать pull request? Вообще доки - это как правило самое простое что можно поправить в проекте, по крайней мере не нужно ничего билдить, тесты прогонять.
«самое простое». улыбнуло. вы, наверное, не техпис? 😁
источник

IK

Ivan Kochurkin in technicalwriters
Да, не техпис, всего лишь программист 😊 Я к тому, что при правке доков обычно не требуется компилить проект, прогонять тесты, на измененный код - а это бывает непросто. По крайней мере на моей практике. Ок, может не самое простое, но не такое сложное, как правки кода.
источник

DM

Dina M. in technicalwriters
Ivan Kochurkin
Да, не техпис, всего лишь программист 😊 Я к тому, что при правке доков обычно не требуется компилить проект, прогонять тесты, на измененный код - а это бывает непросто. По крайней мере на моей практике. Ок, может не самое простое, но не такое сложное, как правки кода.
Иван, мы же коллеги, как я понимаю. Вы из ПТ?  Проект собирать требуется, и не один. Потом в скиме проверить сборку на отсутствие ошибок, на то, что переменные не слетели. Куски документации у нас фрагментируются - нужно проставить нужную таксономию, убедиться, что фрагмент попадает в нужную версию и не попадает в ненужные.
источник

OT

Ola Tishina in technicalwriters
Ivan Kochurkin
Да, не техпис, всего лишь программист 😊 Я к тому, что при правке доков обычно не требуется компилить проект, прогонять тесты, на измененный код - а это бывает непросто. По крайней мере на моей практике. Ок, может не самое простое, но не такое сложное, как правки кода.
😂😂😂 вас не остановить! а впрочем пятница же ))
источник

IK

Ivan Kochurkin in technicalwriters
Dina M.
Иван, мы же коллеги, как я понимаю. Вы из ПТ?  Проект собирать требуется, и не один. Потом в скиме проверить сборку на отсутствие ошибок, на то, что переменные не слетели. Куски документации у нас фрагментируются - нужно проставить нужную таксономию, убедиться, что фрагмент попадает в нужную версию и не попадает в ненужные.
Это все есть в опенсорсных проектах? Обычно доки там это просто набор md файлов.
источник

IK

Ivan Kochurkin in technicalwriters
Было бы интересно узнать в каких проектах есть что-то такое продвинутое) Прощу прощения, если задел кого-то чувства - руководствовался собственным опытом работы с опенсорс проектами, но, возможно, дополнение про сложность было излишним.
источник

S

Sara in technicalwriters
Ivan Kochurkin
Было бы интересно узнать в каких проектах есть что-то такое продвинутое) Прощу прощения, если задел кого-то чувства - руководствовался собственным опытом работы с опенсорс проектами, но, возможно, дополнение про сложность было излишним.
Ну у нас опенсурс и собирается тоже, правда, легко и просто на сфинксе. Но я согласна, что самой простой контрибьюшн - это использовать самому проект, например, заметить, что какая-то часть доки устарела или ошибочна - и поправить.
источник

IK

Ivan Kochurkin in technicalwriters
Хотя у доков гитхаба что-то более продвинутое https://github.com/github/docs
источник

FM

Fox Mulder in technicalwriters
Ivan Kochurkin
Кстати, а как часто техписы контрибьютят в опенсорс? Ну вот блуждаете вы вдруг по гитхабу и видите, что доки у проекта написаны плохо или содержат ошибки. Будете ли вы их исправлять и предлагать pull request? Вообще доки - это как правило самое простое что можно поправить в проекте, по крайней мере не нужно ничего билдить, тесты прогонять.
Я контрибьютил в гит Яндекс.Облако.
В основном техписы не занимаются этим.
источник

NV

Nick Volynkin in technicalwriters
Ivan Kochurkin
Кстати, а как часто техписы контрибьютят в опенсорс? Ну вот блуждаете вы вдруг по гитхабу и видите, что доки у проекта написаны плохо или содержат ошибки. Будете ли вы их исправлять и предлагать pull request? Вообще доки - это как правило самое простое что можно поправить в проекте, по крайней мере не нужно ничего билдить, тесты прогонять.
я теперь по основной работе в опенсорс пишу )
источник

FM

Fox Mulder in technicalwriters
Nick Volynkin
я теперь по основной работе в опенсорс пишу )
Как тебе не стыдно )))
(не удержался)
источник

IK

Ivan Kochurkin in technicalwriters
А можно посмотреть где?)
источник

NV

Nick Volynkin in technicalwriters
Пока негде, вторая неделя )
источник

KP

Kate Potapova in technicalwriters
Ivan Kochurkin
Кстати, а как часто техписы контрибьютят в опенсорс? Ну вот блуждаете вы вдруг по гитхабу и видите, что доки у проекта написаны плохо или содержат ошибки. Будете ли вы их исправлять и предлагать pull request? Вообще доки - это как правило самое простое что можно поправить в проекте, по крайней мере не нужно ничего билдить, тесты прогонять.
Я лет 10 назад контрибьютила в каком-то из проектов ubuntu,  было кстати интересно работать в распреденной разнострановой команде. Там достаточно грамотно было устроено так что каждый пишет свой кусочек и если кто-то выпадает, что бывало, процесс не останавливается. Но тогда был период затишься на работе, а потом он кончился и больше пока не возвращается:(
источник

ET

Eduard Tibet in technicalwriters
Nick Volynkin
я теперь по основной работе в опенсорс пишу )
Gitlab? :)
источник