Интеграция Гитхаба с удобоваримым сервисом

[nat-brit]

Например, с https://asana.com/apps/github

Кто знаком в работой этого сервиса?

1. Изучить возможности
2. Схема документов, что и как там все интегрируется?
3. Что первично? Навести порядок на Гитхабе (#58) или делать одновременно и там и тут?
4. Сроки

@kkrupovich @rossul @netral23

[cptn-solo]

@nat-brit Я открыл, посмотрел бесплатный план, увидел там толи 5 толи 7 человек - и закрыл. Платные не смотрел. Любой сервис (включая, впрочем, гитхаб) - это не блокчейн, а сервис третьих лиц, которые могут диктовать любые условия, а нам потом устраивать миграцию, если условия вдруг станут неудобными/невыгодными. Как и сайт (доменное имя, блокировки). Это, конечно, максимализм, но по хорошему политика должна быть обратной - сервисы должны приносить доход нам, блокчейну, а не мы - сторонним сервисам. Но речь не о деньгах, а о целях, которые мы пытаемся достичь, вписываясь в чужие сервисы - Для начала надо понять, чего нам не хватает от гитхаба и подумать - как мы можем эту потребность удовлетворить. А потом анализировать сервисы. ИМХО. Например, мы совершенно не используем Milestones - а они, в числе прочего, позволяют увязывать изменения в коде с задачами (понимать, в рамках каких задач какие изменения вносились в код, конфигурацию продукта). Мы не читали и не изучали никаких толковых руководств по гитхабу, туториалов. Я уверен, что, какой бы сервис мы не выбрали, в нем так же желательно будет предварительно разобраться. Так почему бы не разобраться сначала с Github? Может, мы просто не умеем им пользоваться, либо в нашей работе не поставлены какие-то процессы, что и лишает работу над нашим продукт прозрачности?

Я за наведение порядка на гитхабе (#58) и за автоматизацию используемых нами workflow (skill->dev). В пределе - разработка своего, либо адаптация существующего децентрализованного инструментария для управления конфигурацией продукта (блокчейна, его программных и пользовательских интерфейсов, документации, бэклога) и проектами, связанными с изменением конфигурации (проекты разработки в рамках развития платформы и новых направлений). Но какой бы сервис мы не выбрали - важно помнить о том, что мы ориентируемся на то, что наши репозитории - это код платформы, которую другие команды могут клонировать под свои нужды и видоизменять. Предельная цель - получить рынок, основными игроками на котором будут DAC, подобные Bitshares и Transnet Space. Возможно, это мое вИдение миссии U-TECH, о котором говорил @rossul, и которое может отличаться от вИдения остальных членов команды.

[cptn-solo]

@nat-brit А зачем @netral23 ? Это, скорее, ближе к @Arteg0r и @codename-art

[nat-brit]

@kkrupovich @Dima-Iron

Предельная цель - получить рынок, основными игроками на котором будут DAC, подобные Bitshares и Transnet Space.

Важное в конце:) Именно. У нас сейчас упор по контенту идет на Transnet Space, в то время как упор должен идти на миссию и концепцию U-Tech. Из-за этого и недопонимание. Мне хотелось бы именно на этом сейчас сконцентрировать все усилия - описать стратегию и road map для U-tech и оттуда плясать с сайтом и задачами и всем прочим. Опять же вопрос по ЦА. Все-таки очень мало людей знакомы с организацией работы на Гит-хаб, включая меня и еще нескольких человек в команде. Кто и когда и в каком объеме будет пользоваться Гитхабом? Только ли команда? Или, когда мы говорим про открытую разработку, любой человек, попадающий сюда должен понимать, что тут происходит. Какой результат мы хотим получить?

Для начала надо понять, чего нам не хватает от гитхаба и подумать - как мы можем эту потребность удовлетворить. А потом анализировать сервисы. ИМХО.

Да.

Например, мы совершенно не используем Milestones - а они, в числе прочего, позволяют увязывать изменения в коде с задачами (понимать, в рамках каких задач какие изменения вносились в код, конфигурацию продукта). Мы не читали и не изучали никаких толковых руководств по гитхабу, туториалов. Я уверен, что, какой бы сервис мы не выбрали, в нем так же желательно будет предварительно разобраться. Так почему бы не разобраться сначала с Github? Может, мы просто не умеем им пользоваться, либо в нашей работе не поставлены какие-то процессы, что и лишает работу над нашим продукт прозрачности?

Достаточно ли, чтобы пару человек (ты, я, @alecvert...) прочитали, изучили и настроили? Или это каждому входящему в проект придется делать?

В пределе - разработка своего, либо адаптация существующего децентрализованного инструментария для управления конфигурацией продукта (блокчейна, его программных и пользовательских интерфейсов, документации, бэклога) и проектами, связанными с изменением конфигурации (проекты разработки в рамках развития платформы и новых направлений).

Возможно это стоит включить road map? Давайте обсудим.

[rossul]

Наверно стоит уточнить, что речь не о переезде с Гитха на что-то другое, а о том, что нужна платформа для управления проектом, которая работает с Гитом.

Гитхаб - репозиторий для кода и заточен на version control и процесс разработки и тестированиее софта. Он не удобен и не позиционирует себя как иструмент для менеджмента проектов. Самая простая аналогия - Jira как платфрома управления проектами у которой есть свой "а ля" Гитхаб - Bitbaket.

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

Вопрос беплатности сервиса - исключително вопрос выгоды. Если Jira или Asana, за $20 в месяц позовлят каждому члену команды съэкономить, скажем 10 часов, то, наверно, это того стоит.

[cptn-solo]

@nat-brit

Опять же вопрос по ЦА. Только ли команда?

Да, команда + любой независимый аудитор - потенциальный/реальный член сообщества/стейкхолдер. Это не маркетинговые материалы для привлечения внимания, это "первичка", первоисточник, исходный "код" конфигурации, к которому обращаются ПОСЛЕ того, как внимание привлечено. Это материалы для анализа, а не яркая и понятная вывеска.

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

Примерно так. Это коллаборация. Это не разработка фиксированным кругом лиц. Любой член команды может раствориться в закате в любой момент, у нас нет никаких формальных обязательств друг перед другом, лишь общность интересов и идеологии. Вопрос в том, как организовать эти потоки сознаний, придать им стройность, классификацию - но эти характеристики имеют смысл только в контексте конкретных ролей. Для разработчиков - все +- понятно просто потому, что они редко смотрят дальше своего репозитория и wiki. Для всех остальных, безусловно, нужно прикладывать усилия и организовывать потоки как работ и ресурсов, так и результатов. Возможно, с применением внешних инструментов. Но любой внешний инструмент сразу проведет толстую линию, отделяющую потребителей отчетов и прогнозов от непосредственных исполнителей той работы, продуктом которой является благосостояние каждого стейкхолдера децентрализованной корпорации. На мой взгляд, надо учиться работать как-то по-другому, без необходимости в мега-сервисах. Быть проще и автономнее. Например, ведение блогов руководителями направлений непосредственно в форме управленческих задач - на мой взгляд это круче, чем wiki :) (если выбирать из доступного в гитхабе)

Возможно это стоит включить road map? Давайте обсудим.

Кстати да, если этого там нет, то можно включить. Это можно даже оформить в виде направления со всеми вытекающими.

[cptn-solo]

@rossul

Наверно стоит уточнить, что речь не о переезде с Гитха на что-то другое, а о том, что нужна платформа для управления проектом, которая работает с Гитом.

Да, основное неудобство для внешних участников, видимо, именно в отсутствии инструментария управления проектом. Но выше в ответах @nat-brit я упомянул ~~притянутую за уши~~ проблему разделения аудитории на менеджеров и исполнителей. Ведь мы так можем далеко зайти - офис, бухгалтер, HR, тестовые задания и рекомендации с предыдущих мест работы ;) А потом внезапно раз - и у блокчейна случился форк, потому что команда решила что ей это не интересно, а то, что осталось в главной ветке - вообще выродилось в приватный блокчейн

Гитхаб - репозиторий для кода и заточен на version control и процесс разработки и тестированиее софта. Он не удобен и не позиционирует себя как иструмент для менеджмента проектов. Самая простая аналогия - Jira как платфрома управления проектами у которой есть свой "а ля" Гитхаб - Bitbaket.

Согласен.

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

Согласен. Просто не хочу полагаться на еще один внешний сервис и вообще - контрагента.

Вопрос беплатности сервиса - исключително вопрос выгоды. Если Jira или Asana, за $20 в месяц позовлят каждому члену команды съэкономить, скажем 10 часов, то, наверно, это того стоит.

Согласен.

Это вообще все достаточно очевидно, то о чем говорят @rossul и @nat-brit - не очевидна, видимо, моя мотивация. Субъективно, доверие материалам в гитхабе выше, чем в любом другом месте, это прямая ассоциация с "самым базовым уровнем". Все, что выше этого уровня - может быть значительно проще скомпрометировано. А раз мы находимся на территории блокчейн-проектов - траст для нас должен быть превыше всего. Но это ведь все только мое мнение, возможно, не совпадающее с мнением @nat-brit @alecvert и других членов команды.

[alecvert]

@nat-brit @kkrupovich @rossul коллеги, думаю что гитхабом нужно учиться пользоваться каждому участнику команды.

Согласен с Костей, мы работаем на блокчейн пространстве, и поэтому github упорядочивает нашу работу и показывает нашу открытость и серьезные намерения/планы, что важно для тех, кто нас поддерживает и будет поддерживать.

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

[cptn-solo]

@nat-brit @rossul @alecvert @Arteg0r С целью оптимизации процессов разработки было принято решение вынести процессы управления требованиями в Jira. Сейчас на примере биржи задач (UT-WORKS) мы попробуем организовать процесс сбора требований в формате User Story (задача в jira от @rossul). Плюс, у Atrassian есть некая программа в отношении Open Source, которую надо бы изучить и понять, на сколько она нам может быть интересна.