GitHub Demo Days, 19 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitHub team collaboration: accelerating collaboration with GitHub #DemoDays

Description

When it comes to GitHub team collaboration, sometimes it's a good idea to look at things from first principles. Rowena Foo, Implementation Engineer, digs into the most fundamental components of GitHub and shows us how to maximize productivity with your teams by using Issues, Project Boards and how to setup your teams and organizations.

2:06 - Stream start
6:42 - Intro
9:24 - What do I get with GitHub?
9:50 - GitHub repositories
11:37 - Issues and Project management
16:24 - Templates
23:25 - Labeling issues and pull requests
24:52 - Tracking progress with milestones
30:22 - Project boards
33:00 - Branches
42:55 - Team and organization management
49:33 - Repositories and policy management
53:02 - How GitHub uses GitHub

GitHub InFocus Developer Experience Week: https://infocus.github.com

A

Hey everyone welcome to demo days, how's it going chad how you doing how you doing that's right. It's me aj back here again for demo days and I'm trying something a little different. I made a linkedin live event this time, uh so hopefully folks found it that way. But in case you didn't, it looks like we found uh the stream anyway. So that's always a good sign nice to see everyone, uh hello, hello, we're all um commenting from today.

A

I am assuming that things are worldwide. As usual, uh hello from wolfsburg germany, nice nice to see you in here yeah all right, so to get right to it. I um been thinking about demo days and we've been doing a lot of in-depth kind of walkthroughs of very specific github features in the past, and uh sometimes when you do a lot of that.

A

You kind of get buried in the details and I want to take things a step back a little bit and uh be less assuming that everyone knows exactly how github works and knows how to put together a yaml file to start up their action or knows how to to deploy end to end in in uh in github. So today my special guest is rowena, hello, rowena, hi, how's it going it's it's nice to see you welcome to demo days.

A

As you can see, we've got lots of folks in the chat from cleveland all the way to india and new york and sweden. So it's very much a global audience so good morning to everyone good afternoon, good evening, good night, thanks to everyone who stays up super late to watch us on what is uh 11 a.m on a friday on the on the west coast, uh but is clearly saturday early morning for many folks. So I always appreciate that kind of dedication.

A

It's nice to have everyone here, marina. Can you tell us a little bit about what you're going to be talking about today?.

B

Yeah, so the title of this presentation is called how to accelerate collaboration on github, and it is very much meant to be um more on a basic level, um just a quick introduction to github how to use github. How do we use github um so yeah? Hopefully it is a more approachable topic than the other demo days that we have seen so far.

A

Yeah yeah- and I think it's also important to note that, like you know, github very much is for software development and building software, but uh we're not all software developers here at github like I personally am not a software developer, but I use github all the time for all the things, and so I'm super excited to see how you can show other folks. You know how we all use github at github and also how it's about everyone understanding how software developers use it as well as non-software developers.

B

Yeah for sure- um and I definitely try to keep the non-software developers in mind- I'm also not a software developer, uh so I I definitely try to keep all of you guys in mind.

A

Cool cool, oh uh by the way, have you seen your github skyline by any chance? Do you know what that is.

B

I have, and it is it's very dramatic uh I don't know if you want to share yours.

A

Yeah yeah, let me see if I can share that your github skyline, if anyone hasn't seen it yet. This is a project that we kind of put together in uh devrel to show your your uh contribution graphs. So what was your handle.

B

A

There we go and it just pops up with your contributions, so it seems like it seems, like you actually were pretty busy in 2020, because I know my contribution graph doesn't look like that.

B

Yeah I have some like manhattan sky towers. In there I it looks like I'm the most busiest like around march-ish and then not so well does some like uh productivity towards the end of the year.

A

Well, I hope you were able to find some break in what was definitely a pretty crazy 2020.. uh So, uh thanks for for coming on today for demo days and I'll leave it to you.

B

Awesome: okay, so I'm gonna share screen.

B

All right, hello, everyone uh can you see my screen, hopefully I'm sharing the right one. Yes, I am sharing the right one, okay, great, so uh the topic of today is to how to accelerate collaboration on github and just a quick introduction about myself. My name is rowena. If you're just joining us, hello, hello, uh I am straight out of chicago illinois. I live here, but actually I am originally from malaysia, so um it is definitely quite the cultural and weather shock uh coming to the us.

B

So uh my day, job at github is implementation engineer, and what that means is that I help github enterprise customers just become successful on our platform, making sure that everyone's getting what they need- and you know making sure that collaboration is very efficient on github and that's what I do on a day-to-day basis. So for today's agenda uh we'll go into uh you know how to get started.

B

Just some kind of high level overview about what this topic is about and then I'll go into how to manage your issues in project management in github and then we'll take one step higher and go into team and organization, and then we'll also talk about how to manage repositories, how to enforce policies and even um how to use automation to enforce those things.

B

So, there's going to be a mix of some a little bit more technical topics, but most of it I'll try to keep it to people who may uh have or may not have seen github before so I'll. Try to keep in mind, uh for you know for the broader uh audience and then lastly, I'll also talk about how github uses github and then we'll leave some time towards the end for some q a so. I spent some time last night to put this image together. I'm very proud of my about my photoshopping skills.

B

I hope pixar doesn't come for me for this, but the main goal that I want to say is that, even though github has been touted to be the home for developers, it is very much the tool for developers. I mean, if you you know, majored in computer, science and university or maybe even in high school. You definitely have used github to host your projects to store projects submit for grading things like that. So it is very much like this starting point for developers, but I want to emphasize too that github is also for everyone.

B

Github. All employees at github is on github, including the core business functions like hr sales, marketing finance everyone's on github, so it's not just a place for developers. It's a place for collaborators as long as you know, markdown syntax, which is not difficult to learn. You are good to go on on github, um so I hope that by the end of this presentation um I can show you how an entire company can get work done on github, all right, so right out of the box.

B

What you get with github is that you get your code base. Your issues, your project boards, those of you who have been using github- you might be very familiar with all these terms, so these are just some things that you get right out of the box and some additional stuff that you get are like advanced security uh code spaces. Things like that, and so um let me just hop over to a repository to show you how that looks like so just to orient ourselves as to what we're looking at you can see.

B

My url github.com forward, slash all diavo, so aldiavo is the name of the organization and then rwnfood demo. That is the name of my repository. What is a repository repository is like a dropbox, folder or drive folder. It is where you would store your project.

B

This is where you would collaborate with your team members, so uh the name of my repository then is rwnfood.demo, and I would also see that relationship at the top left corner of my repository and that's how I know that, I'm in a repository- and I know uh which organization I belong to, so I can hover over it to even see more information about this organization uh right off the bat I'm in the code base once you get in even though it says code, you don't have to code to use github.

B

You can put anything in here you want. I mean there are some limits to that, but you can essentially store project files in here um immediately you get a readme file and this is usually a good opportunity for you to greet anyone who might land on your repository kind of have an overview about what your project is about. How should people contribute to your project? Things like that? So this is a repository. Whenever I talk about it is what it looks like.

B

It is a place to store your project files and to collaborate with your team. Okay. So back to my slides um I'll. Also, try to monitor the chat room to make sure that you know. I answer any questions. I think someone asked about my sweatshirt sweatshirts given to me by github, but I think you can get it on the shop as well. Oh thank you looks like someone just posted a shop uh url. There awesome all right, so, let's jump into the first section, which is about issues and project management.

B

So what are issues issues if you are in project management? You might have heard of this term before or another term, for it could be tickets. um This is a way to track ideas. Enhancements features things that you want to work on or any bugs that you want to report on if you're not working on software.

B

This is also something that you can open to talk about again, ideas, uh things that you want to fix: um brainstorming, meeting minutes at github, we literally open an issue for almost anything, and so each issue that you open has your own respective url, and it's pretty easy to share that. Among your team.

B

So on the ui issues and pull requests, look very similar, uh that's because, on the back end with the mysql database, issues and pull requests have the same table structure, but with pull requests having a little bit more metadata, such as ci checks that kind of thing.

B

So, even though they look very similar, they do two very different things. Issues again is a way for you to track ideas, just some experimentation. Some thought that you have pull request is more about you implementing that thought already. So you already made changes and now you're just trying to get um approvals and reviews suggestions from your teammates and that's a reason to open a pull request. So these are two uh very different things. um If any of you here on the chat, if you are in software and you've, been using github for a while.

B

A common question I get is: why is it called a pull request? You know I didn't pull anything. Why is it called a pull request? um Just a bit of a history lesson back in the day before github came along um git. The way that you would interact with other machines is by git and you would actually email the person to tell them that hey, I'm interested in pulling your machine. uh Can I go ahead and do that things like that. So that's why it's called a pull request.

B

It is a request to pull from another person's machine, and so when github came along we're kind of, like you know, I don't mean to our own horn by github- was the og back in the day and we kind of went with that term. Since everyone was using the term pull request, we went with it as well. So if you're curious, why it's called pull request. That's the historical reason for that all right.

B

So with issues when you open an issue- and uh you know provide when you want to discuss about some topics, it will kind of, uh I guess- show all the anyone who has commented in a timeline. It kind of looks like a facebook feed. I guess, and you can kind of keep track of what everyone is saying and you can add a lot more metadata to that as well. So on issues and pull requests, the syntax that would you would use is what we call a github flavored markdown.

B

That sounds super scary, but it's actually not it's just a very simple syntax to help you style your font, without knowing to you, don't have to know how to code or anything like that. You just need to um remember the syntax. uh Certain things are like: if you use an underscore, it would italicize the font. So if you just remember those few syntax, you are, you are good to go on issues and pull requests.

B

Someone asked: can you talk about repos being a single source of truth? I'm not exactly sure what you mean by single truth. I would assume that you were trying to say that if people want to find information, they would just go to a repository to find that I'm assuming that might be what you're saying and then someone is also asking about security scan for repository.

B

Yes, so that is, um I'm not sure if it's a lot for free or paid, but we do have advanced security for that and what it does is that does scan a repository for any uh security vulnerabilities in code and in packages that you use. um It also does secret scanning.

B

So if you accidentally push any secrets or keys to a repository, our advanced security products will immediately pick up on that as well um all right, so I'm gonna hop back into the slides and I'll try to monitor the chat as well, because there's a lot of really good questions coming through there. um So with issues and pull requests on top of using github flavored markdown.

B

Other things that you can do is at mention an individual or you can also mention a team, so this is really easy to bring in other people, to comment on the issue to look into it and give their ideas as well. You can also cross-reference other issues.

B

You can use markdown to create tables, to create a code block things like that, so it's very versatile for that type of for that type of ticketing system. uh On top of that, we also have issue templates. um Let's say that you, whenever you want someone to report on maybe like a work item, they need to work on during the sprint or maybe, whenever you want someone to create meeting minutes, you want them to follow a certain format.

B

You can always add issue templates into your repository, so that any time when someone wants to open up an issue, they would choose a template uh to to go off of so that you can keep everything kind of neat and tidy and everyone's following a certain type of format.

B

To add issue templates. There's a few locations that you can put them in. You can put them directly into your repository, which is the top left corner. That's an example where you just put it directly in your repository, or you can put it in a folder called docs. You can put it in a folder called github or a folder called.github and then a subfolder. That's called issue template, so these are a few locations that you can add and issue template, and once you do that, that's where github goes in and find and see.

B

If you actually have any templates that you want to use in your repository and to add issue template, there's a few metadata, you can add as well. So this is an example where I'm saying that every time someone creates an issue template with this template, uh please pre-populate it with these items like it can come with. Labels already can come with assignees already so that each time someone creates one, these items are already populated, so it keeps things really easy for you and then once you create them.

B

This is what it looks like in your repository. This is just showing that the location of where you're going to store these files and you're going to put them in all of these folders and for the user when they open up an issue. This is what they see. They get an option to see what type of template they want to use to report on whatever they need to say.

B

So um this is an example where you create an issue off of a template and that you want to fill out the the body of the template and that's what looks like so I'm gonna show you real quick about some templates that I have already and how we're gonna populate them. So I'm back in my repository, I'm gonna jump into issues and then I'm going to say new issue, so I already have some templates you can see here and where do these come from? Well, it's back to that location that I was talking about.

B

So I created a folder and inside. I call it issue template and I have some templates going on and I'll go with the work item one and you can see that I have already filled out some of the metadata that I wanted to come with, so that anytime, someone uses template. These are already all filled out. If I click on edit, you can see the raw form. This is the meta, uh the markdown syntax that I was talking about. um So this is the raw format.

B

If you preview changes, it gets rendered into a nice table, but um in a raw format it just looks pretty simple. So this is what I'm talking about that that syntax that you need to learn. If you intend on collaborating on github, it's not that bad, you will definitely learn it in one day.

B

I promise you um so since I have all this filled out uh going back to the issue, I'm going to create a new issue and let's say that I have something to work on, so I'm going to say get started and because I already filled uh that template out with things that I want to pre-populate.

B

You can see that it's already populating uh some of the items here so ipd to fill is my own personal account, because the one without hyphen is already taken, which is really sad, but I'm glad that this one with the hyphen is available for me to use. So that's what I'm going to do. I am going to create an issue date. It's february, 19th name, I'm just going to say I need to work on this action item.

B

uh I need to make lunch. So what you see here are some examples of markdown syntax. The hashtag is what styles, the header, the more hashtag you use, the smaller the header becomes. So if I type a giant one header, so it's just one hashtag or pound sign, I don't know depending on which generation you're from you might call this a different thing. So I'm gonna call it a hashtag and one hashtag is gonna, be one giant header. So it's gonna look like you're yelling at someone, I'm yelling, and to see this.

B

I can click on preview and you can see how large this text is and the more hashtags I add. So this is only two but I can add three and that becomes a lot smaller, and this is what it looks like when I want a checkbox so that I, when I publish this issue, it becomes a checkable box. So I'll say I need to make lunch yep and the most important syntax you need to know in markdown is emojis to to use emojis.

B

It's very important during this time, especially since everyone is, you, know, isolated and we're not going to the office and seeing everyone's faces using emojis to express yourself can be really helpful in the workspace. So uh to do that, you just do semicolon and uh lunch, I'm thinking about ramen, so I'll just put ramen here. That's how I do emojis and I can submit a new issue and there we go.

B

Let's see any questions coming through.

B

Git is distributed, but to what extent some of these questions, I'm not even sure if I can finish explaining it in in like 30 seconds to what extent is get distributed. Well, it just means that you don't have to work locally, so this is a bit more technical. This is, if you are a software developer and you take things down to your local machine.

B

So if you take things down to your local machine and everyone can kind of go offline and work on their own and come back and then push it up to the local, a central location like github, but you don't have to do that as well. If you want to stay on github and work, you can absolutely do that. So that will, I guess, if you want account github, it's not super distributed, but if you choose to be distributed then you would just clone and everyone work on your local machine.

B

So the style of working is really up to you. It's pretty flexible, github just serves as a central um server, I guess to kind of as your backup repository if you will, but I would definitely argue that github is more than just a backup storage for sure yeah. It comes with so many more features like pull, requests and actions code spaces. So it's not just for you to store your.

B

Repository all right, so next we talk about uh we'll go into labels. Labels is a way for you to organize and prioritize your work, so you can create labels that says high priority low priority labels. That says this is just a meeting note, um or this is something that's a bug, so we definitely need to work on it.

B

Things like that, so, where you would create labels, is that it's in your repository, you will click on labels and you can choose whatever color that you want to go with it and you can also add emojis to it at github.

B

We're really big on emojis, if you use emojis and almost anything and the way that you would add labels to it and what this is, what it looks like you can add as many or as little as you want- and this is an example of how it looks like when you add labels to an issue.

B

So um to do that, I'm gonna show you how to create labels I'm going back to. Actually I don't need to go back into codebase. I can stay in issues I'll go into labels um and I'll, say.

B

Meet attention I'll add an emoji and I'll, create it all right so now the label- that's called needs attention. I'll put that here.

C

B

You go so that's how I would add a label uh to an issue, and next thing. Additional layer that you can add to your project management is to use milestones. Milestone would live again at the issue level. It stays, I guess at the repository level and you would add issues to it. You can keep track of issues that are open and issues that are closed, and you can look at your progress and see how close you are uh towards the end of the milestone.

B

When you add an issue to a milestone, it would also show up in that issue metadata so that you, when you're in an issue itself, you can see which milestone it belongs to and how close you are uh to that end of maybe a release cycle or end of the project management lifecycle. Things like that, and you can also tie it up with git tags or github releases to kind of put a nice bow on top of the release cycle.

B

So for those of you are not familiar or if you're using git and not very familiar with github there's a feature and get a feature. I guess there's a thing and git call tag, so you can definitely use git tags, push it up to github and you can still see tags in your repository.

B

But if you use releases I would argue that releases can be a lot more helpful than text, because you can add a lot more metadata to your releases. You can um add, uh you can add binary files to it. You can do a pre-release. You can save your release as a draft, there's just a lot more flexibility to it. So for those of you who are in the software development life cycle, leveraging, tags and releases can be really helpful.

B

All right. So then, we've covered uh labels milestones. Now we move into project boards. So where this lives is, it could live at the organization level. So one more level above repository or you can have it live at the user level. So this project board belongs to the user um or at the repository level. So there's some nice benefit to having project boards at the organization level.

B

So if you have a lot of repositories at the org level, you can bring in issues across multiple repositories and have it live at the org level, as opposed to. If you have a project board at the repository level, you can only bring in issues from the repo level.

B

Can you please explain how we can use tags for simplification um yeah? So it's a quick way to kind of uh categorize your work. So if you open a lot of issues so think about it as like a ticketing system, if you open a lot of tickets- um and you want a quick view of you know what tickets are the most important or what tickets should we work on first or what tickets need more information?

B

So that's one way that you can use tax to separate them out and it's also a lot easier to filter for issues when you have tags on them.

B

A lot of people are asking me about similarities to get get lab, and you know what I've never worked for gitlab and I I wouldn't know. Maybe you can come and tell me later on when you're you can kind of tell me what your your feeling is, because I've never used gitlab. So I wouldn't know. Oh the screen is so small. I'm sorry. um I only see that now.

B

Let me make it bigger.

B

I'm sorry if it's been small this whole time. I hope this one is good too.

B

Oh, that's the max. I can go. Oh that's a good question. What really is the difference between tags and labels? So tag is more related to your code. It's something that you would tag your code on. So if you're not using it for code, I would say you can also use it for, let's say use your repository for documentation.

B

You can also tag your documentation. Labels are more for your issues and pull requests. So it's just another layer of metadata on it. um I hope that's a little bit more helpful.

B

Are emojis for the colon or semicolon? You know what I think it's got colon. I might be wrong.

B

What are some recommended? Github actions for creating releases? Oh, I have a favorite action for that and I might digress a little bit, but I'm going to talk about a little bit because um there is a github action called release. Drafter and I really like using it. It is not from a verified creator though, but I do enjoy using release drafter. I guess I can go um a little bit off topic. I hope that's okay actions. I'm gonna go to the marketplace.

B

And I'm gonna search for release, drafter.

B

This is a very popular action, even before actions came along. This is a popular probot as well. It's a github app so now that we have actions it. You know it got turned into a good up action, and so it's pretty popular and I really really love using it. uh What it does is that every time you close a poll request, it will draft up your release, notes for you and organize them really well, so you can even categorize it as a feature release or a bug fix or just you know, basic maintenance.

B

So I really like using this github action. I hope I hope that is helpful and yes, that is a little bit off topic hey. You know this is uh more free form, not as formal as maybe like a presentation at a conference or anything like that. So if I see interesting questions, I'm gonna answer them.

B

Okay, so back to project boards, um project boards on github is pretty flexible. um In that you can name your columns. However, you want it, you can name it as to do in progress done or level one level, two level. Three, any anyhow. You wanna manage your projects, you can create them and you can manage that yourself.

B

So if you add issues to a milestone and if you add issues to a project board, the milestones will show up in your project board as well. So there are many layers of metadata. I guess you can add to your issues and a way to think about it. um I'm not a project manager by any means, but I would say if I have to draw some similarities to project management concepts. I would say that milestones, probably probably like an epic, so more of a larger story and a project board is just kind of your standard.

B

Kanban and issues could be a story or a task or a list of tests living in a story. uh However, you want your issues to be. uh The size of the issue is up to you, but that's just kind of how I see it. If I have to map it to a project manager management concept.

B

The way we use project boards uh in terms of shipping uh repositories with products that need to ship, they could have columns like coming soon coming next shipped or feature requests customer feedback things. They still need to work on and get more information. We also use it for onboarding. So when I joined github about a year and a half ago when I joined github, I was also given a project board.

B

So I was given like a list of things to do during my first week and second week, and I also have a list of things that I can give feedback on. So that's just how we use project boards at github project boards come with a few templates, I'm not going to go into every single one of them, but I want to fan girl over the automated kanban template. That's the uh automated combine right here. I this is the template. I use very often because it comes with some uh pre-configuration.

B

I guess so. It allows you to close up issues and clean out your board very easily and I'll show you what that means in a second, because that was very abstract. As I was saying that so, let's say that um I have this issue assigned to me and I need to work on it, so I'm gonna get to work, even though it's assigned to my nemesis, but I'm still gonna work on it.

B

I'm going to make a change, I'm going to create a new branch for those of you are not familiar with the concept of branch, think of the main branch as the latest and greatest. So this is your production version. This is what you would share with your customers. This is the version that you're the most proud of to create a branch is to experiment with things you're I like to think of it as a parallel universe, you're going into a parallel universe, so that you can make changes to.

B

However, you want it and then you can decide if you want to put this um work, that you've done this experiment that you have and if it's successful you can decide if you want to put that into production. So what I'm doing here is that I'm creating my own parallel universe, I'm going to start experimenting with things so I'll just call my branch with my name, because why not so I'm already on my branch, I'm just gonna- make a simple change: nothing, crazy, uh hello from chicago.

B

I hope you don't see snow because snow has not been kind to us. Lately, um okay, commit directly to my branch and right off the bat. Github knows that I made some changes, so it is suggesting that I open a poll request. So I'm going to go with that suggestion, I'm going to say yes, I do want to open a poll request.

B

So let's say that I am making this change uh based on the work item that was assigned to me. What I can do is to reference that issue. So I made my changes. My changes is related to that ticket. That was open, I'm going to close out that ticket or I'm going to close out that issue in my poll requests.

B

To do that, I can use a keyword, call close and I'm going to say, issue number four, because that was the issue that was assigned to me if you missed that, if I type four just based on the title, I know that this is the issue that I need to work on and I made the change I need to make.

B

So now I'm going to close it out with this keyword now a couple of things you can do here, you can either just create a pull request straight away, um but another thing that I would also like to say to add is that you can create a draft pull request and for those of you who are in uh software development development life cycle, I guess even if you're, not in an sdlc, you can definitely leverage draftpole request as well. So I'm going to click this.

B

What it does is that it tells everyone that you are not ready. You are still working on it, so you're going to put your pull request in draft mode, um so then your question might be if it just puts it in draft mode. What's the point of even opening a draft pull request? Well, it is a very good communication tool to let other people know that you are already working on this item.

B

um It is a good way to let people know that you have taken responsibility over this issue or this ticket, and so uh I guess it's a good way to let your manager know that you're working you know in this pandemic times. Who knows what you're doing so opening a draft pull request is a good way to provide visibility into your work.

B

um On that note, I'm also going to open a project board and when I do that, I'm just going to say my project and I'm going to choose automated kanban, it's one of my favorite templates to use because it comes with some simple automation in place already, so I'm going to say create project um and right here you can see that it has a few columns and it's already asking me what do I want to bring in.

B

I can actually bring in an issue that I know that I'm working on, even though I open a draft pull request for it, but I'm still working on it or I guess I'm doing it right now.

B

Okay, okay, so I want you to know that I added this issue to the to do column. I haven't done anything yet. I'm gonna go back to my poll requests.

B

And I'm going to say ready for review okay. So while this is going on, uh what could happen during a poll request as well? Is someone giving you a an approval, so I'm gonna act as my arch nemesis and I'm going to give myself an approval and just real quick to show you again the differences between issues and pull requests. If I go into files change of a pull request, you can see that this is the change that I made. So this could stem from an idea. This could stem from you.

B

Try and experiment with things you can just make your change and see if other people can give you blessing or see if they uh have any better suggestion or better ideas on how to solve this problem. So this is the change that I made I'm back here. uh Someone else can give me their blessing. uh I'm gonna go into my split personality role and give myself an approval.

B

B

I gave myself an approval as another person and, if you for those of you who are more technical, if you have any ci tests that you want to implement, a pull request is a good way to put to include your your ci test. So from here I'm going to merge my pull requests. Merge means that you are satisfied with the work that you experimented with, and you want to put this into production. You want to put this into the latest and greatest source of truth.

B

That's how you can see a merge, pull request, that's what it means. So when I'm done uh right. So when I'm done, you can actually see that this keyword that I use it says this pull request closes issue number four. So that was the keyword that I used going back into project board.

B

So you can see that my issue is automatically set to the done column. So what I really like about using github issues and github project boards and also pull requests is that everything is in the same place. If you are a project manager, you might be familiar with the idea that someone is in github working and then you need to be in jira or the developer needs to switch between github and jira, and you know all this back and forth.

B

um I would also argue that some people might be in jenkins to do some stuff for ci cd, but actions would you know also help with keeping things in the same place. So if you are in that painful situation where you have to switch between tools, what I like about all of these features is that it's all in the same place and your project manager doesn't need to come in and ask: where are you at right now and the status of this ticket? Have you start working on it yet?

B

Well, they can just check your pull request. They can see if you close up issues and they can just use the project board as their own source of truth, and if you close out issues, things will be moved to the done column automatically. So it's a very cool way, a very efficient way to keep everything in one place and people don't need to like check on you to see. Where you are you work, you can just use leverage all these features to keep it nice yeah draft is a good tip. I am glad yeah.

B

A lot of people are not aware of the draft tool, but some people in the past have used automation to keep pull requests in draft mode sort of like a draft mode, meaning that they would prevent people from merging it. But yes, now we have draft feature, and it's really really nice.

B

Yeah um yeah, seeing that you are working, uh I think parnell said that draft pull request is a way that you can have everyone see what you're working on. I would agree with that.

B

um Some of the uh I guess, complaints that I get from customers is that oh, we have a sprint for two weeks and people don't push that where everyone is working on their local machine and they don't push it up until the day before sprint ends and then by then it's kind of too late to do qa and all that kind of stuff.

B

So what I recommend is to always open pull requests, draft requests early and often as soon as you get assigned to something or as soon as you assign yourself to something open, pull requests as soon as you can to let people know that you're working on it- and you can also keep track of how fast they're working on things yeah and putting it on project board, will also provide visibility into.

B

That uh someone asked so we don't need jira for kanban boards. Well, I don't know, I would say github project boards is a lot more simpler than jira, but if you're used to working jira sure, but if your jira board is not even that complicated, you don't need a lot of fancy graphs or anything like that. If you don't need to track story points, then I would say yes, github project board is is good enough. It's simple enough: it is close to code, it's close to developers and developers.

B

Don't need to build any integration back to jira. Then yeah, I mean why not use github project boards.

B

Can you merge draft pull request to production branch? No, so when you have a draft pull request, it is going to stay as draft, and it also means that no one can merge.

B

B

Oh thanks, brian yeah, I'm glad you're learning as well.

B

I that's my goal is to try to make github not as intimidated as sound as intimidating as as it is. I guess uh sometimes, when you know you hear from tech conferences or what you see in newspapers like you know: microsoft, buying, github, whatever it sounds like a very intimidating concept or technology, but really it's just like a place where everyone can work together. So it's not that intimidating and everyone can be on github all right.

B

So I'm going to move from project management into team and organization management, and for those of you who are on the free plan or maybe the team plan. This might be a part where you've probably never seen before. um I am going to be focusing on the enterprise products, because I talk to enterprise customers every day. um That's the product that I'm the most familiar with, I'm not trying to put on a sales, I'm not a salesperson by any means.

B

I don't know how to sell things, but because I am the most familiar with enterprise and it comes with the most features. That's the product that I'm going to be focusing on so before I jump into it. I definitely want to cover some concepts going from free github, free github teams to enterprise.

B

You have additional layers on top of your repositories. Again. Repository is what you see here. This is um where you would keep your project, and so one repository is usually one project and um you can build uh so with github enterprise. uh You would then have the uh another layer called another another layer called organizations, and then, on top of that you have enterprise uh layer, and so uh the enterprise layer comes with uh your github cloud enterprise plan and your github server.

B

So github enterprise server is the on-premise version of cloud um and we also have another product called githubconnect which allows for your cloud product and your server to talk to each other. If you ever need to I'm just putting these concepts out there, so you kind of know what I mean by organization. So you have this higher level uh enterprise level, and then, within that you can have organization and within your organization you have repositories from here.

B

I want to talk about the structure of organizations, so the first kind is that when you have a single org, you invite all of the users into all the repos, and this is how github does it. Github uh does not believe in silos. Well, unless it's like a hr repository, then yeah, of course we're not going to be in there, but other than that. um It's very, very open.

B

In github, I am not a developer on github.com, but I can go into the github.com code source source code and their repository and see what they're working on and see what their latest releases are. um So this is a very open. I guess open concept of uh how you want to manage your organization. So this type of culture is what we call inner source. It is essentially taking the idea from open source culture, so think of open source as everyone on the free internet contributing to projects.

B

So we are going to take inspiration from that kind of culture and put that within the four walls of your company. So when you practice inner source, um you allow for everyone to collaborate with each other. It's pretty free! That's very low barriers to other people's projects. um I guess an example is that our sales cycle, so I work on the pulse sales side. Whenever sales close on an account, um I would come in and help up with the customer, and so the entire sales cycle is all fully open.

B

I can see what's happening in sales or sales can come into our team's repository, and let us know that a customer's coming down the pipeline they're signing the contracts. Then we would bring in legal and finance to kind of finish out the contract deliver it and then we bring in finance again. So it's very open. I don't need to fill out any forms. I don't have a lot of bottlenecks when I need to talk to anyone, that's not on my team, uh so it's a very open place to collaborate.

B

I have another really good example of something I'm really passionate about. um So one of our co-workers. His name is park parker. um He was talking to a customer and noticed that there's like a small little tiny bug in the github.com ui, and what he did is that he just went straight into the github.com repository uh made. His changes opened a pull request and uh he was able to deploy that feature by the end of the day like it was just that fast.

B

If you think about it as a traditional software development, um more of a siloed environment you have to you know: if you encounter a bug, you probably have to talk to a project manager or maybe escalate someone they have to put in a spring cycle, and then you know eventually trickles down to someone working on the ticket, and so it's it's a very long process. But in our world, where everyone belongs to everything, uh we can feel free to just go and make the changes that we see in.

B

If our changes is, you know not something that we need at the moment. They can just say: hey we're not going to accept your changes at this time and that's fine. We tried, we tried to experiment, we provided our ideas, and that was good enough. So that's the kind of culture that you can cultivate, uh based on the structure of your organization and repositories.

B

Now, if that feels a bit too open to you, there's definitely like another level down by just adding teams to repositories instead of having everyone uh be part of every repository. So this is a very common structure for most of the customers that I talk to. They don't want to have everything too open, but they also don't want to have everything too siloed, so this is kind of a good in between.

B

um So just some take away from that. From that uh two slides, I just want to say that keeping things clean in one single organization is something that I recommend um and uh kind of adopt that inner source culture that we just talked about. But sometimes you know some customers, enterprise customers, especially they probably don't- want to have everything to open uh to the internet.

B

So they would probably keep some open source projects on their cloud product and sometimes they would also keep their more sensitive data in their on-premise version and they'll have github connect in between each other to talk to each other and they'll have two of them separate. So there are some customers that do that as well.

B

So that's more of a more on a stricter side of uh open, I guess and we're more on the other side on the other side of the spectrum, where we're pretty open with everything, and then you can also create teams in github and have them belong to each organization.

B

uh Some of the best practices that we recommend is to create teams based on product families. So in this example, that I have is that you can have one umbrella, product family of mobile and have a group called ios, android and web and have smaller child teams belonging to each smaller product. Family.

B

I'm gonna go a little bit faster because I would like to get to the end where I talk about how github uses github, which I think is the most interesting. So I'm going to try and fly through this last section, um so one thing to help with managing your policies and scaling up. Your policy is to use github apps if you're, not from.

B

If you're, on github and you're not familiar github apps, they are first class actors, they have their own identity, meaning that you don't have to manage a password and the username for them and they have a limited set of permissions. So if I hop back into my repository, I can show you an example of a github app.

B

This is something that I built with my co-worker and when you have a github app, it's a standalone identity and you can also give very very specific permissions to to your app so that it has, you know, limited access to everything. So this is an example of a github app, and this is one solution that you can do uh to help scale up your policies across multiple repositories.

B

So one example of how you can use github app is that, let's say you know for a user to join github when they create a repository. There's a lot of options here. They can choose, they can choose if they want to use a template or whether or not they want this repository to be public or private. Now, if a repository is public on github.com, it is public to everyone on the internet. So maybe that's something that you don't want people to have inside your company. Don't want them to accidentally choose the wrong option.

B

So there are settings for that. But let's say you want to use the route. You don't want to completely lock people down. You want to give them an option, but you also want to warn them that hey. Do you know that this is a public repository? Well, one solution you have is probot. Probot is a github app framework in node.js and there's a ton of examples on the probot website in that link, so one of them is to prevent public repositories from being created. So let's say someone creates a public repository.

B

The web hook gets triggered and probot will come and say you know open an issue and be like hey. Did you know that public is public to the internet? Just want to make sure that you know that if you don't intend to do this, you might want to change your repository to private.

B

Another thing is to turn is to use a probot app called settings to turn your settings into code. We always like policy as code. It means that you can version control it. You can contribute to it. If you need to, you can share it with other repositories if you want, but this is another app to to help you with your settings I'm going to skip through this part.

B

um Let's see if you're interested in forking and branching, we can talk about it during q, a uh but it's a one of my most passionate topics of all time, forking versus branching. uh The long story short is that I would prefer branching, especially if I'm in a working in a company, I would definitely prefer branching.

B

I would recommend branching, I wouldn't recommend forking at all in the company and because we use branching, you definitely want to protect your branches as well, protect the master branch or the main branch, especially, and you can do that under the repository settings you go into branches. This is how you would apply branch protection settings to your branch. um We also have a few solutions to protecting branches automatically, and so one of them is a jenkins bot that we have where every time something gets created, a repository gets created.

B

Jenkins will go in and protect those branches. So I'm not going to go too deep into it. I'm going to jump straight to the part where everyone is the most excited to hear how github uses github um some guiding principles we have is that we definitely emphasize devops way of working. We have an amplified feedback loop and it's cloud powered.

B

What it means by cloud powered is that we use github.com as a way to ship features first and then, if we get really good feedback, we here listen to customers and customers, really like some of the features, then only we ship it to the enterprise server on-premise version. So whenever we have on-premise version customers asking us if this feature has been tested out before we can say: yes, we've done it on cloud and it works.

B

We have good feedback. People find it valuable. So that's one way that we definitely emphasize the powered guiding principle, a very shortened recipe for the way github works. How we work in github. uh We have, we all share a common philosophy. We communicate asynchron asynchronously. We are a worldwide global team. uh We are all 100 remote even before coping, so we definitely communicate asynchronous asynchronously.

B

We use chat ups I'll show in a second what that means, and we ship a ton we ship so many times a day that I cannot even keep up. I have been in customer calls where a feature just shows up because they just ship it, and I know that's my first time. Seeing that feature, so that's something that's really cool at github.

B

We ship constantly, so one way that we use issues and our bots is that we would create issue for out of office, and uh once we have, you know, filled out this out of office request in an issue a bot will come in. Oh the screen, dude screenshot didn't work, but anyway, this is the screenshot where the bot says hey this person person's out of office. If you ping them um they're not available right now.

B

So that's how we use our bots to carry out that kind of asynchronous communication, and then uh we also use branching for sure we're not for the forking model. Branching allows us to experiment and hypothesize. We also use pull requests to get feedback from other people. It's a definitely a very open culture that we have at github. We also use github flow. This is a way where, again we create branches for experimentation. We ask for feedback.

B

We also deploy first before merging into the main branch, because deploying first, if anything, goes wrong, we can always roll back on the main branch. We all actually also have another type of workflow called back portflow. This is for our on premise version. Specifically. It means that every time you ship a feature onto main branch, we would cherry pick it to specific commits to uh versions that we want this commit on, and so we do that as well with bots.

B

uh Surprisingly, though, so when we open a pull request, we add labels to it on saying that which version on premise version and specifically, which version we want this feature to be on, so we add labels to it and a bot will come in and cherry pick all the commits onto those branches so that uh 2.21 22 will get those features, but not anything else before that this is our chat up hubot. You can definitely go to cubot.github.com to check out our documentation.

B

So these are some of the examples that we use chat apps, for we can look into our deployments. We can look into how healthy our load balancing is. We can look into notifications.

B

We can get more data back about our servers. Things like that. More frivolous things we use hubot for is we like to sparkle each other, meaning that we like to give people compliments when they do good stuff? And this is what it looks like- I literally took the screenshot yesterday, so I'm not lying.

B

We also give people nicknames and fun things whenever something funny happens, that's what we use hubot for, but for my day-to-day job on a more serious note, we often have to stand up get up enterprise server, our on-premise version uh to talk to customers, so we also use hubot for that where we can specify what region we want the server to be in how long we want it to be, and we instantly get a server ready to go to go off for customer demos.

B

We also use actions for sure. One example is that when we open an issue and a product manager says endorse, you know they're good, to go with this work item, and so when it does that an action will come in and then put this on the public roadmap if you're not familiar with a public roadmap, it looks something like this. You know if you're curious, to know what type of features that github will ship in the next few quarters. um It's all published here in the public roadmap. So that's what this is about.

B

You know in our own internal uh repository. We just need to put this action on and it gets published onto the public world map. So uh some closing word is that you know we're constantly learning we're constantly measuring. So who knows how this presentation will look like three years from now, uh but for now this is some high level thoughts about how we work at github.

B

So that being said, I know I used up a lot of time, but I'm going to reserve the next few minutes for questions and I'm going to look into the comment section as well: how to resolve github conflicts, um there's some really good stuff on learning lab if you're curious to solve conflicts but they're not to be feared of, um I think when I first used github.

B

I definitely feared merge conflicts a lot, but you know it just means that it requires a human being to come in and fix stuff and decide, which is the actual source of truth um and just cleaning up conflict markers. I guess I think it's a very long answer to go into.

C

B

Thanks alex for posting those links.

B

Okay, I thought I think I talked uh really fast uh marcos asked. Why can't I see project templates? Oh so when you create project um at the bottom, there's a template. uh Let's see if I can see here and that's where you would choose your project template.

B

So if I go into projects, I say new project at the bottom project template. This is where you can choose what template that you want to use.

B

Is pr customizable with code review rules? Yes, um you can add something called code owners. Encode owner's file will dictate. Who do you want included in the um in the poll request review.

B

Also aj, I'm not sure if it's that time right, I just want to make sure that.

B

Oh, I think you made it.

A

Of course, I am you're doing great uh feel free to keep answering questions uh or if you want to wrap up, that's perfectly fine too. uh If people do have questions after the stream is over, like where's the best place to ask those questions.

B

um Best place to ask those questions.

B

I I want to say you can message me, but I don't know if that's going to open some kind of floodgate.

A

Yeah that I'm sure that would be nice but, like um I think, maybe like uh github.community, is also a good place to go. uh If you have specific questions, if I saw alex put in a uh link to lab.github.com, which is always a great place to get started, uh the tutorials there are all the way from absolute beginner to some really in-depth stuff.

A

So, like you know, there's there's uh plenty to learn from over there and also, if, if you want to get more in depth as well, uh we've got the infocus series of events coming right up uh starting next week. I believe uh so there will be all kinds of topics covered from developer experience to secure development and everyone's favorite topic devops, so lots of resources available. So you can check them all out. This uh stream itself will be on linkedin available video on demand right after the session's done and we're also uploading it to youtube.

A

So everything we try to make it as available for you as possible and uh we'll see you all over the internet.

B

Cool, should I keep answering questions or are we good.

A

I I think, we're good then.

B

A

Cool thanks again rowena. I super appreciate you coming to demo days and and kind of giving like that end to end view of what am I doing when I'm just starting with github. How do I use github going into things as uh fundamental as like issues and project boards, and everything so super appreciate you being here today and thanks again, yeah.

B

Thank you. Everyone.

A

All right, bye-bye.

B

C