Открытое сотрудничество основано на доверии. Долгое время это доверие защищал естественный, хотя и несовершенный фильтр: трение.
Если вы были в Usenet в 1993 году, вы помните, что каждый сентябрь поток новых студентов университетов, незнакомых с нормами, приходил в сеть, и сообщество терпеливо их принимало. Затем стали популярны обычные интернет-провайдеры с коммутируемым доступом, и в Интернет появился устойчивый поток новых пользователей. Это был сентябрь, который никогда не заканчивался.
Сегодня open source переживает свой вечный сентябрь. На этот раз речь идет не только о новых пользователях. Это огромный вклад.
Когда стоимость участия снижается
Вклад в открытый исходный код в эпоху списков рассылки требует реальных усилий. Надо подписаться, скрыть, понять культуру, правильно отформатировать патч и объяснить, почему это важно. Эта попытка не гарантировала качества, но была отфильтрована для участия. Большая часть вкладов поступила от людей, которые действительно были вовлечены в проект.
Люди также не были включены в это. Входной барьер был высоким. Многие проекты усердно работали над тем, чтобы уменьшить это, чтобы сделать открытый исходный код более привлекательным.
Серьезное изменение произошло с запросом на включение. Размещение проекта на GitHub, использование запросов на включение и пометка их как «хорошие первые проблемы» уменьшили трудности, необходимые для внесения вклада. Сообщества росли, а вклады становились более доступными.
Это было хорошо.
Но трение — это балансирующий акт. Слишком многое исключает людей и их идеи, слишком мало трений может повлиять на доверие, которое полагается на открытый исходный код.
Сегодня запросы на включение могут быть сгенерированы за считанные секунды. Генеративный искусственный интеллект упрощает создание кода, проблем или отчетов о безопасности в больших масштабах. Стоимость создания снизилась, а стоимость рецензирования — нет.
Стоит сказать: большинство участников действуют добросовестно. Многие люди хотят помочь проектам, которые им интересны. Другие мотивированы получением образования, известностью или карьерными преимуществами от участия в широко используемом открытом исходном коде. Эти стимулы не новы и не ошибочны.
Проблема заключается в том, что происходит, когда вклады низкого качества поступают в больших количествах. Когда объем растет быстрее, чем возможности рецензирования, даже материалы, отправленные с благими намерениями, могут перегрузить сопровождающих. И когда это происходит, доверие, основа открытого сотрудничества, начинает ослабевать.
новый показатель шума
Соблазнительно представить «низкокачественный вклад» или «отстойный вклад ИИ» как уникальное недавнее явление. Это не так. Обслуживающему персоналу всегда приходится иметь дело с шумом.
- Ядро Linux работает в соответствии с философией «сети доверия», в 2004 году формализовано руководство SubmittingPatch и введен сертификат происхождения разработчика (DCO).
- Mozilla и GNOME создали формальные системы сортировки, исходя из того факта, что большинство входящих отчетов об ошибках необходимо фильтровать, прежде чем сопровождающие смогут потратить больше времени.
- Автоматизированные сканеры. Задолго до появления GenAI специалисты по сопровождению имели дело с волнами автоматизированных отчетов о безопасности и качестве кода из коммерческих инструментов сканирования и инструментов сканирования с открытым исходным кодом.
Вопрос сопровождающих часто был один и тот же: “Ты действительно пытаешься помочь мне или просто пытаешься помочь себе?“
Тот факт, что инструмент — будь то статический анализатор или LLM — упрощает создание отчета или исправления, не означает, что его вклад ценен для проекта. Легкость создания часто возлагает бремя на практикующего, поскольку существует дисбаланс преимуществ. Участник, вероятно, получает признание (или CVE, или видимость), в то время как сопровождающий получает бремя поддержки.
Операторы ощущают это на собственном опыте. Например:
- Curl прекратила свою программу вознаграждений за обнаружение ошибок после огромного количества отчетов о безопасности, созданных ИИ, на проверку каждого из которых уходили часы.
- Такие проекты, как Ghosty, движутся к модели внесения вклада только по приглашению, которая требует обсуждения, прежде чем принимать участие в коде.
- Многие проекты принимают четкие правила в отношении вкладов, создаваемых ИИ.
Это рациональная реакция на дисбаланс.
Что мы делаем на GitHub
В GitHub мы просто не видим, чтобы это происходило. Стабильность сопровождающего имеет основополагающее значение для открытого исходного кода и фундаментальна для нас. Как родина открытого исходного кода, мы несем ответственность за то, чтобы помочь вам управлять тем, что приходит через дверь.
Мы рассматриваем это с разных точек зрения: оказание немедленной помощи и движение к долгосрочным системным реформам. Часть из них касается инструментов. Что-то о создании четких сигналов, чтобы сопровождающие могли решить, где провести свое ограниченное время.
Функции, которые мы уже отправили
- Управление запросами на извлечение на уровне репо: дает разработчикам возможность ограничить создание запросов на включение только соавторами или вообще отключить запросы на включение. Хотя внедрение запросов на включение имело основополагающее значение для развития открытого исходного кода, сопровождающие должны иметь необходимые инструменты для управления своими проектами.
- Комментарии, прикрепленные к задачам: теперь вы можете закрепить комментарий вверху проблемы из меню «Комментарии».
- Баннер для уменьшения шума комментариев: получайте меньше ненужных уведомлений благодаря баннерам, которые побуждают людей отвечать или подписываться вместо того, чтобы оставлять шум вроде «+1» или «То же самое».
- Улучшение производительности запросов на включение: интервал запросов на извлечение был оптимизирован для большей скорости реагирования, а более крупные запросы на включение в новые файлы позволили ускорить реагирование на 67%.
- Быстрая навигация вперед: Простая сортировка ошибок для значительного повышения скорости просмотра и решения проблем в качестве сопровождающего.
- временные границы взаимодействия: вы можете временно установить период ограничения активности для определенных пользователей в общедоступном репозитории.
Также в ближайшее время: Перетащите запрос на удаление из пользовательского интерфейса.. Это позволит удалить спам и оскорбительные запросы на включение, чтобы репозитории оставались более управляемыми.
Эти улучшения направлены на сокращение накладных расходов на проверку.
Ищем следующие шаги
Мы знаем, что стены не создают сообщества. По мере того, как мы продумываем следующие шаги, мы фокусируемся на том, чтобы предоставить сопровождающим больше контроля, одновременно помогая сообществам открытого исходного кода защитить то, что работает.
Некоторые направления, которые мы изучаем совместно с сопровождающими, включают:
- стробирование на основе критериев: требование создания связанной задачи перед открытием запроса на включение или определение правил, которым должны соответствовать вклады, прежде чем их можно будет отправить.
- лучшие инструменты сортировки: потенциальное использование автоматической сортировки для оценки вкладов в соответствии с собственными рекомендациями проекта (например,
CONTRIBUTING.md) и поверхность, которая тянет запросы, должна быть первым, что привлечет ваше внимание.
Эти инструменты предназначены для помощи в принятии решений, а не для его замены. Обслуживающий персонал должен всегда держать ситуацию под контролем.
Мы также знаем о компромиссах. Ограничения могут несоразмерно повлиять на добросовестных участников, впервые вносящих вклад. Вот почему эти элементы управления являются необязательными и настраиваемыми.
Что мне больше всего нравится в открытом исходном коде, так это то, что когда сообщество упирается в стену, люди строят лестницы. Мы видим многое из этого прямо сейчас.
Специалисты по сопровождению всей экосистемы экспериментируют с разными подходами. Некоторые проекты перешли на рабочий процесс только по приглашению. Другие создают собственные действия GitHub для сортировки участников и оценки репутации.
Интересным примером является проект Мишель Хасимото «Ваучер». Он реализует явную систему управления доверием, в которой участники должны быть подтверждены доверенными сопровождающими, прежде чем участвовать. Это экспериментальный вариант, и некоторые аспекты будут обсуждаться, но он вписывается в длинную историю: от метрики доверия Advogato до кредитной системы Drupal и ядра Linux. Signed-off-by Цепь.
Кроме того, многие сообщества вкладывают значительные средства в образование и адаптацию, устанавливая четкие ожидания относительно того, кто может внести свой вклад. Например, сообщество Python уделяет особое внимание руководствам для участников, консультациям и четко обозначенным точкам входа. Kubernetes сочетает в себе эффективное управление с комплексной документацией и обучением участников, помогая новым участникам понять не только то, как вносить свой вклад, но и как выглядит полезный вклад.
Эти подходы не являются взаимоисключающими. Образование помогает добросовестным участникам добиться успеха. Ограждения помогают специалистам по обслуживанию управлять масштабированием.
Не существует единственного правильного решения. Вот почему мы рады видеть, как сопровождающие создают инструменты, соответствующие конкретным ценностям их проектов. Сообщества инструментов, созданные вокруг платформы, часто становятся испытательной площадкой для вещей, которые в конечном итоге могут стать функциями. Поэтому мы уделяем пристальное внимание.
Нам также нужно поговорить о стимулах. Если мы создаём только барьеры и ограничения, мы создаём крепость, а не рынок.
На данный момент концепция «вклада» на GitHub по-прежнему сильно ориентирована на авторство кода. В WordPress они используют написанные вручную «реквизиты» не только для кода, но также для написания, этапов воспроизводимости, пользовательского тестирования и поддержки сообщества. Он признает множество форм вклада, которые продвигают проект вперед.
Мы хотим выяснить, как GitHub может лучше выделиться и отметить этот вклад. Кто-то, кто постоянно тестировал проблемы или объединял PR-документацию, доказал, что понимает голос вашего проекта. Это признаки уверенности, которые мы должны проявлять, чтобы помочь вам быстрее принимать решения.
Расскажите нам, что вам нужно
Мы начали обсуждение в сообществе, чтобы собрать отзывы о направлениях, которые мы изучаем: поиске решений для борьбы с некачественными публикациями на GitHub.
Мы хотим услышать ваше мнение. Поделитесь, что работает для ваших проектов, где есть пробелы и что могло бы существенно улучшить ваш опыт поддержки открытого исходного кода.
Вечный сентябрь открытого исходного кода — это признак того, что стоит праздновать: больше людей, чем когда-либо, хотят принять участие. Объемы взносов будут увеличиваться – и это хорошо. Но так же, как ранний Интернет разработал свои собственные стандарты и инструменты для поддержания масштабного сообщества, открытый исходный код должен делать то же самое. Не путем поднятия разводных мостов, а путем предоставления специалистам по обслуживанию более качественных сигналов, лучшего оборудования и лучших способов использовать всю эту энергию для работы, которая продвигает их проекты вперед.
Давайте построим его вместе.
написал
