►
Description
Join Ayman Nadeem, Pat Nakajima, and Connor Sears, from GitHub as they introduce two major workflow improvements to GitHub.
Code review improvements introduce the ability to request changes or approve pull requests, with the intent of eliminating ambiguity around next steps, and helping hold one another accountable to ship quality code.
Projects on GitHub aim to simplify the way issues and pull requests within any given repository are coordinated and prioritized. Within a Project, columns can be created and named to represent different categories of work. Issues, pull requests and notes can then be added to and moved around between columns according to the changing needs of a project.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
A
My
name
is
Connor,
so
I'm
the
senior
director
of
practice
on
here
at
github,
I-
guess
not
here
at
github,
but
at
github
and
I've,
been
working
with
the
product
teams
and
the
engineers
and
the
designers
to
really
really
closely
to
think
about.
These
amazing
features
that
we're
all
using
at
github
we're
testing
at
github
internally
and
we're
just
really
excited
to
see
what
you
all
do
with
them.
So
I
just
wanted
to
start
off
and
talk
about
sort
of
how
we
approach
features
when
it
comes
to
the
developer.
Workflow.
A
Really,
when
we
approach
our
product,
there's
really
three
segments
that
we
think
of
we
think
of
developers.
First,
we
say
that
a
lot
is
that
that's
our
bread
and
butter.
We
want
to
make
features
for
you
as
a
developer,
to
make
you
more
empowered
to
build
amazing
things,
of
course.
So
that's
that's
one
way.
We
look
at
it
and,
first
and
foremost,
the
way
we
look
at
it.
A
I,
don't
know
if
you
all
realize
that,
so
if
we
start
sweating,
please
do
not
hold
it
against
us,
but
we're
really
gonna
focus
on
the
workflow
here,
we're
trying
to
empower
developers
to
build
awesome
stuff
and
one
of
the
ways
that
we
do
that
and
one
of
the
ways
we
sort
of
decide
about
what
we're
gonna
build
is
by
hearing
from
the
community.
We've
made
a
concerted
effort
over
the
last.
A
You
know
year
really
to
listen
to
our
community,
to
listen
to
our
community
of
developers
to
our
community
and
our
ecosystem,
building
into
our
platform
and
our
community
of
businesses
using
github,
whether
it
be
on
github
enterprise
or
on
comm,
and
we've
been
trying
to
listen
and
learn
from
all
of
their
experiences
and
bring
the
high
or
the
high
impact
workflow
features
to
dot-com
to
enterprise
and
really
empowering
all
these
people
based
on
their
feedback.
And
so
we're
really
excited
to.
A
You
know,
hear
what
you
all
have
to
think
and
we're
gonna
have
sort
of
office
hours
for
the
speakers,
I
believe
tomorrow,
I'm
sure.
That's
on
a
schedule,
someplace
that
double
check
me,
but
we're
gonna
be
meeting
with
you
all.
We
want
to
hear
your
feedback.
We
want
to
know
how
we
can
improve
these
features
and
just
know
that,
while
we've
always
built
github
in
a
way
that
serves
us
internally
and
our
developers
are
using
these
features
to
build
these
features
and
we'll
get
into
that
a
little
bit
more.
A
That's
true
boards
are
great
for
that,
and
so
we
no
matter
if
we're
serving
individuals
on
open-source
projects
or
just
side
projects.
Or
you
know,
businesses
like
github
building
software.
For
all
of
you,
that's
sort
of
how
we
approach
it
and
then
code
review
is
also
something
we're
going
to
cover,
and
this
is
really
just
coming
out
of
a
lot
of
the
workflows
that
we
were
able
to
see
develop,
especially
after
we
introduced
the
pull
request
and
we've
been
taking
some
of
those
implicit
workflows
and
making
them
explicit.
B
Hey
guys,
how
are
you
guys
doing
today?
That's
great
so,
as
Connor
said,
we've
been
building
something
pretty
exciting
over
the
last
little
while
and
our
product
is
called
projects
now
before
I
dive
into
some
of
the
features
under
projects.
I
wanted
to
talk
a
little
bit
about
how
at
github
it
is
that
we
think
about
project
management
as
a
whole
and
more
broadly,
and
one
of
the
important
things
to
note
is
that
project
management
is
about
helping
developers
or
really
anyone
find
and
easily
organize
the
information
they
need
in
order
to
do
work.
B
That
means
when
I
get
hub
I
want
to
know
exactly
what
I
need
to
do
when
I
need
to
do
it
and
what
are
all
the
other
things
that
I
need
to
be
aware
of
when
I'm
getting
that
done
and
to
be
quite
candid,
this
isn't
particularly
easy
right
now.
On
our
platform,
it's
not
super
easy
to
know
how
a
set
of
issues
map
to
a
set
of
pull
requests
with
so
many
different
people
contributing
to
one
repository
or
multiple
repository.
B
It's
kind
of
hard
to
know
how
disparate
pieces
of
information
and
parts
kind
of
connect
into
something
more
cohesive,
and
so
one
way
that
we've
started
to
address
that
is
through
our
launch
of
projects.
Now,
projects
is
kind
of
a
way
where
you
can
pull
in
all
of
your
stuff,
whether
it's
issues
or
pull
requests
or
something
more
ephemeral,
we're
calling
car
or
Notes
sorry
in
order
for
you
to
kind
of
track
and
prioritize.
What's
going
on
between
named
columns
now
these
columns
kind
of
give
you
categories
that
represent
context
for
your
work.
B
This
is
really
powerful,
and
one
of
the
things
that
I
wanted
to
mention
is
that
the
design
philosophy
we've
had
we've
had
around
this
is
not
to
be
overly
prescriptive
in
the
way
we
build.
We
wanted
to
be
mindful
of
the
fact
that
everyone's
different
there's
a
ton
of
heterogeneity
between
developers.
We
all
have
different
workflows
and
styles
of
collaborating
that
suit
our
individual
needs.
So
when
we
thought
about
projects
and
building
projects,
we
weren't
interesting
interested
in
formalizing
one
particular
way
of
building.
B
We
rather
want
it
to
be
mindful
about
how
much
diversity
there
is
and
not
being
super
ideological.
So
we've
built
strong
primitives
that
allow
you
to
kind
of
manipulate
it
for
your
own
use
that
that's
well
suited
to
your
particular
workflow.
So
without
further
ado,
I'm
gonna
pass
it
to
my
homeboy
partner-in-crime
Pat
Nakajima,
hello,.
C
C
It's
really
important
to
see
people
collaborate
on
and
really
everything
here.
So
here
you
see
a
project.
This
is
the
same
project
that
we
showed
in
our
slide
over
there,
but
this
is
probably
the
most
important
project
at
github
right
now,
you're
really
lucky
to
be
able
to
see
this
I'm
new
to
this
project.
C
Whatever
columns,
your
team
thinks
are
great,
that's
what
you
should
use
if
I
want
to
add
cards
to
a
column,
I
can
go
in
here,
click
add
cards
and,
let's
figure
out
time,
travel
that
sounds
good
for
our
open
source
flux,
capacitor
project
just
drag
that
in
to
backlog
and
there
it
goes
pretty
sure.
Almost
all
of
you
are
familiar
with
this
dynamic
since
I'm
new
to
the
project.
I
got
a
bunch
of
ideas
that
I
want
to
try
to
add
so
I'm
gonna
say
here.
C
You
know
to
the
because
that
seems
like
a
good
thing
to
do
too
and
the
idea
behind
notes
is
you
can
just
kind
of
fill
in
as
many
of
these
ideas
as
you
have
right
off
the
bat
and
not
spam.
Everybody
who's
watching
the
repository
with
notifications
before
we
built
notes.
We're
still
kind
of
using
some
of
this
project.
Stuff
and
I
had
a
lot
of
ideas
that
I
wanted
to
get
in
there
and
somebody
emailed
me
they
were
like.
We
just
got
50
emails
of
all
the
issues
you
just
opened
with.
C
Nobody
know
assignees
know
anything
like
that,
so
we
added
notes
that
you
could
get
things
from
your
head
to
the
screen
as
soon
as
possible,
so
yeah
once
you
want
to
take
that,
you
know
note
and
you
think
that's
a
good
idea
and
you're
ready
for
more
discussion
about
it
or
it
merits
an
assignee
or
something
like
that.
You
can
go
here
and
click
convert
to
issue
and
say:
oh
yeah.
That
sounds
like
a
good
idea.
C
Additionally,
since
a
lot
of
times
when
you're
looking
at
these
columns,
you
know
you
want
to
just
get
that
whole
thing.
You
don't
care
about
any
else
on
the
page,
so
we
also
have
this
little
full-screen
mode
over
here
and
with
that
you
can
actually
enter
a
full-screen
mode.
That
gets
rid
of
the
header,
gets
rid
of
the
other
nav,
and
you
just
have
this
here.
Just
you
can
be
in
the
zone,
that's
my
demo,
so
let
me
figure
out
how
to
get
the
screen
back.
C
That
was
my
demo,
just
to
recap:
draggable
columns
and
cars.
You
can
reorder
columns
as
well.
You
can
use
the
same
search
as
you
use
for
issues
in
that
search
sidebar.
So
if
you
want
to
just
see
things
that
are
labeled
with,
you
know,
bug
or
something
like
that-
that
same
filtering
works
there
as
it
does
everywhere
else
for
repo
search
or
global
search
and
again
we
have
notes
in
here
too,
for
when
you
want
to
just
get
things
on
the
page
coming
soon
to
projects.
C
These
are
working
really
well
right
now
on
a
per
repository
basis,
but
we
think
that
the
next
thing
that
everyone's
going
to
want,
including
us,
are
to
be
able
to
take
all
of
the
issues
all
of
the
pull
requests
your
organization
and
manage
those
because
a
lot
of
projects
you
actually
like
you
care
about
more
than
one
repository,
especially
the
way
we
work
at
github
and
I.
Think
a
lot
of
other
people
do
too
so
we're
gonna
have
support
for
organization
level
projects
we're
also
talking
about
having
support
for
per
user
projects.
C
So
just
for
me,
Pat
Nakajima
I
care
about
all
these
things.
For
work,
but
then
some
of
my
open-source
things
too,
if
I
want
a
board
for
that
that
can
just
be.
You
know
my
thing
to
say
when
the
users
have
repositories,
I
could
have
that
too,
and
that
could
work
really
well.
You
know,
with
things
like
waffles,
knew
the
waffle
bot
where
it
can
organize
things
for
you
and
show
you
like
what
you
care
about
based
off
of
your
actions
elsewhere.
C
Another
thing
that
we're
rolling
out
soon
is
better
support
for
large
projects.
We
got
as
much
as
we
could
out
the
door
as
possible,
but
we
didn't
you
know
we
figured
no
one's
gonna
have
an
enormous
project
on
github
in
the
next
in
the
first
month,
because
I
mean
how
fast
can
anyone
possibly
work,
but
we
want
to
make
it
a
lot
smoother
going
forward
for
if
your
project
is
like
six
months,
old
you've
got
thousands
of
cards,
and
you
know
how
do
you
see
what
you've
done
without
that?
C
Getting
in
your
way,
another
thing
we're
working
on
is
clear
dependency
relationships
in
the
same
way
that
you
can
say
fixes.
You
know
number
one,
two
three
and
a
pull
request
and
that'll
close.
That
issue
issue
number
one:
two:
three:
we
want
to
kind
of
show
that
you
know
in
projects
just
give
you
a
better
idea
of
how
everything
that
you're
working
on
is
related,
what's
being
taken
care
of.
C
What's
not
and
then
integrations
are
gonna,
be
huge
for
projects,
because
we
are
looking
at
this
like
Eamonn,
said
in
terms
of
the
perimeters
of
project
management.
What
really
we're
never
gonna
build
a
hundred
percent
of
what
everyone
wants,
because
that's
zero
of
what
anybody
wants
really.
So
we
want
all
the
more
opinionated
things
to
come
through
projects
give
all
our
integrators
the
ability
to
come
in
say
this
is
how
the
team
works,
and
this
is
what
they
want
for
the
rules
and
then
have
that
just
work
automatically.
C
So
to
recap,
repository
project
boards,
what
we've
launched
we
have
launched
with
issue
and
pull
request
cards,
quick
search,
notes
for
just
getting
it
on
the
page
cross
repository
projects
are
coming
soon,
better
dependency.
Tracking
nested
projects
is
the
idea
that
we
can
have
a
card.
That's
actually
a
project
so
that
you
can
drill
down
from
project
to
project
to
project
until
you
get
to
what
you
actually
care
about
and
then
the
management
of
large
projects.
A
Awesome,
thank
you
both.
So
we're
really
excited
about
projects
again,
we
use
this
project
and
code
review.
Sorry,
words
are
difficult,
sometimes,
when
you're
dealing
with
this.
As
soon
as
we
got
the
base
layer
of
features
for
both
code
review
and
projects,
we
immediately
worked
them
into
our
own
workflow.
So
when
Pat
was
and
Eamonn
we're
talking
about
their
own
board
and
using
it
to
actually
manage
the
projects,
we
actually
did
do
that
and
we
worked
out
a
bunch
of
bugs
I.
A
Think
the
one
about
notes
is
pretty
interesting
is
how
many
notifications
get
sent
every
time
you
open
a
issue
as
we
sort
of
reduce
that
workload
ran
into
that
pretty
quickly.
So,
let's
talk
about
code
review,
so
I'm
going
to
talk
a
little
bit
about
what
we
shipped
today,
what
you
can
expect
from
code
review.
Hopefully
all
of
you
have
had
a
chance
to
play
with
it
already,
but
I'm
also
gonna
give
you
a
little
insight
into
sort
of
where
we're
going
with
it.
A
How
we're
thinking
about
the
problems
again,
like
I,
said
at
the
beginning.
We
really
approach
this
from
what
will
empower
developers
we're
not
we're
not
necessarily
trying
to
look
at
every
organization
and
saying
okay.
They
have
this
particular
unflexible
or
inflexible.
Rather
prescriptive
workflow
we're
not
necessarily
looking
at
that
and
trying
to
build
it
into
the
product.
Instead
we're
looking
at
what
are
the
natural
workflows
that
have
bubbled
up
out
of
our
usage.
Our
community's
usage
in
code
review
is
just
something
that
has
sort
of
always
been
there.
A
I
think
all
of
you
have
probably
used
other
tools
that
provide
some
of
this
functionality,
and
we
definitely
want
to
build
that
directly
into
the
pull
request,
because
we
we
believe
that
code
review
is
beneficial
and
peer
review,
really,
as
a
concept
is
beneficial
to
everybody.
We
believe
that
code
review
and
we
know
that
code
review
because
we
see
it
every
day
at
least
a
better
code,
fewer
bugs
just
overall,
better
quality
code
being
written,
and
so
we
definitely
care
about
that
at
github
because
we
want
to
deliver.
A
A
One
of
the
things
that
we
noticed
with
poor
said
this
earlier.
I'll
say
it
again,
because
why
not
is
that
we
saw
a
lot
of
implicit
workflows
coming
up
out
of
that.
One
of
those
workflows
was
just
line
comments.
That
was
a
novel
idea.
You
know
how
we
actually
incorporated
that
into
the
pull
request
and
made
code
more
collaborative.
A
That's
what
we're
all
about
social
coding
and
a
lot
of
conversations
happen
around
code,
whether
it
be
on
the
conversation
timeline
where's,
where
they
can
court
sort
of
coordinate
around
the
code
or
directly
on
the
code,
with
line
comments
and
some
of
the
workflows.
What
we
see
and
we
use
every
day,
is
that
going
over
to
the
diff
clicking
on
the
line
comment
talking
about
that.
Sometimes
you
have
something
that's
like.
Oh,
this
line
of
code
is
wrong.
You
need
to
fix
this
sometimes
I'm.
A
Just
jumping
in
isn't
someone
who's
ignorant
of
a
certain
language
and
I'm.
Just
saying
oh,
this
is
interesting.
I
just
want
to
sort
of
let
you
know.
Let
somebody
know
that
I
think
what
they're
doing
is
cool
and
other
times.
You
want
to
be
very
prescriptive
and
say
like
yes,
you
are
actually
now
good
to
ship
this.
A
This
is
now
high
enough
quality
that
I
think
it's
great
and
so
we're
seeing
all
this
happen,
but
we're
realizing
that
our
UI
was
just
very
loose
I
guess
it's
the
way,
the
way
it
worked,
the
way
the
press
worked
were
very
loose,
sometimes
you're,
just
replying
to
a
conversation,
someone's
left
a
thought,
and
you
want
to
continue
that
conversation.
That's
fine,
but
that's
not
necessarily
always
quote
code
review.
Sometimes
you
want
to
you
see
a
whole
conversation.
Maybe
it's
twenty
comments
and
half
of
them
are
just
emojis
and
you're
kind
of
like
I'm.
A
Glad
y'all
are
having
this
conversation,
but
there's
actually
some
real
discussion
I
have
here
around
how
you're
implementing
this
great
well,
it's
kind
of
hard
to
have
all
that
in
just
one
thread.
So
we
we
approach
that
problem
with
code
review,
and
so
we
looked
at
all
ways
that
people
are
using
pull
requests
and
using
the
conversations
around
code
review
to
sort
of
think
about
how
we
actually
make
some
of
these
flows.
A
You
know
built
into
the
process
and
one
of
the
things
that
we
really
cared
about
was
not
replacing
all.
That
was
good.
We
think
we
did
a
pretty
good
job
with
the
pull
request.
I
hope
some
of
you
think
so
too,
and
so
we
didn't
want
to
just
throw
that
out.
Instead,
we
took
on
a
design
approach
where
we
looked
at
the
things
that
we're
working
things
that
people
worked
on
every
day
to
get
their
work
done.
A
We
built
on
top
of
that
which
is
actually
an
interesting
design
challenge
is
how
do
you
preserve
old
workflows
and
allow
people
to
just
day
one
jump
in
and
do
what
they've
always
done
and
then
see
the
benefit
of
maybe
a
different
workflow,
that's
built
on
top,
and
it
should
be
approachable,
no
matter
what
you're
doing
so.
That's
again,
sort
of
some
of
the
context
about
how
we
approach
this.
A
It's
really
interesting.
Just
as
an
antidote,
how
we
actually
turn
this
on
in
some
of
the
earlier
versions
and
a
lot
of
people
like
github
weren't
so
used
to
having
to
go
through
this,
and
so
there
was
some
frustration
like
allergies,
here's
another
thing,
and
maybe
it's
a
little
buggy,
because
it's
a
beta
or
alpha
or
whatever,
and
one
of
the
main
signals
that
we
we
saw
is
like
okay
cool.
We
turned
it
off
for
a
day
and
all
sudden
we
got
a
bunch
of
whoa
that
go
that
really
really
helpful
so
anyways.
A
C
A
You're
working
on
a
project
and
these
are
sort
of
how
these
products
and
these
features
work
together.
Oftentimes
you'll
be
on
this
page
you'll
be
trying
to
figure
out
what
to
do
and
you'll
notice
that
you
know.
Maybe
this
isn't
really
a
backlog.
This
is
this
is
something
that
we
need
to
address
right
now.
This
is
in
ready
for
review,
and
so
I
can
sort
of
see
this
and
say.
A
Okay,
great
well,
I
need
to
do
something
about
this,
so
I'm
gonna
click
in
and
see
this
pull
request
and
understand
sort
of
what
needs
to
be
reviewed.
It
looks
like
they're
getting
down
to
the
nitty
gritty
of
figuring
out
time
travel.
That's
really
cool!
I'm
really
excited
about
this.
We've
imported,
better
gifts,
support
support,
I'm,
just
kidding.
We
stop
the
same
old
gifts
apart.
It's
really
hard
to
improve
on
the
gift
but
anyways.
A
So
this
is
just
a
an
example
of
some
documentation
that
we're
gonna
go
through,
and
this
kind
of
goes
at
the
point
that
you
know:
it's
not
always
code
that
we're
reviewing.
This
can
be
just
simple
documentation
around
sort
of
design
process
or,
in
this
case,
sort
of
how
we
approach
time
travel.
So
Caitlyn
has
opened
up
this
pull
request.
She's
ready
to
go
I
can
already
see
a
man's
already
made
some
comments
in
here.
That's
really
great
Oh,
actually,
she's
left
a
thing.
All
right,
cool
I
want
to
use
our
simple
reply
feature.
A
This
is
one
of
those
examples
of
taking
something
that
was
implicit
and
saying.
Okay,
let's
just
build
replies
directly
into
the
UI,
because
we
know
that's
a
use
case
that
somebody
doesn't
want
to
go
through
the
heaviness
of
leaving
a
review
and
trying
to
go
through
some
process.
I
just
want
to
have
a
conversation,
so
I'm
gonna,
say
nah.
C
A
Not
good
conversation
because
you
you
want
to
be
considerate
of
your
coworkers
and
this
isn't
normally
how
we
work,
but
for
this
case
I'm
just
going
to
leave
this
right
here
and
you
can
see
it
just
pop
in
or
in
line
I,
don't
have
to
go
through
all
process,
but
now
that
we're
actually
dealing
with
code
review.
Let's
go
over
to
the
DIF
and
take
a
look
at
this.
So
you
can.
A
Now
we're
working
on
a
markdown
file,
so
I'm
not
really
sure
why
we
have
to
use
HTML
but
I.
You
know
what
to
be
honest
with
you,
the
syntax
around
it's
pretty
complicated.
So
what
have
you
so
we're
looking
at
this
and
you
can
see
the
UI
allows
us
to
still
add
a
single
comment.
If
we
want,
we
don't
have
to
do
this
heavy
thing
again.
A
We
can
just
add
a
line
come
and
be
on
our
way,
but
now
we
have
this
new
option
and
it's
the
start
review
so
right
now
you
can
see
that
that's
been
added
to
the
the
diff.
You
can
see
that
appending
labels
there.
That
means
that
it's
ready
to
go,
but
it
hasn't
been
sent
out.
Yes,
you
haven't
sent
a
notification.
A
I,
don't
know
about
you,
but
I've
done
this,
where
I'm
I
kind
of
have
all
my
line,
comments
composed
and
I,
don't
click
send
in
to
the
very
end,
because
I
know
that
I've
got
some
context
that
I
want
to
talk
about
at
the
end,
this
is
convoluted
process.
Well,
you
don't
have
to
worry
about
that
anymore.
We
just
added
it
right
here.
C
A
We
want
weight,
not
question
mark.
What
am
I
dealing?
Yes,
it
does.
We
do
want
to
time,
travel
and
github.
This
is
a
feature
that
will
be
coming
in
about
a
year.
We're
gonna
bring
the
flux
capacitor
to
the
masses.
It's
gonna
be
great.
Okay,
cool,
so
I
can
add
a
couple
of
comments
here
and
great,
so
maybe
I'm
good
to
go
I.
Think
I
am
so
I'm
gonna
go
up
here
to
this
review
button
and
all
sudden
I
get
this
like
nice,
simple,
drop-down
I
can
leave
a
comment.
I'm
like.
A
So
now
I
can
leave
a
simple
Metta
comment:
that's
gonna
go
along
with
the
review.
I
can
sort
of
describe
the
whole
list
of
changes
in
a
holistic
way.
That's
an
optional
thing.
By
the
way.
You
know
you
can
come
here
and
just
say:
yep
everything
looks
good.
Click
approve
submit,
that's
fine,
but
this
time
I'm
gonna
actually
request
some
changes.
I
think
I
think
I'm
gonna
hold
fast
on
my
my
table
comment
here:
I'm
gonna
submit
the
review
and
so
boom.
It
takes
you
back
to
the
conversation
timeline.
You
can
see
this.
A
This
is
tied
directly
into
our
protected
branch's
feature.
We
think
this
is
really
important
because
we
think
protecting
branches
is
important.
We
want
to
have
some
control
over
what
gets
into
your
master
and
to
your
master
branch
or
whatever
your
default
branch
is,
and
so
this
is
tied
directly
into
this.
A
So
in
this
particular
case
on
this
repo,
as
an
administrator
I
have
enforced,
this
I've
said:
okay
I
want
to
protect
this
branch,
simple
checkbox
and
I've
said
you
know
you
need
at
least
one
reviewer
before
this
gets
merged
in
and
you
can
see
that
enforced
here.
So
now,
I've
left
a
review.
This
isn't
my
pull
request,
but
you
know
we
work
collaboratively
Wow,
get
there
and
now
I'm
just
sort
of
waiting
for
some
changes.
So
I've
asked
my
friend
Pat
Nakajima
to
push
a
commit
that
changes.
A
Some
things
it'll
come
in
boom,
seamless,
demo,
everybody.
This
has
never
been
more
smooth,
so
I've
seen
he's
updated
the
readme,
so
I
can
look
at
those
changes.
Let's
go
ahead
and
look
at
there
all
right
great,
so
he
ignored
my
feedback
altogether,
but
I'm
kind
of
giving
up
at
this
point
I
think
it's
fine
I
think
the
table
works.
Well,
it's
pretty
complex
looks
like
he's
added
some
sort
of
okay
cool.
So
there's
our
other
demo
of
our
new
feature.
This
is
it
working.
A
It
looks
like
we've
made
tons
of
progress
here,
fantastic,
so
I'm
just
gonna
go
back.
This
is
all
looking
really
great,
so
I
have
a
couple
options
here:
I
can
leave
another
review
if
I
want
to
I
can
go
here
and
ignore
the
review.
Summary
and
I
can
just
click
approve
and
be
about
my
merry
way,
but
I
don't
have
to
do
that.
We've
built
in
some
shortcuts.
A
So
if
you
go
back
to
the
conversation
and
if
I'm
looking
around
here
and
I'm
sort
of
seeing
the
code
I'm
like
maybe
his
maybe
his
commit
message
is
a
little
bit
better.
Next
time,
it's
a
little
bit
more
descriptive,
I'm
like
oh
he's,
got
it
I
trust
it
I.
Don't
really
need
to
look
at
the
code.
I'm
just
gonna
make
it
this
quick
shortcut
right
here.
I
can
see
I've
left
a
review
that
requests
change
as
well.
A
I'm
satisfied
now
so
I'm
gonna
go
ahead
and
approve
these
changes
now,
and
so
you
go
down
here
and
you
can
see
the
merge
box
is
updated.
I've,
given
the
go-ahead,
we're
good
to
go.
I
think
we've
made
a
great
plan
and
we're
gonna
go
ahead
and
merge
these.
These
changes,
yeah
looks
great
boom,
I'm,
a
big
believer
in
fleeting
branches.
By
the
way
I
don't
know
about
you,
alright,
so
there's
a
whole
sort
of
process
right
there
we
made
the
code
better.
A
Theoretically,
we
kind
of
made
a
convoluted
example
for
you,
but
you
can
see
how
this
kind
of
just
work
directly
into
your
workflow
and
hopefully
that'll
you
know,
be
incorporated
into
your
company
or
your
open-source
project
or
your
personal
projects
that
you're
working
with
somebody
else
really
soon.
So
that's
our
demo
and
getting
out
of
the
demo
is
hard
JK.
A
So
just
to
recap,
we're
batching
comments.
Together,
we
felt
the
pain
we
heard,
the
pain
from
all
of
our
customers.
We're
gonna
be
able
to
send
these.
It's
just
one
single
review.
That's
one
email
that
you
can
keep
track
of
the
thread
really
easily.
We
simplified
all
that
for
you,
you
can
leave
50
comments
or
you
can
leave
one
comment,
it's
up
to
you,
but
we've
built
that
right
in
simple
status.
Attached
to
your
review,
also
works
as
you
would
expect.
A
You
can
approve
changes
and
sort
of
give
the
thumbs-up
that
this
is
ready
to
be
merged.
You
can
just
leave
thoughts.
If
you
just
want
to
leave
a
bunch
of
comments,
you
still
don't
want
to
bother
them.
That's
fine!
You
can
still
review
the
code.
There's
plenty
of
examples
where
I'm,
not
the
expert
of
course
and
I.
Just
sort
of
lurking
around
a
repo
and
I
want
to
leave
a
lot
of
thoughts,
maybe
they're
questions,
and
so
we
give
that
option
by
default.
A
You
can
leave
general
feedback
without
any
sort
of
explicit
like
approval
or
process
around
that
and
just
leave
that
batch
comment.
We've
built
that
right
in
or
you
can
add
approvals.
This
is
an
explicit
thumbs-up
and
again
you
can
add
sort
of
requesting
changes.
This
needs
to
be
changed
before
give
it
the
thumbs
up.
So
that's
all
built
into
the
simple
UI.
A
We've
also
just
improved
some
of
that
lightweight
conversation
that
people
have
around
their
code.
So,
in
this
case,
we've
built
better
emoji
reactions,
I'm
just
kidding
they're,
so
good,
already
they're
the
same
emoji
reactions,
they're
built
right
in
right,
super
lightweight,
so
you
don't
have
to
muddy
up
the
conversation
when
all
you
want
to
do
is
give
a
heart
that
makes
heart
sound
like
they're,
not
very
impactful,
but
they
are,
we
know,
and
then
we've
built
just
the
UI
a
little
bit
better.
So
it
just
allows
you
to
go
in
and
just
add
a
reply.
A
Really
lightweight
hit
enter
you're
done.
This
is
also
built
directly
into
or
protected
branches.
You
can
protect.
All
of
this.
You
don't
have
to.
You-
can
put
some
explicitness
around
these
processes,
so
you
know
that
the
code
that
you're
building
or
that
you're
merging
in
has
actually
been
reviewed,
and
you
can
have
some
peace
of
mind
that
more
than
one
developer
going
rogue
to
fix
a
bug
at
3:00
a.m.
that
actually
causes
six
other
bugs
happen.
A
A
Then
then
we
would
like
so
code
review,
sort
of
solves
that
for
us
and
we
sort
of
forced
that
extra
minute
of
review
sometimes
makes
all
the
difference.
If
you've
seen
any
spelling
errors
in
these
slides,
I
haven't
I
hadn't
looked
at
spelling,
it
would
have
been
benefited
from
some
code
review.
If
I
was
able
to
do
that,
so
so
anyways
that's
sort
of
how
that
works.
We
can
protect
it
so,
like
I
said,
I
want
to
tell
you
where
we're
going.
A
This
is
what
we
shipped
today
I
want
to
give
you
some
insight
into
what
how
we're
thinking
about
the
product,
how
we
want
to
add
some
additional
features
so
want
to
talk
about
what's
coming
soon,
and
this
is
more
work
in
progress.
You'll
you'll
notice
that
our
UI
is
that
we're
that
I'm
going
to
show
is,
is
a
little
bit
early
in
the
works.
As
you
can
see,
this
is
not
how
to
look.
These
are
sketches
right,
so
we
want
to
be
able
to
build
in
the
process
of
when
I
open
a
pull
request.
A
I
want
to
explicitly
add
it's
someone
I
want
to
add
a
man's
eyes
and
I
want
to
make
sure
she's
seeing
this
and
right
now
you
have
to
go
to
slack.
You
have
to
go.
You
know,
go
in
person
if
you're
working
in
the
same
office,
you
have
to
send
a
text
message,
some
way
to
sort
of
send
the
link
and
say:
can
you
review
this
code?
A
Well
now
we
can
just
build
that
writing
in
the
UI,
and
we're
really
excited
about
working
on
this
and
getting
this
out
soon
is
the
idea
of
just
adding
people
as
part
of
the
process
of
opening
a
pull
request
and
saying:
hey
I
would
love
your
eyes
on
this,
because
we
think
we
know
that
it
makes
things
better
and
so
how
that
could
actually
look
in
the
UI.
These
again,
like
we're,
still
exploring
this,
but
we
can
work
pretty
quickly
and
we're
excited
to
work
on
this.
A
Next
is
the
idea
of
like
the
merge
box,
so
we're
reflecting
that.
So
you
know
this
idea
when
it
comes
to
your
build
statuses,
there's
there's
tests
that
are
building,
for
instance.
Well.
This
is
the
same
sort
of
idea,
I'm
waiting
for
Todd,
Berman
or
VP
to
get
his
eyes
on
this.
He's
he's
really
slow
to
act,
sometimes
so
I'm
still
waiting
on
him,
but
the
idea
is
I
can
see
the
status
of
all.
The
reviews
that
are
going
into
my
pull
requests
are
not
going
into
my
pull
request
and
Todd.
A
If
he's
looking
at
the
merge
merge
box,
he
can
sort
of
jump
in
and
really
quickly
see.
Oh
I'm,
holding
everything
up
well,
I
think
we're
gonna
look
in
two
ways
of
sort
of
building
more
shortcuts
into
the
UI.
So
there's
not
just
one,
maybe
heavy
way
to
do
it,
but
there's
also
lighter
weight
ways.
One
thing
I
really
am
interested
in
and
I'm
about
to
put
us
on
the
hook
for
it.
I
want
keyboard
shortcuts
for
this
sort
of
stuff,
but
anyways
we'll
look
at
that
more
a
little
preview
for
that.
A
This
concept
of
something
we're
exploring
is
code
ownership.
So,
anyway,
we
can
automate
processes,
whether
it
be
you
know
in
the
future,
when
we
have
robots
writing
our
code
for
us,
we'll
write
documentation
for
that
and
that'll
be
the
next
demo
I'm
sure,
but
we
want
to
automate
anything
for
people
just
make
it
easier
for
you
to
write
better
code
with
peer
review
or
code
review,
and
so
we're
exploring
this
idea
of
code
ownership.
A
We
know
that
whether
it
be
out
of
necessity,
because
you
were
the
original
writer,
sometimes
this
doesn't
work
for
us,
because
we
look
at
some
feature
that
we're
building
and
we
see
to
funks
name
next
to
the
blame
and
we're
like.
Oh
this
was
years
ago.
He
has
no
idea
how
this
was
built,
alright,
but
there's
a
ton
of
other
examples
where
somebody's
the
maintainer
of
a
codebase,
whether
it
be
a
file,
whether
it's
our
Design
Systems
team,
that
sort
owns
the
CSS
across
our
entire
system
of
design
and
across
our
entire
code
base.
A
A
You
have
to
sort
of
scour
your
notifications
and
sort
of
filter
through
all
that
we
just
want
to
make
that
super
easy
and
make
it
so
you're
automatically
notified
when
a
piece
of
code
that
you
need
to
be
maintaining
is
touched
by
someone
else,
and
this
is
a
workflow
that
you
know.
I
personally
have
used
at
past
jobs
at
past
systems,
where
we
built
in
you
know
basically
hacks
into
our
code
base
with
owner's
files
and
things
like
that
that
are
sort
of
the
list
of
names.
A
But
then
some
API
tool
goes
through
whatever
we're
using
and
then
automatically
notifies
use
or
add
you
to
the
review.
We
want
to
build
this
as
a
first-class
thing
right
into
github.
We
think
this
would
be
really
powerful.
It
could
be
somebody
like
Josh
pick,
I,
don't
know
if
he's
in
here,
but
you
know
any
time
you
write
a
line
of
JavaScript.
You
want
Josh's
eyes
on
it.
A
So
that's
sort
of
the
idea.
I,
don't
know
how
this
is
gonna
work,
we'd,
love
to
hear
your
feedback
I
mean
it's
pretty
easy
to
think
about
it
from
a
from
how
it
works
standpoint
to
say,
Oh
someone
will,
you
know,
just
be
notified
any
time
they
touch
this
file,
but
we
think
it's
more
interesting
to
sort
of
be
even
smarter
and
over
time
we
want
to
be
able
to
have
owners
of
functions.
I
don't
know
like
it
seems
like
more
granular.
Ownership
could
be
really
interesting
as
well,
so
we're
exploring
all
of
these.
A
So
just
to
recap:
what
we're
shipping
today
is
first-class
code
review
on
github.
This
means
you
can
approve
or
request
changes.
You
can
also
just
do
lightweight
commenting.
We
want
to
build
in
and
solidify
a
simple
lightweight
reply,
workflow
so
that
you
can
continue
to
have
important
or
frivolous
conversations
around
your
code.
A
We're
batching
up
all
these
line
comments
so
that
you
don't
have
to
worry
about
sending
a
million
emails,
because
you
have
a
lot
of
thoughts
or
maybe
you
learn
more
about
the
code
like
okay,
so
here's
another
use
case
you're
going
through
the
diff
and
you
think
you
understand
it
and
you're
like
oh.
This
is
wrong
wrong
wrong
and
then
you
scroll
through-
and
you
realize
oh
I'm
wrong
and
now
I've
already
sent
a
bunch
of
notifications
to
everybody,
letting
them
know
I'm
wrong
and
there's
no
way
to
fix
that.
A
Well,
now
you
can,
you
can
go
through
and,
as
you
get
more
context,
because
you
sort
of
rushed
into
things,
you
can
go
through
there
and
send
one
notification
and
edit
it
and
make
sure
it's
exactly
what
you
want
to
say
as
part
of
the
holistic
review
of
the
code
and
then
finally,
we've
built
into
protected
branches
directly
right
now.
The
way
it's
gonna
work
is
that
you're
gonna
by
default,
where,
when
you
turn
this
on
we're
gonna
require
that
a
single
other
developer
or
other
person
reviews
your
code
and
gives
it
a
thumbs-up
explicitly.
A
But
that's
not
where
we
want
to
end
up
long
term
so
coming
soon,
what
are
we
exploring
we're
exploring
requested
reviewers
we're
exploring
resolvable
comments?
I
didn't
mean
talk
about
this
stuff,
but
these
workflows
are
really
interesting.
You
have
a
50
comments
and
they're
all
sort
of
two
dudes,
because
they're
all
really
good
points
of
feedback.
A
Well,
you
want
to
use
that
as
a
task
list
you
want
to
go
through
and
just
send
lightweight
progress
to
that
person
and
say
well
I'm
resolving
one
comment
at
a
time
we
want
to
build
those
sorts
of
workflows
directly
into
it.
We
want
to
talk
about
code
ownership.
We
want
to
figure
out
exactly
what
that
means
exactly
in
a
forward
github
and
for
you
want
to
build
that
directly
in
and
and
tie
it
directly
into
our
code
review
feature.
We
want
to
do
things
like
multi-line
comment.
A
It's
stupid
that
you
can
only
comment
on
a
single
line.
I
want
to
it's
a
whole
block,
I'm
talking
about
or
what,
if
you
know,
whatever
you
get
the
picture
we
want
to
build
in
lightweight
ways
of
you
know
you
can
imagine
clicking
one
line
dragging
down
and
highlighting
a
bunch
and
leaving
a
comment
on
a
whole
blob,
that's
great,
and
then
we
want
to
improve
the
protected
branches
feature.
When
we
look
at
this
and
as
an
administrator,
you
want
to
have
a
little
bit
more
fine
control.
A
We
think
projects
encoder
view
working
together
are
extremely
powerful
and
that's
why
we
built
them
directly
into
our
product,
because
we
think
they're
not
just
something
that
you
use
at
work,
although
that
is
equally
important.
We
also
think
it's
great
for
any
project
that
you're
working
with
another
person,
whether
it
be
your
wife,
like
myself,
working
on
their
home
or
building
projects
and
to
github
building
code
review.
We
think
these
are
extremely
great.
A
So
that's
our
workflow
improvements,
if
there's
one
thing
I
want
everyone
here
to
take
away,
is
that
we
are
listening
when
we
hear
feedback,
whether
it
be
and
a
letter
that
we
get
eight
months
ago,
that
we
definitely
learned
learn
from
and
we
reacted
to
appropriately
or
feedback
that
we
hear
here
at
the
conference.
We
want
to
listen
to
you,
we're
not
gonna,
build
everything
you
asked
for.
A
Well,
we
have
this
great
ecosystem
of
developers
that
can
build
in
all
those
specialized
workflows
on
top
of
that
and
plug
directly
into
it.
We're
really
excited
about
that,
because
we're
better
together
so
anyways,
that's
it
that's
a
workflow
improvements,
we're
gonna
be
around
all
two
days,
I
think
and
there's
office
hours,
I
believe
their
necks
or
tomorrow
I'm
not
actually
sure
about
that.
But
please
figure
when
we're
going
to
be
get
those
tables
and
come
talk
to
us.
We
want
to
hear
from
you.
Thank
you
so
much.