К старту курса по 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.
А мы поможем вам прокачать навыки или освоить профессию, востребованную в любое время:
Выбрать другую востребованную профессию.
Краткий каталог курсов и профессий
Data Science и Machine Learning
Python, веб-разработка
Мобильная разработка
Java и C#
От основ — в глубину
А также
Комментарии (54)
napa3um
21.04.2022 02:06+2Я буквально несколько дней назад тыкнул звёздочку проекту и положил в закладки. Микрософт, ты хочешь, чтобы я повторно гонял заряды по проводам, выделял тепло трением кнопок и суставов в пальце? А нагретый эмоциями об этом тупом вахтёрстве стул? Счета за парниковые газы над планетой отныне можно отправлять в штаб-квартиру Микрософта. Откровенное «я одна, а вас много» вместо правильного уравновешивания сил корпораций перед незащищёнными гражданами - «клиент всегда прав» (должны быть сервисы для клиентов, а не клиенты для сервиса!). Капитализм себя изжил!
Микрософт однозначно должен был помочь. И исправить гуй и флоу работы с данными, чтобы исключить такое в будущем. Здоровья автору. Не удивлюсь, если в больничку загремел с серчишком.
rnd71
22.04.2022 00:02С чего Вы решили, что клиент всегда прав?
https://www.artlebedev.ru/kovodstvo/sections/87/ - вот ссыль на подумать над своими словами...
И завязывайте уже с этим пережитком.
napa3um
22.04.2022 00:57+2Подумайте внимательно, в чём же, по-вашем, Микрософт оказался более компетентным, чем клиент в описанной в статье ситуации? Что именно вы пытались аргументировать своей ссылкой об разграничении зон ответсвенности компетенциями участников?
Завязывайте уже с этим корпоративным раболепием :).
cypok
21.04.2022 02:58+27Please type httpie/httpie to confirm.
Я всегда думал, что это достаточная защита от глупостей.
napa3um
21.04.2022 03:27+2Да, наказание за глупость - это именно то, чем должна заниматься компания по отношению к своим клиентам. :)
DimNS
21.04.2022 05:15+31Этот текст легко копипастится на автомате, им надо сделать название репозитория картинкой, чтобы всегда вводили вручную
Я сам всегда копирую эту строку, потому что лень набирать )
rrrad
21.04.2022 08:37в CSS 5 есть возможност для того, чтобы отключить возможность копирования текста, что заставит либо открыть средства разработки, либо пользоваться плагином к браузеру, включающим копирование любого текста. В последнем случае пользователь сам должен поддерживать свою внимательность
tommyangelo27
21.04.2022 10:41+3Я сам всегда копирую эту строку
А зря :-) У меня была похожая история с копипастом email. Раньше в формах регистрации, где email нужно вписать дважды я всегда копипастил. Однажды, я вписал email с опечаткой, потом его скопипастил и зарегистрировался. Через неделю оказалось, что не могу сменить пароль, не могу сменить сам имейл без подтверждающего письма, не могу зарегать второй акк, потому что там привязка к персональным данным (типа номера ИНН), который должен быть уникальным.
В общем, я запомнил тот случай, и теперь всегда вручную вбиваю email в поле подтверждения :)
Popadanec
21.04.2022 12:02+4Никогда не понимал, почему некоторые ресурсы позволяют указать почту/телефон без подтверждения кодом/ссылкой.
Мало того что этим можно создать проблемы другим, так ещё и безопасность(а именно на неё чаще всего и упирают, когда предлагают дополнительно указать телефон/почту) от этого не повышается.
AVX
21.04.2022 23:56Почта? Берите выше! Можно взять кредит, и указать ЛЮБОЙ телефон в качестве резервного для связи, а свою симку выбросить. И на тот номер потом будут звонить коллекторы. Соответственно, если указать адрес, то и придут. Никто не подумает даже о подтверждении и согласии абонента об этом (и об этом прямо сказано в законах, как оказалось, что не нужно подтверждения).
selivanov_pavel
21.04.2022 06:02+18Нет, потому что когда работаешь с каким-нибудь пустым только созданным репозиторием, предупреждение абсолютно точно такое же.
Человеческий мозг так устроен, что мы запоминаем повторяющиеся рутинные действия и начинаем делать их автоматически. После выполнения таких действий с несколькими репозиториями начинаешь делать "выделить название в предупреждении - скопировать - вставить" уже на автомате.
Сам никогда об этом не задымывался, но автор статьи прав: явно потенциально сильно разрушительное действие (в духе, вы точно хотите удалить активно используемую базу данных большого объёма) должно выводить не просто "вы уверены, да/нет", а более подробное описание происходящего, с описанием того, что будет в результате потеряно.
slonopotamus
21.04.2022 11:24+1Человеческий мозг так устроен, что мы запоминаем повторяющиеся рутинные действия и начинаем делать их автоматически.
Сколько раз в день вы меняете видимость своих репозиториев?
Draedan
21.04.2022 12:41+3А с чего вы взяли, что частота сильно влияет на автоматизм?))
Я штук 10 только удалил в своей жизни в принципе личных репозиториев, и уже где-то на 3ем это было автоматическое действие- выделить мышкой, ctrl+c, ctrl+v, ок.
Я так еще один раз жесткий диск с личным архивом фото отформатировал) Вставил его в NAS, кликаю, кликаю, ок, ок, надпись- вы точно хотите отформатировать, ну я на автомате да, конечно. И через минуту я только осознал, что жесткий был не пустой...
sepulkary
21.04.2022 13:34GitHub при попытке смены типа репозитария с публичного на приватный предупреждает, какие минусы несет это действие, с пунктом про потерю всех звезд в том числе.
Но, видно, человек, ковырявшийся в настройках репозитария, был сильно утомлен и не обратил внимания на предупреждающую плашку.
13werwolf13
21.04.2022 06:50+3было бы лучше если бы этот текст нельзя было скопипастить, например выводить его в виде png
ryzhehvost
21.04.2022 13:09+1Задача защитить человека за ошибки, а не наказать за поспешность. А то что вы предлагаете - это именно последнее, попытка (не особо успешная, поскольку всё ещё можно копи-пастить из адресной строки) сделать работу неудобной, чтобы её нельзя было сделать быстро. Это плохой путь.
13werwolf13
21.04.2022 13:20соглашусь что поспешность человека это его личные проблемы. но всё же мне кажется что это неплохая идея, как вариант сделать её не принудительной, например в настройках профиля сделать переключалку plaintext/png чтобы пользователи знающие о том что у них руки чешутся смогли оставить себе "неудобный вариант" а пользователи самоуверенные переключили на текстовый. всё же вводя символы руками меньше шансов что не дойдёт "я удаляю не то репо" чем тупым копипастом
AVX
22.04.2022 00:09Нужно всё же ПОКАЗЫВАТЬ как-то интуитивно понятно и визуально, что будет, и что именно удаляется. Я имею плохую привычку удалять с shift+del, и было не один раз уже, что пути были похожи, но один - актуальные данные, второй - там где что-то экспериментировал с ними. И удалил не то. Просто вопрос "вы действительно хотите удалить /home/avx.../data/files/ ?" не помогает, когда у меня /home/avx/project1/movies/auto/2347987987/data/files и /home/avx/project1/movies/auto/2347987987_temp/data/files
А вот если бы мне при этом показали картинку со структурой, и выделена была та область, которую собираюсь удалить, это намного более действенно.
sepulkary
21.04.2022 13:35Что интересно, его и нельзя скопипастить, но только при попытке удаления репозитория.
edogs
22.04.2022 02:23+2Я всегда думал, что это достаточная защита от глупостей.
Уже нет.
Это из серии «никто не читает лицензионное соглашение».
Последнее время все сайты настолько приучили к тому, что «согласись принять печеньки, подтверди регион, пройди капчу, реши задачку, введи код» по каждому чиху, что практически на любое требование что-то подтвердить срабатывает условный рефлекс «подтвердить».
А разнообразие способов подтверждения на разных сайтах только усугубляет проблему, т.к. даже атипичный вид подтверждения не особо настораживает.
Тут же стандартное окно, схожее с безобидным запросом, сам запрос типичный. Немудрено ошибиться.
p.s.: Делали сайтик в конце прошлого года. У заказчика было требование — что бы в админке не было ни одного подтверждающего окна, но что бы любое действие можно было откатить хотя бы в течении 15 минут (не из бакапа с перезаливкой всего) и сам список всех действий был доступен. Объяснил тем, что с одной стороны подтверждать задолбало, с другой стороны подтверждаешь все настолько на автомате, что это абсолютно бессмысленно стало.
cypok
22.04.2022 08:17Почитал ветку, чувствую себя лохом: я всегда руками печатал. :(
Справделивости ради, надо заметить, что редко подобным занимаюсь, раз пять всего сталкивался с этим диалогом и он меня не успел задолбать.
agentf
23.04.2022 10:12Если вы упустили, автор заявляет, что незадолго перед этим он также скрывал README собственного профиля, где название репозитория соответствует имени профиля. И после этого автор, следуя той же логике, попытался сделать приватным README организации. На автомате.
paluke
21.04.2022 07:27+1А кроме звезд на гитхабе есть еще и форки. И с ними вообще интересно:
As with deleting a public repository, one of the existing public forks is chosen to be the new parent repository and all other repositories are forked off of this new parent.
То есть сейчас у кого-то другого куча форков…
Areso
21.04.2022 08:07Мне так однажды "достался" чужой проект, когда автор устал. Потом, спустя пару лет, он передумал, но теперь у проекта два набора форков.
TiesP
21.04.2022 08:25+11Довольно странная логика работы при смене типа проекта. Можно было бы просто «замораживать» состояние, не удаляя из базы. А при обратной смене всё возвращать. Ну хранилось бы немного больше лишних «звёздочек» в базе.
kryvichh
21.04.2022 10:08+8Автор проекта, ориентированного на консольное управление, нарвался на беспощадный GUI от GitHub... В этом что-то есть.
Zer0Sum
21.04.2022 10:28+3Ситуация скверная и вызывает сочувствие. Конструктивная критика в адрес гитхаба разумна и полезна, возьму эти замечания себе на заметку.
Однако лично для меня в этой ситуации есть ещё один пункт, который можно было бы добавить в "извлечённые уроки". Это напоминание о том, как важно порой просто "следить за мячом" - осознанно поддерживать минимальный уровень внимательности когда делаешь что-то. Иногда неудача не несёт в себе ценных уроков, а является результатом простой невнимательности, которой порой подвержен каждый, - и тут остаётся только пожать плечами, сказать "упс" и двигаться дальше.
Хорошо, когда удаётся извлечь дополнительный ценный урок, но лично для меня в такой ситуации, базовый урок №0 - это важность самой элементарной концентрации. Звучит банально, но если я буду игнорировать первопричину случившегося, потому что она наносит удар по моему эго, вероятность того, что нечто подобное повторится, будет выше, чем если я проглочу горькую пилюлю личной ответственности и через боль запомню это надолго.
napa3um
21.04.2022 10:42+3Извлечённый урок: человек лишь пылинка перед огромной корпорацией. Дрессировка раба прошла успешно. Уж простите меня за такую «коммунистическую» пропаганду, но ваше (и некоторых других тут отписывающихся) раболепие поражает. Это, блин, звёздочки на гитхабе, а не ракета в космосе или искусственное сердце. Это даже не ресурс самой компании, а усилия комьюнити (которые компания использует, предоставляя взамен ему тот самый «сервис»). Нет никакой причины тут оправдывать столь «поучительную» цену ошибки.
Кажется, многие программисты мечтают о технократии, фантазируя себя Верховным Инженером (или как минимум мегаинтеллектуалом, защищённым от человеческого фактора, «кек, сам дурак, я так не ошибусь»). Или это стокгольмский синдром? :).
QDeathNick
21.04.2022 13:25+1При чём тут раболепие, человек пишет, что надо работать, следя за уровнем концентрации. Точно так же можно и в децентрализованном хранилище уделать репу, потеряв концентрацию.
napa3um
21.04.2022 16:45А я пишу, что сервис надо делать для людей, прислушиваясь к клиентам, а не навязывать им их вину (будто это не Микрософт, а Святая Инквизиция). Более того, автор привёл пример, когда аналогичную проблему внутреннего сотрудника порешали (возможно, создав некоторые неудобства в том числе своим клиентам), а вот внешнему клиенту отказали (готовому даже заплатить за эту работу деньгами, а не только своей лояльностью). Т.е., проблема решаема, но выбрано было с высоты своего (около)монопольного положения забить на отдельного клиента. Это угроза и лично вам в конечном счёте, поймите :).
DimNS
22.04.2022 05:18+1Внешнему клиенту отказали по вполне понятным причинам: чтобы не создавать прецедент, стоит только один раз кому-то помочь и поддержку завалят такими просьбами по сотне в день (если не больше)
napa3um
22.04.2022 10:06А то мы не понимаем, почему. Удивляет только ваше сочувствие этим мотивам :).
Zer0Sum
21.04.2022 17:10Если со стороны выглядит, что я выразил позицию "дрессированного раба", значит, вероятно, я не правильно сформулировал свою мысль.
Пункты, которые касаются гит-хаба, прекрасно расписаны в исходном посте, и я с ними согласен.
Но все они относятся к внешним факторам, которые не всегда легко контролировать, как показывает этот конкретный случай. Я лишь дополнил список, указав на ещё один, внутренний фактор, над которым у меня обычно больше контроля, чем над внешними.
Подчеркну, что из моего указания на важность внутреннего фактора не следует, что я отказываюсь влиять на факторы внешние.napa3um
21.04.2022 20:15Но все они относятся к внешним факторам, которые не всегда легко контролировать
Но поднятый в статье вопрос именно в них заключается :). А все остальные личные "выводы" и страхи автор заработал уже автоматически, не прикладывая к этому никаких усилий, тут и обсуждать нечего, ибо прозвучит как назидание глупому ребёнку: "споткнулся, упал? ну поплачь, в следующий раз под ноги будешь смотреть внимательнее!". :)
ryzhehvost
21.04.2022 12:01+4> В каком из этих двух диалогов подтверждение безопасно, а в каком — приводит к удалению сообщества с 10-летней историей?
В левом - безопасно. Имя репозитория явно указано. Более того, вы должны руками ввести это имя для продолжения. На фоне всего этого утверждение, что
> Это, безусловно, заставило бы меня задуматься.
Выглядит голословным. Вы видели, и даже сами вводили, признаки того, что делаете что-то не то. Вас это не остановило. Что заставляет вас думать, что если бы признаков было не N, а N+1 - это заставило бы вас задуматься?
Вот то, что поддержка Github не пошла навстречу - это, конечно, очень печально. Чёрт с ним, что им плевать на одну отдельно взятую организацию, но выходит что им так же плевать на удобство всех пользователей, поставивших звёзды (и потерявших их) - и вот это конечно расстраивает. Я бы очень расстроился, если бы не нашёл нужный мне репозиторий среди моих звёздочек - иногда не помнишь конкретное название продукта, и ищешь по косвенным признакам... в вашем случае всё проще, проект крупный и есть надежда что те, кому он реально нужен - найдут его по названию.
konst90
21.04.2022 13:39+2Что заставляет вас думать, что если бы признаков было не N, а N+1 - это заставило бы вас задуматься?
То, что именно так и работает любая система предупреждений. Чем нагляднее предупреждение - тем меньше людей туда сунутся.
Например, как-то в Абхазии мы нарвались на заброшенное здание и хотели туда залезть. "Не входить, опасно" на воротах было нами проигнорировано, а вот большая надпись МИНЫ на дверях здания - уже нет. И мы не полезли.
Так и здесь. Предупреждение "вы закрываете репозиторий и потеряете 54 тысячи звезд без возможности автоматического восстановления" воспринимается иначе, чем "вы закрываете репозиторий xxx и потеряете все звезды". Особенно если "54 тысячи" будет написано большим кеглем.
Fodin
21.04.2022 19:38"Вы потеряете всю свою звезду" на полэкрана. Конфирм при уничтожении Солнца и репозитория с одним фолловером.
Fodin
21.04.2022 19:35Прочитал статью и
понялпочувствовал, что это Гитхаб виноват в потере звезд, а не авторы проекта. Сообщение о том, что для себя Гитхаб готов сделать несколько больше, чем для других, вообще вызвало лютую ненависть, ведь такое поведение неестественно и несправедливо! Пойду покормлю соседей.
xenon
22.04.2022 13:06Проблема в необратимости. (Причем, все таки обратимой при усилиях в исключительных случаях).
Мне кажется, при дизайне таких систем нужен особый подход.
Вариант 1 - предложенный в статье _deleted=true. Но тогда база засоряется мусорными записями и надо ее как-то чистить. К тому же надо аккуратно везде SELECT'ить, COUNT'ить и даже UPDATE'ить, чтобы избегать этих удаленных записей.
Вариант 2 - При удалении автоматически создавать какой-то "скрипт восстановления" (данные для него, список звезданувших в данном случае), который будет существовать еще день-месяц (потом удалится как протухнет), и его можно в крайнем случае запустить снова.
nmrulin
21.04.2022 23:17Кстати да, когда вываливаются предупреждения по каждому чиху, потом теряешь бдительность, когда действительно предупреждение нужно.
axilirator
21.04.2022 23:35У GitHub есть приоритеты важнее, чем возрождение сообщества одного из старейших и самых популярных проектов на платформе.
Это точно. Например, банить без разбора и предупреждения аккаунты тех, кто по их мнению работает на санкционные компании: https://habr.com/ru/news/t/661113/.
DirectoriX
22.04.2022 01:34+1Есть два типа пользователей: одним предупреждений раздражающе много (и они пишут статьи, что приходится слишком много тыкать мышкой), а другим предупреждений будет всегда мало, потому что они их не читают (как автор этой статьи).
Aleks_ja
Уже 17к поставили. Причём свежих и не растянутых на 10 лет, значит активных аккаунтов, возможно, там будет даже больше. Нормальный PR получился.
aborouhin
Ну да, вот я сейчас этот перевод почитал, софтинку поставил и звезду тоже. А то всё curl'ом POST-запросы посылал и куки сохранял. Раньше как-то не задумывался для этой задачи искать что-то отдельное, а тут увидел, вроде удобно.
jimquery
Postman попробуйте :)