Webcast • Github for Project Management

(Cynthia) Hello there everyone,

we're about one minute before the start
of our webinar,

and we'd like to do a just a quick
audio check,

make sure everyone can hear us ok.

So, I have put a poll up on the screen

about our audio levels,
if you could please just let us know.

(Allen) Okay.

(Cynthia) Great. It looks like we
are in good shape then for our audio.

So we are right at 12:00,
and we will go ahead and get started.

First up, I'd like to introduce myself,
my name is Cynthia Rich.

I am a trainer with GitHub
and I am joined today by Allen Smith,

another trainer...from GitHub

and we're going to trade off today
as we go through this topic

and share some of our relevant
experience with you.

Today's session is about project
management and how we use GitHub

to manage projects within GitHub.

So really quick, just so we know who
we have on the phone with us,

on the webinar with us, excuse me,

a little more about you,
I've put a poll up to tell us

a little bit about your project
management experience.

While you're doing that
I'm going to tell you

a little bit about
what we hope to accomplish today.

So during today's webinar
we'd like to share with you

some of the best practices
that we've found

for managing projects using
the GitHub architecture.

So we as a company we manage
all of our projects within this platform

and we store all of our conversations,
communication, everything goes here,

and so we want to share with you
the secrets that we use

to make this effective and to ensure
that we can collaborate

and communicate effectively
across our team.

So it looks like, okay great...

So it looks like we have a good split

of folks who do
a lot of project management

and then some folks who
are interested in the topic.

If you have someone on your team
that you'd like to share this webcast with

we will be recording this and we'll send
you a link after we finish up.

So I'm gonna go ahead and close the poll.

And, I'd like to jump right in
and let's show you

what we're going to accomplish today.

So the project we've set up that we'd like
to show you today

is a very basic GitHub Pages page.

Now if you're not familiar
with GitHub Pages

GitHub Pages is our,
essentially free web hosting,

if you will, platform.

It allows you to connect
your GitHub repository directly

to this GitHub Pages and set up
a project webpage,

something that you can communicate
with the outside world about your project.

So again, these are free to set up.

There are instructions on this page

that we're showing you here
so pages.github.com

You can go there, it'll tell you
everything you need to know for how

to set up your repository
to communicate with this page.

The page that we have set up
is actually a little cookbook

So let's go back over,
and if you'll, there we go...

Our Project Management Cookbook,

and you can see there this is
a really simple page

just something we set up for example sake

with a few links to some
different recipes,

hopefully this isn't lunch time
for everyone,

we'll all be hungry when we get done.

But like I said,
a really, really simple page

'cause what we really want to show you
is what's under the hood,

or what's behind the scenes that's
helping us to manage this project.

So, as you know, everything within GitHub
is managed within a repository

and that repository is the collection
of everything relating to your project.

So your project files, your project
communications, all of the metrics

involving your project.

Everything within your project is stored
in this repository.

Now in order to do some of the things
that we are going to show you today,

we had to make a few assumptions,

and one of those is that you're an owner
on the repository that you're working on.

So if you're not an owner
on the repository

there may be a few things
we're gonna show you along the way

that you won't be able to do

and so you might want to either look into
changing your permissions level

or how you can work out
getting some of these tasks accomplished

with someone that has
the appropriate permissions.

So, I'm gonna start by just walking you
through the interface

showing you how we use some
of the different sections within GitHub

and I'm gonna start
on the right-hand side.

Right now you can see that we're
on the Code tab over there on the right

and the Code tab is exactly what it sounds
like, these are your source files.

This is all of the content that belongs
to the repository,

that is then shown on that webpage.

Below that we're gonna see Issues
and Pull requests.

We're gonna talk a lot about those
in just a minute,

so we'll come back to those.

But one of the things that's really useful
within the project is the Read Me file.

The Read Me file...

There are a couple of magic words,
the Read Me file being one of them,

and with the Read Me file,

this is a page that's automatically gonna
render on the front page of your project.

So when someone comes to visit you
they can see all of the information

in your Read Me file
just as its shown here.

Now in our Read Me file we've decided
to put some more information about

how to add recipes to our cookbook,

so a little information about
how to contribute to it.

We've even provided a recipe template

so if someone wants to contribute a recipe

they can just copy and paste
that into a text file,

put in their recipe and then commit it

and do a Pull Request back to us.

We tried to make it really easy for people
who wanted to join in.

There is another type of file that you
may see commonly,

called a CONTRIBUTING.md,

and that file,

that file tells people how to contribute.

This page is a little bit different

because this page is only going to show up

when somebody tries to submit
a Pull Request,

to actually contribute a recipe
to the cookbook.

So we'll see that in action
in a little while.

Now you'll notice that we do have some

really basic formatting
on all of these pages

and if we click the little pencil button
there, we can see...

that all of these pages

are written in a very lightweight language
called Markdown.

Markdown is really basic, really simple

as you can see the header there is just a
hash mark and a space

and then your header.

Our bullets are created
with simple dash marks.

There are actually guides
on using Markdown

we won't get into that in the course
but we will include a link

in the course notes for you
so you can go in and find out how

to do Markdown on your own.

So like I said, really simple language
to use and we're gonna show you

a couple of pretty cool things you can do
with it in just a little while.

So, another option
I'd like to show you

that is particularly useful
for project managers is the wiki.

Not gonna get into this too much,
I think most of you probably know

what wikis are,
just a collection of pages,

but these are really good for if you want
to store a project schedule maybe,

or a budget, or maybe a team charter,
something like that

you can put that here.

And like I said, we won't spend a ton
of time on that.

On the top bar, lets look up there
where we talk about

watching and starring and forking,
and what are those things.

One of the things as a project manager
you're probably going to be pretty

interested in what's going on
in your project,

so you'll want to watch the communications
and conversations that are coming through

any of the actions that are happening.

So if that's the case, then you'd want
to select this option here to be watching.

So you would get literally a notification
any time someone creates a Pull Request,

commits something, closes something,
you're gonna get a notification.

But maybe you decide you don't want
that much information about your project,

you can choose Not watching,

and if you choose Not watching,
notice there that you'll still be notified

if you participate in a conversation,

so if you add something to a discussion
you'll continue to get notifications

about that discussion.

The other key there is if someone
@ mentions you.

So if someone is entering an issue
and specifically says,

"Hey, I need your help with this Bill,
can you give me your opinion",

then you'll still get a notification.

So Not watching doesn't mean
you never find out anything,

it just means its a more limited set
of information.

And then of course, you could ignore it,

which I don't think you'd want to do
as a project manager,

but I guess that's always your option.

The other option there is to Star
a repository.

Starring is a little bit more
like bookmarking.

So we get this question a lot, what is the
difference between Watching and Starring.

Starring essentially will add these stars
to your homepage.

So if we star this page and then go back
and look at GitHub Teachers homepage

you'll notice down here
on the left-hand side there's a Starred

and you could click that link to see any
of the pages you've starred.

So this is just a way to keep track
of pages that look interesting to you,

and a nice way to bookmark those pages
to come back to them later.

So, what I'd like to do
is run back to the main repository

and we're gonna jump right in to talking
about some of these core

communication tools we use
within our projects,

And we're gonna start
with Issues and Pull Requests

and I'm gonna ask Allen to jump in here
and help me with these

and I'm gonna have Allen tell us
a little bit more about Issues.

Before I do, I just want to say
the difference between these two

to conceptually think about these,
if you think about Issues as

"I have a question,
or I see something that's wrong,

but I don't know what to do about it",
then you'd enter an Issue.

If on the other hand,
you have a question

you know how to fix it,
or you already have fixed it,

then you're gonna use a Pull Request.

So that's how we think about these

to kinda separate what goes
in each of these buckets.

And now I'm gonna turn it over to Allen,

to give you more information about Issues.

(Allen) Alright, yeah, thank you Cynthia.

So let's dive right in and take a look
at our Issues here, on the Issues tab.

And, its right there under our Code tab,
so we'll go ahead and click that.

So traditionally when you think
about issues, you know,

in terms of software development

you may think that issues represent
problems, represent bugs,

and that's certainly the case.

Depending on how your project is set up,
you may be using Issues to track bugs,

or possibly even enhancements.

If this is sort of a general project

you may want to use this to track your
project requirements for instance.

And that's sort of what we've done
in our example here.

So if you notice in our Issues list,
we have several different recipes

that are to be added to our cookbook.

So we have recipes for Mexican
hot chocolate, or holiday punch,

but then we also have other Issues
that have been entered by other people.

For instance, this one is a problem,

so the Lemon Icebox pie directions
are missing steps.

So in this case it is an issue,

I'm sorry, it is a bug, or an error
that needs to be corrected,

so Issues are very flexible and you can
use them to manage

different types of issues. (laughs)

But ultimately what we're talking about
here is workload management, right?

So Issues track the work to be done.

and GitHub has tools that let you manage
that work both at a high level,

and then also with a kind of fine grain
focus when you need to.

So, I think the best step for us right now
is to dive in and create a new Issue.

So, we click the green New Issue button

and we're presented with this screen here
where we enter a title for our issue,

so we want to have something
that is descriptive,

or as descriptive as possible,
so we would say for instance,

maybe, "add new lunch menu items",
something like that.

And down below we have a comment section
and just like other areas of GitHub,

this comment section does support Markdown

so we're gonna leverage that power
to do a couple of things

to help us manage our tasks
related to this Issue.

So for instance, I think we need to have
a lunch section, so here are some ideas.

And we can use the Markdown syntax
to create to-do list items

within this Issue.

So, for instance, we have hoagies,
we have, oh, I don't know,

strawberry salad,
everybody likes strawberry salad,

so, we'll create our checklist here
of items that are suggested

and, uh,

you can even,
if you'll notice at the bottom there,

you can drag and drop images directly in.

So, for instance, if you are reporting
an issue, you can take a screen shot

and drag it straight over to your browser
window and it will automatically

upload to GitHub and post it to the Issue.

It kinda lets you communicate the issue
as you see it, in a little bit better way.

Just like other areas,
if you @ mention someone here,

GitHub is going to send that person
a notification as well,

and that feature is useful for pulling
people into the conversation,

like Cynthia said.

Especially people who are not necessarily
watching the repository.

And so we'll enter another comment here,

and so in this case, GitHub Student
is going to receive a notification

that they've been pulled into
this conversation by GitHub Teacher,

and GitHub Teacher is requesting
input from them.

So...

If we go back to our Issue screen
we can see that the new Issue

has been created at the top there.

Now one thing I want to show you here,
is that you'll notice to the right

of that Issue description,
we have a little check box,

and then we have 0 of 3.

So let's hop into that menu item
one more time,

and if you'll notice, GitHub did create
these check boxes

based on those we created in Markdown.

So let's check hoagies off for instance,

so let's say that hoagies have been added
to the cookbook,

if we navigate back to that Issues page
we can see that GitHub has updated

that task list to show us that one
of the three tasks from that Issue

has been completed.

So, if you think about it,
that's a really powerful feature

for digging down into these Issues,

that may have subtasks
associated with them.

It lets you break your work up
and manage it, but still,

track the progress,
which is super valuable.

Let's take a look at how GitHub

lets you manage this list.

Because we have how many items?

We have 20 open items
and 6 closed items,

so let's say we wanted to track certain
things about certain items.

We can use Labels,
and assign them to Issues.

So let's hop back in to our
new lunch menu item Issue

Over on the right-hand side of the screen
we have a Labels option.

So Labels are pretty powerful
because what they let you do,

is essentially tag an Issue
with a particular category or context,

that you can use for filtering later.

So there are a couple different examples
you might use for this,

You could use it to track progress,

so for instance in our repository here,

we have different labels for marking
how far an Issue has progressed,

if its in the backlog,
or if its in progress,

or even if its completed,
we can label it that way,

and then filter by that tag, I'm sorry,
filter by that Label later.

Other ways you might use Labels

You can use it to track priority.

So for instance,
if you have a critical issue,

or something maybe that's low priority,

you could use Labels for that as well.

You can also check Labels
for the nature of the issue,

and in this case we have
different departments.

So we have Content,
or Design, or Editorial.

So we can check those Issues and then

filter by them later,
which is what we will do right now.

So, if we navigate back to our Issues page

and click on the Labels header,

and then let's see everything
that is maybe, in progress,

that is also critical.

So if we click the Labels header again,

we can see that these filters
are additive.

So, this is terrific because there's
nothing in progress that's critical.

But it could be bad, because there could
be critical issues in the Backlog.

So, lets take a look

and see if we have anything
critical that's in our Backlog.

So, nothing there,
so that's definitely good news.

So you can see how you can use
these Labels to kinda filter

your Issue list down,
and manage a large number of Issues,

in a very small way,

to kinda focus in on where
you want to work.

So, another thing we can do with GitHub

is we can manage those Labels in bulk.

Which is really helpful, right?

Because you wouldn't necessarily want
to go into every single Issue,

just to change one Label on say,
60 different Issues.

So if you use the check boxes
to the left of the Issues,

you can select multiple Issues,

and then you can assign a label
to all of those Issues.

So for instance, if we wanted to mark
these as in progress,

we could click In Progress and it would
add that Label to any of the Issues

that don't already have it.

And you can do this for unassigning
Labels as well.

Another thing we can do
when we select multiple items,

is we can assign multiple items
to a particular user.

So this is one thing that's helpful

if you have several issues
that have reached an end point

where they need to be escalated
to a different user.

So for instance, if all of these Issues
need to be viewed or managed

by GitHub Teacher now, instead of both
GitHub Teacher and GitHub Student

you could click that and it would
reassign those Issues,

uh, it should,

to Git Hub Teacher.

But it looks like anything
that was assigned to GitHub Teacher

has now been unassigned.

But again, you can use
the Bulk Add feature

to go in an reassign it to GitHub Teacher,

and in this case GitHub Teacher will get
an email notification

or a notification on GitHub

that they have been assigned
to this Issue.

One more way that we can manage our tasks,

over on the right-hand side
of that top bar we have a Sort option.

And it let's us sort by a couple
of different criteria.

So, we can sort by newest or oldest.

So this is a great way of letting us see
what's coming in.

If we sort by newest, we can see these new
Issues that have come in.

If we sort by oldest, we can actually see
the Issues that have stuck around

in our repository for a long time.

So maybe if there are Issues there
that aren't getting resolved,

we can sort by that and see
what's been here the longest.

Another way we can sort is by
Most or Least Commented.

And a great way to use this,
is for instance, if you see an Issue

that has a ton of comments on it,
but it's not really progressing,

that might be an opportunity for maybe
potential conflict resolution.

Maybe people are talking about an Issue
that needs to get resolved,

but nobody has really moved
that Issue forward.

So that's a great way to drill down
into those Issues

that a lot of people are talking about
but not necessarily solving.

Alternatively, if you sort by Issues
that don't have a lot of comments,

that means that those Issues are maybe
not getting the attention they deserve.

Maybe you need to @ mention somebody
in some comments and say

"Hey, can you guys weigh in on this".

And the final way we can sort,

is by Recently Updated,
or Not Recently Updated.

And this is a great way of seeing
which Issues are active

which have a lot of activity on them,

and also which activities don't have a lot
of activity on them.

Again, maybe they're kind of stale,

and they need to be moved forward.

So, we'll mention GitHub Student here,

and we'll ask GitHub Student
to work on this.

So let's go ahead and take a step back
and talk about what we're working toward,

in a bigger picture view.

So we've kinda drilled down
into the way that you can manage

individual tasks on Issues.

But now if we wanna step back and look
at our larger goals or our objectives.

We use a feature called Milestones.

So, if we click the Milestone link,
on our Issue,

we have a couple of different Milestones

I guess we just have one Milestone here,
its our Third Edition.

So, Milestones let you organize

your Issues into groups

that satisfy objectives
within a particular timeframe.

So this kind of dovetails nicely
with project management in general

because that's a typical workflow
that you would have.

You'd have milestones that have to be met

with a certain amount of work
that has to be done, by a deadline.

So let's go back to our Issues list,

and up at the very top
we'll click on Milestones,

and get a better view of this.

So, in our repository we have one
open Milestone

called Third Edition.

And what we're using Milestones
for in this case,

is to manage publication editions
of our cookbook.

So in this case we have four open Issues

that need to be completed
by March 21st of 2015.

So if we click on Third Edition,

this will drill down in and apply filters
so that we can see all of the Issues

that are assigned
to that particular Milestone.

So we have our Lemon Ice Box
pie directions are missing steps,

the recipes are showing up duplicated,

there's a request to add more side
dishes with vegetables.

So let's say that Holiday Punch Issue
down at the bottom,

that's in our Backlog right now,

but maybe that's too much work for us

to get into this Milestone
by mid-March here.

So what we can do,

is we can change that Milestone,

and what GitHub let's us do
is actually create a Milestone on the fly

from this page right here.

So if your Milestone doesn't exist
you can type in the name,

so we'll say Fourth Edition, perhaps.

And if you'll notice GitHub automatically
gives you the option to create and assign

this Issue to a new Milestone,
which is a terrific shortcut.

So if we go back to our Issues page

and let's go back to our
Milestones page again,

and take a look.

So we now have our Third Edition
and our Fourth Edition Milestones.

So we can click into our Fourth Edition.

Oh I'm sorry, let's go back to our
Milestones page.

We'll click Edit under our Fourth Edition.

So if you'll notice when you create
a Milestone you can create a title,

and add a description,
and you also have an optional due date.

And the description itself
is optional as well,

but its helpful to add it
because again,

coming back to project management

we're always looking to increase
communication,

just to communicate our goals clearly
and transparently.

And so we see that deadline
has now updated.

So one way to apply this, you know,
depending on the context of your project,

you know, if you're working
maybe in an agile environment,

you might use Milestones to organize
your Issues into sprints.

So you could have a sprint for the month,
or a sprint for the two-week period.

However you have it organized.

And that let's you as a project manager
come in and see what types

of Issues still need to be completed
for that particular sprint.

And then again, if you have completed
all of your Issues,

you can always close a Milestone.

And then if we go
over to our closed section,

we can see all of the Milestones
that we've closed out.

In this case, it looks like
there are a few Milestones

that didn't get completed

and that's okay
for demonstration purposes,

but again this let's you see

what was completed and what wasn't.

So its a nice way of looking at your work
at a higher level.

And so with Issues, we've looked
at ways to manage the work

that needs to be done.
Right?

So, I'm gonna turn it back
over to Cynthia,

and now we're going to explore some
ways to review and approve

the work that is being done.

(Cynthia) Great, thank you Allen.

So we're gonna jump over now...

we've reviewed what to do when we
don't know how to fix the problem

but now let's take a look at what to do
when we do know how to fix the problem.

Maybe its something really simple,

You know, 'I'm a project manager,
I can add instructions to a recipe',

'So, I don't need someone,
a developer to do that for me',

'I can actually go in
and fix this problem.'

So let's go back to that recipe,
that didn't have instructions,

and we can find that in our Issues.

And we can see that its our Lemon Ice Box
pie that's missing directions.

So we're gonna keep in mind

that we have an Issue
open on this for just a second,

and let's navigate over,
using our code view,

let's navigate to that
Lemon Ice Box pie recipe.

So we're gonna click on recipes,
go to desserts,

grab our Ice Box pie.

Now you can see here
this is the actual file,

its again written in Markdown

GitHub allows you to write all of your
content in Markdown

and then it uses Jekyll to display
those on the web for you.

But in this case, we're just going to edit
this Markdown file.

So you can see that on the top bar there,
there's a pencil,

and we're just going to click that.

And here's our nice Markdown,

again you can see some other formatting
options with Markdown here,

you've got the double asterisks
which provide the bold text,

the triple hashmarks,
which create a third level heading.

So let's go down here to the preparations

and oh yeah, we definitely need
to fix these.

Put all the ingredients for the crust
together and bake it.

I think we're missing a couple of steps.

So let's make sure that we also combine
the ingredients for the filling,

and put those in the crust
before we bake it.

(Typing sounds)

Perfect. So now that we've made
some changes,

the nice thing about GitHub obviously
is that its going to version control

everything that you do.

So, we've created a new version
of this document.

In order to save that
and put that into version control,

we need to commit these changes.

So, it's really nice, GitHub knows
that we've made a change to this document,

so it's automatically gonna give us
the option to commit those changes

right here, you don't have to go
anywhere else to do it.

So, it even is nice enough to give you
a recommended title for your commit

so this is where you're going to put
a descriptive title there,

so that everybody else knows
what you did in this commit.

So for this commit I'm gonna
say something simple like

'added preparation instructions'.

The extended description is optional
you don't need to use that

we are not going to use it today.

And then I want you to notice
at the bottom

there's two different changes, er,
two different options.

Notice that the first option says
that you can commit directly

to the GH Pages Branch.

Well we haven't talked
a lot about branches just yet,

but essentially the branch
is the set of code.

And for this particular example
GH Pages is the set of code

that's actually displaying
on our external website.

So if we commit this directly
to the GH Pages Branch,

then its gonna go live right away,

and everyone who's visiting
our recipe website

will see the changes that we've made.

Well we don't quite want to do that.

We actually want to have some other folks,

maybe our cooks
are going to look at the recipe,

and make sure
that we got this right.

So what we're going to do instead
is we're gonna create a new branch.

What a new branch does
is it isolates these changes

from our live code
from what's displayed on the website,

so we can make changes to the code

maybe have a conversation about it,
discuss what we need to do,

but we can do that completely separate,

so that we don't harm that code,
that's out there on the website.

We can even decide,
you know what,

we decided that we don't
want to do this after all,

and we can delete this branch
and those changes will never go

to the main site.

So in this case,
we're gonna create a branch for this,

we can call this branch
'Updating Recipe',

and we can go into proposed file change.

Now the very next step its going to ask
us to do is create a Pull Request.

And you remember
a little while ago we looked at

that CONTRIBUTING.md document,

well you'll notice in the yellow box here,

you'll see some guidelines
for contributing,

this is where that file appears.

So if I wanted to click on that link,
which we won't do now,

that's where you would see those
contributing instructions.

So in this case, we've made a change

we want to have some discussion about it.

The next thing we need to do

is we need to ask for feedback
from our coworkers.

And the way we do that within GitHub
is to create a Pull Request.

And so you can think of a Pull Request

as sort of pulling in comments,

pulling in feedback
before you make a change.

So we have the option here
to write a comment,

we could perhaps put a comment here like,

'I added some instructions
please take a look at this'.

(Typing)

There you go.

And so we can even, if we wanted to here,

notice we can still drop images
just like we could in the Issues,

like Allen showed us
a few minutes ago.

So I think this note is pretty good.

We can go ahead and click
the big green button

that says create Pull Request.

So notice that GitHub has automatically
created a conversation for me.

It has added that original commit.

So if you'll notice there is says,

"added preparation instructions"

and there's that number
over there at the side,

that's the commit,
so it saved that version,

and it has added some comments
so that your peers can come back,

or so your friends can come back,

and they can give you feedback.

You'll notice that we have to option here

we can immediately merge this
if we want to,

but we actually want
to get some feedback,

we want some discussion.

So if you scroll down,

you'll notice there's the option there

to leave comments,
just like you saw in Issues,

and we can continue to comment,
make changes to that file,

and it'll all stay in this safe place
in this branch,

where we can get it absolutely perfect

before we publish it
to our main page.

The nice thing about the Pull Request

is that it also gives us the option
to see what has changed.

So if you go up to the top
and you look at the Files Changed

you'll notice that it shows you
a view here

that is the original file on the left

and then what's been added
or changed on the right.

So in this case we've just added
a couple of things

so that's highlighted in green for us
to show that its new.

If we had deleted anything
it would be shown in red

to show you what was taken out.

So this is just a really nice way

if someone puts a Pull Request in,

to see what actually changed,
what are they doing that's different.

This is also really good in a more complex
project to do code review,

Where you might want to show...

You might want to be able
to look at the code

and understand what's changed on that.

You can integrate other tools with this.

There are tools,
continuous integration tools

that will allow you to automatically check

the code as soon as you submit
the Pull Request

to see if its gonna build or not.

So those are some really nice tools.

You can find out more about those at
github.com/integrations

So in this case, you know what,

I think maybe we need
more instructions here.

I feel like putting the ingredients
in the crust and baking it

isn't the end of the process.

So I'm gonna put a note
on this line down here

So, 'putting ingredients in crust,
feels like there needs to be more here',

and so by clicking on that line

I'm able to insert a line comment.

Again, really helpful if you're
commenting on code.

And again Markdown is supported here.

You could also enter pictures
if you wanted to into this comment,

and then just click Comment.

So in this case we really do need to add
some more instructions,

so let's go back over to our file,

(clicking)

and it's gonna give us the option here,

to change it again
using our online editor.

So in this case we need to put
the ingredients in the crust and bake it,

but then we probably need
to make that meringue.

So let's go down to the bottom

and let's add some instructions there
to make the meringue topping.

And...

Here we go, add the meringue.

Now you'll notice that this time
its asking us

"Do we want to commit directly
to that Updating Recipe branch?"

So it knows because we went to this file
through that Pull Request,

that we're making these updates
on the branch,

and not on the main
GitHub Pages website.

So in this case, yes,
that is exactly what we want to do.

We want to update that branch
and we're gonna commit those changes.

So now we're back at our view
where we can see the difference

between the two,

and you can see that we've added
this meringue topping.

So I think this looks pretty good now.

So let's go back to the conversation.

And one of the things that we like to do
to kind of sign off

and let each other know that we think
something is ready to go,

is we'll go down into the comment field

we love emoji,

and so we'll enter a little +1 emoji
to give the thumbs up.

And Comment.

So perfect, it looks like we're ready
to take the next step.

So in this example,
let's look back up at the top,

back up for just a second,

we can see the complete story
of this recipe.

What's happened to this recipe
since we started making changes to it.

So we can see that GitHub Teacher added
some preparation instructions,

then someone made some comments
on those instructions,

that says, 'we feel there should be more
information there,'

there's been a second commit
that added those instructions.

So at this point
we're in pretty good shape.

So I feel like we're ready to go ahead
and merge this Pull Request.

So let's click the big green button.

And by merging this Pull Request,

what we are doing is we're actually taking

this recipe now and we're moving it back

to that main GitHub Pages branch,

so that it will show to the world.

So everyone will be able to see
the changes that we've just made.

The other really nice feature here

is GitHub wants to save you some time.

So if you reference that original Issue,

so you remember we had
that Issue that said

we needed to add instructions
to our lemon merigue pie?

There are a few keywords you can use,
Fixes is one of those.

And so you can say, 'this fixes
or this closes',

and then you can use the hashmark,

and you'll notice now it pulls up
the open Issues that you have.

So you can find the Issue,

that's related to this Pull Request

or the Issue that you were trying to fix,

you can, if the list is really long,

you can type in a word
that you remember from the Issue,

like we've done here so you can see.

There's our Lemon Ice Box pie directions,

its Issue number 32,
I'm gonna click on that,

and I'm gonna confirm merge.

Now it says the Pull Request
was successful,

its been merged and closed.

We don't really need that branch anymore,

there's nothing on it, its empty,

so we can go ahead and delete that.

But not to worry,
you can always restore it if you need to

as you can see the option there.

So let's see what's happened,
to this Pull Request.

So if we scroll back to the top
of the Pull Request,

we can see that the Pull Request
has been merged.

So that's done.

But what about that Issue?

So let's go back over to the Issues,

and we'll have to go to Closed,

and there's that Issue,

so that Issue has now been moved
into Closed

as you can see up there
on the left-hand side.

So that's just a really quick walk-through

of how you'd handle making changes.

As I mentioned its very intuitive
as you go through,

it'll tell you exactly what you need to do
for the next step,

its just a matter of following along
and remembering your primary steps here.

You're gonna edit the file.

You're gonna commit those changes.

You're gonna create your Pull Request,

and then after the changes
have been finalized,

you're gonna merge that Pull Request
back in with the main branch.

So with that...

We have a few more things that we want
to show you for managing your project,

and I'm gonna hand it back over to Allen,

who is gonna take you through
how to add team members,

and see how the team members
are progressing.

(Allen) Yeah. Thank you Cynthia.

So with the time that we have left,

I wanted to take a little bit of time

to walk through some of the tools
that you can use

to manage the human resources
on your project,

as opposed to the code resources,
and the tools that you have

at your disposal.

The first way that we can help manage
this increased communication,

as Cynthia said,
is by using teams.

So in our example
we're assuming a few things.

We are assuming that you have
an organization account,

as opposed to just a personal account.

So if we go back to our repository

and we click on our settings,
over on the right-hand side,

there's an option for Collaborators.

And, I'll type in our password here.

And you'll notice on our repository
right now we have one team

associated with it.

So that's our owner's team,

and in that case the owners control
everything on the repository.

But let's say we want
to create a new team

to kind of group people together.

And that's one of the ways
that teams really shine.

If you think of teams,
they're kind of a hybrid

between a distribution group
in something like say Outlook,

and an Access control group

from something like
maybe, Active Directory.

So you can use them
to control access to your repository.

But what's really awesome
is they let you group people together,

so you can bring multiple people
into the conversation all at once.

In this case we gonna create
a Vegetarians group,

who has read access to our repository.

And we're gonna see how you can use that
to further a conversation,

or put it in a different direction.

So let's navigate back to our repository,

I'm sorry, I jumped ahead here,

let's add some people to that team.

So let's go back to our settings

and Collaborators,

and we will choose an existing team,

and we see Vegetarians here,

so we'll click Vegetarians and add team.

And it looks like we have
one person in that team,

but we'll add them to our repository.

And so now we'll go back to our cookbook,

or we could add people to this team
if we wanted to, so maybe Cynthia,

do you want to be on this team?

And maybe we'll add GitHub Student.

So really easy, GitHub just autocompletes
these names for you,

it makes adding people a breeze.

So now we'll navigate back
to that PM Cookbook.

And let's take a look at an Issue,

and see how we can use Teams
to push an Issue forward.

So down here we have Issue 26 for
"Add more side dishes with vegetables".

So, it looks like Cynthia here
has proposed new recipes,

so she says maybe we should add
some dishes with carrots, green beans,

or maybe artichoke.

And I commented back, and I said,

"Well, I'm not really sure an artichoke
is technically a vegetable."

What would be great in this instance
as a project manager,

you can loop in those vegetarians,

and say "Hey, can you guys weigh in,

since you happen to know a little bit
more about vegetables in this case?"

We can @ mention our vegetarians.

And we say,
"Vegetarians, what do you think?"

And so we'll comment,
and everyone in that distribution group,

that Team, will get a notification.

And if you mouse over vegetarians,
you can see who that went to.

Its a nice way of seeing

who all is on a team,
who you actually just pinged,

and who you can expect to hear back from.

So the next thing I want to talk about
is a tool called Graphs.

And there are a lot of different pieces
to this Graphs tool,

but the one we're gonna look at today
is this Contributors tab.

This is a really great way of getting
a better sense

of who's doing what work on your project.

So you can filter this graph
a couple of different ways.

Right now its filtered on commits

but we can also filter it on
Additions or Deletions.

So if you think about Additions,
these are people who

were adding code into your repository.

If you go to Deletions, the same deal,
its people who are removing code.

And then if you filter by Commits,

that shows you people
who are making changes,

whether they're additions or deletions.

Now, I have a tab open
here in this browser,

because we don't have a ton of data
here in this repository,

so if you see up here,

Contributors to GitHub Training Kit,

this is the repository
for our public training kit,

these are open source materials,

we have a much bigger timeline,

and you can see how
the activity fluctuates.

We have a much larger group
of Contributors,

and so we can see who is pushing code
into this repository,

right now it looks like
Jordan McCullough is our rockstar

because he has added 236,237
lines of code to this repository.

Now this is a big long timeline

but let's say we just wanted to look
at the activity in 2014,

from let's say, February through March,

if we click on the graph
and drag across it,

the green one up here at the top,
if we drag across,

it will actually dive down
into that timeline

and show you a zoomed in view
of that particular selected timeframe.

So if you want to examine
some of these curves a little bit closer,

you just drag across,

and GitHub automatically shows you
that timeframe.

So its a nice way to see
what activity is going on,

but more importantly,
who is doing it.

So finally, lets take a look
at the Pulse tab.

So we've dove down into our repository,

we've looked at all the ways to manage
Issues, manage Pull Requests,

at a very highly detailed level,

especially through the Graphs tool,

we can dig down and see
what those changes are

that are actually going on in the code.

If you think of the Pulse tab,
its a way of stepping back,

and viewing your project,
sort of at a distance,

but at a higher level so you can get
a better sense of what

kind of activity you have going on.

So let's hop back over to our GitHub
PM Cookbook repository.

And we'll go to the Pulse tab here,

'cause there's a little bit better
activity going on.

It shows you how many Pull Requests
and Issues have been opened

and also been closed.

So you may use this for instance if you
have a lot of new Issues coming in,

but not a lot of Issues being closed
in this time period,

you may want to dig down in and see,
you know, what's going on there.

Down below, it breaks these numbers down

so you can see which Pull Requests
and Issues are contributing

to the numbers at the top.

And so, as an example, let's take a look
down at one of our open Pull Requests.

And I'll show you how you can use
this tool to kind of dig in

and look at workflow issues
that you may be encountering.

For instance, one of these proposed
Pull Requests,

we have side recipes for review.

So it's been open for four days

and there hasn't been
a lot of activity on it,

it hasn't been closed
since it's been opened,

so let's see what the conversation
is on this particular Pull Request.

Somebody had submitted ideas
for side recipes,

and GitHub teacher has commented back

and said, "Hey, I believe Crockpot
may be a trademarked name."

So as a project manager we can see
that this has stalled out,

what we might want to do is comment back,

and we can actually
loop in our legal team,

we have a legal team here
in our cookbook repository,

and we'll just @ mention our legal team.

And ask them if they can weigh in
and see if they can let us know

just to clarify this so we can move
that Issue forward.

Because that's what we're really aiming
to do here is to increase communication,

we're looking to identify issues
that may be blocking us,

and help our developers
get their work done.

So we've commented back

we're saying "Hey legal department,
can we use 'Crockpot'".

And hopefully the legal department
would comment back

after they receive their notification,

and that would help us move that issue
toward resolution,

we could get that Pull Request merged in
once that had been resolved.

So, let's just kind of review back,
we're just about out of time here.

But, we're talked about a lot of things,

so we've talked about the high level view
of our repository,

what goes into a repository,
how you manage your files.

We looked at using Issues to manage
that workload as it comes in,

you can, you know, filter your Issues,
you can sort your Issues,

You can assign Labels,
or assign staff members

to individual Issues.

And then you can even use Milestones
to take a step back

and see what those Issues
are contributing to.

We looked at Pull Requests

so that we could see the flip-side
of that equation,

we've managed the work that's coming in,

and now we need to manage the work
that's being done,

so that we can control it,
we can review it,

we can approve it if necessary.

And then we looked at a few tools
that you can use,

to kind of report out on your activity.

Just to get a better idea of the pulse,

to steal a phrase from GitHub here,

of what's going on in your repository,
to see what that activity is.

So I think with that in mind,

we definitely want to open it up
for some Q and A,

if anybody has any questions,
if we went to fast over an issue,

if you'd like to see something repeated
we're happy to do that.

Feel free to type your questions
into the question box,

and we'll try to answer
as many as we can

with the time we have available.

(Cynthia) And just before everyone
signs off

this course is really just meant
to be a taste of what's...

what you can do in GitHub,

we actually have open enrollment courses,

that we offer once a month.

They're online, so you can take them
during the workday,

and they do a much deeper dive
into how to use GitHub,

and how to really work your workflow,
or your team's workflow,

into this so you can be very effective
and collaborative.

So we encourage you if you're interested,

take a look at the schedule,
sign up for one of those classes,

and we hope to see you
in one of those classes soon.

And I am going to put up
just one last little poll.

This is our first time doing this class

so we hope that you
will give us some feedback

on how we can improve it in the future.

But if you could,
just give us your general opinion,

of how you felt about today's class,

and we will stick around
for a little while,

and answer any questions
that come up in the questions tab.

Thank you so much.

(Allen) And Cynthia,
I wanted to chime in here,

looks like we have a few questions
that have come in,

so we'll try to get to those.

It looks like somebody has asked,

"How can I integrate GitHub
with other services."

The short answer is yes you can,

you can definitely integrate
with other services,

so for instance if you are wanting
to integrate GitHub with maybe

your favorite CI tool,

if you use continuous integration
for code review or code testing,

or something like that.

GitHub supports integrations
with a lot of different platforms.

So if you go to...
and I'll put it up on my screen here,

github.com/integrations

we have a site here devoted to all

the different integrations
that are possible,

with all of your favorite tools.

So you'll notice that we do integrate with

Asana, or PivotalTracker, or even Zendesk.

We integrate with Travis CI,
CloudBees, Circle CI,

a lot of different services out there,
and GitHub integrates with them.

At a very high level,
I will answer the question to say

that you can integrate
with other services,

most of the use GitHub web hooks,

that's gonna be the topic of another
webinar that we offer,

'cause it needs a little bit more detail
to explain it properly.

But in general that is the process,

is that you would use GitHub webhooks
to integrate with these services.

Uh, let's see here.

So we have a question,
"What is the best place to go

to get an idea of how to populate complex

repositories with different file types."

And in this case, I'm not exactly sure,
what you'd be asking.

If you'd mind restating your question?

(Cynthia) I think one answer
to this question might be,

you know obviously GitHub has a huge
open source community,

and so one way that you can find new
information on GitHub is to look

at trending repositories.

So if you go to GitHub and you sign in
under your user name,

let me just go over here,

and we'll look at GitHub Teacher,

so let's see,

Alright Allen, trying to drive
on your screen

is a little challenging for me,
do you mind--

- (Allen) Yeah.
- (Cynthia) just going to github.com?

(Allen) Yeah absolutely,
sorry about that,

isn't technology great everybody?
(Cynthia laughing)

I think what we're looking for
is to explore these trending repositories?

Yeah.

(Cynthia) Yeah, thank you.
So on this you can look

at a bunch of different types
of repositories,

these are just ones that have
a lot of activity on them.

So these might be a good place for you
to start looking to find

some of the more complex file types.

Does that help? Or were you looking
for a more specific example?

Uh, okay perfect.

(Allen) Very cool.

So I think that kinda concludes
the session, we're just about out of time.

I will put our contact info
back up on screen.

So again, Cynthia Rich and Allen Smith,

we are both trainers here at GitHub.

You can reach Cynthia on GitHub,
her handle is @crichID

her email is [e-mail]

My handle is @loranallensmith and my email
is [e-mail]

We're available if you have questions
via email if you want to follow up,

feel free to reach out to us.

(Cynthia) And real quick,
since we have just a couple minutes left,

we got a great question about what options
GitHub Enterprise has.

And well that's a huge question.

We do our best to make sure
that we have feature parity between

GitHub.com and GitHub Enterprise,

so you'll find that a lot of what
we showed you today

is also available on Enterprise.

That said, you know, there's obviously

some logistical difference
with Enterprise.

You know GitHub.com we can send
changes out to anytime,

with Enterprise, you know,
its kind of dependent on the Admin

to load the next,
the most recent updates,

so you won't always see exactly the same
issues because of that,

however we do our best to make sure
that anything we've put in to .com

is also available on Enterprise.

If there's a specific feature that you're
curious about that we covered

and you're wondering
if its also in Enterprise,

just let us know and we can answer
that specifically.

(Cynthia) Okay, well we are right
at the hour,

so thank you everyone for joining us,

for your great questions,

and like Allen said,
if you have any follow up questions

feel free to reach out
to either one of us directly,

and thank you so much
for attending today.