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

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

К старту курса по 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.

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

  • Профессия Fullstack-разработчик на Python

  • Профессия Data Scientist

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

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

Data Science и Machine Learning

  • Профессия Data Scientist

  • Профессия Data Analyst

  • Курс «Математика для Data Science»

  • Курс «Математика и Machine Learning для Data Science»

  • Курс по Data Engineering

  • Курс «Machine Learning и Deep Learning»

  • Курс по Machine Learning

Python, веб-разработка

  • Профессия Fullstack-разработчик на Python

  • Курс «Python для веб-разработки»

  • Профессия Frontend-разработчик

  • Профессия Веб-разработчик

Мобильная разработка

  • Профессия iOS-разработчик

  • Профессия Android-разработчик

Java и C#

  • Профессия Java-разработчик

  • Профессия QA-инженер на JAVA

  • Профессия C#-разработчик

  • Профессия Разработчик игр на Unity

От основ — в глубину

  • Курс «Алгоритмы и структуры данных»

  • Профессия C++ разработчик

  • Профессия Этичный хакер

А также

  • Курс по DevOps

  • Все курсы

Источник: https://habr.com/ru/company/skillfactory/blog/662155/


Интересные статьи

Интересные статьи

Это продолжение истории Экваториальной Градусной экспедиции, в XVIII веке отправившейся к, как следует из названия, экватору, чтобы уточнить форму Земли.Измерение широтыОсенью 1739 года, не смотря на ...
Сегодня я расскажу вам как можно опубликовать своё Spring Boot приложение в GitHub Packages с помощью GitHub Actions. Вот так. В общем-то всё. Вот. Спасибо за внимание.
В 1998 г. мало кому известный стартап под названием Netflix, только что запустивший собственный сайт, платил своим сотрудникам значительно меньше рынка: в фирму семейного типа шли не ...
В прошлый раз мы рассказывали о картах, на которые нанесена разного рода аудиоинформация. Продолжаем тему музыкальных находок и говорим о сервисах, в которых можно «залипнуть». ...
Последние года 3 на давно сложившемся рынке спутниковой связи можно наблюдать приличный хайп вокруг проектов низкоорбитальных (НОО) спутниковых гиперсозвездий — телекоммуникационных систем, состо...