Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Навести порядок на Гитхабе #58

Open
nat-brit opened this issue Jan 20, 2018 · 11 comments
Open

Навести порядок на Гитхабе #58

nat-brit opened this issue Jan 20, 2018 · 11 comments

Comments

@nat-brit
Copy link

nat-brit commented Jan 20, 2018

Насколько срочно? Нужно ли запланировать на эту неделю?
@kkrupovich

  • Наглядная и понятная организация всех внутренних документов
  • Работа по задачам (постановка и прием в работу под залог квалификационного токена)
@cptn-solo
Copy link
Contributor

@nat-brit

Насколько срочно? Нужно ли запланировать на эту неделю?

Не уверен, на сколько это срочно, т.к. смотря в каком контексте нам нужен гитхаб с наведенным в нем порядком - для сайта? для блогов? Если так, и сайт и блоги - срочные задачи - то, видимо, сроки как-то должны быть связаны.
Могу себе поставить в план, и заниматься в фоне вместе с приведением в человеческий вид с точки зрения Open source best practices, возможно, с помощью @codename-art , который как-то проговорился, что активничал в этой области. @Arteg0r @codename-art @mparkhomenko что нам нужно изменить в наших вакансиях, чтобы кандидатам было понятно, что проект с открытым кодом, и что в приоритете у нас специалисты, имеющие опыт разработки ПО с отрытым кодом?

@cptn-solo
Copy link
Contributor

cptn-solo commented Jan 22, 2018

@nat-brit @Arteg0r @rossul на этапе выбора более академичного подхода к организации работ в рамках наших направлений предлагаю:

  • считаем задачу Неделя #4/2018  #60 эталоном "обзорного" плана работ на неделю в разрезе потоков работ и направлений
  • обзорный план расставляет акценты (перечисляет критические задачи)
  • обзорный план детализируется в аналогичных задачах руководителей направлений и координаторов
  • детализированные планы в обязательном порядке должны ссылаться на задачи, выполняемые или формулируемые в процессе работ в рамках этих планов
  • в пределе (с) ни одна задача в наших репозиториях не должна формулироваться и/или выполняться вне привязки к milestone и/или задаче планирования той или иной степени детализации

Добавил простой milestone Неделя #4 и пометил им две задачи - обзорную ( #60 ) и координацию UTCORE (#61 ) - посмотрите как это выглядит. @Arteg0r к сожалению, хаб не шарит майлстоуны и тэги (лейблы) между репозиториями, поэтому варианты у нас такие:

  • либо надо GameDev (и все другие направления) планировать в Info для сведения в обзорном плане и майлстоунах,
  • либо в головном репозитории каждого направления вести свой недельный майлстоун, а в u-transnet/info - обзорный план и все, что касается самого UTCORE (включая его детальный план)

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

Таким образом вся структура работ по реализации DAC будет формироваться из:

  • доска проекта с общей дорожной картой (u-transnet, уровень организации, без майлстоунов - это просто перечень направлений и основных работ по ним, порядок следования направлений и работ - от более приоритетных к менее приоритетным)
  • обзорный план + майлстоун к нему (одна неделя = один майлстоун, см. Неделя #4) - каждую неделю в репозитории info (направление - платформа, UTCORE),
  • детальный план направления + майлстоун к нему - каждую неделю в головных репозиториях направлений:

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

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

@Arteg0r
Copy link

Arteg0r commented Jan 22, 2018

@kkrupovich

что нам нужно изменить в наших вакансиях, чтобы кандидатам было понятно, что проект с открытым кодом, и что в приоритете у нас специалисты, имеющие опыт разработки ПО с отрытым кодом?

Явно указать в списке требований в вакансии.

Один кандидат говорит: "взял на себя смелость почитать документацию по проекту, надеюсь, так и было задумано" :) То есть, на мой вкус, добросовестный кандидат перед откликом, ну или собеседованием, изучил хоть сколько-то проект.

@Arteg0r
Copy link

Arteg0r commented Jan 22, 2018

@nat-brit @kkrupovich

Насчет наведения порядка - на текущий момент не успел навести беспорядок у себя )

к сожалению, хаб не шарит майлстоуны и тэги (лейблы) между репозиториями

про майлстоуны: взял на заметку твои варианты, пока не могу выбрать

@cptn-solo
Copy link
Contributor

cptn-solo commented Jan 24, 2018

@nat-brit решили:

  • создать 6 репозиториев для закрепления в шапке организации (новые репозитории, нацеленные на внешнюю аудиторию):
    • ABOUT (все о платформе, проекте - основные документы, дорожная карта, вопросы и ответы (FAQ), источник информации для маркетингового направления и PR)
    • CONTRIBUTE (задачи, ищущие исполнителя - сформулированные верхнеуровневые задачи/вакансии с бюджетом)
    • UT-CORE (ядро, блокчейн, интерфейсы - info, codebase, gateway, etc.)
    • UT-GAME (игровая платформа - gamedev, gameop, gamestrat)
    • UT-KIT (создание прототипов - transnet-sumulator)
    • UT-SCHOOL (обучение, введение в блокчейн - новое направление)

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

@nat-brit
Copy link
Author

nat-brit commented Jan 24, 2018

@kkrupovich @alecvert @Dima-Iron

Репозитории предназначены для знакомства с проектом. Пользователи, попадaющие сюда с сайта или через другие каналы чаще всего не будут знакомы с Гитхабом. Поэтому:

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

добавить в ABOUT (все о платформе, проекте - основные документы, дорожная карта, вопросы и ответы (FAQ), источник информации для маркетингового направления и PR)

@cptn-solo
Copy link
Contributor

cptn-solo commented Jan 24, 2018

@nat-brit @Dima-Iron @Arteg0r @alecvert

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

гуглодок - основной инструмент для коллаборации вокруг документов. Коллаборация в рамках задач: документ создается в привязке ссылкой к конкретной задаче/задачам - ссылки из документа на источники (задачи) обязательна.

Итоговыми согласно точкам дорожной карты. Из промежуточных - отчеты.

итоговые версии документов, относящихся к конфигурации продукта (ТЗ - от концепции до спецификации + документация) публиковать в вики соотв. репозиториев)

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

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

Также указывать ссылку на группу в Телеграм (когда сделаем такую группу для всего проекта).

см. выше

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

возможно.

добавить в ABOUT

сделал

@nat-brit надо бы еще сформулировать методику работы с проектами, задачами и организации их в milestones в рамках этих новых репозиториев

@nat-brit
Copy link
Author

сформулировать методику работы с проектами, задачами и организации их в milestones в рамках этих новых репозиториев

поставлю в задачу

@cptn-solo
Copy link
Contributor

@nat-brit

поставлю в задачу

На выходе должен быть регламент, подобный регламенту создания задач, но написать его можно предварительно в гуглодоке в рамках упомянутой @nat-brit задачи, а потом перенесено в wiki

@cptn-solo
Copy link
Contributor

cptn-solo commented Jan 26, 2018

@nat-brit @Arteg0r @alecvert

screen shot 2018-01-26 at 18 12 18

Нужно поработать с описаниями этих новых репозиториев (есть краткое описание, есть readme.md).

screen shot 2018-01-26 at 18 11 45

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

@nat-brit
Copy link
Author

Переходим к задаче #65 @kkrupovich

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants