Open nat-brit opened 6 years ago
@nat-brit
Насколько срочно? Нужно ли запланировать на эту неделю?
Не уверен, на сколько это срочно, т.к. смотря в каком контексте нам нужен гитхаб с наведенным в нем порядком - для сайта? для блогов? Если так, и сайт и блоги - срочные задачи - то, видимо, сроки как-то должны быть связаны. Могу себе поставить в план, и заниматься в фоне вместе с приведением в человеческий вид с точки зрения Open source best practices, возможно, с помощью @codename-art , который как-то проговорился, что активничал в этой области. @Arteg0r @codename-art @mparkhomenko что нам нужно изменить в наших вакансиях, чтобы кандидатам было понятно, что проект с открытым кодом, и что в приоритете у нас специалисты, имеющие опыт разработки ПО с отрытым кодом?
@nat-brit @Arteg0r @rossul на этапе выбора более академичного подхода к организации работ в рамках наших направлений предлагаю:
Добавил простой milestone Неделя #4 и пометил им две задачи - обзорную ( #60 ) и координацию UTCORE (#61 ) - посмотрите как это выглядит. @Arteg0r к сожалению, хаб не шарит майлстоуны и тэги (лейблы) между репозиториями, поэтому варианты у нас такие:
В info так же необходимо создавать майлстоуны и для всех пунктов дорожной карты. Кроме того, в репозитории каждого направления должна присутствовать своя дорожная карта и майлстоуны к ней - это поможет публиковать планы направлений для последующего голосования по ним, а так же формировать отчеты перед стейкхолдерами DAC.
Таким образом вся структура работ по реализации DAC будет формироваться из:
Однако не стоит думать, что майлстоуны можно использовать только для отделения недель друг от друга. каждая задача может ссылаться на несколько майлстоунов (как и проектов, лейблов и исполнителей) - поэтому при желании можно создавать майлстоун для каждой фичи/состояния (например, сайта, кабинета, или прототипа) и метить им задачи в рамках направления данного репозитория (в каждом репозитории-направлении будут свои майлстоуны, между репозиториями они, к сожалению или к счастью, не шарятся, о чем я упоминал выше).
Посмотрите на отчеты Bitshares о состоянии сети - я хотел бы прийти к чему-то подобному, но сделать упор на направления. По мере роста их количества обзорные планы и отчеты будут разрастаться и будет вынуждены фокусироваться на по-настоящему интересных и важных задачах в рамках направлений.
@kkrupovich
что нам нужно изменить в наших вакансиях, чтобы кандидатам было понятно, что проект с открытым кодом, и что в приоритете у нас специалисты, имеющие опыт разработки ПО с отрытым кодом?
Явно указать в списке требований в вакансии.
Один кандидат говорит: "взял на себя смелость почитать документацию по проекту, надеюсь, так и было задумано" :) То есть, на мой вкус, добросовестный кандидат перед откликом, ну или собеседованием, изучил хоть сколько-то проект.
@nat-brit @kkrupovich
Насчет наведения порядка - на текущий момент не успел навести беспорядок у себя )
к сожалению, хаб не шарит майлстоуны и тэги (лейблы) между репозиториями
про майлстоуны: взял на заметку твои варианты, пока не могу выбрать
@nat-brit решили:
На объекты (задачи, документы, проч.) в ранее созданных репозиториях можно ссылаться как на "рабочие". Новые репозитории - имеют больше презентационный и организационный характер, позволяющий упростить вход в проект потенциальным участникам команды.
@kkrupovich @alecvert @Dima-Iron
Репозитории предназначены для знакомства с проектом. Пользователи, попадaющие сюда с сайта или через другие каналы чаще всего не будут знакомы с Гитхабом. Поэтому:
добавить в ABOUT (все о платформе, проекте - основные документы, дорожная карта, вопросы и ответы (FAQ), источник информации для маркетингового направления и PR)
@nat-brit @Dima-Iron @Arteg0r @alecvert
Все документы, попадающие в эти репозитории, должны быть понятными (т.е. редактура перед публикацией очень желательна)
гуглодок - основной инструмент для коллаборации вокруг документов. Коллаборация в рамках задач: документ создается в привязке ссылкой к конкретной задаче/задачам - ссылки из документа на источники (задачи) обязательна.
Итоговыми согласно точкам дорожной карты. Из промежуточных - отчеты.
итоговые версии документов, относящихся к конфигурации продукта (ТЗ - от концепции до спецификации + документация) публиковать в вики соотв. репозиториев)
В каждом готовом документе внизу указывать ссылку на репозиторий разработки и контакты (не обязательно руководитель направления, даже лучше, чтобы был отдельный человек, отвечающий за прием сообщений с гитхаба).
важно ссылаться за задачу, в рамках которой появился документ - все вопросы и контакты должны происходить в задаче по документу, а не в документе. На этапе работы в формате гуглодока, конечно же, удобнее обсуждать и комментировать непосредственно сам документ, однако в родительской задаче документа имеет смысл делать пояснения в случаях, когда изменения носят какой-то концептуальных характер, а не просто исправление ошибок.
Также указывать ссылку на группу в Телеграм (когда сделаем такую группу для всего проекта).
см. выше
Нужен ответственный человек, который будет вести эти репозитории .
возможно.
добавить в ABOUT
сделал
@nat-brit надо бы еще сформулировать методику работы с проектами, задачами и организации их в milestones в рамках этих новых репозиториев
сформулировать методику работы с проектами, задачами и организации их в milestones в рамках этих новых репозиториев
поставлю в задачу
@nat-brit
поставлю в задачу
На выходе должен быть регламент, подобный регламенту создания задач, но написать его можно предварительно в гуглодоке в рамках упомянутой @nat-brit задачи, а потом перенесено в wiki
@nat-brit @Arteg0r @alecvert
Нужно поработать с описаниями этих новых репозиториев (есть краткое описание, есть readme.md).
Дальнейшие шаги - думаем, что складывать в эти репозитории.
Насколько срочно? Нужно ли запланировать на эту неделю? @kkrupovich