Githubのオープンソースでの40日間の毎日の作業の印象

2013年10月1日の朝、 私のgithubページで行われた作業のオープンソースカレンダーは次のようになりました。



これは単なる偶然ではありませんでした。 毎日 Githubで何かをしようと長い間（ GTDの考慮事項に基づいて）意図的に決定し、（もしそうなら）Habrahabrでまさにそのような働き方の最も価値のある印象を共有することにしました（ カレンダー駆動開発と呼びましょう） ）インプレッションが蓄積されるとき。

そしてそれを共有します。

まず、 Githubの真夜中の重要性が増します。つまり、カレンダーに新しい灰色の四角が表示され、アクションで緑の塗り替えを開始できる瞬間です。 同時に、過去のGithubの日に対応する正方形の色も固定されています。これらの日中に何もする時間がなかった人は、それらに対して、「Current Streak」カウンターがリセットされます。 負け

私は今、Githubの深夜がモスクワ時間の11:00に来ることを心から知っています。 これは、 UTC + 4がモスクワで動作し、太平洋夏時間（現在はカリフォルニアで有効-昨年10月日曜日まで動作し続ける）がUTC-7に対応するという事実によって明らかに説明されています。

第二に、Githubの真夜中の後、新しい正方形を塗り直そうとする動機ができるだけ早く現れます。そのため、一日中、その灰色を心配する必要はありません。 これにより、小さなファイル編集の重要性が認識されるようになります。 通常、開発者は（セルフフォーカスのために）コードの主要な作業のみを行い、さまざまな小さな変更（「最新の変更を説明するドキュメントに別の段落を入力する」、「ドキュメント全体を段落全体に書く、またはあまりにも神秘的です”、“最近の機能をカバーする別の小さなテストを作成します”、“ CP808エンコーディングのサポートを、すでに1文字だけ異なるCP866エンコーディングをサポートしているモジュールに追加します”）off 時間をかけて蓄積すると、「このヒープを分解したくない！」と先延ばしになります。 カレンダー開発では、これらのささいなことの1つだけで「1日を始める」（より正確には、Githubの真夜中から1日を始める）理由があります。その結果、ささいなことは蓄積されません。 逆もまた同じです。完成した小さなものが十分にない日があります。 彼らがもたらす利益を見逃し始めます。

彼らの利点は何ですか？ それらが「流れの状態」への内部上昇のための準備ができたステップであること。 通常、「ストリームに」入るにはかなりの努力が必要です。開発者はプロジェクトのコンテキストに突入し、次のタスクを解決するために来ているアクションを心で把握する必要があります。 開発者は、ささいなことから始めて、ささいなものが属するプロジェクトのコンテキストに簡単に突入します。 この些細な問題を解消する作業は、今後のより大きな仕事のために心を「温める」（この手法は、体重がそれほど大きくないウェイトを持ち上げることにより、筋肉が「温まる」までボディビルダーが半ポンドのウェイトを持ち上げないようにすることができます） 。 涙なし。

しかし、 GTDのルール 「 先送りしない」 と「小さなビジネスを始めて、そこに参加する」はすでに広く知られています。 カレンダー駆動型の開発は、これらのルールに従うことを完全に自然にします。開発者は、これらのルールを覚えたり、強制的に従わせるための特別な努力をすることはありません-それどころか、ゲームのルールから必然的に従う既製のゲーム技術としてそれらを知覚しますカレンダーで。 灰色の四角をすばやく緑にするには、今日の編集をささいなことから始めます。したがって、明日の翌日にそれを延期しないでください。 ツーインワン。

開発者は毎日プロジェクトに時間を割く必要があると考え、GTDの実践では「部分的に象を食べる」と呼ばれる（そしておそらくEvernoteがロゴを所有している）小規模な実行可能なサブタスクに大きなタスクを分割するスキルを「ポンプアップ」します。 この画像の芸術的な力を変えるには、「カバをかむ」などのフレーズを使用できます。

Githubのカレンダーを使用したこのようなゲームのルールには微妙な違いがあります。 たとえば、フォークコミットはカレンダーの四角を緑化しません （コミットはメインリポジトリに到達したときにのみカウントされます-さらに、デフォルトブランチまたはgh-pagesブランチにのみカウントされます）。 しかし、マージ要求（プル要求）の開始 -緑の四角。 これは、リクエストを遅延させないためのヒントです。

このゲームでは、残念ながらごまかすことができます。 カレンダーの問題（問題）の緑色の四角に関するメッセージを開きます。 オープンソースの開発者がGithubカレンダーで「プレイ」して、ページの次の日の四角を緑にするためだけに作成された軽度の問題（または誤ったメッセージ）に関するメッセージで互いに衝突するのは望ましくありません。 これは不正行為であり、完全に不要です。 開発者の勤務日や空き時間がどれほど忙しくても、彼はGithubで本物の（偽物ではない）些細なことを30分だけ見つけることができます。

確かに、アプリケーションを開発者自身に送信することは、Githubを画像ホスティングサービスとして使用する優れた手段となります 。 プロジェクトのリポジトリにスクリーンショットを入れたくないと仮定します（コードが開発されると、スクリーンショットのビューが変わるため、リポジトリはすべてのバージョンを格納することで容認できないほど大きくなる可能性があります）。 一方、このスクリーンショットはREADMEで役立ちます。 どうする 外部画像ホスティングのサービスに頼るか、問題レポートにイラストを添付し 、そこから画像のURLをコピーしてREADMEに貼り付けることができることを忘れないでください 。 同時に、カレンダーの次の四角をアクションで緑化します。

すべて自分で試すことができます。

主なことを覚えておいてください：Githubだけでなく、そのようなカレンダー（その日までのハードスタートを含む）だけでガイドすることができます。 私はまだ同様の労働会計のツールに会いませんでした （その日の特定の時間にカレンダーに新しい灰色の正方形が自動的に現れ、労働の量に応じて正方形の緑が増します）が、時間の経過とともに必然的に現れます。