Если какую-то метрику можно "нагнать", именно это кто-нибудь и сделает. Tracking the Fake GitHub Star Black Market with Dagster, dbt and BigQuery рассказывает про то, как разоблачить накликанные звездочки на GitHub. Ну и про то, как их покупают тоже. Даже сделали контрольную закупку и специального спам-эксперта привлекли.
Фальшивки определяли по профилям, поставившим звезду:

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

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

В подкасте { между скобок } вышло интервью с человеком, который успел поработать и с технопиар, и с техпиар (если вы понимаете :))) - Михаилом Клюевым.
Весь подкаст интересный, но я хочу отдельно вытащить один кусочек сюда: https://youtu.be/3BEbs4C4So8?t=2102 Потому что это ППКС (олды тут? Подпишусь Под Каждым Словом на старо-жежешном). И говорить об этом нужно чаще: сначала создаем условия, потом уже хотим что-то от разработчиков. Здесь я бы даже “сервис” объединила с “социальной мотивацией”. Вместе это и есть DevRel-культура, о которой мы часто говорим. Суть организационной (и DevRel-) культуры именно в том, чтобы упростить людям желаемые действия (и усложнить нежелательные, конечно).

…Ну если есть какой-то блокер, нужно сначала понять причину. Когда мы поняли причину, мы эти блокеры снимаем. …там [в Avito] мы делали по сути внутренний сервис для разработчиков, который им помогает заниматься публичными выступлениями. Ключевая задача этого сервиса прежде всего снять геморрой с разработчика… Например, я сам плохо пишу. Мне нужна помощь специалиста по буквам и значит знакам препинания. У нас есть такой специалист. Напиши черновик, мы отдадим его редактору. Редактор превратит это в красивый текст, ты потом его проверишь, мы это опубликуем. Нету времени у тебя писать черновик, приди к нам. Мы тебе зададим вопросы и расшифруем. Или нужно тебе помочь: ты не знаешь как подготовиться к выступлению. Окей. У нас есть специалисты которые помогали другим людям проводить выступления ты с ними поработаешь и сможешь выступить. Тебе нужны картинки? Вот есть у нас человек, который делает картинки, и так далее и тому подобное…

Второй уровень [мотивации] - это общественное, точнее, она называется Social motivation, общественная мотивация. Это про то, что если человек этим занимается в компании, его компания должна поддерживать. Не должно быть ситуации, когда человек поехал выступать, вернулся в команду и там на делике не или на виклике ему говорят: Слушай, ну там пока ты выступал, мы закрывали задачи, значит ты там не доработал”. Вот такого быть не должно. Все должны понимать на всех уровнях, что это тоже работа. Это просто может быть не основная работа, шапочка, которую человек одел и пошел помогать компании, и у него должна быть поддержка коллег. #конспект

Авторы статьи How to Tell If a Potential Employer Has a Burnout Culture составили список "звоночков" на собеседовании. HBR немного капитанят, но к каждому пункту дают список полезных проверочных вопросов, так что есть материал для подумать. Итак, если есть один или несколько признаков, высоки шансы, что что вас заездят без всякого work-life balance:

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

Среди плохих признаков затесались, например, тимбилдинг в нерабочее время и требование отвечать на сообщения/письма немедленно (и в выходные тоже). Сюда же относятся постоянные слишком ранние или слишком поздние созвоны или встречи.

Непрозрачность оценки сотрудников: непонятно, что нужно для пересмотра зарплаты и повышения (в идеале все должно быть прописано).

Нет постоянной программы развития сотрудников.

Нет культуры обратной связи, работы с ошибками.

Кстати, если не спрашивают про хобби, значит, - делают вывод авторы, - вы им не интересны как личность. Минус таким. А еще если опоздали, перебивают или что-то не сходится то, что говорили до собеседования с тем, что говорят на нем. Каков рекрутер, намекают нам авторы между строк, такова и контора.

Проблемки с ценностями (они как бы есть, но ими не пользуются).
Меня так заинтересовал этот блок, что я даже приведу полный список вопросов по нему:
- Как эта позиция связана с миссией компании?
- Как ценности компании влияют на принятие решений?
- Как работа команды влияет на выполнение целей компании?
- Какие OKR?
- Поддерживает ли компания общественную активность в рабочее время?
- Какой вклад вносит компания в местное сообщество?

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

Взгляд разработчика на DevRel с точки зрения улучшения опыта взаимодействия с компанией + как карьерная перспектива. Осторожно, внутри заложена потенциальная холиварность на тему дев адвокатства. Бонусом идут несколько классных идей мероприятий для разработчиков, которые можно реализовать малыми силами.

Кстати, Марк - именно тот человек, который поддерживает жизнь в московской части DevRel-завтраков, за что ему большое спасибо.

День программиста празднуют 13 сентября, а что делать, если вы хотите отдельно закатить вечеринку в честь фронтенда и отдельно в честь "дата сатанистов"? У Data science уже три года как есть свой праздник - четвертая пятница апреля (в 2023 выходит 28 апреля, еще успеваете), а у фронтендеров нет. Подсказка в статье Codenrock: 7 мая, которое называют «Днем CSS» (Cascading Style Sheets) или 10 ноября. Этот день совпадает с датой создания проекта jQuery, который является одним из наиболее популярных JavaScript-фреймворков для разработки фронтенда. Сохраняем в закладки, еще пригодится: https://codenrock.com/blog/professionalnye-prazdniki-v-it/ #инструменты

Посмотрела запись онлайна с Настей Кабищевой, где она рассказала, как начала делать DevRel для армянского банка, где проект, несмотря на удачные первые шаги, поставили на паузу: https://www.youtube.com/watch?v=wJlRaVnV3Zs

Выделила несколько особенно интересных мне “граблей”, на которые может наступить даже самый синьорный синьор, потому что “дело не в тебе, username”.

Это может быть неудачный момент для старта/переформатирования DevRel. Да, наверху могли решить, что DevRel развивать пора. Но на самом деле, все внимание может концентрироваться на более важном по факту для бизнеса проекте. Туда же будут уходить и ресурсы, включая внимание руководства. А для того, чтобы произошли серьезные (и болезненные иногда) изменения, это внимание жизненно важно. Просчитать уместность момента снаружи крайне сложно, особенно, когда нанимающие менеджеры сами недооценивают сложности и транслируют на собеседовании скорее желаемую картину, чем реальную (но про это вы узнаете намного позже).

Решение сверху есть, а понимания нет. Так появляются странные метрики (ни с одной из которых запрашивающие не знают, что делать) и бесконечные отговорки на среднем уровне. Мне очень понравилось, как Настя вела от “хорошо бы” к конкретике через серии встреч, итоги каждой из которой четко фиксировались.

Нет понимания, но есть страхи. Многим бы хотелось, чтобы люди на работе работали без всякого вот этого там межличностного. Но так не бывает. Сверху сказали, что мы делаем что-то непонятное, появляется новый важный человек со своими идеями, обсуждает их с твоим руководством… а не подрывает ли это твою репутацию и власть, директор по маркетингу или HRBP? Кое-кто может подумать, что да. И начнет саботировать реализацию задуманного. Тут всегда многое зависит от личностей людей, с которыми нужно договариваться, и нет 100% гарантии, что договориться получится. Хороший пример из записи: как Настя разбирала возражения, пытаясь узнать, откуда (пред)убеждение появилось.

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

DevRel-бюджет не был заложен в текущий год. И этот пункт тоже про работу с людьми. Можно поискать, вписывается ли трата в маркетинг, HR, обучение или нужно согласовывать ее отдельно (и через кого это будет проще сделать). Очень хороший пример в стриме про согласование DevOps Conf и участия в Highload++ Armenia

Актуально для работы в “странах релокации”: для работы с HR-брендом может понадобиться знание местного языка, а для работы с сообществом - местного и английского. И на этом моменте часть спикеров или стендистов (например, владеющие только русским и английским) может просто отвалиться.

Очень полезный стрим, есть, над чем подумать. #конспект #карьера

Кажется, собирается новый книжный пост. В прошлый раз были книги на английском, теперь фиг знает, как их купить, зато вот эти относительно свежие (третья, про hr brand, только что вышла). #книги

Наконец дописала рекап нашего стрима про резюме, собеседования и все такое на джуновые и мидл позиции в DevRel. Получила за это время несколько отзывов, судя по ним, вопросы мы выбрали правильные и ответили на них достаточно развернуто. Намного больше люблю оффлайн, но чтобы собрать таких экспертов, можно и стрим. Теперь со вкусом букв: https://habr.com/ru/articles/738334/ #карьера

A review of DevRel job titles and career progression

Hoopy (DevRel-консультанты и организаторы DevRel Con) выложили результаты исследования на предмет того, какими должностями наделяют ответственных за DevRel. Начнем с теории. В списке основных "ролей" кроме дев-адвокатов и ожидаемого управления сообществами появилось что-то новенькое: Developer Educator. Не волнуйтесь, это знакомая песня на новый лад (и, возможно, ее исполняете именно вы).

Адвокатов поделили на несколько видов:
- outreach-focused (по-старому это "евангелисты")
- product-focused (больше про обратную связь с пользователями продукта для разработчиков, создание или инициация создания удобных доп инструментов и т.п.)
- internal (развитие инженерной культуры внутри, внутренние сообщества, коммуникация между командами и т.п.)

Пока ярче всех сияют outreach-focused адвокаты, менеджеры по развитию сообществ возделывают почву, на которой расцветает developer program (то, что и зачем будут делать с разработчиками в принципе).

До недавнего времени контент для разработчиков чаще всего создавали техписы и тренеры, а дев адвокаты заполняли пробелы менее формальным контентом. Developer educator беспощадно рвет со своим прошлым и в то же время трепещущей рукой сбрасывает таинственный покров будущего разрабатывает learning journeys (как customer, только learning), не чуждаясь новых форматов и педагогических приемчиков.

Для каждого вида специалистов есть примерный список обязанностей (основных и тоже встречающихся), требования и даже обозначено место на "радаре DevRel": Адвокатство, Маркетинг, Сообщество и Успех пользователя (Enablement). Ну и пару страничек посвятили карьерной лестнице.

Кроме трех основных типов должностей в классификацию вошли:
- менеджер программы (как менеджер проекта, только программы)
- операционный менеджер (ежедневная поддержка деятельности DevRel-команды)
- Developer experience engineer (как будто бы выделенная в отдельную роль часть работы дев-адвоката, если пользовательский опыт критически важен для коммерческого продукта)
- Developer success engineer (как техпод, только еще лучше, потому что активно ищет, как бы сделать жизнь инженера-пользователя лучше)

С одной стороны, старая работа - новые названия. С другой стороны, такие переименования и пересборка "шляп" на отделе (даже если головных уборов по-прежнему больше, чем голов) отражают приоритеты компаний и следить за ними поэтому полезно. #тренды #карьера

Они еще и квиз сделали по мотивам исследования. Так что если лень читать, начать можно с него: https://commonroomresearch.typeform.com/devrelroles2023 Меня разоблачилиопределили довольно точно

В процессе обсуждения перебрала свою PR-библиотечку, и нашла сборник эссе Михаила Умарова “PR в реальном времени. Тренды. Кейсы. Правила” 2016 года (на фото в центре). В основном работает до сих пор. Особенное внимание обратила на главу “Как измерить результаты PR”. Пожалуй, уроки пиарщиков и деврелам подойдут. Сделала конспект (чего не сделаешь, чтобы убрать книгу обратно в шкаф уже). #PR #метрики #книги

Хочется мем из этого скриншота. Apache Spark сделали офигенную вещь, но комментарии про недостатки документации ("всегда такая фигня") немного портят момент. Документация - часть Developer Relations и первый пункт меню, который интересует разработчика на продуктовом сайте. PS и да, у меня явно сеть connections повышенной занудности

Конечно, не конспект, но я не могу наслаждаться этим одна! На выставке “Египетские мотивы в истории Санкт-Петербурга” в Петропавловской крепости увидела афишу. Встречайте: неизвестный копирайтер нэпманского (потому что Царское село стало детским в 1918 году только) кинотеатра Казино. По-моему, его находки можно вставлять рэндомно в любой анонс, чтобы увеличить привлекательность мероприятия на 1000 пойнтов!

*Собств. исправное электрическое освещение
*Ввиду исключительного успеха и по желанию публики
*Участвуют тигры, змеи и свыше 10.000 человек артистов
*Всюду фурор! Всюду успех!
*Все Детское Село будет петь [подставить нужное]

Просто представьте это в описании своего митапа. Ну красота же!

Внимание: это перекрестное опыление :)) На самом деле, решили с участниками близких сообществ (PR и Digital) обменяться подборками каналов. Чтобы развивать кросс-функциональную насмотренность 💪 так что ждите скоро ответные подборки. Если я кого-то пропустила в DevRel-списке, дайте знать, добавлю.

ТГ-каналы про Developer Relations и коммуникации в IT:

Говорите громче! - канал Жени Голевой про работу деврелом, публичные выступления, обратную связь и обучение взрослых

My DevRel - канал Натальи Макаровой про работу в DevRel

не доводи спикера - канал Адель Макашовой про работу со спикерами и не только

Логово редактора - канал Тони Татчук про контент-маркетинг в технологической сфере.

что-то на техпиарном - канал Алины Боровицкой про осознанный SMM, техпиар и софт-скиллы <3

Geek Relations - коммуникации и образование в ИТ. DevRel. TechComm. Knowledge management. ITHR. Немного BigData и AI.

DevRel Склад - канал Ксении Романовой с краткими конспектами и комментариями по материалам о Developer Relation и Community Management (в основном зарубежным)

23derevo - канал Лёши Федорова из JUG Ru Group о работе над IT-конференциями (самый движ происходит в чате канала)

Это работа для DevRel’a - канал @svetlanada с вакансиями для DevRel-менеджеров, Tech PR, редактуров технических текстов и IT HR

Деврел-бюро - канал, где Алексей Долгушев и Мишаня Сторожилов иногда рассказывают про DevRel и постят вакансии

Коммуникаторы: обсуждают, что некоторые шутки, которые были классными 5-6 лет назад, в 2023 уже слишком рискованные для репутации компании

Тем временем некоторые шутки: https://Fuckjava.com