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