Tom Bloor's Blog

How I use Github Projects

Introduction

I'm sure we can all relate when I say I have way more ideas for projects than I do time to create them all. Like many others, I'm guilty of starting way more projects than I finish. Sometimes that's ok, perhaps it was just a learning experience, and I never really intended to 'complete' it. But sometimes I feel like I lose direction when working on personal projects. This leads to me not being able to decide what to work on next, my productivity drops, and then eventually I stall and move onto something else.

In an attempt to fix this pattern, I decided that I would start to take inspiration from some of the practices that I use in my work projects. My hope was that I could pick the bits that would help keep me organized and motivated, without making it feel like a second job.

After thinking about it for a while I came to the realization that the piece I was missing was simply a defined plan. I would happily start coding for a week or two while all the ideas were fresh in my head, then life would happen and I'd get busy, not work on the project for a few days, and just like that all my momentum was lost. I needed to treat my personal projects a bit more seriously and get into the habit of documenting these ideas and tasks which needed to be completed.

I tried out a handful of platforms for organizing my work (I intentionally avoided the platform I use at my job, to keep things fresh) and ended up spending some time messing around with GitHub projects. It took me a little while to get into the rhythm with it, but now that I have things set up it's pretty nice to use. Plus GitHub is where I keep all my code, so everything is grouped together nicely and it all stays in sync automatically.

I'll go ahead and say there is nothing revolutionary about the way I approach organizing my projects now. It's all pretty common sense, and for most professionals it's something we just do as part of every day work. What was key for me was getting over the idea that this is overkill for a small project that only I'm going to touch. I think I've managed to strike a nice balance between keeping organized and not going overboard.

How do I set up my project boards

I have all of my work items grouped into one of three priority categories, based on their urgency/importance.

  • High - Critical bugs, or new developments that must be completed before other tasks.

  • Medium - Short list of work I want to focus on next, that I can pull from when there is nothing high priority to take care of

  • Low - My general backlog. These tasks aren't that important or urgent. They could wait for a while before I get around to them.

I use these categories to pick which tasks I should be working on next, and I regularly re-evaluate and move things around as my priorities change. To set these up, I created a custom text field with these three categories as the options.

Similarly, I have another custom text field to track the status of each task.

  • No status - Newly created tasks which I need to plan out and document before I start working on it. These will stay as draft issues for now.

  • To Do - This task has enough requirements and notes documented for me to start working on it. At this point the task will also be converted to a fully fledged GitHub issue.

  • In Progress - Once I create a branch to start working on a task, I'll switch it to 'In Progress' so that I know I've already started it. I try to limit myself to only one or two tasks with this status at a time.

  • Done - This task has been completed, but may or may not have been merged into the main branch yet.

I personally like the 'Table View' for GitHub projects. I may find uses for the 'Board View' in the future, but at the moment it's easier for me to group tasks how I want in a table. I have all of my tasks grouped by Priority. This way any high priority tasks will always be visible right at the top of my list. Within the groups I'll sort my tasks by status, so that I'll see all 'In Progress', followed by 'To Do', and then anything which isn't ready to be worked on will stay towards the bottom.

Finally I add a filter to my view is:open so that as I close issues with pull requests, they automatically get filtered off my board. In the future I want to set up a separate view to track issues that were closed recently, but I don't have that set up yet.

Simple walkthrough

Again, there is nothing groundbreaking in this approach. But here is the general flow I follow when I sit down to do some coding in the evening.

I'll start by looking through the high priority tasks, if I had any that are still in progress then I try to get those finished, otherwise I pick out another one which is ready and start working on it. Once I've completed the task I open a PR for it. Even though I am the only person working on these projects, I still find benefit in self-reviewing PRs and will talk about this a bit more in the next section.

Once the PR is merged into the main branch, the related issue will be closed and the task will drop off the board automatically. Now I can move onto the next task in the list, working from top to bottom.

At the end of a session I try to set aside some time to do two things. First, I will review my tasks and shuffle around priorities as needed. Secondly I'll open up a couple of draft tasks and try to add a bit more documentation to remind myself what needs to be done, and start putting together a plan for how to achieve it.

And at this point I'm ready to finish for the day and have enough information to jump in and get started right away next time.

Note on PRs

This tip is more about how i use GitHub for solo projects as a whole. If an item is not urgent and would not block me from working on other stuff, I like to leave the PR open and come back to it after a few hours, to perform a self review. I find sometimes this helps you to create a bit of distance from the solution you previously coded and spot silly errors that you might not have noticed in the moment.