Впечатления от сорокá дней ежедневной работы над открытым исходным кодом на Гитхабе

    Утром 1 октября 2013 года календарь проделанной работы над открытым исходным кодом, расположенный на моей гитхабовской странице, выглядел вот как:

    [скриншот календаря]

    Это не было простой случайностью. Я нарочно решил (руководствуясь GTD-соображениями) достаточно долгое время стараться каждый день чего-нибудь делать на Гитхабе, а затем (если дело пойдёт) поделиться на Хабрахабре наиболее ценными впечатлениями от именно такой манеры работы (назовём её, скажем, calendar-driven development), когда впечатления накопятся.

    И поделяюсь.

    Во-первых, возрастает ощущаемое значение гитхабовской полуночи то есть того сáмого мгновения, когда на календаре появляется новый серый квадратик и его можно начинать перекрашивать в зелёный цвет своими действиями. В этот же момент фиксируется и цвет квадратика, соответствующего предыдущим гитхабовским суткам — и кто не успел за эти сутки ничего сделать, для тех счётчик «Current Streak» обнуляется. Проигрыш.

    Я знаю теперь наизусть, что полночь на Гитхабе наступает в 11:00 по московскому времени. Объясняется это, по-видимому, тем, что в Москве действует время UTC+4, а Тихоокеанское летнее время (сейчас действующее в Калифорнии — оно продолжит действовать до последнего октябрьского воскресенья) соответствует UTC-7.

    Во-вторых, появляется мотивация как можно скорее после гитхабовской полуночи перекрасить новый квадратик, чтобы затем целые сутки не беспокоиться о его серости. Это приводит к росту ощущаемой значимости мелких правок в файлах. Обычно у разработчика есть соблазн (для ненарушения самососредоточенности) делать только основную работу над кодом, а разнообразные мелкие правки (задачи наподобие «набрать ещё один абзац в документации, описывающий последние изменения», «разжевать краткую пометку в документации до целого абзаца, а не то она чрезмерно загадочна», «сочинить ещё один небольшой тест, покрывающий недавно появившиеся возможности», «добавить поддержку кодировки CP808 в модуль, ужé имеющий поддержку кодировки CP866, отличающейся всего-навсего на один символ») откладывать «на потóм», хотя накопление их со временем вызывает естественную реакцию «я не хочу разбирать эту кучу!» и прокрастинацию. При календарной разработке появляется повод «начать день» (точнее, начать сутки после гитхабовской полуночи) именно с одной из этих мелочей — в итоге мелочи не накапливаются. И даже наоборот: случаются такие дни, в которых готовых мелочей недостаёт. Начинает не хватать пользы, ими приносимой.

    В чём эта их польза? В том, что они являются готовою ступенькою для внутреннего подъёма к «состоянию потока». Обычно для вхождения «в поток» требуется существенное усилие: разработчику приходится погрузиться в контекст проекта, а затем охватить умом действия, предстоящие для решения некоторой очередной задачи. Начиная же дело с мелочи, разработчику проще погрузиться в контекст того проекта, к которому принадлежит мелочь; а работа над устранением этой мелочи одновременно как бы «разогревает» его ум под более крупную предстоящую задачу (можно уподобить этот приём воздержанию любителя бодибилдинга от подъёма полуторапудовой гири до тех пор, пока мускулы не окажутся «разогреты» поднятием тяжестей, имеющих менее существенный вес). Нет надрыва.

    Впрочем, GTD-правила «не откладывай» и «начинай дело понемногу, а там втянешься» и без того известны широчайше. Calendar-driven development (календарная разработка) просто делает следование этим правилам совершенно естественным делом: разработчик не прилагает специальных усилий для того, чтобы вспомнить эти правила или затем принудить себя следовать им — напротив, воспринимает их как готовые игровые приёмы, неизбежно следующие из правил игры с календарём. Чтобы побыстрее озеленить серый квадратик, начни сегодняшние правки с мелочи — тем самым и не отложи её на послезавтра. Два в одном.

    Поставив себя перед необходимостью уделять некоторое время проекту ежедневно, разработчик «прокачивает» и тот навык разбиения крупных задач на посильные ежедневные подзадачи меньшего масштаба, который в GTD-практике называется «есть слона по частям» (и которому, вероятно, Evernote обязан своим логотипом). Для изменения художественной силы этого образа можете использовать словосочетание «пережёвывать бегемота», например.

    В правилах такой игры с календарём на Гитхабе есть нюансы. Например, коммиты в форк не озеленяют квадратик в календаре (коммиты засчитываются только при попадании в основной репозиторий — более того, только в его ветку по умолчанию или в ветку gh-pages). Зато открытие запроса на слияние (pull request) озеленяет квадратик. Это намёк не оттягивать запросы.

    В этой игре можно и плутовать, к сожалению. Открытие сообщения о некоторой проблеме (issue) озеленяет квадрат в календаре. Я не желал бы того, чтобы разработчики открытого кода, «заигравшись» в календарь на Гитхабе, бомбардировали друг друга сообщениями о незначительных проблемах (или вовсе некорректными сообщениями), создаваемыми только для того, чтобы озеленить квадрат очередных суток у себя на странице. Это читерство, причём совершенно не нужное. Каким бы загруженным не был рабочий день и свободное время разработчика, а уж полчаса найти на какую-нибудь реальную (а не поддельную) мелочь на Гитхабе он сможет, ведь на это даются целые сутки.

    Правда, отправка разработчиком заявки самому себе может зато стать прекрасным средством употребления Гитхаба в качестве хостинга изображений. Предположим, что вам не хочется помещать в репозиторий своего проекта некоторый скриншот (в том числе и потому, что по мере развития кода вид скриншота будет меняться, так что от хранения всех его версий может неприемлемо распухнуть репозиторий). Между тем этот скриншот был бы полезен в README. Что делать? Либо прибегнуть к услугам внешнего хостинга изображений, либо вспомнить о том, что к сообщениям о проблемах можно прилагать иллюстрации, после чего скопировать URL картинки оттуда и вставить в README. И заодно своими действиями озеленить очередной квадрат в календаре.

    Можете сами всё это попробовать.

    Пóмните главное: руководствоваться именно таким календарём (с жёстким началом суток и всё такое) можно не только на Гитхабе. Я не встречал пока ещё средств для аналогичного учёта труда (автоматическое появление нового серого квадрата в календаре в заданное время суток, нарастание зелёности квадрата в зависимости от количества труда), но они со временем неизбежно появятся.
    Поделиться публикацией
    Комментарии 43
      +3
      Забавно, насколько иногда сходятся мысли — я тоже начал так делать, и тоже в августе. (Посредине там отпуск, на морько ЭВМ решил не брать. Да, да, я оправдываюсь перед зелеными квадратиками.)

      Отличное средство для дополнительной мотивации, в самом деле.
        +2
        Это немного странно, но интересно. Использовал этот же календарь во время написания текста диплома (в мае), и правда ведь помогал: нужно было каждый день хоть абзац да написать.
          +39
          GTD по хабровски ;)

          image
            0
            Счастливый вы. У меня вот так совместно с работой не получается.
              +1
              Взгляните на эту картинку трезво, взгляните попристальнее — и Вы увидите, Вы поймёте тотчас же, что Wolf6969 всего-навсего отфотошопил мой календарь.

              (А не то, например, цифры были бы под ним другими.)

              Счастье ли в этом?
                +1
                Прошу прощения. Написал случайно в ветку, а не в основание. Этот комментарий предназначался вам с вашей настоящей историей коммитов.
                  0
                  А, тогда понятно теперь.
            –8
            А вот с коммитами комментариев на Хабр у автора похуже. Есть места по19 коммитов в один день в последние 100 дней, а есть 0:


            (Плотность коммитов любого автора можно посмотреть через юзерскрипт habrActivity.)
              +17
              как жутко выглядит ваш Хабр, что вы сделали с ним?
                0
                  0
                  Без него всё гораздо разреженее, но специально для Вас повторил скриншот на стандартном Х.:
                  imagehttp:

                  Я не встречал пока ещё средств для аналогичного учёта труда
                0
                коммиты засчитываются только при попадании в основной репозиторий — более того, только в его ветку по умолчанию или в ветку gh-pages


                Странно. То есть при политике master = stable держать steak в одиночку, без pull-request самому себе, не получится? напомните старику, какая у гитхаба предпотительная политика по стабильным/дев веткам — я почему-то был уверен что master обычно стабилен — с него же все рекомендуется кланировать?
                  –1
                  У самогó Гитхаба — политика GitHub Flow.

                  И она также (как и календарь) предполагает частые коммиты в master (aka stable).
                    +1
                    Github Flow, насколько я понимаю, подразумевает master = stable. Правильно ли я понимаю, что если я работаю над проектом в гордом одиночестве и не хочу каждый день радовать пользователей новыми непротестированными коммитами в мастер — то steak мне не светит?
                      0
                      Есть обходные пути.

                      Во-первых, можно новый код покрывать сразу и тестами. Настроить Travis CI, превратив каждый коммит в master-ветке в протестированный. (Пример.)

                      Во-вторых, пользователям можно рекомендовать брать итоги Вашего труда не из ветки master, а из источников кода, пополняемых Вами менее часто (в те моменты времени, когда в коде Вы уверены). На самóм Гитхабе для этой цели служит механизм GitHub Releases. У разработчиков модулей для этой цели служат внешние хранилища (в Node.js — npm; в Python — PyPI; в Ruby — RubyGems; ну и так далее).
                  0
                  Я что-то полгода не заходил в статистику, глянул хоть…
                  image
                    0
                    Тогда и я поделюсь =)
                    image
                      +1
                      Солиднее моего, молодцом!
                        +2
                        Раз уж такое дело — тоже есть что показать)
                        image
                        Жаль, только master учитывается
                          0
                          А с чего Вы взяли, что только master?
                          +7
                          Не забывайте, что роль играют только OS проекты. Я вижу ваш профиль иначе:

                          image
                          +2
                          В апреле отпуск был?
                        +3
                        У меня максимум получилось 20 дней, а вот у Qiang Xue, архитектора Yii, наверное, рекорд: github.com/qiangxue
                          +1
                          Я натыкался на треки у которых практически все дни были зелёные. Так что ИМХО до рекорда ему далеко :)
                            0
                              +2
                              Не пойдёт.

                              У него только 17 дней нынешний период ежедневной работы, 37 дней самый длинный.

                              (Даже я его превосхожу по этому показателю.)

                              А вот у Qiang Xue — 141 день.
                                –2
                                аа, вы про дни активности. Меня больше сама активность интересует
                              +1
                              а вот у Qiang Xue, архитектора Yii, наверное, рекорд
                              Longest Streak: 177 days
                              :)

                              Я бы, впрочем, предпочел видеть данные по неделям. То есть не за последние 7 дней, а вот прямо по неделям, чтобы с чистой совестью валять пень отдыхать в выходные.
                              +4
                              Согласен с автором на 90% т.к. сам использую такой же подход уже давно. Issues — это тоже шаг вперёд т.к. иногда бывают дни когда писать код не хочется, тогда просто запускается проект и ищутся ошибки в нем, или описываются фичи которые хочется сделать в будущем. Таких дней не много, так что особо плутовством на мой взгляд это не назовешь. Просто другой тип работы.

                              Вот мой трек:

                              image

                              В июле был отпуск, а предыдущий год «пропал» после смены работы :)
                                +2
                                image
                                Все испортили жесткие дни в июле с >90 коммитами :)
                                  +16
                                  Штука, которая нарисует в вашем календаре что угодно: github.com/gelstudios/gitfiti

                                  image

                                  Имхо, все-таки важнее что и куда ты коммитишь, нежели то, как часто ты это делаешь.
                                    +2
                                    Да ) Специально искал в каментах. Кто-то должен был это запостить
                                    +2
                                    Предложенная вами методика, calendar-driven development, реализуема на практике далеко не всегда. У меня на работе, например, используется достаточно распространенная схема с ветками master-develop и форком основного репозитория. Задачи достаточно крупные, логически и функционально законченные, в большинстве случаев выходящие за рамки 2-3 дней.

                                    Как бы мне не хотелось стимулировать себя закрашиванием квадратиков, если я начну отправлять мелкие PR-ы, то уже через полчаса будет «ай-йа-йа-й» от человека ответственного за кодревью — проверять достаточно больший, законченные по смыслу куски кода значительно проще.

                                    Да, моя работа — не оупенсорс, но, во-первых, многие проекты с открытыми искодниками придерживаются подобной схемы разработки, а, во-вторых, большинство хабравчан, я полагаю, всё-таки занято на ниве разработки коммерческого ПО с очень похожими требованиями к PR.
                                      +2
                                      Я знаю, какой буду делать проект на гитхабе — скрипт, чтобы убирать знаки ударения из текстов автора.
                                        +3
                                        Хабр поломал гитхаб? Я вижу розового единорога и сообщение об ошибке :)
                                          0
                                          Это временно. (Гитхаб починили ужé.) Случайное совпадение, вероятно.
                                          +3
                                          Вы меня простите, ибо не моё, но автор LeechCraft просил передать: image
                                            0
                                            Пожалуй возьму платный аккаунт для своих проектов.
                                              0
                                              Расскажите лучше о интересных проектах, которые стоит поддерживать.
                                                +1
                                                image

                                                Текущий мой трек. Это чисто заливы кода, Issue Tracker я не юзаю
                                                  +1
                                                  Немного моей истории про Форки. Тут было сказано что коммиты не засчитываются в Fork репозитарии. Это верно.

                                                  Но бывает это неудобно, когда репозитарий форкнут, но Пуллов в основной репозит не будет. Мое действие — я например в Support, и мне сбросили Fork статус
                                                    0
                                                    40 дней в русской традиции специфическая дата.
                                                    Проект еще жив?

                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                    Самое читаемое