Introduction to GitHub Projects

Part 1/2

The speaker discusses the recent introduction of GitHub Projects, a feature designed for managing repositories and issues within GitHub itself. They highlight its seamless integration with GitHub’s native features, making it a suitable tool for managing repositories exclusively. The speaker walks through creating a project, setting up different views such as Kanban and Tabular, and demonstrates how to manage issues within these views. They emphasize the flexibility of GitHub Projects, including its ability to manage multiple repositories and customize fields for sorting and categorization. Throughout the discussion, the speaker shares insights on practical usage and tips for optimizing project management workflows within GitHub.

Summary

Introduction to GitHub Projects

• Overview of using GitHub’s project feature for managing repositories and issues.
• The suitability of GitHub Projects for managing GitHub repos exclusively.

Creating a Project

• Steps to create a new project within an organization.
• Options available when creating a project.

Project Management Features

• Explanation of project views, including board and tabular views.
• Customization options for organizing tasks within views (e.g., to-do, in progress, done).
• Managing projects across multiple repositories within an organization.

Issue Creation and Management

• Demonstrating the process of creating issues within a project.
• Troubleshooting and addressing bugs encountered during issue creation.
• Assigning issues, adding labels, and customizing fields.

Advanced Project Configuration

• Adding custom fields for sorting and metadata.
• Grouping and organizing issues by different criteria such as assignees or repositories.
• Exploring options for creating views tailored to specific needs or projects.

Podcast

Check out on Spotify

Transcript

0:00

Hey there, hope you’re doing well. In this podcast, let’s take a look at GitHub projects. Right. They launched GitHub, launched a new, you know, project feature a little while ago, and we actually used that for managing our repos, our issues.

0:17

Essentially, we use our own product for project management in general, but this is at the repo level managing issues in GitHub and everything that’s really close to GitHub. We, you know, it’s the right tool for the job, right? We feel like this GitHub’s projects actually make sense to manage GitHub repos and just exclusively for that purpose, right?

0:38

Nothing more, as opposed to using other tools for managing issues because they sit separately and they integrate with GitHub. This is literally GitHub’s native features. So it actually works quite well and it’s simple to get started. So let’s, we have a number of repos, but I’m just going to create, you know, just use like a sample report to showcase this.

1:02

So let’s create. So if you go basically to your organization and then you go to Projects, you’ll see a new beta feature. So you can hit new project. I’m just going to say it. It asks you whether you want a board, you want a template and whatnot.

1:18

It doesn’t matter. You can just actually even hit cancel here. And then we’ll go back here and say I did a podcast on GitHub Code Spaces, a repo. So I’m just going to use the code space name. I’m just going to say code spaces project or something, right? Or Code Spaces app, even though, you know, code spaces, just a place where you build apps, I’m just going to say Code Spaces first app or something like that.

1:45

OK, now this project view, you know that if you’ve used the GitHub projects previously but not the beta version, it’s at a repo level, right? So the project, whatever you create is at the repo level here. There’s some fundamental differences on top of Views and Kanban and what other features and functionalities it brings to the table.

2:03

It also has a holistic view of everything across your repos. When you have a number of repos, as an organization, you’re obviously going to have a number of repos and but as your company and the teams grow, you’re going to have a lot of repos.

2:18

But again, if you have hundreds of them, each team is responsible for say 10 as in it’s just a random number, right? So you want a project maybe that manages all 10 or you have multiple project managers or dev managers that have the responsibility of project managing, so they manage a few repos.

2:34

So however you is structured, you can have this as a project that manages multiple GitHub repos essentially. So we just have one. I mean we have plenty but in this example is 1. So let me see how much of what I just said earlier I can showcase, but if not, hopefully you at least get the idea.

2:54

Now let’s go say, OK, now there’s there’s multiple views that you could create. You know, let’s say let’s go to view one and let’s call it a board, right. So that’s going to be a Kanban view. And the second one is just a tabular view essentially, right.

3:11

So now let’s go. It gives you a few different items, you know, list to begin with to do progress done. Let’s say you how you want to arrange this. We like to have our to do here. This is in progress and maybe you would have something like ready for.

3:31

So once it’s done you’re saying it could be ready for review and then maybe you have another one that says ready for merge. OK. I’m going to drag this thing all the way here. And maybe you have something called on hold, etcetera, right?

3:53

So let’s say now it shows this blue dot there. So you want to save the changes to that view and you want to rename the view, let’s call it Kanban, right. You’ll have better names there, but I’m just going to call it that. I’m just going to call it Tabular, maybe. OK.

4:09

And now let’s say we go create an issue. I’m going to say to do, right. I’m just going to say you can do a hash and it’ll pull up a bunch of your repos. Let’s say I’m going to say code spaces. I have a code spaces repo.

4:25

It’s going, I’m going to say create video podcast, which I had just done earlier, but I’m going to say create video podcast and we have some, you know, convention that we use. I’m going to say documentation, hit enter.

4:42

Oh, that is a weird bug. They’re in beta. They’ve had a few bugs. They’ve fixed a bunch along the way. Let’s try again create video podcast.

5:06

That’s strangely interesting. We actually use it, and we’ve not run into typed. Let’s just say wow wow.

5:23

Let me just open another one and then go to Code Spaces to see if any issues even got created. Nope, nothing had created. Let’s just create one here. OK, submit new issue and now we’re actually going to say to do let’s try video, let’s just try code spaces.

5:54

It pulls up the one that we had created earlier, but it should actually let me create one here as well. I want to keep trying one more time. You know, I oh, that’s weird. You know, Einstein’s code is, you know, if you repeat the same actions and expect different results, it’s insanity.

6:11

But I just as I was just sharing it earlier today with someone else in my team. Einstein probably didn’t. Unfortunately for us, didn’t live long enough to see the day where sometimes you do the same thing and it actually things work differently because something else changed. Obviously you don’t exactly know what it is, but that makes a difference.

6:29

OK, that’s good. Right here. Code spaces. Oh, this is a maybe only to find an issue. Maybe that’s what it is, not a bug, it’s a user error. So unless you’re finding something, you probably just type it. So let’s say if I do docs two.

6:46

Oh yeah, it creates it here, right? OK, so I just created one. It creates it as a note and then you can convert it to an issue. Or sometimes, you know, you can even have it as a note. I don’t know why I did this guy. What is the next thing? Yeah docs create video podcast explaining GitHub projects.

7:14

The previous one was video podcast explaining code spaces. OK, and then you know you can they have this nice edit mode, but

of course you know you can do all of it here. There are things that like if you have to assign it to somebody who depending on the privilege and the permission they have, it may not show up here.

7:35

You actually have to go open a new tab and then you get a bunch of options that you can actually do right. OK, so let me close that. I can assign it to somebody. I’m going to assign it to myself here. So this repo only has two people. It’s a sample repo.

7:51

So I just pulled up two people who have access to it and I assigned it to myself. And there are labels here. These are default repo labels. You can obviously create or change them if you want to create a new one or they only have one fix. Let’s create one called cannot reproduce, reproduce.

8:13

See you. Maybe you cannot create a new label here. So for things like that, you have to go to a new tab, then you create a new label, and then you just save it, come back here, refresh the page and then you open create video podcast explaining code spaces.

8:35

Go to labels. Now you’re going to see cannot reproduce, right? But because I don’t want to add that here, it’s not a bug, it’s not it’s documentation, right? So I’m going to pick that, assign it to myself, There’s there’s more fields and I’ll show you how we can add more fields here. Now this is again, let’s convert this to an issue as well, right?

8:54

So we’re going to say code spaces becomes its own issue, and you have that here. Now if you go to the tabular view, you actually see this here right? Now you can add a number of these. You can add columns GitHub already has, or you can add a custom field, right? So you can add a custom field of any type.

9:10

For instance, let’s say we use a field for sorting, like a metadata field if you will. So we have it underscore prefixed. So what this tells us is basically we have numbers that says it’s in progress or completed or on hold or whatnot.

9:28

So I’m going to put one here, right? And then what I can do is I can say sort by this, OK, right. And then I have I want to save the view. Now what happens is everything that’s one, if it’s one is means it’s open, right?

9:48

Shows up at the top. We have two for like in progress, zero is completed and and so on. So this is a quick way for us to actually get to the issues. And now this is a single repo. They have options for you to actually have multiple.

10:04

So when you have items assigned to multiple repos, it just shows it categorized essentially right. It’ll just say repo 1, repo 2 whatever the name of the repos for instance. But what you can also do, you can actually say expose fields.

10:20

Let’s say how do I add a field? I’m going to say repository. In this case it doesn’t matter because it’s all code spaces, but if you have multiple repos, you can see that it’s going on, It’s going to give you some details and then you can actually do a group by. However, however you want to group by by assignees and whatnot, so you can have different views for different.

Part 2/2

The speaker provides a comprehensive overview of utilizing GitHub Projects for managing repositories, emphasizing customization, scalability, and adaptability to team dynamics. It discusses how items assigned to multiple repositories can be categorized and how fields can be exposed for better organization. The importance of creating custom views tailored to different developers or project types is highlighted, alongside the iterative process of refining project structures for optimal workflow efficiency. The transcript also explores features like Kanban views, customization options, and access control, while advocating for simplicity and integration with GitHub. Overall, it offers practical insights and recommendations for leveraging GitHub Projects effectively within diverse team environments.

Summary

Introduction to GitHub Projects:

• Explanation of how items assigned to multiple repositories are categorized.
• Introduction to exposing fields and adding repositories.

Custom Views and Groupings:

• Discussion on creating different views for different developers or teams.
• Examples of different views based on project types or team structures.
• Importance of experimentation and adaptation based on team dynamics.

Scaling and Iteration:

• Challenges in scaling GitHub Projects with increasing number of items.
• Importance of testing methodologies with larger numbers of issues.
• Iterative process of finding the optimal structure for the team’s workflow.

Flexibility and Adaptability:

• Emphasis on the need for adaptable project structures.
• Recognition that what works for one project or team may not work for another.
• Continual improvement and learning as key principles.

Project Views and Customization:

• Overview of Kanban and tabular views in GitHub Projects.
• Discussion on creating custom views with relevant columns.
• Exploration of additional features such as charts and access control.

Integration and Simplicity:

• Advantages of GitHub Projects being closely integrated with GitHub.
• Recommendation to keep project management tools simple and focused.
• Suggestion to use specialized tools for higher-level project management needs.

Conclusion:

• Recommendation to explore GitHub Projects for repository-level management.
• Advice on converting notes to issues and managing access to repositories.

Podcast

Check out on Spotify

Transcript

0:00

So, when you have items assigned to multiple repos, it just shows them categorized, essentially, right? It’ll just say repo 1, repo 2, whatever the name of the repos, for instance. But what you can also do is expose fields.

0:16

Let’s say, how do I add a field? I’m going to say repository. In this case, it doesn’t matter because it’s all code spaces, but if you have multiple repos, you can see that it’s going to give you some details, and then you can actually do a group by however you want to group by, by assignees and whatnot.

0:34

So you can have different views for different developers in your team or different types of items. UI middleware, back end caching, database. I don’t know, Redis, or however you want to break it down, right? You can have it, and this could be a daily Kanban view where like, “Hey, what’s going on? Who’s working on what?” And then you drag and drop, put it here, do some updates and whatnot, and then everything else is basically a GitHub issue.

0:58

This we don’t need to go into because this is no different, right? If you had a traditional GitHub issue and a traditional project, this part actually does not change. So let’s not worry much about it. Here is where this new notion of GitHub projects comes into place. So we have a number of these views, we have some play areas so people can make changes and check things out.

1:19

We have some more team views. The views change by repos because if you’re an API for API repos, we want to be able to track different things differently. For web and mobile. Web it’s a certain way, for mobile it’s different. So it’s depending on the type of project, the size of the team, the nature of work that we do, our cycles, sprints, frequency of deployments, a lot of that plays a role in defining how you actually end up structuring this.

1:46

You know, as I always say, the devil is in the detail, right? The more you create it, the more you’ll figure out what works best. There’s no single way of doing it. Before I arrived at the option and the layout that actually works for us, I tried like many different options and I actually, The thing is, sometimes you take two issues, three issues and try it.

2:04

You know, the problem is when you’re not doing things at scale, any methodology, even the not so good one or a terrible one, still might work. Where things start to fall apart, much like production systems, is when you actually increase the number of items.

2:20

So when I had 10 issues and I said, “OK, that’s great.” It started working and then I started porting over other issues. We have hundreds of them. It didn’t work. So I had to do it again and again. Each time I actually did at least 50 to 75 issues to see how this thing worked at scale essentially and then arrived at a structure that worked best for us.

2:39

I want to go into the details of what worked best for us because that’s just personal/team paradigms of our organization. What fits us best. You’re going to have to, you know, just try it and figure out what works best for you and your team and it could be fluid.

2:55

It’s not like it’s set in stone either. What works for us for a certain project in the same team does not work for another project with the same team for a different feature, maybe even, right? So we keep changing it and we belong to the school of thought where we don’t think that just because we’ve done certain things a certain way in the past it needs to be we should continue to do it the same way in the future.

3:15

We exactly belong to the opposite school of thought, which is keep changing as long as you can, improve as long as you’re improving, as long as you’re learning. As long as you see a quantifiable gain, a measurable gain in productivity, then just go for it, right? If not, everything is going to turn out perfect, not even good.

3:32

Then you just learn from those mistakes and keep chugging along. OK, so this is the Kanban view, the tabular view. And again, you can create any number of views with different columns. We have different views with some columns that are relevant in that view, some that are not. Like in certain cases, you just want to see the title, who it’s assigned to, and what the status is, right?

3:51

That’s it for one view, but the other view might go into the details of that particular item. Maybe you want to expose the labels, right? I can go here. See, it actually shows the status. It also, there might be a way to expose just like we expose the repository.

4:07

Yep, you can show labels. Now again, maybe in some of these cases, you don’t want the labels, you don’t want like a view with 200 columns. There are 25 columns. It’s too noisy. So you just figure out what actually makes the most sense to you and then add as you go.

4:24

And it looks like they have like a chart feature, which I actually haven’t particularly used much. Yeah, but maybe even you have data, I help you and then if you go here to settings you can then say who gets to access this, right? Right now it’s only me who has access, but maybe I’m curious.

4:43

I’m curious because I was able to you know what the repo, there’s another developer who had access to the repo but not of the project. They’re two different things, right? So the ACL is kind of interesting. So just because you have access to the repo and the issue gets assigned doesn’t mean you have access to the project.

5:01

So even though I may assign this to somebody else in the team, they may not be able to see this. They will not be able to see the project unless they have access to the project. So you’ll have to actually grant them explicit access here. And then obviously you can go create custom fields whether it’s single select it or number or text and whatnot.

5:22

There’s some basic stuff, read me and description that’s pretty straightforward and self-descriptive. But that’s what it is for projects. And again, what this Kanban should look like, what maybe you have several versions of it, you know we have like 8 or nine of these lists.

5:41

More than that. It’s difficult to drag and sometimes you have one here and you have to drag it all the way. And again, if you have pull requests and stuff, it, it creates, it is new, it is transient, no status list. And once you remove something from here, let’s say I archive it, or maybe archive it, then that list disappears,

right?

6:00

So that’s what shows up. If it’s like a

temporary placeholder, I think that’s basically I think it works quite well. We get, you know, this is purely again at the repo level or across repos, it has nothing, It’s managing your repo, right?

6:17

It’s called projects, but it’s limited in its scope and rightfully so, it’s not trying to, you know, it’s very code-oriented project management, right, not generic project management. So I just want to make sure there’s no confusion there.

6:34

Maybe there isn’t. I’m just stating the obvious, but I think it does the job. The fact that I like is it’s very closely integrated with obviously GitHub. It’s a native GitHub feature so you don’t have to worry about using something else to tracking issues. I was never a fan of that, right?

6:50

If you’re doing issue level, project-level issue tracking, just do it right there, right? Do it right there. Keep it simple, keep it informal. You don’t need like 200 fields. You don’t need a lot of these. There are tools that are way too complex and actually provide very little added value, at least in my opinion.

7:09

Right? So the right tool for the job, I think for managing repos and issues at the repo level. I highly recommend that you actually check this out for anything else that is a little bit of a higher level. Something that you’re managing projects across different territories if you will, then obviously you need a better tool and you know where I’m going with this.

7:32

You certainly check out Snowpal and use it and get yourself more productive and organized. But outside of that, if you’re just doing it at the repository level, check this one out. I don’t know if I missed anything. I think the rest of it is not specific to GitHub projects per se. So yeah, I think it’s it’s the only other thing I would say is you know a lot of times we create these notes which we don’t convert them to issues.

7:57

When you convert it to ratio, convert some note to any issue, it needs to belong to a repo. So it depends on who has access to those repos. Sometimes we have quick notes for ourselves, the team, so it just sits as a note and then it goes to the done column essentially, that’s basically what it is.

8:15

Hopefully you learned a little bit more than what you might have already known. Talk to you soon. Thanks for watching.

Snowpal Products

• Backends as Services on AWS Marketplace
• Mobile Apps on App Store and Play Store
• Web App
• Education Platform for Learners and Course Creators

Subscribe to our newsletter on products.snowpal.com so you do not miss a beat about Technology (in general) and everything we do at Snowpal (in particular).