Impressions of forty days of open source daily work on GitHub.

On the morning of October 1, 2013, the calendar of the work done on open source, located on my gitkhabovskaya page , looked like this:



It was not a mere coincidence. I deliberately decided (guided by GTD considerations) for quite a long time to try to do something every day on GitHab, and then (if things go) to share at Habrahabr the most valuable impressions of just such a manner of work (let's call it, say, calendar-driven development ) when impressions accumulate.
')
And share.

First, the perceived value of githabove midnight increases — that is, that instant when a new gray square appears on the calendar and you can begin to repaint it green with your actions. At the same time, the color of the square corresponding to the previous githabby day is also fixed - and who didn’t manage to do anything for that day, for those “Current Streak” the counter is reset. Losing

I now know by heart that midnight on Gietgub comes at 11:00 Moscow time. This is explained, apparently, by the fact that Moscow time is UTC + 4, and Pacific Summer Time (now operating in California - it will continue to operate until the last October Sunday) corresponds to UTC-7.

Secondly, there is a motivation to repaint a new square as soon as possible after a Gitkhab midnight so that you do not worry about its dullness for a whole day. This leads to an increase in the perceived significance of minor edits in files. Usually the developer has a temptation (for non-violation of self-concentration) to do only the main work on the code, and various minor edits (tasks like “type another paragraph in the documentation describing recent changes”, “chew up a short mark in the documentation to the whole paragraph, and not it is overly mysterious ”,“ to compose another small test covering recent opportunities ”,“ add support for the CP808 encoding to a module that already has support for the CP866 encoding that differs by only one character ”) off adhering “on sweat”, although their accumulation over time causes a natural reaction “I don’t want to disassemble this pile!” and procrastination. In calendar development, there is a reason to “start the day” (more precisely, to start the day after the midnight Githaby) with just one of these little things - as a result, little things do not accumulate. And even the opposite: there are such days in which there is a shortage of ready-made trifles. Begins to miss the benefits they bring.

What is their benefit? In that they are a ready step for an internal rise to the “state of flow”. Usually, entering a “stream” requires considerable effort: the developer has to immerse himself in the context of the project, and then wrap up with the mind the actions to be performed to solve some regular task. Starting a business with trivia, it is easier for a developer to immerse himself in the context of the project to which the trifle belongs; and the work on eliminating this little thing at the same time “warms up” his mind under a larger upcoming task (you can assimilate this technique to abstaining from an amateur bodybuilder from lifting a 1.5-puddle weight until the muscles are “heated” by lifting weights that have a less significant weight) . No strain.

However, the GTD rules “do not delay” and “start things a little, and then you will get involved” are already known most widely. Calendar-driven development (calendar development) simply makes following these rules completely natural : the developer does not make special efforts to remember these rules or then force himself to follow them — on the contrary, he perceives them as ready-made game techniques that inevitably follow the rules of the game. with a calendar. In order to quickly plant a gray square, start today's edits with trivia - and thus do not set it aside for the day after. Two in one.

Having faced the need to devote some time to the project on a daily basis, the developer “pumps” the skill of splitting large tasks into capable daily subtasks of a smaller scale, which in GTD practice is called “eating an elephant in parts” (and to which Evernote probably owes its logo) . To change the artistic power of this image, you can use the phrase “chew hippo”, for example.

There are nuances in the rules of such a game with a calendar on Github. For example, commits in the fork do not plant a small square in the calendar (commits are counted only when they hit the main repository - moreover, only in its default branch or gh-pages branch ). But the opening of the request to merge (pull request) - greens the box. This is a hint not to delay requests.

In this game, and you can cheat, unfortunately. Opening a message about a certain issue (issue) greens a square in the calendar. I would not want the open source developers, "playing around" on the calendar on Gitkhab, to bombard each other with reports of minor problems (or completely incorrect messages) created only to green the square of the next day on their page. This is cheating, and absolutely not necessary. No matter how busy the working day and free time of the developer, and only half an hour to find on any real (and not fake) change on Gitkhab he can, because it gives the whole day.

True, sending the application to the developer himself can, on the other hand, be an excellent means of using GitHub as an image hosting service . Suppose that you don’t want to put some screenshot into the repository of your project (also because as the code evolves, the screenshots will change, so the storage of all its versions may unacceptably swell the repository). In the meantime, this screenshot would be useful in the readme. What to do? Either use external image hosting services, or recall that you can attach illustrations to problem reports, then copy the URL of the image from there and paste it into the README. And at the same time, with your actions, plant another square in the calendar.

You can try it yourself.

Remember the most important thing: to follow this calendar (with a hard start of the day and all that) is possible not only on GitHub. I have not yet met the means for a similar accounting of labor (automatic appearance of a new gray square in the calendar at a given time of day, an increase in the greenness of a square depending on the amount of labor), but they will inevitably appear over time.