Setting up GitHub

Today, I thought I'd talk a little bit about how I decided to setup my GitHub account and manage my work.

I didn't really start doing anything with source control or DevOps until I began my first developer position at IDF. At that point, I decided to make a GitHub account and started pushing up some code for my side projects.

Figuring out what worked​

At work; however, we used Azure DevOps instead of GitHub. Comparing the two, I liked Azure DevOps a lot more:

• Everything is organized into projects
• All of your repositories related to a given project are grouped together
• Sprints make it easy to see what I'm working on for the current week
• The backlog is available to see work that hasn't been started yet
• The "My Work" area gives you a summary of what's assigned to you and it's status
• There's a designated "pipeline" and "artifact" area

I had considered using Azure DevOps for my personal work, however there was one major concern:

• I wanted my personal work to be open source. Not only so others can use what I build, but so it can serve as a portfolio of sorts.

This meant that my work needed to be public and easily accessible to others. Sure, you can make a project public in ADO, but, at least to my knowledge, there's not really a "collection" of public ADO repositories and projects somewhere.

This led me to start a search for how I wanted everything organized. Essentially I just needed source control and project management software. I tried a few different things, such as Jira, ClickUp, GitHub, Gitlab, and Todoist. Each had their pros and cons, and each was better at different things. I especially liked the fact that you could self host GitLab, but again - I wanted my projects easily accessible & searchable without a custom domain.

The project management software I looked at all had the option to integrate with various source control, but wasn't quite what I was looking for. Recently, I found the beta GitHub Projects and, although still not quite what I wanted, it was close enough to start using and setting everything up.

Source Control​

As you can probably guess, there's nothing special about source control. Everything's hosted under my GitHub Profile. I have some small personal and experimental projects, template repos, and a couple "hopefully to grow into larger projects" repos for things like KLog and PyFarm.

Project Management​

For managing all of my work, I was actually pretty happy when I found the new GitHub Projects. It lets me create multiple views, group work (issues) from all of my repos into a single area, and make my own columns or fields.

Initially, I thought about making a separate project for each repository, specifically the KLog and PyFarm repos mentioned above. Doing so would have meant going back and forth between the two projects. Instead, I made a single, public "Open Source Work" project that will have work from all of my repos. This way I can see everything that's happening and schedule my time accordingly.

Views​

To start out, I made 4 different views:

• Work Summary
• This is an overview of all work items / issues between my active repositories. There's no filtering, so I can see the entire picture.
• Backlog
• This is a traditional "backlog" view that shows work items that are not assigned to a particular sprint.
• Current Sprint
• Current sprint is a board view that shows the work assigned to the current sprint along with it's status.
• My Work
• This view shows all work assigned to myself, regardless of sprint or status.

Fields​

The beta projects come with certain fields by default, like title, assignee, labels, repository, etc. In addition to those, I decided to make the following:

• Status
• Technically, status is one of the default fields, but I changed the values to contain:
• Not Started
• In Progress
• Blocked
• Review
• Complete
• Closed
• Points (est)
• Rather than using a time estimate for tasks & issues, I decided to give points a try. Basically, you assign each task a certain number of points according to its level of effort. I used the following values:
• 1 = Simple task, requiring ~15 minutes of effort
• 2 = Typical task, requiring 1-3 hours of work
• 3 = Larger task, requiring at most, a full day's work (8 hours)
• 5 = Complicated task, requiring 2-3 days of work (16 - 24 hours)
• 8 = Large, complicated task, requiring a minimum of 1 week to complete (40 hours). Most times, this would be, at minimum, a feature, and should contain smaller sub-tasks
• Sprint
• Sprints are essentially a unit of time to complete a given number of items. I like the weekly sprints that we used at IDF, so that's what I went with here. Considering that I also work full time, I'm assuming that, given my schedule, I can complete approximately 14 hours of work per week.
• Category
• Taking sprints and points into consideration, some tasks are obviously much larger than others, and can contain sub-tasks. Because of this, and to stick with the kind of setup that ADO utilized, I created a category field that has the following values:
• Epic
• Feature
• Story
• Task
• Bug
• Due
• The final field that I've created (at least so far!) is a Due field, which will contain my target due date.

Final Thoughts​

So, there you have it. My simple setup for managing code and work items. Overall, I think (hope) this will work for what I had in mind, but I'm currious about your thoughts. What do you prefer for source control and project management, either for work or personal projects? Let me know in the comments!