Pull to refresh
89.58
Skillfactory
Онлайн-школа IT-профессий

Как мы потеряли 54 000 звёзд на GitHub

Reading time7 min
Views36K
Original author: Jakub Roztočil

К старту курса по Fullstack-разработке на Python рассказываем о том, как один из самых популярных репозиториев GitHub лишился десятков тысяч своих звёзд, а также о том, как помочь пользователям ваших решений избегать подобных ситуаций.


Как мы получили 54 000 звёзд на GitHub

10 лет исполнилось с момента первого коммита HTTPie для терминала. Это консольный HTTP-клиент с открытым исходным кодом, изначально он создавался для удобного взаимодействия с API из терминала.

С первой публичной версии, выпущенной 25.02.2012 в дождливом Копенгагене, проект размещался на GitHub, участником и фанатом которого я стал двумя годами ранее и даже носил футболки с октокотом. Это было ещё в те времена, когда на странице About GitHub гордо сообщалось о 0,00 $ венчурного финансирования и вкусном разливном пиве в офисе GitHub в Сан-Франциско.

Поэтому, когда я понял, что результаты тестирования моего API могут заинтересовать широкий круг разработчиков, выбор GitHub был очевиден, к нему возник интерес. Помню, как быстро HTTPie впервые стал главной ссылкой на Hacker News и расширилось его сообщество на GitHub.

Все эти годы мы делали проект лучше, привлекая к нему всё больше внимания. Он стал самым популярным API-инструментом на платформе, а его сообщество на GitHub выросло до 54 000 участников, поставивших звёзды, и более 1 000 наблюдателей.

HTTPie вошёл в число 80 самых популярных из 289 000 000 публичных репозиториев, опередив 99,99997203% репозиториев. Невероятно, как этот скромный инструмент привлёк столь большое внимание. И GitHub сыграл в этом важную роль.

Мы пользовались преимуществами «социального программирования» GitHub, а платформа извлекала выгоду из размещения на ней нашего популярного проекта. Возможно, нашу страницу на GitHub за последние 10 лет посетили миллионы разработчиков.

Это способствовало укреплению GitHub (Microsoft) как компании, которая заботится об Open Source ПО и сообществе. В общем, это были взаимовыгодные отношения.

Как мы потеряли 54 000 звёзд на GitHub

Но если ещё несколько недель назад вы были одним из тех 55 000 наблюдателей и участников, поставивших звёзды, то сегодня уже нет.

Что произошло?

Из-за неудачного стечения обстоятельств я случайно — всего на мгновение — сделал репозиторий проекта приватным. В итоге наше сообщество на GitHub, которое создавалось 10 лет, было каскадно удалено.

Что это значит?

Если вы сопровождаете проект, интегрирующий его работу с другими, или ранее подписались на получение уведомлений о httpie/httpie, вам придётся повторно стать наблюдателем репозитория. Кстати, недавно мы опубликовали релиз безопасности.

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

Почему вы сделали репозиторий приватным‽

Это, мягко говоря, особенность GitHub: когда репозиторий делается приватным, все наблюдатели и звёзды удаляются безвозвратно. Я даже знал об этом и, очевидно, не намеревался делать httpie/httpie приватным. Зачем же тогда я сделал это?

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

По ложному пути меня направило вообще-то совершенно не связанное с этим действие: я только что скрыл пустой README в своём профиле, сделав jakubroztocil/jakubroztocil приватным.

Для концептуальной модели GitHub пользователи и организации — очень похожие сущности в том, что касается профилей и репозиториев. В этом контексте и поскольку мне просто хотелось повторить это безобидное действие в профиле нашей организации, мой мозг переключился в режим автопилота.

В тот момент я не осознавал несоответствия в названии этого специального репозитория, содержащего README профиля, и отличия его для пользователей и организаций: name/name и name/.github.

Вот почему, не сознавая своей ошибки, я сделал приватным httpie/httpie, а не httpie/.github.

Но ведь есть подтверждение?

Да, есть окно подтверждения. Его цель — не дать пользователю совершить в подобной ситуации какую-нибудь глупость. В окне сообщается: «Вы навсегда потеряете все звёзды и наблюдателей этого репозитория». Звучит страшновато.

Проблема в том, что это окно выглядит одинаково — и для репозиториев без коммитов и звёзд, и для репозиториев с 10-летней историей, у которых 55 000 наблюдателей и участников, поставивших звёзды. Ещё там написано: «Предупреждение: это потенциально разрушительное действие».

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

Вопрос на 54 000 звёзд. В каком из этих двух диалогов подтверждение безопасно, а в каком — приводит к удалению сообщества с 10-летней историей?

Диалог должен быть более контекстуальным, и (снова перефразируем) в нём должны быть слова: «Вы сейчас удалите 55 000 подписчиков». Это, безусловно, заставило бы меня задуматься.

Сделать приватным легко, но переключить обратно…

Можете представить моё замешательство, когда я вернулся на страницу организации: не было видно не только пустого README, но и нашего самого популярного репозитория. 

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

Почему так долго? Именно столько времени заняло каскадное удаление на GitHub наших звёзд и наблюдателей за 10 лет. И остановить этот процесс было невозможно. Можно было лишь написать в службу поддержки GitHub, обновить страницу и дождаться, пока звёзды обнулятся. Только после этого снова сделать репозиторий публичным.

Почему в GitHub не восстанавливают репозитории?

Очевидно, в GitHub есть резервное копирование. И на самом деле последствия того, что репозиторий случайно сделали приватным, можно отменить. Команда GitHub сама однажды случайно сделала репозиторий приложения GitHub Desktop приватным, для себя они всё восстановили за нескольких часов. Вот как бывший генеральный директор GitHub объяснил эту ситуацию:

«Сегодня утром один из разработчиков случайно сделал репозиторий GitHub Desktop приватным. При переключении его обратно звёзды (и ещё кое-что) не восстанавливаются, поэтому мы восстанавливаемся из резервной копии БД. Вот и всё».

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

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

И ответ на вопрос «почему», к сожалению, неутешительный. В GitHub восстановят репозиторий, повреждённый из-за того, что его сделали приватным, но только если это один из их собственных проектов, а не проект какого-то сообщества. Последнее в лучшем случае получает от них твит.

Извлечённые уроки

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

1. Дизайн пользовательских интерфейсов

Не рассказывайте, а показывайте. Создавайте в окнах подтверждения диалоги, над которыми не надо думать. Когда пользователь своими действиями рискует что-то разрушить, не представляйте это как потенциальный сценарий, описывая его абстрактными словами, которые пользователю ещё нужно преобразовать в мысленные образы и придать им смысл. Особенно когда побочный эффект основного действия — каскадное удаление. Например, вот как мы подходим к этому в HTTPie для рабочего стола:

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

2. Дизайн базы данных

Применяйте удаление с возможностью восстановления. Все мы люди и совершаем ошибки; при удалении без возможности восстановления предусмотрите задержку.

3. Отношения с GitHub

Ошибка произошла на нашей стороне, и в GitHub чётко дали понять, что юридически они не обязаны помогать: тон наших десятилетних взаимовыгодных отношений задан в Условиях использования GitHub. Думать, что он определяется чем-то ещё, было наивно.

В конце концов, в GitHub часто предпринимают противоречивые действия, идущие вразрез с духом открытого ПО и сообщества, а затем отменяют их только из-за возмущения общественности. И у Microsoft, нынешнего владельца GitHub, несмотря на недавно обнаружившуюся благосклонность к Open Source, не всегда была отличная репутация.

Что дальше?

Мы по-прежнему надеемся, что в GitHub/Microsoft изменят своё отношение и в один прекрасный день восстановят сообщество проекта. Все данные и средства для этого у них есть. 

Мы также надеемся, что во избежание повторения подобного с другими командами в будущем будет улучшен пользовательский интерфейс и дизайн базы данных. Чем можете помочь вы? Поделиться этой историей и повторно стать наблюдателем или поставить звезду репозиторию. А я, наверно, пока перестану носить футболки с октокотом.

Эпилог

Несмотря на то, что наши звёзды на GitHub превратились в пыль, у HTTPie всё как никогда здорово. Из изначально второстепенного проекта недавно возникла компания, команда которой превращает HTTPie в платформу разработки интерфейса программирования приложений, самую лучшую, какая только могла получиться из HTTPie. 

Закрытую бета-версию HTTPie для веба и рабочего стола встретили отличными отзывами, и в ближайшие недели мы с нетерпением ожидаем запуска её публичной версии. Хотите быть в курсе всех событий? Присоединяйтесь к нашему сообществу в Discord или подписывайтесь на @httpie.

А мы поможем вам прокачать навыки или освоить профессию, востребованную в любое время:

Выбрать другую востребованную профессию.

Краткий каталог курсов и профессий

Tags:
Hubs:
+48
Comments58

Articles

Information

Website
www.skillfactory.ru
Registered
Founded
Employees
501–1,000 employees
Location
Россия
Representative
Skillfactory School