Using github project to manage my life - what i've learned.

Originally written in 2023-11-6 , rewritten in 2024-01-31

This post is a continuation of my endeavor to find a good way to manage my life. In this previous blog, I tried to build a text-based markdown style todo system, which somewhat worked for an academic quarter. However, the previous attempt quickly became very hard to use. Obsidian isn't the best tool for management. The best it can do without increasing operational complexity is creating simple lists, which will soon became hard to manage if you have many of such lists.

Table of content:

• Initiation
• Iteration 1: A rudimentary attempt
  • The basics
  • The project interface
• Iteration 2: The Current Form
  • The priority matrix-list
  • Additional views
• Future improvement

Initiation

During my internship this summer,I managed to learn a thing or two from the daily standup. Hiya chose to use Kanban boards, and they seemed quite effective at first glance. So, I decided to try them out for to-do management to see if things would work out.

While consulting with ChatGPT on this topic, I was excited to discover that GitHub itself has a project feature that includes Kanban boards and a whole suite of other project management tools. As an avid user of GitHub, I had to try it out. I spent my autumn quarter of 2023 on iteration 1 and refined my process during iteration 2, in the winter quarter of 2024."

Iteration 1: A rudimentary attempt

The basics

My first attempt involved carving out the basics. Following GPT's suggestion, issues were the obvious choice for the basic unit of tasks. Since GitHub projects are closely knit with repositories, I borrowed the idea I had during Hiya's hackathon to host things (issues) in a dedicated repository. Since I'm not good at naming things, I will just call it:

Same with the project:

I've also quoted one of my favorite sentence from Krzysztof Kowalczyk's "Lessons learned from 15 years of SumatraPDF, an open source Windows app"

Here is an example of my issue/todo:

Due to some automation reasons later on, I decided to limit the issue description to text only. Markdown to-dos were to be put in the first comment of the issue. Any logging text would then be added in comments, starting with the second comment. This acts like a commit; each time I make some change to this to-do, I log it. The logging ends after I close my issue. I hoped to use the logging as a motivational tool.

On top of these mechanisms, I also repurposed the milestone section as a way of categorizing these issues in the project view. A milestone can be a goal, as originally intended, or it can simply be a category, like a class I'm taking this quarter or a book list I'm going through.

The project interface

In the project interface, issues can have four possible statuses: Backlog, In Progress, On Hold, and Done. An issue starts in the Backlog and then moves back and forth between In Progress and On Hold until it ends up in Done, operating just like a regular Kanban board.

Issues are organized by iteration using the iteration template. Each week is one iteration. The iteration divides up the multitude of tasks I have and provides me with a sense of 'this is what I'm doing this week,' which, in turn, helps me to stay focused on my tasks.

Here's an example of what i see most of the time:

There are a total of six views in my project: Current Iteration, Current Iteration: Done, Next Iteration, Planning, Road Map, and Task Pile.

When going through my workflow, I first select a category of tasks I'm interested in reviewing, as shown in the previous image. The tasks then flow from left to right. Once I finish a task, I go into the issue and close it. This triggers the default automation of moving the issue to the 'Done' status upon closure.

example of issue in project view

the logic of closing issue automation

Similar automation is also applied to issue labeling. For instance, when an issue is edited, a label of last_worked_on will automatically be added, and the previously labeled last_worked_on issue will have its label removed.

Another example is the has_todo lable, if a issue have uncheck todos like so

• an example todo

a label of "have_todos" will be added.

.

These labeling automation is all done in github actions using yml files and various scripts.

Iteration 1 was going well until it encountered a problem similar to the one with the Obsidian method: priority ordering. My tasks were still prioritized based on urgency, and I was left feeling unfulfilled. I constantly felt like I was doing busy work. Moreover, GitHub decided to add timeline items into the GitHub Project's issue view, which practically ruined my workflow. My automation, along with the rule '1st comment for to-do and 2nd+ comments for logging', no longer worked. So, these changes jump-started iteration 2.

Iteration 2: The Current Form

For iteration 2, I decided to go back to the Eisenhower matrix that i mentioned here. I consulted this article to learn about the difference between urgency and importance, and came up with the following ideas:

The priority matrix-list

Here is the priority list I made stemming from the Eisenhower matrix:

As you can see, I did not use the classic 'Do, Schedule, Delegate, and Delete.' This is because the original wording does not make sense in a 'white-collar job' scenario. The Eisenhower Matrix was created against a background of military leadership, which assumes that 1) you don't have time to handle all the tasks at hand, and 2) you have people working under you. Neither assumption applies to me.

Instead what i did was:

1. Priority 1 means I have to finished this task today or tomorrow
2. Priority 2 means I don't have to finish it within two days and I have to:
   1. plan it by dividing this issue into sub-issue tasks, or create a small todo-list of sub-task within the issue
   2. complete one sub-issue/sub-task
3. Priority 3 means to either spend as little time on it as possible to complete it, or let chatGPT do most of the work.
4. Priority 4 means this task is not worth my time (not in the present nor in the future)

And here is an example application of that in a real task:

Additional views

Additionally, I've also added a few extra views to my GitHub project:

• Task Importance Analysis: This is a straightforward view where I sort all my tasks based on long-term importance and due dates, assigning the correct priorities to them.
• Today: This view shows the tasks I manually assign to myself based on the priorities. It provides an additional division of labor, allowing me to focus solely on the tasks I need to finish today.
• Due Today: This view allows me to see if I've missed any tasks that are due today. I check this periodically.
• Task Shelf: This holds all the tasks that I've assigned priority 4-leave-it to. I check them periodically to decide if I should restart any.
• Current Iteration: Done: This view shows all the completed tasks. At the end of each week, I perform a review, asking myself if the completed tasks were genuinely important, urgent, and how many hours I've spent on them.

Future improvement

This method so far is going pretty well. The only caveat is that sometimes my actual workload is the same between a priority 1 task and a priority 3 task. So, for the future, I will work on automation for common tasks that fall into priority 3.