GitHub have just launched the Projects feature a whole 6 years after announcing it at GitHub Universe mid-2016!
For me this is huge, and I immediately made a 'meta planner' board and used another to plan my meals for the week (then closed it upon completion, "shipping" my grocery shopping).
Back in 2016 the hot kanban tool around was in Ruby, and I loved mine, but the commercial equivalent was Trello (which was OK but I didn't like all the pointing and clicking, and loved my weird little Dropbox-synced markdown config DevOps for Babies setup and the ability to add what GitHub now call 'autolinks').
At work last week I trialled a 'mini Kanban' approach to "single-piece flow" (the lean directive to keep to 1 WIP task) in which I
Besides reading the DevOps Handbook, the idea lodged in my mind after coming across the draft PR feature added to GitHub in 2019 (“GitHub ❤️'s your WIP”):
Been trying a technique the past few days of keeping a small whiteboard in 2 sections: “WIP” and “TODO”, and avoiding ever having more than 1 WIP (if something takes priority then the WIP has to go down to TODO). Nothing goes in WIP until it’s begun, and no high-level description
In practice the WIP entries become commit messages, and the overall effect is to prevent necessary prerequisites of tasks that appear during development from becoming ‘parenthetical parallel’ tasks — which subtly keep the context you’re working towards open (mentally/virtually)
This is not a planning technique but an execution prerequisite.
A little theory of language
Philosophers of language (JL Austin, GEM Anscombe) would refer to it as 'testimony' of 'practical knowledge'.
“holding true that one will φ, or that one will try to φ”
(where φ is the WIP).
Unlike speculative knowledge (belief), practical knowledge is that of intention: the act of intending φ brings about the execution of φ (making it a productive form of knowledge). The knowledge is the cause of the execution of φ.
Intuitively this makes sense: in particular the emphasis on "sustaining" the intention. If you momentarily forget your intention in doing something (at an immediate task level), and you seek to recall that from the environment, you have effectively paused from execution (in psychological terms you have interrupted your flow state).
Using GitHub Projects
GitHub Projects live on your account, and default to private.
When I was working with cloud-synced kanbans as a student, I used to long for the ability to go from a written note to a kanban, and this is possible in GitHub now via 'drafts' (which you create as free-floating single line TODOs).
You can elevate these 'drafts' to issues on a repo, for which I advise to create a dedicated general repo (I called mine meta).
To test it out I created a meal plan for the week, with a kanban column for each day of the week (the 'status'), and added entries for the meals or future shop visits for particular ingredients, and used markdown checklists in the body of each entry (all 'drafts'). This was surprisingly effective and once I was done I 'closed' the entire Project (this is hidden in Settings, either to avoid accidental use or as it's not a common task).
You can create multiple 'views' in tabs (either a list or a kanban board). It's not as feature complete as ZenHub (the filter toggles are much simpler), and checklists are slow to update, but it's overall more than enough for a single user.
The + icon on the table view's columns can add columns for Repository and Milestone,
which let you organise tasks by location and in time. Labels lets you add arbitrary tags.
All 3 of these are only available for issues not 'drafts'.
You can also import drafts from existing repos by searching with the # key.
When you do so, the repo you pick an issue from stays 'selected' after your issue
gets added to the Project, so you can easily add multiple issues from a repo in one go.
Unlike repos (whose URL includes the name), links to Projects are numbered (in the order you created them). Your first will be
https://github.com/users/USERNAME/projects/1/views/1
In the next section I'll discuss the specific requirements for personal development, and how to keep things under control and moving forward.
This post is part of Supporting and structuring personal development and open source contributions with GitHub Projects, a series covering how I began using the GitHub Projects tool for tracking my personal development and shipping outside of work. Read on for part 3, discussing how to structure your GitHub Project for success