Так не случится. Чтобы "условный Google" мог отдать v4 адреса, они уже должны быть ему не нужны, что следует только из практического отсутствия v4 клиентов. К этому моменту отданные адреса будут уже никому не нужны.
Обычное. Скрипты зачастую пишут люди не сильно квалифицированные как программисты, поэтому чтобы игра не падала на каждой опечатке скриптовые движки лояльно относятся к некорректному коду. Но это не отменяет того что движок при этом должен сыпать warning'ами, и все они должны исправляться на этапе тестирования.
У Google был хостинг исходных текстов, и неплохой для своего времени. Что они с ним сделали? Похоронили. И вообще сомнительно, что из покупки ради "ключевого актива" получится что-нибудь хорошее, независимо от покупателя.
Promoted-каналы — это такой канал, на который вы автоматически будете подписаны при подключении к прокси, он будет закреплен наверху списка контактов/чатов и его нельзя удалить пока вы не отключитесь от данного прокси.
Пока есть свободные клиенты, никаких "нельзя удалить" конечно же не будет.
Самое большое число портов NAT — 65 тысяч (с уникальной комбинацией из IP-адреса источника и IP-адреса назначения), значит, столько же локальных адресов можно превратить в один публичный.
Это кто вам такое сказал? Нет никакой прямой связи между количеством портов на машине, осуществляющей трансляцию и размером сети за NAT'ом. Транслируемый поток определяется тройкой <локальный порт, удаленный адрес, удаленный порт>, соответственно основное практическое ограничение состоит в количестве одновременных соединений из сети за NAT'ом на единственный внешний хост: порт — их не может быть больше количества портов используемых для NAT. Т.е. технически можно NATить хоть /8 через один порт, но к google.com больше одного клиента одновременно подключиться не сможет.
Например, протоколы, которые появились раньше этого метода (например, FTP), могут работать через NAT нестабильно
Что значит "нестабильно"? FTP passive mode работает не менее стабильно чем любые другие tcp соединения, он их просто требует больше на одну операцию. Active mode стабильно не работает без специальной поддержки от машины, осуществляющей трансляцию.
а в «Яндексе» используют протокол во внутренних сетях
Стоит добавить что в Яндексе есть целые ДЦ на IPv6 only.
Быдлокодер, не быдлокодер — странно что вас это вообще беспокоит. Проекты которые пилятся в одиночку пишите хоть на брейнфаке — никому дела до вашего кода нет. А когда дело дойдёт до больших проектов и групповой разработке, понимание принципов грамотного проектирования кода придёт само и довольно быстро.
Я включил в таблицу пометку, позволяет ли сайт ещё DuckDuckGo индексировать свою заглавную страницу, в попытке показать, насколько тяжело приходится в наши дни новым поисковым системам.
На своих сайтах я вижу больше переходов с DDG чем даже с Яндекса, но ни разу не видел в логах их собственного краулера (только DuckDuckGo-Favicons-Bot/1.0 десяток раз в месяц, но это, судя по названию, не то). В Википедии написано что DDG использует массу источников, в том числе Bing, так что предполагаю что по факту заблокированность DDG в robots, к счастью, не сильно мешает его работе.
Приватные репы к опенсорсу не имеют никакого отношения.
Мы же говорили про issue, нет?
Нет. PR и issue отличаются только наличием патча.
Приведя в пример ситуацию из 90-х годов. Сейчас большинство вещей, что вы описали не нужно и не работает. Интерфейсы изучать не нужно, все запихнули в "настроки", ввести нужно только набор стандартных полей, например.
Вы невнимательно или избирательно читаете. Не собираюсь повторяться.
Для него это как бы… не проблема
Это проблема для его пользователей в этой стране. И что вы сейчас пытаетесь доказать я не понимаю — начиналось с того что "GH плохой, блокирует для России по требованию РКН", а закончилось тем что блокирование всего хостинга — не проблема.
Мне кажется, проявление позиции "сделайте для меня максимально удобно"
Не "для меня", а "для всех". Напомнить про цифры?
Самая главная киллер-фича — халявные приватные репы и ci
Ничего из этого не является киллер фичей.
Но если у вас в интересах freebsd и работа с нее, то в целом ничего удивительно.
Вроде количество интересных мне проектов хорошо видно и оно сильно больше одного, или у вас опять избирательное зрение?
Если вы считаете, что gitlab не вырос с того времени в размерах, учитывая, что как раз на это время пришли все основные его плюшки
вы, скорее всего, очень ошибаетесь
Считаю, поскольку, как я уже неоднократно говорил, на VCS хостинг идут к аудитории, а её на GL не было, нет и пока не предвидится. И проектов на GL я как не видел, так и не вижу. Что до плюшек, то никаких киллер фич там не появилось — он всего лишь немного причесался и приблизился по возможностям к лидерам рынка.
А актуальную разницу, если угодно, можно посчитать самому: посмотрим, например, на число репозиториев, в которые коммитили за последний месяц там и там. Берём список реп на GL, с сортировкой по last updated и промотаем все репозитории до "updated 1 month ago". Я получил 1460 страницу, это 1460 * 20 = 29k репозиториев. То же самое на GH делается (к слову о плюшках) простым поиском. 2.25M реп. Разница в 77 раз, два порядка.
К слову, если корректно сравнить данные из википедии, а именно отчёт GL на начало 2016 года и press страница GH на то же время, получим точную разницу в общем количестве реп, и это 546k vs. 31M = 56 раз (2 года назад). Выводы делайте сами.
Вот запретят в одной северной страные технологию vpn и github быстренько заблокирует доступ ко всем ее реализациям с этой страны
Это правда, и известно что всего лишь заблокирует, и при этом даже не тронет форки. Известно также что GitLab никуда не денется, иначе одна северная страна заблокирует его целиком. А что он сделает — заблокирует, удалит, или удалит сразу все копии — неизвестно. Зато известно что аналогов *-takedowns он не ведёт, так что что именно и с чем он сделал вы даже не узнаете. Итого, он в этом объективно строго хуже GH.
Я очень стесняюсь спросить, а в какие крупные проекты вы так контрьбьютили и что вы понимаете под "крупным проектом"?
А вы не стесняйтесь, мои аккаунты на github и openhub всем доступны.
Или отклонять все не по форме (и более того не по теме), как это делает, например, ansible (хотя это и ему не помогает)
Неправда. Специально для вас провёл эксперимент: https://github.com/ansible/ansible/pull/32473 — наступил себе на горло, поскольку у ansible как раз абсолютно адекватный шаблон, которым хочется пользоваться, и понятно зачем он нужен (робот по нему сортирует PR, которых тысячи), и сделал "не по форме". Приняли без вопросов менее чем за сутки, всего лишь с просьбой пользоваться шаблоном.
Создание аккаунта — это не проблема
Я доходчиво объяснил что (и почему именно) это проблема.
Мне сложно представить, зачем вы в состоянии потока серфите по github
Очень просто — обновляю пачку FreeBSD портов которые поддерживаю, получаю пачку патчей (где-то что-то сломали), засылаю в апстримы. Обновился clang во FreeBSD — ещё пачка, перешли на lld — пачка, добавили поддержку новой архитектуры — пачка, ужесточили требования к сборке — пачка. Это — будни, и я даже не говорю о таких квестах как прошерстить все накопившиеся в дереве патчи (28k штук) и заслать в апстрим всё до чего руки дойдут, или взять какой-нибудь распространённый антипаттерн и исправить его вообще везде.
это прямо подчеркивать, что вам проект не интересен
Странно как-то получается, на GH интересны, а на GL нет, по вашему так по какой угодно причине только не объективной. Я же подчёркиваю что не предоставление возможности контрибутить через GH — неуважение к контрибуторам.
Сборку можно делать в поддиректории проекта (честно говоря, ни разу не приходило в голову собираться где-то совсем снаружи), она же в глобальном ~/.gitignore.
А еще так же указали на то, что для крупных проектов скорее исключение, чем правило хостится на github.
Крупные проекты ну никак не релевантны "советам как оформлять open source проект". Они скорее антипример: во-первых, они вынуждены использовать более сложную инфраструктуру просто из-за объёма фидбэка от пользователей. Во-вторых, они неповоротливы и отягощены тоннами легаси, из-за чего могут до сих пор использовать и CVS, и свои кривые системы сборки, и устаревший стандарт C++, и что угодно. В-третьих, у них свои заморочки с инвесторами. И да, от этого страдают и разработчики, и контрибуторы, и пользователи, и аудиторию они теряют — контрибутить в таких монстров хочет и может далеко не всякий. И тем не менее, зеркало на GH среди них — скорее правило, чем исключение. И почти все (их тех у кого апстрим в git) таки принимают PR.
Ну так мы же говорим про регистрацию на крупном хостинге проектов. В наше время стоит завести аккаунты хотя бы на github, gitlab и bitbucket.
Ещё раз: gitlab и bitbucket это НЕ крупные хостинги. Человек, работающий с сотнями репозиториев на GH имеет шанс встретиться разве что с единицами проектов на GL/BB, так что на практике они ничем не отличаются от self-hosted решений — тот же оверхед, те же неудобства, та же пустота.
Мы говорим про gitlab/bitbucket или про интерфейсы из девяностых?
Мы говорим про не-GitHub в общем, а это суть одни и те же трущёбы, не очень подходящие для разработки F/OSS. Да, в GitLab нет кошмарных форм мантиса, зато есть регистрация, непривычный интерфейс и нет аудитории — не далеко ушёл. А self-hosted "крупные проекты" которые вы притянули — это как раз ещё и интерфейсы из девяностых во все поля: мантисы, багзиллы, траки и жиры.
И в github template используются для того, что бы описание было структурировано.
Нет, они нужны чтобы описание было полным и чтобы люди создающие первый в своей жизни PR не писали "у меня всё сломалось".
Конечно, вы можете заполнять это все так, как вы хотите, но тогда ваш issue даже не будут читать, а просто закроют с комментом "не по форме" в почти любом крупном проекте.
Спасибо за мнение, но я достаточно контрибутил и принимал патчи в крупные проекты чтобы утверждать что это неправда. Бюрократия в равной степени мешает как авторам проекта, так и контрибуторам, и от неё избавляются при малейшей возможности. Закрыть с комментом "не по форме" — это дикость и самодурство, я такого не встречал ни разу. Самые грамотные issue всегда оформлены без шаблонов, точно так чтобы максимально точно и ёмко описать конкретную проблему.
Истеричек же которые вместо разработки прыгают между хостингами из-за проблем других проектов, которые их никогда не коснутся (а тем более даже не разобравшись в сути проблем, и не осознавая что на другом хостинге ситуация не изменится), я просто не понимаю.
Проблема решаема. Все абсолютно так же, как в случае github
Не решаема, и не так же, просто потому что аудитория на два порядка меньше. Для большинства пользователей GitLab останется хостингом одного проекта (при этом на GitHub), ничего даже близко похожего на то что я описал не получится, пока существует GitHub.
А если вам настолько не интересен проект, что даже лень создать аккаунт
Вы невнимательно прочитали мой комментарий, если всё ещё пишете "даже лень создать аккаунт", как будто это пренебрежимо быстрое и лёгкое действие. Я повторюсь. Во-первых, оно само по себе необосновано тяжело, поскольку в общем случае это изучение нового интерфейса, заполнение формы регистрации, ожидание подтверждения и заполнение формы issue. Это минут 10 времени, за которое можно было сделать множество куда более полезных вещей плюс выпадение из потока. Во-вторых, если вы делаете это один раз, можете и не заметить, но представьте каково делать это десятки раз в день.
Как это работает? Вы заходите в github и ищете репозиторий с проектом? А те проекты, у которого bug tracker в другом месте, как с ними поступаете?
Я же написал: никак, мне жалко тратить на них время.
Опять же, а перед заполнением issue вы читаете issue template или просто как-то что-то напишите и все? А если читаете, то чем это отличается от 10 полей
Читаю. Даже не пытайтесь сравнивать issue template и монструозными формами всяких мантисов. Во-первых, template используются крайне редко, и это правильно, потому что для большинства issue не нужно ничего кроме заголовка и описания. Во-вторых, если template есть, в них будет только то что нужно конкретному проекту. Скажем, если это 3D движок, то будет поле с моделью GPU (что не все гордые самостоятельные трекеры позволяют), и по-прежнему ничего лишнего. В-третьих, issue в любом случае можно заполнить как хочется, и я не при каких обстоятельствах не буду, исправляя опечатку в README, заполнять полтора десятка полей, создавать и прикреплять патч, ещё и уникальное имя ему выбирая.
В том плане, что F/OSS разработка — это прежде всего сообщество, а сообщество — на GitHub. Игнорируя GH, вы теряете значительную часть аудитории, а оставшейся части усложняете взаимодействие с проектом, потому что люди привыкли что у них всё в одном месте — свои проекты, проекты за которыми они следят и в которые контрибутят, входящие и исходящие PR и issue, одна лента новостей, одно мобильное приложение, если оно нужно, и патч отправляется одной кнопкой без изучения нового инструмента и регистрации. И это место — GitHub, просто потому что он самый большой. Любой другой хостинг, понятно, из этой схемы вылетает: кто-то ради одного проекта не будет даже регистрироваться, кто-то отправит issue и забудет про него навсегда (и вы никогда не получите ответа на запрос дополнительных сведений о проблеме). Также вы теряете кучу интеграций, которые ориентируются, естественно, прежде всего на GH.
Поисковые запросы из google и в gitlab ищут.
В большинстве моих проектов в статистике трафика в Referring sites первой строчкой идёт сам github, с отрывом от google в разы.
Или вы из тех людей, которые ищут проекты сразу через поиск github?
Последнее время всё больше да, и не вижу в этом ничего плохого. Во-первых, там почти всё находится. Во-вторых, обычно я "ищу проекты" с целью заслать патч, а их у меня после 15 лет в СПО порой появляется десятками в день, и мне банально жалко тратить больше времени на регистрацию на очередном "не как у всех" хостинге, разбирательство в очередном "привет из 90-х" self-hosted багтрекере, ожидание писем подтверждения регистрации (когда-то иного выхода не было, и с тех пор у меня остался текстовый файл с 500+ таких учёток — половина сайтов уже мертва, к слову о self-hosted — но эта эпоха, к великому счастью, ушла навсегда) и заполнение issue формы из десятка обязательных полей, чем на собственно подготовку патча, поэтому проекты не представленные на GH мне не особо и интересны. В-третьих, в ленте и рекомендациях на GH, которые строятся на основе звёзд и follower'ов, порой проскакивают интересные проекты которые google мне никогда не покажет.
Колебательный процесс объясняется обычным недельным графиком и означает, по идее, большее проникновение IPv6 в домохозяйствах, чем в офисах.
Почему, можно намеренно попасть под санкции поисковиков и домен станет никому не нужен.
Так не случится. Чтобы "условный Google" мог отдать v4 адреса, они уже должны быть ему не нужны, что следует только из практического отсутствия v4 клиентов. К этому моменту отданные адреса будут уже никому не нужны.
MacOS там есть. А о странностях в статье о собственноручной сборке софта я не уверен что уместно заявлять.
В общем случае, конечно, не нужно ничего собирать, а можно поставить готовый пакет из репозитория своего дистрибутива:
https://repology.org/metapackage/pgmodeler/versions
Обычное. Скрипты зачастую пишут люди не сильно квалифицированные как программисты, поэтому чтобы игра не падала на каждой опечатке скриптовые движки лояльно относятся к некорректному коду. Но это не отменяет того что движок при этом должен сыпать warning'ами, и все они должны исправляться на этапе тестирования.
У Google был хостинг исходных текстов, и неплохой для своего времени. Что они с ним сделали? Похоронили. И вообще сомнительно, что из покупки ради "ключевого актива" получится что-нибудь хорошее, независимо от покупателя.
Пока есть свободные клиенты, никаких "нельзя удалить" конечно же не будет.
Ну как последний. На днях закончилась последняя сеть под раздачу — 185/8, это да, но если посмотреть графики RIPE: https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph то помимо 185/8 есть пул адресов из других сетей, в том числе возвращённые для выделения адреса, и их ещё дофига. При текущей динамике их, увы, хватит ещё на пару лет.
Это кто вам такое сказал? Нет никакой прямой связи между количеством портов на машине, осуществляющей трансляцию и размером сети за NAT'ом. Транслируемый поток определяется тройкой <локальный порт, удаленный адрес, удаленный порт>, соответственно основное практическое ограничение состоит в количестве одновременных соединений из сети за NAT'ом на единственный внешний хост: порт — их не может быть больше количества портов используемых для NAT. Т.е. технически можно NATить хоть /8 через один порт, но к google.com больше одного клиента одновременно подключиться не сможет.
Что значит "нестабильно"? FTP passive mode работает не менее стабильно чем любые другие tcp соединения, он их просто требует больше на одну операцию. Active mode стабильно не работает без специальной поддержки от машины, осуществляющей трансляцию.
Стоит добавить что в Яндексе есть целые ДЦ на IPv6 only.
То есть с одной стороны, можно менять свой IMEI и ни о чём не беспокоиться, с другой — можно подставить чужой IMEI и лишить человека связи.
Открытые компании не пытаются заявись исключительные права на интерфейс командной строки (Cisco vs. Arista).
Быдлокодер, не быдлокодер — странно что вас это вообще беспокоит. Проекты которые пилятся в одиночку пишите хоть на брейнфаке — никому дела до вашего кода нет. А когда дело дойдёт до больших проектов и групповой разработке, понимание принципов грамотного проектирования кода придёт само и довольно быстро.
На своих сайтах я вижу больше переходов с DDG чем даже с Яндекса, но ни разу не видел в логах их собственного краулера (только DuckDuckGo-Favicons-Bot/1.0 десяток раз в месяц, но это, судя по названию, не то). В Википедии написано что DDG использует массу источников, в том числе Bing, так что предполагаю что по факту заблокированность DDG в robots, к счастью, не сильно мешает его работе.
Приватные репы к опенсорсу не имеют никакого отношения.
Нет. PR и issue отличаются только наличием патча.
Вы невнимательно или избирательно читаете. Не собираюсь повторяться.
Это проблема для его пользователей в этой стране. И что вы сейчас пытаетесь доказать я не понимаю — начиналось с того что "GH плохой, блокирует для России по требованию РКН", а закончилось тем что блокирование всего хостинга — не проблема.
Не "для меня", а "для всех". Напомнить про цифры?
Ничего из этого не является киллер фичей.
Вроде количество интересных мне проектов хорошо видно и оно сильно больше одного, или у вас опять избирательное зрение?
Считаю, поскольку, как я уже неоднократно говорил, на VCS хостинг идут к аудитории, а её на GL не было, нет и пока не предвидится. И проектов на GL я как не видел, так и не вижу. Что до плюшек, то никаких киллер фич там не появилось — он всего лишь немного причесался и приблизился по возможностям к лидерам рынка.
А актуальную разницу, если угодно, можно посчитать самому: посмотрим, например, на число репозиториев, в которые коммитили за последний месяц там и там. Берём список реп на GL, с сортировкой по last updated и промотаем все репозитории до "updated 1 month ago". Я получил 1460 страницу, это 1460 * 20 = 29k репозиториев. То же самое на GH делается (к слову о плюшках) простым поиском. 2.25M реп. Разница в 77 раз, два порядка.
К слову, если корректно сравнить данные из википедии, а именно отчёт GL на начало 2016 года и press страница GH на то же время, получим точную разницу в общем количестве реп, и это 546k vs. 31M = 56 раз (2 года назад). Выводы делайте сами.
Это правда, и известно что всего лишь заблокирует, и при этом даже не тронет форки. Известно также что GitLab никуда не денется, иначе одна северная страна заблокирует его целиком. А что он сделает — заблокирует, удалит, или удалит сразу все копии — неизвестно. Зато известно что аналогов *-takedowns он не ведёт, так что что именно и с чем он сделал вы даже не узнаете. Итого, он в этом объективно строго хуже GH.
А вы не стесняйтесь, мои аккаунты на github и openhub всем доступны.
Неправда. Специально для вас провёл эксперимент: https://github.com/ansible/ansible/pull/32473 — наступил себе на горло, поскольку у ansible как раз абсолютно адекватный шаблон, которым хочется пользоваться, и понятно зачем он нужен (робот по нему сортирует PR, которых тысячи), и сделал "не по форме". Приняли без вопросов менее чем за сутки, всего лишь с просьбой пользоваться шаблоном.
Я доходчиво объяснил что (и почему именно) это проблема.
Очень просто — обновляю пачку FreeBSD портов которые поддерживаю, получаю пачку патчей (где-то что-то сломали), засылаю в апстримы. Обновился clang во FreeBSD — ещё пачка, перешли на lld — пачка, добавили поддержку новой архитектуры — пачка, ужесточили требования к сборке — пачка. Это — будни, и я даже не говорю о таких квестах как прошерстить все накопившиеся в дереве патчи (28k штук) и заслать в апстрим всё до чего руки дойдут, или взять какой-нибудь распространённый антипаттерн и исправить его вообще везде.
Странно как-то получается, на GH интересны, а на GL нет, по вашему так по какой угодно причине только не объективной. Я же подчёркиваю что не предоставление возможности контрибутить через GH — неуважение к контрибуторам.
А это и есть персональная настройка, такая же как где собирать код. Кто использует поддиректорию в проекте тот и прописывает.
Сборку можно делать в поддиректории проекта (честно говоря, ни разу не приходило в голову собираться где-то совсем снаружи), она же в глобальном ~/.gitignore.
Не вижу разницы.
Вообще-то, в 250 раз: https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities#Popularity (и это при том что данные по gitlab там свежее почти на год).
Крупные проекты ну никак не релевантны "советам как оформлять open source проект". Они скорее антипример: во-первых, они вынуждены использовать более сложную инфраструктуру просто из-за объёма фидбэка от пользователей. Во-вторых, они неповоротливы и отягощены тоннами легаси, из-за чего могут до сих пор использовать и CVS, и свои кривые системы сборки, и устаревший стандарт C++, и что угодно. В-третьих, у них свои заморочки с инвесторами. И да, от этого страдают и разработчики, и контрибуторы, и пользователи, и аудиторию они теряют — контрибутить в таких монстров хочет и может далеко не всякий. И тем не менее, зеркало на GH среди них — скорее правило, чем исключение. И почти все (их тех у кого апстрим в git) таки принимают PR.
Ещё раз: gitlab и bitbucket это НЕ крупные хостинги. Человек, работающий с сотнями репозиториев на GH имеет шанс встретиться разве что с единицами проектов на GL/BB, так что на практике они ничем не отличаются от self-hosted решений — тот же оверхед, те же неудобства, та же пустота.
Мы говорим про не-GitHub в общем, а это суть одни и те же трущёбы, не очень подходящие для разработки F/OSS. Да, в GitLab нет кошмарных форм мантиса, зато есть регистрация, непривычный интерфейс и нет аудитории — не далеко ушёл. А self-hosted "крупные проекты" которые вы притянули — это как раз ещё и интерфейсы из девяностых во все поля: мантисы, багзиллы, траки и жиры.
Нет, они нужны чтобы описание было полным и чтобы люди создающие первый в своей жизни PR не писали "у меня всё сломалось".
Спасибо за мнение, но я достаточно контрибутил и принимал патчи в крупные проекты чтобы утверждать что это неправда. Бюрократия в равной степени мешает как авторам проекта, так и контрибуторам, и от неё избавляются при малейшей возможности. Закрыть с комментом "не по форме" — это дикость и самодурство, я такого не встречал ни разу. Самые грамотные issue всегда оформлены без шаблонов, точно так чтобы максимально точно и ёмко описать конкретную проблему.
А нигде лучше не будет. Так, GitLab прямо заявляют что с радостью удалят ваш проект: https://about.gitlab.com/dmca/. Что до "зашквара", так у вас нерепрезентативная выборка, так как про GitHub вы слышали звон, а про GitLab ещё нет. При этом GitHub придерживается прозрачности (https://github.com/github/dmca), чётко определяет политику (https://help.github.com/articles/dmca-takedown-policy/), отфутболивает невалидные претензии (https://github.com/github/dmca/blob/master/2014/2014-05-01-Pushwoosh-SDK-counternotice.md) и не удаляет форки. По мне так это выглядит куда более адекватно и надёжно чем писулька от GitLab, который даже не показывает ЧТО уже наудалял.
Истеричек же которые вместо разработки прыгают между хостингами из-за проблем других проектов, которые их никогда не коснутся (а тем более даже не разобравшись в сути проблем, и не осознавая что на другом хостинге ситуация не изменится), я просто не понимаю.
Не решаема, и не так же, просто потому что аудитория на два порядка меньше. Для большинства пользователей GitLab останется хостингом одного проекта (при этом на GitHub), ничего даже близко похожего на то что я описал не получится, пока существует GitHub.
Вы невнимательно прочитали мой комментарий, если всё ещё пишете "даже лень создать аккаунт", как будто это пренебрежимо быстрое и лёгкое действие. Я повторюсь. Во-первых, оно само по себе необосновано тяжело, поскольку в общем случае это изучение нового интерфейса, заполнение формы регистрации, ожидание подтверждения и заполнение формы issue. Это минут 10 времени, за которое можно было сделать множество куда более полезных вещей плюс выпадение из потока. Во-вторых, если вы делаете это один раз, можете и не заметить, но представьте каково делать это десятки раз в день.
Я же написал: никак, мне жалко тратить на них время.
Читаю. Даже не пытайтесь сравнивать issue template и монструозными формами всяких мантисов. Во-первых, template используются крайне редко, и это правильно, потому что для большинства issue не нужно ничего кроме заголовка и описания. Во-вторых, если template есть, в них будет только то что нужно конкретному проекту. Скажем, если это 3D движок, то будет поле с моделью GPU (что не все гордые самостоятельные трекеры позволяют), и по-прежнему ничего лишнего. В-третьих, issue в любом случае можно заполнить как хочется, и я не при каких обстоятельствах не буду, исправляя опечатку в README, заполнять полтора десятка полей, создавать и прикреплять патч, ещё и уникальное имя ему выбирая.
В том плане, что F/OSS разработка — это прежде всего сообщество, а сообщество — на GitHub. Игнорируя GH, вы теряете значительную часть аудитории, а оставшейся части усложняете взаимодействие с проектом, потому что люди привыкли что у них всё в одном месте — свои проекты, проекты за которыми они следят и в которые контрибутят, входящие и исходящие PR и issue, одна лента новостей, одно мобильное приложение, если оно нужно, и патч отправляется одной кнопкой без изучения нового инструмента и регистрации. И это место — GitHub, просто потому что он самый большой. Любой другой хостинг, понятно, из этой схемы вылетает: кто-то ради одного проекта не будет даже регистрироваться, кто-то отправит issue и забудет про него навсегда (и вы никогда не получите ответа на запрос дополнительных сведений о проблеме). Также вы теряете кучу интеграций, которые ориентируются, естественно, прежде всего на GH.
В большинстве моих проектов в статистике трафика в Referring sites первой строчкой идёт сам github, с отрывом от google в разы.
Последнее время всё больше да, и не вижу в этом ничего плохого. Во-первых, там почти всё находится. Во-вторых, обычно я "ищу проекты" с целью заслать патч, а их у меня после 15 лет в СПО порой появляется десятками в день, и мне банально жалко тратить больше времени на регистрацию на очередном "не как у всех" хостинге, разбирательство в очередном "привет из 90-х" self-hosted багтрекере, ожидание писем подтверждения регистрации (когда-то иного выхода не было, и с тех пор у меня остался текстовый файл с 500+ таких учёток — половина сайтов уже мертва, к слову о self-hosted — но эта эпоха, к великому счастью, ушла навсегда) и заполнение issue формы из десятка обязательных полей, чем на собственно подготовку патча, поэтому проекты не представленные на GH мне не особо и интересны. В-третьих, в ленте и рекомендациях на GH, которые строятся на основе звёзд и follower'ов, порой проскакивают интересные проекты которые google мне никогда не покажет.