Webcast • Github for Project Management

(woman) Hello there everyone,

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

and we'd like to do a quick audio check,
just to 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.

(man) Okay.

(woman) 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...
I'm 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 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 effectively

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 alot 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 show
you what we're going to accomplish today.

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 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
we're showing you here pages.github.com

You can go there and 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 to 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 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 tells people
how to contribute.

This page is a little 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
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 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

and 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'll 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

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 its 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.

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 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,
go ahead and click that.

So traditionally when you think
about issues

in terms of software development

you 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.

But ultimately what we're talking about
here is workload management.

So Issues track the work to be done.

and GitHub has tools that let you manage
that work 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 help
us do a couple of things to manage

our tasks related to this Issue.

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 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 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 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,

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 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 there's anything critical

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.

(silence)

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.

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 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

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.

(Silence)

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 into 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 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.

(silence)

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
of the ways the work 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
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 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,

and 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'.

There ya go.

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

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

just 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 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 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

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,

(silence)(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.

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 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 on the right-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 of 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 groups really shine.

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

between a distribution group
in say something like Outlook,

and an Access control group
from something like an 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,

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.

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 time line,

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 on 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.

(Silence)

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 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 that 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.