►
From YouTube: GitHub Universe 2020: Day 3 - Enterprise
Description
Senior leaders and decision-makers from global companies can hear from industry experts on transformation, security, scalability, and productivity. Whether it’s modeling for DevOps with 3M or learning how to overhaul legacy engineering practices through innersource with Intuit, these sessions will help you and your teams build like the best.
https://githubuniverse.com
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B
Hello
welcome
so
I'm
kelsey
and
this
talk
is
kind
of
has
a
weird
title:
kelsey
kubernetes
and
get
ops.
I
think
you
would
think
those
three
things
go
together,
given
my
status
in
the
kubernetes
community.
B
But
if
you
really
want
to
understand
kelsey,
you
kind
of
have
to
understand
the
whole
person
we
like
to
label
ourselves
technologists
and
just
like
many
others.
I've
used
many
labels
over
my
career,
but
the
first
label.
I've
ever
had
like
many
people.
I've
worked
in
fast
food,
specifically
mcdonald's,
where
you
get
the
purple
hat
and
the
shirt
to
match.
B
You
come
home,
smelling
like
french
fries
and
whatever
they
fight
it
in
and
a
lot
of
my
work
ethic.
A
lot
of
my
maturity,
this
this
nature
of
being
a
professional
started
for
me
around
the
age
of
15.
and
there's
a
long
trajectory
between
those
humble
beginnings
to
the
person.
You
speak
in
front
of
you
today
or
commit
to
your
open
source
or
your
favorite
open
source
project,
and
a
lot
of
us
try
to
figure
out.
B
What's
the
success
behind
it
and
I
don't
have
a
lot
of
answers,
but
I
know
I've
been
on
this
marathon
for
a
little
while
now
and
there's
a
big
checkpoint
in
my
career.
I
remember
getting
my
first
like
real
corporate
job.
You
know
the
one
where
they
make
you
wear
slacks
monday,
tuesday,
wednesday
thursday
and
then
on
friday.
Everything
turned
out.
B
Okay,
you'll
get
to
wear
jeans
and
it
was
a
financial
services
job,
and
I
remember
I
was
a
system
administrator,
just
learning
things
like
python
and
all
this
automation
stuff,
and
it's
really
what
I
lean
into
ops,
big
time.
This
is
when
outages
and
production
really
mattered
a
ton-
and
I
remember
one
of
our
outages-
we're
sitting
in
one
of
those
war
rooms
and
for
you
all
watching
this
that
have
never
been
in
a
war
room.
B
Think
about
a
very
small
office
space
with
the
bunch
of
chairs
lined
around
and
everyone's
on,
their
laptop,
sometimes
pretending
that
they're
actually
working
on
the
problem,
even
though
they
don't
know
what's
going
on,
and
I
remember
we're
taking
longer
than
normal
to
resolve
the
issue
and
the
company.
I
work
with
they
process
credit
cards.
You
know
the
things
you
keep
in
your
wallet
and
they
also
process
the
ebt
cards
so
for
people
that
are
getting
assistance
from
the
government.
B
If
that
car
continues
to
decline,
then
they're
going
to
be
stuck
or
the
most
embarrassing
thing
having
to
put
all
of
those
groceries
back
and
then
leave
home
or
leave
the
grocery
store
empty-handed
at
that
particular
checkpoint.
In
my
career,
I
kind
of
understood
that
there's
a
lot
more
than
just
writing
scripts
and
throwing
them
at
servers
and
hoping
they
work.
B
B
B
We
always
think
we
have
all
the
time
in
the
world,
and
I
remember
a
lot
of
people
telling
me
you
know.
Success
is
measured
in
time.
I
remember
getting
an
award
like
top
40
under
40.,
and
I
always
thought
to
myself.
It's
like.
Why
is
there
a
time
limit
on
this
kind
of
thing
right?
Why
is
there
not
more
opportunities
for
success
that
have
nothing
to
do
with
your
time?
The
truth
is,
there
is
no
time
limit,
so
I'm
going
to
do
right
now.
B
Is
I'm
going
to
share
my
screen,
and
this
is
a
very
interesting
number
if
you're
using
github,
you
may
be
fascinated
with
the
number
of
github
stars.
Apparently,
if
you
get
over
like
a
hundred
github
stars,
you
can
probably
raise
an
a
round
in
silicon
valley,
so
those
numbers
do
have
meaning,
but
this
number
on
the
screen
one
hour,
59
minutes
and
40
seconds.
B
B
He
did
it
and
we
tend
to
put
the
person
who
crosses
the
finish
line
first
in
the
foreground.
Look
at
this
picture
notice
behind
him.
All
the
other
runners
are
cheering.
That
seems
a
bit
odd.
It's
supposed
to
be
a
marathon.
That's
like
a
race
winner.
Take
all
there's
only
one
first
place
finish,
but
the
people
behind
him.
If
you
watch
this.
B
B
There's
about
30
other
world-class
runners
in
this
formation.
All
of
them
are
taking
turns.
So
maybe
you
run
a
few
miles
and
maybe
the
top
two
guys
switch
out
and
the
other
two
join
in
now
any
of
them
any
of
the
30
who've
been
training
for
months
to
help
them
break
this
world
record
of
a
person
running
a
marathon
in
less
than
two
hours,
something
we
didn't
think
was
humanly
possible.
B
B
B
B
When
you
think
about
git,
it's
one
of
the
world's
best
collaboration
tools
for
writing.
Software
and
github
is
where
we
all
meet
and
collaborate,
but
it's
the
people
that
make
all
of
this
work
and
when
people
think
about
kubernetes,
they
want
to
hyper
index
and
hyper
over
optimize
on
containers
versus
this
other
thing,
and
you
could
do
that.
You
can
click
on
all
the
hacker
news
links
and
have
about
10
000
tabs
in
your
web
browser.
But
if
you
focus
on
the
technology,
I
don't
think
you'll
ever
get
it.
B
What
we've
been
doing
with
all
of
these
platforms
is
serializing.
The
way
we
work,
there's
been
a
lot
of
ideas
over
the
last
20
years,
and
a
lot
of
them
have
been
serialized
in
kubernetes,
that's
the
gist
of
it.
I
know
people
want
it
to
be
more
complicated
than
that.
There
should
be
a
series
of
best
practices
hell.
I
even
wrote
a
book
about
it,
but
the
truth
is
there's
just
practice
and,
as
we
learn
we'll
contribute
to
those
things.
B
If
you
have
a
clear
goal,
if
you
know
what
you're
trying
to
do,
maybe
you
know
where
the
finish
line
is.
You
can
actually
bring
in
all
of
these
people
and
all
of
these
tools
and
they
should
be
aiding
you
to
go
faster
than
you
can
by
yourself
now
elliot
kipchoge.
He
is
a
world-class
marathon.
Runner
he's
never
ran
the
marathon
in
less
than
two
hours
he's
gotten
close,
but
he's
never
been
able
to
do
it
on
his
own
and
sometimes
because
he's
the
only
one
in
front
and
there's
no
one
there
to
push
him.
B
But
with
this
setup
it
changed
the
game
and
if
you
do
it
right
and
you
keep
these
kind
of
north
stars
clear,
then
I
think
it
makes
it
much
easier
to
understand
how
all
the
technology
comes
together
and
the
people
around
it.
You
can
wrap
that
around
you
and
then
use
it
to
push
you
forward.
That's
the
way
you
got
to
think
about
this.
B
If
you
want
to
understand,
get
ops,
you
got
to
understand
the.
Why?
Why
are
you
using
it
what's
important
about
it?
What's
the
peloton
formation
you're
trying
to
build
around
you
and
is
it
designed
to
help
you
go
faster?
Are
you
just
doing
stuff
because
people
said
it
on
twitter
so
now
we're
going
to
jump
into
kind
of
this
live
demo
about
how
all
of
this
works.
B
B
Most
people
write
software
to
put
it
in
the
hands
of
their
customers,
so
in
this
case
we're
going
to
have
a
very
simple
app,
because
what
I
want
you
to
do
is
focus
on
the
actual
workflow.
That's
what
this
whole
get
off
things
about.
What
type
of
application
can
you
deploy?
I
don't
know
what
kind
of
applications
can
you
write?
B
So
you
see
I'm
rocking
that
new
dark
thing.
Maybe
this
is
going
to
be
the
new
trend
and
I
just
have
a
simple
app:
that's
called
hello
universe
and
as
a
developer,
if
you
put
your
developer
hat
on,
you
have
some
very
specific
goals.
Your
goal
is
to
write
code
that
hopefully
works
and
then
deploy
it
to
the
proper
environments
and
then
you
should
be
able
to
hit
an
endpoint
and
get
some
results.
B
B
B
Why
is
it
going
to
change
the
way
you
think
about
things
and
work?
The
honest
truth:
it
shouldn't,
if
you
think
about
the
way
you
write
code
today,
if
you're
a
developer,
there's
a
big
chance
if
you're
walking
watching
this
talk
that
you're
already
using
git
think
about
it.
When
you
write
code,
you
tend
to
make
a
few
commits
and
then
you
push
it
up.
B
You
can
run
that
binary
locally.
If
you
really
wanted
to
I
can
I
can
do
something
like
hello
universe.
I
have
this
binary,
that's
on
my
machine.
I
can
run
it
locally
and
if
I
were
to
go
to
another
tab
and
call
curl
on
localhost,
the
thing
you
expect
to
happen
should
happen.
I
could
hit
this
on
port
8080
and
there
we
go
that's
pretty
straightforward
and
then
you
push
your
code
to
some
repository,
but
here's
the
thing.
B
If
you
really
want
to
know
how
this
works,
I
think
one
of
the
best
examples
that
I've
seen
online
is
probably
to
the
people
who
coined
the
term
weaveworks.
They
get
ops
and
the
whole
goal
behind
get
ops.
Is
that
imagine
if
you
were
to
able
to
use
the
same
development
workflow
for
managing
infrastructure,
but
here's
a
twist
we've
been
doing
this
for
a
super
long
time.
A
lot
of
people
will
look
back
to
like
puppet
and
chef
and
ansible,
and
we
wrote
a
lot
of
code
back
thing
and
yeah.
B
A
lot
of
us
checked
into
version
control.
So
what's
new
about
this,
this
looks
like
the
same
thing
we've
been
doing
and
someone
just
came
up
with
a
better
name
for
it.
That's
probably
true,
and
they
raised
a
lot
of
cash
behind
it,
but
the
ideas
are
solid.
Why
are
they
solid?
Well,
there's
a
twist
here
given
kubernetes
and
the
way
it
works.
We
now
can
start
to
treat
infrastructure
as
data
and
a
lot
of
people
say
nope.
I
thought
it
was
infrastructure.
B
As
code
yeah,
you
can
write
a
lot
of
code,
but
code
has
some
other
issues
to
it.
One.
You
need
something
that
understands
that
programming
language
in
order
to
write
that
code,
parse,
that
code
validate
that
code
and
those
tools
exist,
don't
get
me
wrong,
but
the
idea
that
if
we
can
write
code
or
config
as
data,
maybe
we
can
simplify
this.
B
I
know
what
you're
thinking,
oh
more
yaml,
look
yaml
ain't
that
bad
stop
complaining,
it's
readable,
you
can
modify
it
and
we
can
run
things
like
static
analysis
without
having
a
compiler
or
something
that
can
parse
that
language
an
overview.
This
is
what
it
looks
like.
I
know
people
get
this
super
complicated.
I
know
a
lot
of
people
will
talk
about
ci,
cd
and
pipelines
and
deploying
two
trillion
times
a
day,
even
though
they
don't
have
a
reason
to
deploy
two
trillion
times
a
day.
It's
something
we
brag
about
at
conferences.
B
The
truth
is
it's
all
about
the
workflow,
how
you
encapsulate
that
workflow?
Well,
that's
going
to
be
up
to
you.
Look
at
this
diagram
as
a
developer.
On
the
left
side,
you
write
code,
it
goes
into
a
version
control
system
and
then
ideally
you're
going
to
produce
an
artifact.
So
here's
where
this
kubernetes
connection
comes
into
play
kubernetes
requires
a
container
as
the
price
of
admission.
B
Oh,
I
know
what
you're
saying.
Oh
my
god,
I
got
to
build
a
container.
This
is
the
hardest
thing
in
the
world,
always
going
to
take
me
7,
000
years
to
learn
how
to
build
a
container,
and
I
ask
people
like
wow:
have
you
even
tried,
like
seriously?
Have
you
tried
to
build
a
container
before
you
start
freaking
out?
B
Think
about
what's
required
right
if
you
know
how
to
build
your
app
locally
right
like
these
are
the
same
kind
of
commands,
I
would
put
in
the
build
script
then,
in
my
case
I
keep
things
super
simple.
I
build
my
app
the
same
way.
I
normally
do
and
then
based
on
the
results
here,
this
hello
universe,
binary.
B
I
simply
copy
it
from
my
build
step
and
then
package.
It
we're
really
talking
about
glorified
tar
balls,
but
they're
really
powerful,
but
they
are
very
similar
to
using
things
like
ruby,
gems
or
a
war
file.
If
you
come
from
the
java
world,
you
gotta
package
software
in
something.
Why
not
pick
something?
That's
super
universal!
B
That's
the
selling
point!
If
you
don't
like
docker
files,
there
are
other
tools
that
can
build
container
images
get
over
it
once
you
do,
then,
the
world
kind
of
opens
up
to
this
other
thing
that
we're
talking
about
in
order
for
this
get
off
things
to
work,
the
way
we're
talking
about
it
with
declarative
infrastructure.
We
don't
want
to
be
dealing
with
the
differences
between
node.js
python
and
go.
We
want
to
have
a
normal,
consistent
object
or
artifact
to
deal
with.
B
Let's
go
back
to
the
diagram,
really
quickly
notice,
this
container
registry
component,
that's
the
key
to
normalizing
your
workflow
across
all
your
applications.
So
what's
the
contract
between
you
and
the
developer?
Well,
as
the
developer,
your
job
is
to
write
code
that
works.
Ideally
it's
secure
as
well,
and
then,
if
you
do
that,
we
can
automate
the
process
of
building
those
docker
files.
So
it's
on
you
to
put
a
description
of
how
to
build
your
app
right
and
then,
when
it's
done,
you
can
actually
create
that
entry
point,
so
we
know
how
to
run
it.
B
So
how
do
we
automate
this?
Well?
Github
has
a
really
nice
feature,
so
in
github
you
can
actually
do
something
pretty
neat.
You
can
set
up
some
actions.
Basically,
so
when
I
push
this
repository
or
tag,
a
branch
in
this
repository
it'll
kick
off
a
set
of
actions
and
they
have
all
of
these
nice
little
brew
plants
that
say
hey
whenever
code
is
checked
in
here
push
to
sum
repository
before
my
talk,
I
was
bumped.
I
was
producing
a
few
versions.
B
B
Does
all
this.
In
the
background,
every
time
I
commit
or
or
tag
something,
and
then
once
that's
ready,
the
important
part
here
is
you
want
to
push
it
to
a
central
repository.
If
you
haven't
been
paying
attention,
github
also
has
a
new
container
repository,
so
you
can
manage
packages
for
all
your
repositories.
Look
here.
B
Now
that
we
have
repository,
let's
pop
back
over
to
that
diagram
again,
I
don't
think
this
has
to
be
as
complex
as
a
lot
of
people
make
it
at
least
not
the
fundamentals.
So
now
we
have
this
part
of
the
loop
established
checking
in
our
code
and
making
container
images
got
it.
So
at
this
point,
we're
now
ready
to
start
releasing
our
application
to
something
like
kubernetes.
B
Now,
how
do
you
go
about
that?
Well,
you
can
do
simple
ops
and
what
ops
looks
like
is
in
this
world
of
the
declarative
world
is
ops,
is
about
writing
yaml
files
yay
one
time
for
the
yaml
files,
you'll
learn
to
love
yam.
While
I
promise
you
and
if
you
have
like
vs
code
and
any
of
those
robust
editors,
it
will
help
you
write
a
lot
more
yaml.
So
don't
worry,
yamo
is
your
friend.
What
does
that?
Yaml
stuff?
Look
like
I'm
just
going
to
show
you
one!
Here's
a
deployment
file.
B
Really
the
goal
here.
Is
you
to
articulate
what
you
want
the
system
to
do?
I
want
to
deploy
this
version
of
my
application.
I
want
this
much
memory
and
cpu.
You
get
the
idea,
but
ideally
you
can
have
tools
that
help.
You
generate
these
configs
they're
very
explicit,
but
the
whole
point
here
is
that
they're
declared
we're
not
writing
any
scripts,
we're
not
using
any
custom
languages
or
any
custom
tools.
We're
just
crafting
some
data.
B
The
nice
thing
about
this
data
is
that
we
can
push
it
to
any
kubernetes
cluster
that
we
want.
The
goal
is
between
the
deployment
object
and
the
service
that
allows
me
to
attach
this
to
a
load
balancer
and
a
horizontal
scaling
config.
I
have
the
three
components
that
I
need
for
dealing
with
my
infrastructure.
So
how
does
that
work?
Well,
there's
a
bunch
of
things
you
can
do
here.
Let's
go
back
to
the
diagram
in
this
diagram
notice.
B
B
So,
if
I
were
you,
I
would
consider
following
this
pattern.
This
blueprint
keep
your
config
repo
separate.
So
what
does
that
look
like
in
the
github
world?
Well,
you
probably
know
what
this
looks
like
if
I
click
over
here
to
my
github
tab.
I
just
have
another
repository
where
I'm
storing
all
of
my
configs-
and
here
I
can
have
my
same
git
flow.
I
can
do
pull
requests.
I
can
review
them
and
all
of
my
configs
are
just
sitting
here.
B
If
you
have
lots
of
clusters,
one
model
may
work
better
than
the
other.
One
thing
I
like
to
do
is
give
myself
the
flexibility
to
have
different
kubernetes
clusters
have
different
versions
of
the
config,
even
at
the
same
time,
let's
see
what
that
looks
like
in
practice
really
quickly.
So
I
have
a
couple
of
live
clusters
running
in
my
infrastructure.
B
I
basically
have
something
in
us
west,
one
usb4
and
I
have
another
one
in
us,
west,
one
in
the
b
zone.
Now
what
I'm
going
to
do
is
I'm
going
to
treat
this
second
cluster
in
u.s
west
as
my
canary
cluster.
Now
this
is
where
things
get
a
little
interesting,
I'm
going
to
go
with
the
pull
model,
I'm
using
a
tool
called
config
sync
and
there's
other
great
tools
out
there,
some
made
by
weaveworks
and
many
others.
The
choice
is
up
to
you.
B
They
all
have
different
feature
sets
pick
something
that
works,
but
the
fundamentals
are
roughly
the
same.
We
want
these
clusters
to
link
to
our
configuration
repository.
This
is
the
core
premise
to
what
we're
doing.
We
want
these
artifacts
to
work.
So
here's
the
other
thing
we
want
to
do.
I
want
to
leverage
multiple
branches.
B
That
way.
Maybe
I
want
1.0
deployed
to
all
of
the
clusters
and
when
2.0
is
ready.
Maybe
I
tell
just
one
cluster
that
it
should
be
running
the
2.0
version
of
my
configs
and
we'll
see
what
that
looks
like
all
right.
So,
let's
see
where
we
are
at
this
point,
we
have
everything
set
in
terms
of
our
config.
I
have
my
tool
called
nomos,
which
is
part
of
the
command
line
tool
that
allows
me
to
interact
with
the
config
sync
repositories.
B
So
if
I
run
the
status
command,
it's
going
to
connect
to
my
clusters
and
tell
me
the
current
status
of
the
repositories
that
it's
been
syncing
to,
while
that's
running
what
I'm
going
to
do
now
is
run
that
curl
command
again
and
you'll
notice
that
we're
hitting
our
universal
url
and
that
universal
url
is
pointed
at
all
of
my
kubernetes
clusters.
I
have
a
load
balancer
sitting
here
and
that
load
balancer
is
pointing
to
three
different
clusters.
Hello
universe
is
pointing
to
all
of
those
zones
here
we
go
down
here
so
with
that.
B
B
If
we
look
at
our
syncing,
we'll
see
that
all
three
clusters-
us
west
one,
a
and
east,
all
of
them-
are
syncing
to
the
1.0
branch
of
my
hello
world,
universe,
config
and
they're,
all
in
sync
and
I'm
getting
the
right
version.
Everything's
working
nicely
so
now
I
want
to
make
that
change.
Well,
of
course
you
update
your
code
and
you
go
back
to
the
flow
that
you're
used
to
checking
your
code
and
then
what
will
happen
is
a
bill
process
will
kick
off
drop.
Something
in
your
package.
B
Repository
give
you
a
new
tag,
that's
eligible
for
deployment,
and
then
all
you
have
to
do
is
make
a
change
in
the
config
repository
now.
There's
ways
to
automate
this,
but
I
just
want
to
show
you
how
it
works
underneath
the
covers.
Your
goal
is
on
that
separate
branch
where
those
configs
live.
Well,
those
configs
I'm
going
to
show
you
the
differently
quickly.
B
B
B
I
did
a
little
bit
of
work
ahead
of
time
at
this
config
management
directory
and
if
you
look
at
them,
they're
currently
all
the
same,
but
let's
look
at
the
one
that
I've
deemed
our
canary
cluster.
So
what
I've
done
is.
I
have
a
separate
load:
balancer,
that's
sending
traffic
only
to
one
of
these
clusters
and
it's
called
hello
universe
canary.
B
B
Now
I
have
those
stages
changed.
I
have
the
containers
built.
We
only
need
to
do
one
more
thing
here:
we'll
update
the
config
management
config.
Just
for
that
one
cluster,
so
we'll
say
usbs
west1b
and
we'll
come
over
here
and
say.
Look,
I
want
to
sync
instead
of
the
branch
2.1.0,
we'll
change
it
to
2.0
and
then
what
we'll
do
here
is
we'll
tell
that
cluster
that
it
should
re-prioritize
where
it's
pulling
config
and
the
way
we
do
that
is,
we
run
a
command.
B
B
Once
this
config
is
in
place
that
kubernetes
cluster
will
go
to
that
new
branch
of
that
config
repo
and
then
try
to
update
the
state
of
the
world
based
on
those
configs.
The
nice
thing
about
this
workflow
is
that
developers
can
keep
checking
in
code
and
tagging
releases
and
then
those
will
flow
into
the
container
registry.
B
Only
when
the
config
repo
is
updated
specifically
for
a
specific
environment
will
it
go
and
pull
the
right
container
at
the
right
time.
So
for
most
people
once
you
get
this
stuff
set
up,
you
end
up
working
like
you
were
normally
working
now
you
kind
of
have
this
get
out
workflow
on
both
sides.
You
can
start
the
diff
review.
Changes,
merge
them
in
so
with
that
in
place.
B
If
I
go
over
here
and
look
at
the
cluster
output,
we'll
look
at
our
workloads
and
we
should
see
kubernetes
hard
at
work,
trying
to
replace
some
of
those
old
versions
of
my
app
one
by
one
or
how
I
direct
it.
Based
on
my
controller,
that's
doing
the
work
inside
of
the
cluster
remember
everything's,
declarative!
On
my
side
I
got
a
few
more
pods
to
go
we'll
hit
refresh
here
to
see
if
everything
is
up
to
date,.
B
And
we
have
one
more
that
we're
shutting
down,
but
so
far
it
looks
like
everything
is
green
and
we're
ready
to
test.
So,
let's
see
if
this
works
we'll
go
back
to
our
command
line
and
we'll
hit
that
canary
endpoint
again-
and
we
see
it's
on
2.0
and
just
to
be
sure
that
everything
is
working,
we'll
hit
the
global
load
balancer
and
ideally
we're
going
to
bounce
around
to
various
endpoints.
B
So
with
that,
I'm
going
to
stop
the
presentation,
and
hopefully
you
have
a
better
understanding
of
how
git
ops
works.
There's
a
lot
more!
You
can
do
here.
We
just
scratched
the
surface.
A
lot
of
people
are
looking
at
this
as
a
very
complex
thing,
but
remember
you
already
know.
Most
of
the
workloads
you've
probably
already
been
working.
D
Github
universe,
don't
forget
to
hit
us
up
on
twitter
because
I'm
sure
you're
about
to
have
a
lot
to
say
here.
Martin,
you
are
certainly
looking
sharp
today.
I
don't
know
if
it's
because
business
insider
may
have
named
you
one
of
the
hot
and
upcoming
microsoft
executives,
or
maybe
I
saw
on
twitter
james
governor
from
redmonk,
was
giving
us
a
hassle
about
how
enterprise
appeal
are
dressed.
Since
so
we
thought
we
spruced
it
up.
A
little.
D
D
E
That
is
that
your
is
that
your
captain
cap
you're
wearing
wow,
fancy
damn
looking
good.
If
something
isn't
quite
right,
though,.
D
I
thought
we
did
good,
I
don't
know
I,
you
know,
I
don't
even
own
a
shirt
with
buttons
and
I
had.
G
E
Yeah
indeed,
enterprising
the
heck
out
of
this
one
remember
we're
putting
the
enterprise
in
the
entertainment
in
enterprise.
I
believe
that's
what
we're
doing
isn't
it
anyway,
let's
get
cracking
so
if
you
missed
the
last
two
days,
you're
probably
wondering
what
the
heck
is
going
on
right
now,
but
we
have
four
different
channels:
we've
got
the
dev
channel,
we've
got
the
play
channel,
we've
got
the
university
channel
and
then
we've
got
the
enterprise
channel
that
you're
watching
right
now.
E
Obviously
because
you
know
or
enterprise
and
today
is
all
about
developer
experiences,
yesterday
was
about
devops
and
then
you
can
check
out
those
sessions
on
demand.
If
you
go
up
to
the
more
tab
or
if
you
go
to
githubuniverse.com
on
demand
now,
we've
got
a
great
day
for
you
today
up
on
the
enterprise
channel,
but
you
know
have
a
look
at
the
enterprise
on
the
play
channel.
It's
all
about
inspiring
tech
today
and
obviously
check
out
the
university
channel
as
well.
If
you're
a
student
or
faculty.
E
Now,
then,
let's
see
what
we've
got
coming
up
so
coming
up.
We've
got
the
code
snippets
search
session,
which
I'm
really
looking
forward
to
and
then
dana
one
of
your
favorite
sessions,
how
into
it
is
overhaul
in
legacy
engineering
practices
at
scale
within
a
source
they're,
definitely
into
it
in
the
source
in
into
it.
Something
like
that.
You'll
get
that
joke
better
in
a
bit,
though,
and
then
later
on,
we
have
getting
better
together
what
we
can
learn
with
enterprise
pattern.
E
D
Subject
matter
experts
or
smes
with
the
community
who
will
be
engaging
during
our
sessions,
taking
your
questions
for
each
speaker
after
q
a
so
join
us
on
github
universe.com
discussions,
but
happening
right
now
on
the
dev
channel
we
have
project
scara,
open,
jdk,
moving
to
github
and
over
on
the
play
channel.
How
do
you
feel
something
you
can't
touch
and
other
questions
encountered
in
xr
but
martin?
How
about
we
tell
the
peeps
what
we
got
next
right
here.
E
Yeah
we've
got
a
great
session
coming
up
now
on
code,
snippet
search,
so
we've
got
two
speakers
for
us:
we've
got
hamel
and
rock
hamel.
Hussein
is
a
staff
machine
learning
engineer
here
at
github.
He
enjoys
building
tools
for
data
scientists
and
then
rock
novocell
he's
a
software
engineer
from
the
beautiful
slovenia
and
he's
a
member
of
the
real
python
tutorial
team.
So
don't
remember,
don't
forget,
to
you
know
rate
this
session.
On
these
the
little
session
thing
there
we
go.
E
H
Hi,
I'm
hamil
hussein,
I'm
a
staff
machine
learning,
engineer
at
github
and
I'm
joined
by
rock.
Who
is
a
engineer
at
sourcecraft
and
today
we're
going
to
be
talking
about
co-snippet
search.
But
first
I
want
to
talk
about
code
search
net,
which
is
what
powers
code,
snippets
search
and
a
number
of
other
projects
as
a
way
of
introduction.
H
Winning
games
like
alphago,
mundane
things
like
text
message,
completion
when
you're
on
your
phone
and
even
other
things
such
as
winning
jeopardy.
These
are
all
things
that
have
been
popularized
in
in
the
media
as
a
lately.
As
far
as
things
that
artificial
intelligence
can
do.
However,
there's
another
side
to
artificial
intelligence,
there's
a
side
of
it
that
can
help
everyday
people,
do
their
jobs
and
especially
skilled
labor.
So
what
do
I
mean
by
that?
H
So,
for
example,
radiologists?
We
see
artificial
intelligence,
helping
radiologists
zone
in
on
potential
areas
where
there
might
be
a
disease
or
a
diagnosis
that
needs
to
be
made
oops.
I
went
to
the
wrong
side,
and
you
see
here
that
there's
a
heat
map
where
the
artificial
intelligence
algorithm
has
highlighted
for
the
radiologists
points
of
interest
that
they
might
want
to
pay
more
attention
to,
and
what
this
does.
It
doesn't
replace
the
radiologist
it
augments
the
radiologist
and
it
helps
make
them
more
effective
at
what
they're
doing.
H
Similarly,
we
see
artificial
intelligence
augmenting
writers,
so
this
is
a
very
popular
tool
called
grammarly.
You
may
have
used
it,
and
not
only
does
it
help
you
with
spell
checking,
but
it
helps
you
with
more
nuanced
type
of
things
like
engagement
and
grammar
and
things
that
are
a
little
bit
harder
to
do
with
non-ai
approaches.
H
We
also
see
artificial
intelligence
augmenting
lawyers,
so
there's
a
lot
of
tools.
There's
a
growing
set
of
tools
out
there
that
oops.
This
is
the
wrong
slide.
Sorry,
we
have
artificial
intelligence
augmenting
lawyers,
so
we
see
that
harvest
challenge
is
allowing
lawyers
to
go
through
lots
of
documents
and
cut
out
the
mundane
work
of
sifting
through
lots
and
lots
of
data
manually
and
helping
lawyers
focus
on
more
high
value
tasks
that
they
are
trained
for.
H
And
we
also
see
that
artificial
intelligence
is
helping
in
basic
science,
so
helping
with
things
like
drug
discovery,
helping
researchers,
scientists
find
molecules
and
compounds
that
might
help
in
things
like
having
creating
therapeutics
or
medicines
for
various
different
diseases
and
being
able
to
find
those
a
lot
faster
than
ever
before.
H
H
So
this
is
why
github
released
code
search
net
code
search
net
is
a
large
corpus
of
of
data
and
it's
essentially
code
and
comment
pairs.
There's
two
million
code
in
comment,
pairs
pulled
from
various
github
repositories,
cleaned
and
curated,
and
what
that
what
that
is,
is
a
treasure
trove
of
data
for
researchers
to
then
use
for
various
artificial
intelligence
and
machine
learning
tests.
H
So
so
well,
not
only
is
it
the
data,
but
there's
also
some
other
things
that
you'll
talk
about
in
a
moment,
but
this
gives
you
a
breakdown.
Various
languages
have
been
represented
in
this
data,
go
java,
javascript,
python,
ruby,
so
on
and
so
forth,
and
we
can
see
there's
a
lot
of
diversity
in
here
for
researchers
to
dive
into.
H
So,
in
addition
to
the
data,
we
also
provided
benchmarks
and
reference
models,
and
one
task
that
we
propose
is
search
so
given
a
natural
language
description
of
some
kind
of
code
that
the
task
is
that
we
propose
is:
can
you
find
code
that
does
that
and
to
do
that
in
a
very
semantic
way,
so
not
keyword
search.
So
you
can
imagine
this
case.
That
is
illustrated
on
this
slide.
Let's
say
you're
trying
to
find
code
that
pings
a
rest,
api
and
returns
results,
but
suppose
the
code
doesn't
contain
any
of
those
keywords
at
all.
H
The
code
doesn't
contain
the
words
ping
or
rest
or
api.
So
how
would
you
find
that
code,
if
you
didn't
know
if
you're
not
familiar
with
the
syntax
you're
just
new
to
a
project?
So
what
this
is
meant
to
illustrate
is
ai
can
help
with
tasks
like
this
semantic
search
of
code,
and
this
is
one
of
the
references
provided
by
codesearchnet.
H
H
I
I
I'm
on
next
slide,
so
code
search,
for
me
at
least,
is
one
of
the
most
important
tools
during
coding.
I
noticed
that
searching
and
navigating
through
code
heavily
outweighs
the
actual
coding.
So
when
I'm
already
familiar
with
the
code
base,
I
find
that
exact
search
is
what
they
need,
for
example,
regular
expressions
and
case
insensitive
search.
That
is
because
I'm
already
familiar
with
the
naming
scheme,
and
I
can
reasonably
predict
how
to
formulate
a
search
query
and
every
id
and
code
editor
is
already
equipped
with
it.
I
But
when
I'm
not
familiar
with
the
code
base
or
even
a
new
folder
within
an
existing
large
project,
it
makes
searching
more
difficult
because
it's
more
trial
and
error,
a
tool
like
code
snippet
search,
would
allow
me
to
easily
explore
unfamiliar
code,
focusing
on
the
semantics
without
getting
bogged
down
in
the
syntax.
For
example.
This
is
especially
useful
when
onboarding
a
new
developer
onto
a
project,
because
it
can
be
a
significant
boost
to
their
productivity
outside
of
a
work
environment.
We
encounter
unfamiliar
code
in
the
form
of
github
repositories.
I
I
To
give
a
short
example,
let's
say
I'm
a
new
developer
at
a
company
and
I
get
a
ticket
to
implement
an
api
endpoint
that
fetches
products
and
their
shipping
information.
Additionally,
I
want
to
implement
as
much
as
possible
on
my
own.
Traditionally
I
would
start
searching
and
going
through
all
classes
and
functions
that
mention
products
or
shipping,
depending
on
the
size
of
the
code
base.
That
may
be
a
lot
of
code
to
go
through.
I
There
really
is
no
good
way
to
automatically
narrow
down
the
search
results
until
you
get
more
familiar
with
the
code
base
and
you
only
get
more
familiar
if
you
work
with
it
for
long
enough,
so
this
leads
to
bootstrap
problem
that
all
developers
eventually
overcome
to
shorten
the
bootstrap
time.
I'd
rather
enter
a
few
general
queries
that
automatically
surface
the
best
possible
results.
So,
in
our
case
here
I
will
enter
get
all
products
get
shipping
info
for
product
and
paginate
api
response.
I
I
would
expect
to
get
product
and
shipping
info
classes,
for
example,
if
we're
programming
in
an
object-oriented
language
and
some
functions
dealing
with
sql
and
retrieving
the
entities
from
the
database.
I
may
be
a
bit
stretching
with
this
example,
but
hopefully
you
get
the
overall
point
next
slide,
please.
I
I
On
the
first
page,
we
see
a
list
of
supported
repositories
with
their
descriptions
and
these
supported
languages.
Now
we
need
to
select
the
repository
to
search
and
since
django
powers
the
back
end
of
this
project.
It
seems
like
a
good
place
to
start
next
next
slide.
Please
so,
let's
say
we
wanted
to
know
how
to
get
a
database
table
name
in
django.
Well,
we
get
back
a
list
of
code
snippets
each
one
containing
a
link
to
the
github
file
match.
I
Reading
similar
code,
snippets
and
syntax
highlighted
code,
everything
except
the
match
rating
and
the
similar
code.
Snippets
link
should
be
pretty
self-explanatory.
We'll
go
over
the
similar
code
snippets
later
on.
The
match
rating
is
calculated
from
the
vector
distance
between
the
query
and
the
snippet,
so
higher
the
match
rating,
the
closer
the
query
and
the
snippet.
This
is
a
little
foreshadowing
into
how
code
snippet
search
works
under
the
hood.
I
In
this
case,
we
didn't
get
the
exact
answer
we
were
searching
for,
but
looking
at
the
first
snippet,
I
think
we
could
make
it
work
with
a
bit
of
tweaking
next
slide.
Please
to
showcase
the
similar
code
snippets
option.
Let's
say
you
wanted
to
know
how
to
convert
a
time
zone
to
a
local
date
time
by
clicking
on
the
similar
code,
snippets
link
code,
snippet
search,
will
look
for
other
code
snippets
that
best
match
the
selected
one,
as
we
can
anticipate
we'll
get
a
lot
of
time
zone
converting
functions.
I
This
is
great
for
exploring
the
code
base
and
similar
functionality
next
slide,
please,
okay!
So,
let's
move
on
to
the
web
extension
web
extension
can
be
used
directly
on
the
github
repository
I'll,
be
using
the
python
repository
as
an
example,
because
I'm
using
it
to
implement
the
neural
networks
within
code,
snippet
search,
the
web
extension
is
implemented
in
the
form
of
a
sidebar
that
is
opened
by
pressing
alt
shift
and
s
there.
You
can
search
by
entering
a
query
or
a
code.
Snippet
next
slide.
I
So
if
I
was
interested
in
one
dimensional
convolution
in
pi
torch,
I
can
enter
the
query
in
the
sidebar.
The
search
results
have
the
same
format
as
an
as
on
the
web
application,
but
they
are
more
accessible
through
the
sidebar
next
slide.
Please,
a
convenient
way
of
searching
by
code
is
selecting
a
code
snippet
right,
clicking
and
selecting
the
search
by
code
option
with
the
search
by
code
option
you
can
search
using
any
arbitrary
code.
Snippet
and
the
most
similar
snippets
from
the
repository
will
be
returned.
I
This
could
be
repurposed
into
detecting
duplicate
code
in
pull
requests
as
an
automated
check
or
even
as
an
offline
tool
to
help
us
while
developing
next
slide.
Please
the
main
data
source
and
inspiration
for
code
snippet
search
is,
of
course,
the
code
search
net
project.
It
provides
various
baseline
implementations
of
neural
code
search
and
tensorflow.
I
They
range
from
simpler
ones
like
bag
of
words
to
the
ones
using
state-of-the-art
techniques
like
self-attention.
My
implementation
was
inspired
by
their
neural
bag,
awards
baseline
implementation
because
it
was
performing
the
best
overall.
Initially
I
had
written
code
snippets,
searching
keras
and
was
able
to
search
through
the
code
search
at
corpus.
I
The
keras
models
became
really
unwieldy
to
work
with
due
to
the
specific
structure
of
the
neural
networks.
It
also
did
not
place
play
nice
when
developing
the
app
together
with
django.
So
I
had
to
look
for
alternatives.
I
decided
to
switch
to
pytorch
when
I
wanted
to
add
support
for
searching
github
repositories,
because
the
model
code
became
really
simplified
and
there
were
no
issues
when
developing
and
deploying
the
django
app
next
slide.
Please
so
code
snippet
search
works
by
using
joint
embeddings
of
code
and
queries
to
implement
a
neural
search
system.
I
The
training
objective
is
to
map
code
and
corresponding
queries
onto
vectors
that
are
similar
to
each
other.
There
are
multiple
ways
to
measure
similarity
between
vectors,
but
I'm
using
cosine
similarity
throughout
with
a
trained
model.
I
can
embed
a
natural
language
query
and
then
yield
and
then
use
nearest
ever
search
to
return
a
set
of
closest
code
snippets
during
training.
I
use
function,
dark
strings
as
approximations
of
natural
language.
Queries
next
slide,
please.
I
So
here
here
is
just
a
simple
visual
representations
of
these
visual
of
these
embeddings
that
we're
we're
trying
to
learn
by
training
the
models
next
slide.
Please,
and
in
this
image
I
have
the
entire
model
split
up
into
layers.
First
is
the
input
layer,
one
input
is
four
queries
and
one
input
each
for
languages
inputs
are
forwarded
into
embedding
layers
with
drop
out
applied,
afterward
the
magic
happens
in
the
encoding
and
pulling
layer.
I
Here
I
take
the
simplest,
but
in
this
case
the
most
effective
way
of
encoding
the
tokens
using
a
weighted
mean
the
weights
are
used
for
weighting,
are
learned
in
a
separate
strainable
layer.
Since
we
split
up
the
languages
at
the
input,
we
have
to
concatenate
them
back
in
the
same
order
as
they
appear
in
the
queries.
I
I
Okay
and
how
is
the
actual
searching
performed?
I
take
all
of
the
code
snippets.
I
encode
them
using
the
trained
model
and
store
them
in
a
nearest
neighbors
search
index.
When
I
want
to
look
up
the
nearest
code
snippets
using
a
query,
I
first
encode
the
query
and
then
look
for
the
nearest
code
snippets
and
here
we
have
the
training
procedure,
which
is
split
into
two
major
parts:
training
the
base,
language
values
and
then
training.
The
repository
language
models,
with
the
help
of
the
base
models
both
contain
roughly
the
same
steps.
I
First,
the
code
and
query
sequences
are
pre-processed.
For
example,
the
tokens
are
converted
to
lowercase
and
invalid
documents
are
filtered
out.
Then
we
prepare
the
vocabularies
for
code
and
query
tokens
and
we
only
keep
the
most
frequent
ones
with
the
help
of
the
vocabularies
we
encode
the
tokens
into
integers
that
can
then
be
used
in
the
neural
network
and
paddings.
All
that
is
left
is
to
train
the
model
and
save
it.
I
train
the
base
language
models
using
the
codesuch.corpus
first.
I
The
main
goal
of
the
base
language
model
is
to
train
the
world
and
code
token
embeddings.
That
can
then
be
transferred
to
repository
models.
I'm
hoping
that
the
base
language
model
learns
general
language
features
that
can
then
be
fine-tuned
by
the
repository
data
with
repositories.
I
was
on
my
own
to
extract
the
corpus,
I'm
using
github's
three-seater
to
find
functions
and
then
tokenize
them
repository
models.
Have
the.
I
I
Large
well-documented
repository
to
train
the
model,
and
even
then
it
only
works
on
functions,
so
the
first
next
step
would
be
to
figure
out
how
to
work
on
smaller
chunks
of
code,
for
example,
a
couple
of
lines
of
code.
With
a
comment
above
from
a
model
perspective,
I
would
like
to
experiment
with
the
tree
based
models
that
could
potentially
capture
the
information
hidden
in
the
abstract
syntax
tree.
But
for
that
I
would
need
to
gather
a
lot
more
samples
next
slide.
I
Please,
and
I
saved
a
small
anecdote
for
the
end,
which
highlights
why
reinventing
the
wheel
is
sometimes
good
and
perhaps
even
necessary,
a
software
engineers.
We
have
thought
that
we're
thought
that
we
should
avoid
reinventing
as
much
as
possible
and
just
use
the
already
proven
solution.
This
is
generally
good
advice
that
prevents
us
spending
too
much
time
developing
unnecessary
things,
but
if
you're
looking
to
learn,
deepen
your
knowledge
and
have
fun
while
doing
it,
then
revamping
the
wheel
is
a
great
place
to
start.
I
That
was
the
main
source
of
motivation
for
me
and
why
I
wanted
to
join
the
code
search,
math
challenge.
Of
course,
I
could
have
taken
the
already
implemented
baseline
models
and
tinker
with
them.
My
goal
was
to
learn
newer
networks
in
depth
and
actually
understand
the
mechanics
behind
them,
and
my
reimplementation
efforts
led
me
to
discover
a
small
bug
in
the
region
in
the
original
baseline
pipeline
that
was
causing
a
big
problem
with
the
evaluation.
I
As
I've
mentioned,
I
re-implemented
the
code
search
and
baseline
models,
including
the
evaluation
part.
I
used
scikit's
nearest
neighbor
search
class
instead
of
annoy
index,
which
is
a
nearest
neighbor
library
used
by
codesurchnet.
I
wasn't
expecting
a
good
result
on
the
challenge,
since
I
wasn't
doing
anything
special,
but
it
turned
out.
I
was
at
the
top
of
the
leaderboard,
almost
doubling
the
previous
best
evaluation
score.
I
This
puzzled
me
and
the
organizers
as
well,
so
I
did
some
digging
since
I
re-implemented
the
models
twice
once
in
keras
and
once
in
pi
torch,
I
was
fairly
confident
that
my
models
were
close
enough
to
the
baseline
models.
The
only
thing
different
in
my
pipeline
was
the
evaluation
I
swapped
out
the
sidekick
version
I
had
been
using
for
searching
with
the
floyd
index
and
my
score
instantly
dropped.
I
It
turned
out
the
baseline
code,
search
at
the
variation
code,
didn't
update
the
size
of
the
annoying
index
and
the
final
search
index
was
too
small
to
capture
the
necessary
information
that
meant
it
was
returning
terrible
results.
So
the
lesson
is
always
benchmark
the
index
size
if
you're
using
only
index
and
don't
be
afraid
to
reinvent
the
wheel.
You
just
might
find
yourself
giving
a
talk
at
github
universe
a
couple
of
months
later,
and
that
will
be
all
from
me.
Thank
you.
E
Awesome,
thank
you
very
much.
I
really
enjoyed
that.
So
thank
you.
So
we've
got
a
few
questions
coming
in.
Remember,
hamel
and
rock
will
be
in
discussions
for
the
next
30
minutes
to
continue
answering
your
questions
at
githubuniverse.com
forward,
slash
discussions,
but
before
we
do
that,
let's
just
go
through
some
of
these
that
are
coming
in
from
the
audience.
E
If
that's
okay,
folks,
so
a
first
one
is
around
it's
actually
around
machine
learning
in
general,
there's
quite
a
few
questions
from
sort
of
lots
of
different
people
about
getting
started
with
machine
learning
and
like
pie,
torch,
and
things
like
that.
So
you
know
it's
obviously
data
science,
you
know,
and
machine
learning
are
two
of
the
really
hot
topics
right
now.
If
people
are
looking
to
get
into
machine
learning,
where's
a
where's,
a
good
place
for
them
to
start
so
hamill
we'll
go
to
you.
First.
H
Yeah
my
number
one
recommendation
for
this,
for
that
is
to
look
at
some
website
called
fast.ai
or
fastai
github,
actually
partners
with
fastai
on
a
couple
of
different
things
and
it's
a
it's
a
great
resource.
It's
a
non-profit
that
focuses
on
education
of
machine
learning,
and
it's
it's
really
the
best
one,
the
one
that
I
would
recommend.
I
Yeah,
I
would
have
to
agree
with
hamill
here.
I
really
when
I
started
with
pytorch
and
neural
networks
in
general,
fast,
ai
tutorials
were
really
kind
of
the
best
ones.
That
kind
of
really
illuminated
neural
networks.
For
me,
so
yeah,
that's
a
great
place
to
start.
D
That's
awesome,
so
y'all
heard
it
there
there's
two
there's
a
really
great
resource
for
you
to
go
check
out
if
you
are
learning
how
to
get
into
it.
So
we
have
another
question
for
you:
people
want
to
know
how
can
machine
learning
improve
programmer
productivity
beyond
code
search?
What
are
some
other
applicable
ways
that
we
can
utilize
this
this
type
of
technology?
H
Yeah,
so
there's
a
lot
of
applications
not
only
for
search,
but
things
like
helping
you
write
documentation
more
effectively
or
even
you
know,
even
helping
you
write
tests
all
the
way
to
you
know,
detecting
duplicate
issues,
things
that
help
maintainers
help,
reduce
maintainer,
toil
and
help
open
source
generally
and
there's
a
lot
of
areas
any
anytime.
You're
writing
something
or
doing
anything
repetitive,
which
happens
a
lot
in
programming.
D
What
about
you
rock?
What
are
some
of
the
tools
that
you
know
you
utilize
to
help
your
productivity
or
maybe.
D
Love
the
call
out
on
docs
and
like
it's
so
true
like
the
repeatable
stuff,
should
be
done
by
the
robots,
but
you
know
that's,
I
think,
a
universal
opinion
there
rock.
What
do
you
think.
I
Yeah,
I
would
have
to
agree
because
I
think,
like
I
mentioned,
the
duplicate
stuff
should
really
become
much
more
automated.
So
if
I'm
writing
a
piece
of
code
that
already
exists
somewhere
in
the
code
base,
I
would
like
to
reuse
it.
Instead
of
writing
my
own
thing
and
kind
of
have
a
universal
code
across
the
entire
code
base
which
I
could
use.
So
I
think
that
would
be
the
main
thing
that
I
kind
of
wish
that
would
exist
because
you
know
then,
of
course,
right
back
to
code
search.
I
E
That's
fantastic
and
yeah:
that's
actually
a
great
teaser
for
the
next
session.
We've
got
coming
up
around
code,
reuse
and
things
like
this
and
doing
in
the
source.
So
I
think
what
we'll
do
is
we'll
we'll
let
you
get
on
into
discussion
so
remember,
haml
and
rock
are
going
to
be
in
discussions
for
the
next
30
minutes
over
at
githubuniverse.com
forward,
slash
discussions
but
we'll
let
you
head
on
over
there
now.
So
thank
you
very
much
come
on
rock.
Take
care,
bye.
J
A
K
D
Past
present
and
future
of
technology
and
public
health,
how
the
who
uses
tech
on
the
play
program,
which
I
heard
is
was
like
super
awesome
that
last
one
so
go
check
that
out.
We
have
poetic
computation,
but
up
next
on
the
enterprise
channel,
I
I
am
so
into
it.
That's
right
we
got
into
it.
Do
you
think
they
get
that?
I
bet
they
get
that
all
the
time,
because
you
know
it's
just
fun
to
say
I
know
martin
is
into
it
as
well,
because
he
is
into
intersourcing
and
looking
forward
to
this
one.
D
D
L
L
Thanks
rocio,
let's
just
just
jump
right
in
I'm,
not
going
to
say,
let's
jump
into
it,
but
let's
go
ahead
and
jump
right
in
now.
What
if
engineers
worked
as
a
community
as
code
stewards
and
not
code
owners?
Mark
earls
the
author
of
the
book,
titled
heard
cited
a
study
in
new
york
between
two
high
school
students,
two
high
school
schools
that
are
close
in
proximity
to
each
other,
but
also
have
similar
socioeconomic
conditions.
The
thing
that's
different
about
them,
though,
is
that
the
test
scores
between
the
two
schools
were
so
different,
especially
in
math.
L
One
of
the
schools
had
really
high
test
scores,
and
so
they
looked
into
why
and
what
they
found
was
the
school.
With
the
higher
math
test
scores.
They
found
that
the
students
worked
on
homework
together
and
studied
for
their
tests.
Together,
they
created
a
community
where
each
member
was
both
teacher
and
student
and
where
each
felt
supported
and
worked
towards
a
common
goal.
L
But
what
if
we
can
imagine
a
world
where
we
work
as
engineers
in
communities
of
practice,
have
almost
no
meetings
and
are
code
stewards?
We
would
probably
hear
something
like
this.
On
my
first
day,
I
was
up
and
running
and
ready
to
code
before
lunch.
Each
team
really
understands
the
customer
that
they're
solving
for
and
the
problem
our
team
gets
to
own
our
own
mission
make
decisions
and
solve
for
that
customer.
We
get
to
see
the
difference
that
we
make,
and
I
know
I
can
make
that
big
impact,
and
so
that
feels
really
great.
L
L
If
it
is
man,
we'd
love
to
connect
with
you
and
learn
from
you
now,
we
do
want
to
reach
that
nirvana
and
we
are
at
into
it
in
a
journey
to
get
there,
but
today
to
get
there
does
have
some
challenges
at
intuit
we
have
six
big
groups
across
multiple
continents
and
multiple
time
zones,
engineers
and
other
technologists
focus
on
delivering
solutions
declared
as
priorities
by
their
groups.
We
have
aggressive
schedules
to
deliver,
features,
fixes
and
products
to
millions
of
customers
and
speed.
Yes,
it's
a
necessity,
but
man
to
get
there.
L
There
are
some
challenges,
so
I'm
going
to
name
four
of
them
right
now.
Let
me
just
build
this,
so
the
first
is
in
order
to
for
us
to
enable
work
effectively
right
now
we
are
still
in
this
journey
to
move
from
where
code
is
owned,
by
teams
and
and
individuals
to
to
to
more
and
we'll
talk
more
about
the
solution,
but
today
so
many
of
our.
So
much
of
our
code
is
still
owned
by
individual
and
so
there's
a
heavy
reliance
on
these
folks.
L
To
actually
you
know,
do
everything
from
you
know
answer
questions
you
may
have
on
that
repo
to
you
know
allowing
or
to
doing
reviews
on
your
pr
now
the
waiting
that
is
involved
with
that,
especially
when
you
have
you
know
when
you
have
disparate
locations
across
the
globe,
can
get
in
the
way
of
really
being
speedy.
In
terms
of
you
know,
committing
your
code
and
that
actually
sometimes
leads
to
heroics
for
our
engineers.
L
L
And
finally,
even
though
you
may
tell
me
that
you
have
that
you're
adhering
to
standards,
we
found
that
standards
actually
varied
across
the
various
organizations
and
teams
and
so
onboarding
to
a
project
or
to
that
repo
really
was
hard
because
you
had
to
keep
learning
new
rules.
If
you
will
so
how
did
we
solve
it?
L
M
Thank
you
alisa.
So,
yes,
we
implemented
a
solution
that
included
an
inner
source
model.
Inner
source
takes
the
principles
of
open
source
into
the
enterprise
environment
in
resource.
It's
a
great
tool
to
help
break
silos,
encourage
internal
collaboration,
accelerate
new
engineering
onboarding
and
identify
opportunities
to
even
contribute
back
to
open
source.
So
let's
talk
about
what
our
inner
source
program
included.
M
When
we
first
started
to
look
at
inner
source,
we
discovered
that
many
business
units
and
team
were
already
practicing
some
form
of
inner
source.
The
logical
first
step,
then,
was
to
declare
a
set
of
unified
guidelines
that
outline
the
one
way
that
intuit
engineers
could
use
to
contribute
to
any
repositories
in
our
intuit
ecosystem.
M
These
unified
guidelines
included
a
document
structure
that
every
repository
should
have
in
order
to
be
inner
source.
Ready.
Github
will
automatically
recognize
these
files
and
enhance
a
collaboration.
Experience
for
engineers
documents
like
code
owners
to
quickly
get
those
prs,
a
line
assigned
to
a
code,
reviewer
a
contributing.md,
to
detail
the
rules
of
engagement
with
each
repository
and
the
pull
request
template
that
gives
every
contributor
a
checklist
to
complete
before
submitting
a
pr.
This
proven
to
be
really
helpful
in
the
contribution
process.
M
Additionally,
we
required
having
continuous
integration
and
continuous
deployment
automation
on
each
of
the
prs
completed
with
unit
and
functional
tests.
That
was
definitely
a
must.
These
pr
automations
gave
contributors
quick
and
useful
feedback
about
the
pr
and
the
code
that
they
are
trying
to
merge
on
the
next
slide.
We're
going
to
show
you
that
technology
changes
were
not
enough.
We
actually
needed
to
set
up
our
teams
for
success
in
this
new
world,
so
we
actually
needed
to
think
that
inner
source
is
more
of
a
mindset
change
rather
than
a
technological
approach.
M
We
needed
our
teams
to
understand
that
internal
engineers
were
now
a
first-class
customer,
and
that
would
practice
trial
and
error.
There
were
going
to
be
that
these
frequent
contributors
that
we're
going
to
become
a
trusted
committer,
it's
a
new
role
for
us,
a
role
with
defined
responsibilities,
to
ease
and
optimize
contributions
from
frequent
teens.
M
Now,
please
go
back
one
elisa.
M
One
more
sorry:
there
we
go
at
the
heart
of
inner
source.
There
are
the
code
reviews
we
implemented
training
for
new
engineers
and
existing
engineers
that
teach
them
techniques
to
foster
a
healthy
contribution
environment.
When
doing
code
reviews,
we
actually
think
that
each
pr
is
an
opportunity
for
mentorship.
It
was
also
very
important
to
get
teams
to
agree
to
their
slas
for
code
reviews,
release
and
support
and,
of
course,
publish
them
in
their
contributing.md
on
the
next
slide.
M
Additionally,
we
looked
for
services
that
were
the
most
common
and
already
had
a
big
number
of
contributors,
so
we
prioritized
these
repos
and
getting
them
in
their
source.
Ranking,
of
course,
we
needed
to
establish
a
rewards
and
recognition
program.
We're
going
to
talk
about
more
on
that
later,
but
rewarding
early
adopters
was
really
important.
M
So
have
I
sold
you
on
getting
intersource
implemented
in
your
company?
This
would
be
the
steps
that
you
need
to
take
in
order
to
do
so,
you
will
for
sure
need
leader
support
in
order
to
provide
you
know,
time
for
training
of
their
engineers,
time
for
their
engineers
to
adopt
engineer
guidelines
and
make
the
technology
changes
and,
like
I
mentioned
before,
you
need
to
create
a
set
of
unified
guidelines,
also
identified
your
model
teams.
M
These
themes
that
are
going
to
be
like
I
mentioned
foundational
capabilities
in
each
of
the
business
units
that
you
have
conduct
workshops
to
teach
how
to
do
in
your
source.
We
actually
had
workshops
at
each
intuit
site
and
every
chance
we
got
every
conference
every
event
there.
We
were
inner
source
rara.
So
it's.
M
M
You
need,
of
course,
engineers
and
a
product
manager
make
sure
that
you
have
diversity
under
volunteers
from
staff
level
to
early
career
team
members,
and
you
need
to
make
sure
that
they
actually
can
tell
a
story
and
can
do
it
well.
You
will
need
to
implement
dashboards
and
metrics
in
order
to
share
the
progress
and
track
the
readiness
of
the
repos,
as
well
as
the
ability
to
find
those
most
popular
repos,
and
the
foundational
capabilities,
tooling
and
rewards
proved
to
be
very
useful
in
getting
everyone
excited
about
inner
source.
M
We
recognize
that
all
the
benefits
when
we
talked
about
the
benefits
of
inner
source,
we
were
only
talking
about
the
benefits
to
the
business
right,
prioritization
ease
of
releasing
to
our
customers
more
quickly,
more
features.
But
when
we
wanted
to
focus
on
the
engineer,
the
benefits
were
that
they
were
able
to
collaborate
in
different
teams
and
collaborate
in
different
programming
languages
that
they
usually
do
on
their
teams.
So.
M
Time
contribution
site
on
the
previous
slide
outlined
projects
that
were
actively
looking
for
contributors.
These
projects
signed
up
to
the
site
and
said
here
are
some
of
the
issues
that
we
have
and
they
could
be
on
jira
or
on
github,
and
they
were
good
first
issues
that
anybody
could
jump
on
and
solve
them.
We
also
added
an
inner
source
batch
to
our
internet
for
those
who
have
onboarded
to
inner
source
and
were
participating
in
the
program.
This
is
kind
of
like
a
batch
of
one
now
back
to
alisa.
L
We
also
wanted
to
let
you
know
that
many
engineers
told
us
that
by
allowing
us
allowing
engineers
to
contribute
to
other
repos,
they
were
actually
investing
in
their
craft
and
that
they
were
learning
new
skills
and,
in
addition
to
the
engineers
there
were
other
stakeholders
that
really
do
benefit
the
other
one
is
our
internal
and
external
customers,
and
our
customers
definitely
said
that
wow,
the
the
the
products,
not
only
are
they
delightful,
but
when
there's
a
problem
you
get
that
fix
out
right
away
now
for
the
business
rosio
did
mention
the
business
earlier
for
the
business.
L
Not
only
was
there
speed
and
delivering
solutions
and
and
products
to
customers,
but
there
was
definitely
higher
engagement
from
our
engineers
or
from
product
development
teams,
and
we
believe
that
that
and
we're
starting
to
see.
You
know
some
data
on
this,
but
we
believe
that
higher
engagement
leads
to
higher
higher
retention
of
top
tech
talent,
and
this
is
our
final
slide.
We
are
we'd
love
to
share
with
you,
the
resources
that
you
know
might
also
inspire.
L
You
to
take
on
this
model
or
maybe
enhance
the
model
you
currently
have
on
your
inner
source
model
in
your
company.
The
first
is
the
book
that
I
mentioned
called
heard
by
mark
earls,
and
this
is
all
about.
How
do
you
tap
into
the
social
nature
of
beings,
including
human
beings,
in
order
to
actually
create
a
movement
in
order
to
actually
create
change?
The
second
is
inner
source
commons.
We
took
a
lot
of
inspiration
from
the
learnings
and
best
practices
that
they
shared.
L
We
also
wanted
to
make
sure
I
know
rocio
kind
of
touched
on
it,
but
fun
has
to
be
in
a
lot
of
the
things
that
you
do.
I
mean
rosia
talked
about
how
we
went
to
different
sites
and
did
the
rah-rah,
but
we
have
to
infuse
fun
and
we
loved
how.
When
we
looked
at
made
with
code,
they
had
a
section
under
community
and
we
love
some
of
their
ideas.
There
we've
definitely
adopted
those.
And
finally,
this
is
all
about
change
management.
L
Rocio
mentioned
it
that
yes,
tech
is
there,
but
so
much
of
it
is
mindset,
and
so
much
of
it
is
definitely
about
community,
and
so
we
recommend
this
book
by
the
heath
brothers
called
switch.
How
to
change
things
when
change
is
hard,
and
you
probably
you
know,
based
on
what
you've
heard,
you
probably
probably
heard
the
three
parts
to
that
book,
which
is
the
writer
the
visionary,
the
elephant,
which
is
the
emotional
impact
or
the
emotional
you
know
embodiment
of
what
you're
trying
to
do.
L
D
Also
did
a
panel
discussion
recently
talking
about
women
leading
open
source
and
you
two
are
just
real
life
examples
of
the
future
of
the
community
and
I'm
sorry,
I'm
fan
momming
a
little
bit
on
y'all
too.
That's
just
so
inspiring
it
was
it
was
I
mean,
I'm
a
huge
proponent.
I
think
that,
like
when
you're
thinking
about
the
size
of
a
company
like
intuit
and
starting
a
grassroots
roots
effort
with
just
the
two
awesome
people
saying
like
this
will
make
us
better
and
not
just
you
know
in
a
way
to
produce
amazing
code.
D
D
Talked
a
little
bit
about
how
y'all
y'all
did
this
code
review
training?
How
did
you
you
know?
How
did
you
get
buy-in
to
take
people
away
from
building
features
to
say?
Listen
if
we
give
this
people
training
and
we
look
at
our
code
reviews
through
this
new
lens.
You
know
we'll
be
better
on
the
other
side,
because
I
know
people
always
get
nervous
and
they're
like
oh,
my
gosh
you're
doing
this
and
not
shipping
shipping
code
right.
D
L
Sure
I
I
want
to
just
let
you
know
that
when
we
say
training
it
is
still
ongoing
and
the
the
thing
that
it
that
we
need
that
we
need
to
make
sure
that
you
know
is
that
any
movement
takes
support
from
high
up.
It
also
takes
support
from
you,
know
the
front
lines,
and
so,
when
you're
talking
about
the
training,
we
are
embedding
it
from
the
moment
that
you
started
into
it.
It
is
part
of
our
onboarding
program
called
dev
at
intuit
for
engineers.
L
We
also
do
it
as
workshops
for
women
in
tech.
We
do
it
in
various
workshops.
You
know
as
part
of
inner
source
and
open
source,
but
it
is
in
everything
that
we
do
and
let
me
tell
you
one
of
the
things
that
the
people
don't
realize
is
that
our
chief
architect
into
the
chief
architect
who's
our
boss,
alex
bellage.
L
You
know
he
co-wrote
a
paper
with
all
of
the
leaders,
including
our
cto
mariana
tessel,
and
that
paper
was
about
the
vision
of
intuit
engineering
culture,
and
that
is
still
our
vision
and
our
road
map,
and
we
actually
took
that
inspiration
and
we
created
a
team.
And
yes,
it
started
with
me
and
rocio.
We
are
now
up
to
ursa.
Are
we
eight
now
we
are
now
up
to
eight
people
yeah,
but.
J
L
It
was
it
took
it
took
some.
There
was
definitely
some
swag
that
we
had
to
deliver.
There
was
some
swag,
but
also
the
fact
that
we
did
these
things
called
beautiful
code
tours.
We,
we
actually
branded
everything
and
there
was
so
much
excitement
in
the
community
and
rocio,
and
I
have
gone
everywhere
from
london
to
india,
to
you,
know
all
parts
of
like
the
world
to
canada.
L
M
Yeah
for
them
for
the
code
review
training,
it
was
really
important
for
us
to
teach
engineers
that
they
needed
to
be
open
and
create
a
healthy
environment
right,
because
one
of
the
things
about
open
source
is
that
you
know
that
barrier
of
being
scared
of
what
they're,
gonna
think
about
my
code.
M
You
know
the
outline
for
these
code
reviews
and
shares
techniques
and
has
his
own,
like
slang,
slang
terms
to
say
this
is
how
you
do
code
reviews.
You
have
to
create
your
priorities:
don't
slam
everybody,
you
don't
slam
your
contributor
with
the
20
issues
that
you're
seeing
you
know
do
one
by
one
and
all
these
techniques
that
were
really
useful,
and
you
know
we
teach
every
newcomer
existing
engineers,
and
we
say
this
is
how
we
do
code
reviews
and
add
into
it.
E
That's
fantastic:
have
you
ever
thought
about
sharing
some
of
that
code
review
guidance
externally
as
well,
because
I
know
you
know
as
a
maintainer
of
open
source
projects
teaching
other
people
how
to
do
that.
Sort
of
thing
is
hard
and
there's
this
huge
there's,
a
huge
emotional
kind
of
thing
you've
got
to
get
over
when
you
start
sharing.
You
know,
imposter
syndrome
comes
up
big
time
and
you
think
I
can't
share
my
code
with
anybody.
E
You
know,
and
it's
and
sort
of
the
conversation
I
would
have
with
them
was
you
know,
especially
because
I
used
to
work
at
microsoft
before
I
came
over
to
github
and
quite
often
you'll
be
talking
to
teams
and
they
wouldn't
want
to
share
code
around
the
organization
and
you
still
dig
into
them.
E
E
Code
comments
and
then
you
want
to
fix
all
these
things
and
refactor
it
and
whatever,
but
it's
good
enough
like
share
it
first
and
help
the
community
come
with
you
on
that
journey
as
you
improve
it.
So
how
do?
How
do
you
get
people
over
that,
like
that
emotional
hurdle
to
to
help
them
share?
Is
it
just
through
positive
incentives,
or
what
do
you
do?
What
how
do
you
encourage
them.
M
It's
definitely
positive
in
sentence
and
by
highlighting
the
highlighting
the
good
practices.
Usually
we
we
used
to
highlight
the
people
that
did
the
heroics
right.
That
turned
something
bad
into
good,
but
now
we're
trying
to
highlight
engineers
that
are
doing
good
since
the
start,
that
are
great
leaders
and
that
showcase
that
a
healthy
contribution
environment,
it's
rewarded.
So
we
have
newsletters,
we
have
a
slack
channel
and
whenever
we
see
these
leaders
that
are
welcoming
and
accepting
and
open
to
these
new
contributions,
we
highlight.
F
M
L
I
think
it's
also
really
important
something
rosie
mentioned
around
influencers.
We
did
take
steps
to
start
and
by
the
way,
we
that
was
an
inspiration
that
we
took
from
the
fashion
industry.
To
be
honest,
in
terms
of
influencers,
we
saw
that
being
able
to
you
know,
start
looking
for
those
that
are
going
to
be
our
fans
that
are
going
to
be
supporting
us,
but
people
are
able
to
go
gosh,
I'm
a
software
engineer,
level
2
and
that's
a
software
engineer
level.
2
who's
also
doing
this.
L
I
can
do
that
and
so
being
able
to
see
yourself.
You
know
in
you
know
with
others
that
may
be
the
same
level
as
you
does
remove.
Some
of
that,
like
you
said
a
little
bit
of
that
terror
of,
is
my
code
going
to
be
good
enough?
Is
my
contribution
going
to
be
accepted,
and
so
I
think,
being
able
to
really
leverage
the
community,
something
that
I
do
want
to?
Let
everyone
know
this
isn't
just
about.
I
think
in
any
kind
of
change
management,
you've
got
to
figure
out.
L
How
do
you
create
community
that,
as
rocio
says,
like
supports
one
another,
but
also
teaches
one
another
and
is
open
to
in
a
way
failing
and
learning,
and
so
that's
another
thing
that-
and
I
know
rocio
mentioned
it
but
being
having
a
safe
open
environment
is
so
important
because
we
know
we're
all
learning
our
way
through
this
too,
and
I
feel
like
rocio,
and
I
are
constantly
learning
about
things
that
we
didn't
know
about.
You
know,
hurdles
or
challenges
and
so
we're
having
to
adopt
constantly
well,
okay.
L
D
F
D
C
D
Right
but
the
reward
and
the
fulfillment
of
like
seeing
the
people
around
you
go
on
to
do
great
things,
and
I
think
that
you
know
when
you
bring
those
principal
engineers.
It's
not
always
like
the
hard
deep
technical
code,
but
the
force
multiplication
that
you
can
do
by
bringing
in
that
kindness
and
that
culture
and
lowering
that.
D
D
Did
I
do,
and
I
just
think
that,
like
like
y'all
said
it
best
like
starting
with
good
incentivization
like
telling
people
that
you're
going
to
be
rewarded
through
helping
others,
and
then
you
know
making.
D
D
Taste
come
taste,
my
cheese
platter
and
I
just
love
what
y'all
are
doing
there
and
sharing
these
lessons,
because
applying
what
open
source
community
has
done
and
that
workflow
is
really
what
it's
about
right
collaboration.
So
I
got
one
question
I'll
put
yabbing,
I
love
y'all.
Y'all
are
awesome.
So
what
was
if
you
could
I'll
throw
it
to
one
of
you
rocio?
What
was
your
biggest
lesson
learned
in
this
journey
and
and
and
if
you
could
do
something
over
again,
what
would
you
do.
M
The
biggest
lesson
learned
was
that
for
the
younger
engineers,
inner
source
was
a
done
deal.
They
were
like
you.
Do
you
really
need
the
teaching
resource?
This
should
be
how
it
works
like.
If
I
need
a
change
on
another
repository,
I'm
good
enough.
I
know
how
to
run
a
repository.
A
M
And
do
it
the
harder
part
was
to
get
you
know,
senior
level,
staff
level
and
even
managers
in
the
mindset
of
inner
source,
and
obviously
that
comes
because
okay,
we
now
need
to
think
about
supportability.
We
now
need
to
think
about
the
bugs
that
might
come
up
in
production.
We
now
need
to
think
about
this
external
contributor
going
on
vacation
and
now
I'm
stuck
with
with
with
an
issue
right.
So
for
me
that
was
you
know
a
super
interesting
light
bulb
that
definitely
help
us
leverage.
M
M
I
wish
that
you
know,
and
and
again
it
was
just
a
lisa
and
I
I
wish
I
could
have
like
duplicated
myself
to
create
the
dashboard
and
also
do
all
the
all
the
processes
and
investigations
and
research,
but
now
that
we
have
it,
I
I
wish
we
have
had
it
earlier.
L
Yeah
for
me
for
me,
I
wish
that
we
would
have
started
from
the
get-go,
including
product
managers
in
the
in
our
roadshows.
We
definitely
focused
because
we
come
from
engineering
focused
on
you
know:
dev
managers,
architects
and
the
frontline
engineers
and
really,
as
as
key
partners
to
this,
we
really
needed
to
bring
product
managers
from
the
get-go.
I
mean
we
figured
it
out
right
racial.
L
I
would
say
on
our
third
trip
in
another
location,
we're
like
we
should
be,
we
should
probably
have
product
managers
and
so
because
they
really
needed
to
understand
the
benefits,
and
I
think
it
was
such
a
black
box
to
many
of
them
like.
Why
would
we
do
this,
and
why
would
we
take
time
for
this?
And
so
I
I
would
say
that's
the
one
thing
that
I
would
say
we
could
have
done,
and
then
I
do
a
plus
one
on
on
the
dashboarding.
L
I
do
think
that
we
needed
to
the
thing
that
we
should
have
added
was
be
really
strong
around.
If
you
will
your
okrs,
what
was
the
key
results
at
the
end,
I
know
we
focused
first
on
foundational
capabilities
first
for
inner
sourcing,
but
it
would,
I
think
we
could
have
been
stronger
in
the
state
that
we
put
in
the
ground
around.
What
does
success
really
look
like.
D
E
That
was
a
really
inspiring
day.
I
really
really
enjoyed
that
one
thanks,
so
yeah
we've
got
the
dev
chat,
the
university
channel
and
the
play
channel,
which
is
just
for
fun
but
you're
in
the
enterprise
channel
and
we're
putting
the
entertainment
in
enterprise
today
feel
free
to
pop
in
and
out
of
the
other
channels.
If
you
want
you're
not
going
to
want
to
miss
this
next
session,
I
promise
you
happening
now
on
the
dev
channel
is
an
excellent.
Actually
to
be
honest,
you
might
want
to
go
watch
the
replay
of
this
one.
E
It's
a
great
panel
discussion
building
your
community.
We
have
github
discussions
and
it's
got
our
very
own
divine
ops
joined
by
one
of
our
kids
stars,
actually
gina
hausger
as
well.
So
it
should
be
a
really
good
panel
discussion
and
then
over
in
the
play
channel.
We've
got
the
future
of
web
in
an
xr
world,
but
yeah
I'm
gonna
introduce
the
next
session
actually
because
dana's
a
little
bit
of
a
little
bit
of
a
stand
when
it
comes
to
our
next
guest.
E
But
it's
my
pleasure,
my
absolute
pleasure
to
introduce
dr
nicole
forsman
she's,
going
to
be
joining
us
to
talk
about
getting
better
together.
If
you
don't
know,
nicole
she's
the
vp
of
research
and
strategy
here
at
github,
she
wrote
an
amazing
multi-award-winning
book
called
accelerate
the
science
of
lean
software
and
devops.
If
you
haven't
read
that
book
and
you're
into
the
discussions
you've
been
hearing
today
and
yesterday
on
this
channel,
then
you
definitely
want
to
get
that
book.
I
know
it
was
recommended
pretty
heavily
yesterday.
E
Actually
so,
hopefully
you
already
got
it
by
now
remember
to
engage
on
discussions.
If
you
head
on
over
to
githubuniverse.com
forward,
slash
discussions,
everybody's
there
answering
questions
and
there's
a
load
of
people
from
the
research
team
that
nicole
works
with
actually
in
the
discussions
ready
to
answer
your
questions
and
also
don't
forget
to
rate
this
session
very
highly.
If
you
go
and
click
on
the
button
in
the
bottom
of
your
screen,
you'll
see
a
little
rate
session
there.
E
We
really
value
your
feedback
so
find
that
your
little
yellow
star
to
join
the
next
to
join
the
discussion
on
the
bottom
of
the
page.
Okay
without
further
ado,
let's
start
the
talk
with
nicole
on
getting
better
together
what
enterprises
can
learn
from
a
global
patterns.
Take
it
away.
K
Hi
everyone
thanks
for
joining
me.
I
am
here
to
talk
all
about
really
some
of
the
latest
research.
I
don't
know
if
you've
heard
I
like
research,
I
like
strategy.
I
really
like
data.
Why?
Because
it
helps
us
get
better.
So
I
do
research
and
strategy
here
at
github
in
a
previous
life.
Back
in
the
day,
I
was
actually
writing
mainframe
programs,
so
it
feels
appropriate
that
I'm
here
hanging
on
the
enterprise
channel
that
I
was
a
software
developer.
I
was
an
engineer.
I
was
building
systems.
I
was
supporting
them.
K
I
was
assist
admin
and
then
I
decided
to
go.
Do
some
research?
I
was
lead
investigator
on
the
state
of
devops
reports
for
years,
but
the
accelerate
some
of
you
may
have
heard
of
it.
A
lot
of
that
work
was
based
on
helping
us
understand
some
of
the
core
principles,
capabilities
practices
and
processes
to
help
companies
of
all
sizes
understand
how
we
can
help
build
and
develop
software
for
high
performance
so
that
we
can
really
do
things
that
are
dope.
So
what
have
I
been
up
to
lately?
I
just
joined
github
earlier
this
year.
K
Well,
we
just
released
the
state
of
october's
report
last
week.
It
was
a
birthday
present
to
myself
and
everyone
else.
We
took
a
slightly
different
approach
this
year,
so
in
addition
to
sharing
with
the
world
how
github
has
grown
and
changed,
we
also
did
some
deep
dives.
So
if
you
go
to
the
website,
octoverse.github.com
you'll
see
a
little
button.
That
says
download
three
reports.
Now
you
don't
have
to.
I
was
also
a
professor,
so
I'm
not
going
to
assign
some
homework,
but
you
may
find
them
really
interesting,
because
the
site
will
walk
you
through.
K
K
K
K
K
K
These
four
time
zones
for
development
activity
include
the
uk
time
zone,
u.s
eastern
time
zone,
u.s,
pacific
time
zone
and
japan
standard
time
zone.
Now
we
selected
these
because
we
have
some
some
strong
data
in
these,
so
they
won't
be
overly
influenced
by
any.
You
know,
significant
standout
organizations
and
these
these
time
zones
also
had
some
pretty
strong
shelter
in
place
orders
now
the
one
I'm
displaying
here
is
uk
time
zone.
K
There
are
a
couple
things
to
notice
here,
as
you
take
a
look
at
this
chart.
That
line
where
everything's
kind
of
centered
is
our
zero.
So
if
we
hadn't
seen
any
changes
in
activity
noticeably
compared
to
the
prior
year,
everything
could
kind
of
be
hanging
along
there.
K
Here's
what
we
take
a
look
at
first,
we
worked
longer
take
a
look
at
those
purple
bars
as
we
kind
of
chug
along
up
until
shelter
and
place
orders.
We
see
a
strong
covet
effect
as
we
compare
the
time
difference
between
our
first
and
last
get
push
to
the
main
branch
in
any
repository
that
we're
working
in,
we
see
a
strong
increase
right.
People
are
working
longer
hours.
K
Now
I
will
say
a
little
bit
of
this
is
expected
right,
because
once
people
start
working
from
home
even
before
covet,
we
tend
to
work
a
little
bit
longer
hours
because
we
lose
this
boundary
between
work
and
life,
but
we
see
this
gross
for
a
while
until
maybe
people
are
getting
used
to
it
a
little
bit
right.
Maybe
we
start
adjusting.
Maybe
we
get
a
little
bit
better
at
creating
boundaries.
Maybe
we
create
a
commute
right?
Maybe
we
take
a
lap
around
the
block
to
kind
of
separate
work
and
home.
K
So
then
our
next
question
is
well.
Are
we
spreading
out
work
or
are
we
actually
doing
more
work?
That's
the
green
line
you
see
is
is
how
much
work
are
we
doing
for
this?
We
proxied
it
with
the
number
of
pushes
that
we're
doing
per
day
per
day.
So
here
we
kind
of
see
that
kind
of
jog,
along
that
zero
line.
K
Until
we
initially
see
shelter
and
place,
orders
go
into
effect
and
it
kind
of
takes
a
dip
as
we're
suddenly
adjusting
to
uncertainty
and
change,
and
so
many
things
are
happening,
kind
of
comes
even
and
then
it
jumps.
Quite
a
bit,
so
it's
interesting
because
overall
and
we
see
this
fairly
consistently
across
the
time
zones,
many
people
are
both
working
longer
hours
and
getting
more
done.
K
K
K
Some
of
us
played
video
games.
Some
of
us
turned
to
open
source
to
learn,
create
turn
to
our
community.
It's
kind
of
exciting,
because
there's
so
much
for
us
to
do.
But
then
then
we
step
back
and
we're
like
wait.
There
are
only
so
many
hours
a
day.
How
are
we
working
more
and
on
open
source
more
so
we
took
a
look
by
day
of
the
week.
K
Here's
what
we
saw
now
we
are
working
more.
These
are
kind
of
light
out,
but
laid
out
by
days
of
the
week,
starting
with
monday
we're
working
as
much
on
saturdays
and
sundays,
as
we
are
on
mondays.
K
Take
from
that
what
you
will,
but
we're
working
more
on
tuesdays,
wednesdays,
thursdays,
fridays
spend
development
time
we
step
down
that
work
on
saturdays
and
sundays,
and
look
what
happens
to
open
source.
So
the
bars
are
the
are
work,
work
days,
work
hours,
open,
source
kind
of
chugs
along
and
it
jumps
up
on
the
weekends
we're
creating
time
for
open
source.
This
is
a
great
opportunity
for
us
to
disconnect
reach
out
pair
with
our
community.
K
K
K
Flexibility
is
key
here
and
one
tip
we
can
say
to
anyone
here:
managers
developers,
one
of
the
big
tips
that
we
see
resonate
with
many
many
people-
is
that
it's
important
to
manage
your
energy,
not
just
manage
your
time.
Some
people
are
finding
great
success
by
focusing
in
the
mornings
or
by
focusing
late
at
night.
K
K
So
look
at
the
impact
of
automating
just
one
aspect
of
your
workflow:
it
helps
reduce,
toil
work.
It
helps
reduce
manual
work,
the
things
that
are
important
to
do,
but
we
may
not
love
doing
it
frees
up
time
to
do
the
things
that
we
love.
It
improves
our
developer
experience
it
kind
of
greases
the
wheels
for
the
rest
of
what's
great.
K
Yes,
we
see
amazing
productivity
gains
and
that's
important,
especially
in
a
year
like
this,
but
it's
also
about
making
tech
sustainable
and
if
we
think
back
beyond
march
march
march,
so
many
marches
this
year,
devops
was
kind
of
the
original
hipster
for
building
systems
and
making
tech
more
sustainable.
K
So
speaking
of
communication
and
collaboration,
we
also
saw
this
happen
at
scale.
As
we
look
again,
it's
so
interesting
right.
We
see
this
covet
effect
appear
so
many
places
as
we
kind
of
chug
along
the
air
by
the
way
that
that
quick
jump
on
the
left
is
thanksgiving
holiday.
We
saw
a
shift
in
it
across
weeks,
but
as
we
take
a
look
at
pr
merge
times
once
shelter
and
place,
orders
occur
across
all
open
source
repositories.
K
K
K
K
We
really
figured
out
how
to
get
this
done
and
I
think
it's
exciting
and
and
not
just
with
prs,
not
just
core
in
the
code,
but
talking
about
all
of
the
things
that
make
our
projects
and
our
community
great
github,
released
and
announced
discussions
earlier
this
year.
So
we
took
a
look
at
the
next.js
repository
and
how
they
were
using
discussions,
and
it
was
great
to
see
and
kind
of
excited
to
see
how
this
grew
over
time,
and
what
we
found
is
that
it
really
helped
keep
this
community
more
resilient
and
more
sustainable.
K
What
some
of
our
other
analysis
found
is
that
some
of
the
best
ways
to
invite
and
encourage
and
foster
newcomers
to
stick
with
the
community
are
with
issues
the
challenge
with
issues
that
can
burn
out
maintainers.
So
the
exciting
thing
is
that
we
also
found
that
one
of
the
best
ways
to
encourage
newcomers
is
with
discussions.
K
Discussions
is
a
way
to
engage
talk
about.
What's
happening,
learn
new
norms.
Now
some
of
you
may
be
thinking
well,
what
does
this
have
to
do
with
me,
nicole,
this
enterprise
track?
This
is
great
because,
as
we
think
about
scaling
our
solutions
and
scaling
throughout
our
enterprises
think
about
things
like
centers
of
excellence
or
communities
of
practice.
This
helps
make
sure
that
our
expertise
isn't
siloed.
K
K
We
also
looked
at
at
how
open
source
is
used
and
across
all
of
the
package
ecosystems
that
github
supports,
so
many
of
them
most
of
them
over
90,
rely
on
open
source,
and
I
think
that's
so
exciting
and
so
wonderful,
because
there
is
this
amazing
amazing
resource,
that's
available
to
almost
everyone
right.
That's
incredible!
K
We
also
then
took
a
look
to
say
to
ask
ourselves
what
does
that
mean
in
terms
of
dependencies
right,
because
we
also
need
to
be
thinking
about
security.
So
what
does
this
mean
in
terms
of
our
security
posture?
What
we
found
is
that
it's
super
important
to
secure
our
code,
because
any
piece
of
software
can
have
hundreds
and
thousands
of
dependencies,
and
this
chart
here
shows
you
both
direct
dependencies.
K
If
something
that
you
directly
pull
in
a
library
or
file
has
a
dependency
or
if
a
transitive
dependency
or
how
many
transit
dependencies
it
has.
So,
if
anything,
you
know
in
turn
pulls
out
a
file.
What
we
found
is
that
any
piece
of
code
or
any
repo
has
a
59
chance
of
getting
a
security
alert
in
the
next
year
for
those
active
repositories
with
supported
package
ecosystems.
Now,
in
case
you're,
saying
wait.
K
Most
vulnerabilities
are
mistakes
only
17
of
them
are
explicitly
malicious
things
like
backdoor
attacks,
and
they
result
in
only
point
two
percent
of
alerts
in
the
in
the
very
commonly
and
most
used
repos
and
most
use
files.
Eighty-Three
percent
of
of
these
vulnerabilities
are
the
result
of
mistakes.
So
it's
important
to
remember
anyone.
Anyone
can
make
a
mistake
and
anyone
can
insert
a
mistake
into
your
code
base
so
by
leveraging
the
power
of
community.
K
K
So
what
does
this
open
source
vulnerability
timeline?
Look
like.
It
actually
takes
over
four
years,
often
to
find
a
vulnerability.
Once
it's
introduced.
This
seems
kind
of
long.
It's
actually
not
totally
unheard
of
the
only
analysis
that
we
could
see
that
was
similar
to
this
was
from
an
oda
analysis,
which
is
kind
of
like
comparing
apples
and
oranges.
K
But
rand
ran
this
analysis
and
it
was
about
five
five
years
to
identify
vulnerability,
but
once
that
vulnerability
is
identified,
it
takes
the
community
just
over
four
weeks,
almost
four
and
a
half
weeks
to
fix
the
vulnerability
takes
about
10
weeks
to
identify
the
community
and
then
one
week
to
fix.
K
K
We
have
so
many
opportunities
to
to
build
security
in
so
again
we're
leveraging
the
wonderful
things
that
the
security
community
finds
for
us.
We
can
build
in
that
patch
automatically,
and
it
just
happens
now,
I'm
about
out
of
time.
So
let
me
share
just
a
few
more
favorites
that
I
had
in
the
findings.
K
K
This
one
made
me
personally
very
happy,
because
much
of
my
prior
work
shows
that
some
of
the
best
ways
to
get
work
done
is
to
work
in
small
batches,
so
pro
tip
keep
working
in
small
batches.
It
makes
your
releases
faster
and
more
stable
and
it
makes
it
easier
to
be
running
your
pr's
now.
What
else
github
is
the
home
for
more
than
just
developers
in
our
community
report
we
ran
an
analysis
that
went
beyond
just
one
year
in
arrears.
K
K
We
see
people
in
data
like
data
analysts,
there's
there's
a
space
for
so
many
people
here,
managers
leaders,
so
many
people
are
joining
github
and
github
is
a
place
not
just
for
code,
but
it's
a
place
for
so
many
different
file
types.
The
platform
itself
is
maturing
becoming
a
place
for
many
different
types
of
creation.
K
We
also
found
that
the
most
critical
vulnerabilities
are
caught
in
code
review
code
review,
not
just
for
code
and
and
linting
and
tabs
these
faces.
It's
also,
most
importantly,
for
security
and
our
security
vulnerabilities.
Okay,
listen,
there's!
So
much
more.
There
go
check
out
the
report,
go
check
out
the
site
octoverse.github.com.
K
E
Thank
you,
nicole
and
people
certainly
have
been
tweeting
out
a
bunch
of
stuff
about
that
talk,
so
it
was
a
great
session.
Thank
you
very
much.
We've
got
quite
a
few
questions
coming
in
already,
actually
so
we're
just
going
to
dive
straight
into
q
and
a
if
that's,
okay
with
you
got
a
question
here
from
ian
so
ian
I
think,
deserves
some
sort
of
swag
or
something
there
because
he's
been
with
us
all
the
way
through
the
enterprise
track
throughout
the
whole
week.
So
we've.
E
First,
yeah
yeah.
Definitely
I'm
going
to
shawn
a
little
bit
because
you
know
I
know
ian,
I
know
he's.
I
know
he's
he's
dogs
as
well
we've
seen
pictures
as
we
go
so
I've
shot
this
one.
Basically,
what
insane
is
what
were
some
of
the
hypotheses
that
the
team
came
up
with
around
the
people
doing
as
much
or
more
more
work
on
a
sunday
as
on
a
monday,
and
was
there
anything
you
were
able
to?
Actually,
you
know
dig
into
the
in
the
data
around
those
hypotheses.
K
This
is
an
amazing
question,
so
there
are.
There
are
a
few
hypotheses
that
we
are
going
to
be
following
up
on
individually
as
well
as
in
partner
with
some
of
the
team
partnership
with
some
of
the
teams
at
microsoft
research.
So
some
of
these
hypotheses
might
be
that
that
people
are
maybe
catching
up
with
previous
week's
work,
but
but
more
likely
is
that
we're
prepping
for
the
week
to
come,
especially
because
it's
on
a
sunday
right.
So
how
can
I
set
myself
up?
K
K
I
want
to
make
sure
my
my
pr
is
ready
for
my
team
and
so
suddenly
you're
doing
a
few
things,
and
I
think
in
particular
the
reason
that's
similar
to
monday,
because
we
saw
a
big
jump
in
tuesday,
wednesday,
thursday
and
by
the
way
that
jump
is
even
more
drastic
and
pacific
time
zone.
That's
a
side,
but
mondays
we
think,
might
be
slightly
shorter,
because
mondays
are
in
many
cases,
kind
of
a
big
meeting
day
right.
K
D
I
I'll
tell
you
you
know
if
you
want
to
include
me
as
a
part
of
that
research.
Sundays
are
the
day
I
go
in
my
office,
avoid
the
family
and
have
heads
down
like
non-zoom
work
on
video
conferencing.
I'm
sure
a
lot
of
people
are,
like
you
said,
are
using
that
time.
For
me,
it's
it's
like
the
focus
time.
D
I
know
sunday
mornings,
everybody's
sleeping
and
not
bothering
me
because
we're
here,
24
7
right
now,
so
I'm
sure
a
lot
of
other
working
parents
out
there
too
are
using
using
that
time
chunk
to
be
like
I'm
busy
but
it'll,
be
interesting,
interesting
to
see
what
you'll
find
in
some
of
the
the
nuances
there's.
D
We
got
some
more
stuff,
we're
coming
for
you,
so
people
want
to
know
you've
been
doing
this
report
for
a
while,
I
like
to
think
of
it
as
the
holiday
gift
that
dr
nicole
gives
us
every
season,
but
this
year
being
a
very
interesting
one,
as
you
said
or
interesting,
as
martin
would
say
what
was
something
that
was
unexpected,
that
you
found
in
the
data.
Did
you
see
anything
that
you
were
like
whoa?
I?
K
There
were
a
couple
things
you
know,
I
would
say
the
the
covet
effects.
Weren't
super
surprising.
There
were
a
couple
levels
of
activity:
developer
activity
data
like
number
of
pushes
number
of
pull
requests
overall
activity,
data
that
showed
growth
year
over
year,
and
it
was
very
typical
growth
year
over
year
and
it
didn't
change.
K
So
the
fact
that
we
saw
consistent
growth
with
no
change
given
2020
was
really
interesting
right
and
then
issues
in
enterprises,
issues
kind
of
like
chugged,
along
and
then
kind
of
dove,
but
in
free
repos
issues
chugged
along
and
jumped,
and
when
we
think
about
it
right
now,
as
I
kind
of
think
back
and
reflect
on
it,
we
think
maybe
this
makes
sense.
K
It
could
be
that
in
enterprises
we
always
sit
in
a
big
room
with
white
boards
to
build
up
our
backlog
of
what
we're
gonna
build
right,
because
issues
are
how
we
plan
and
track
work,
but
in
open
source.
Of
course,
we've
always
been
distributed.
Moving
home
like
no
big
deal,
it's
fine,
but
in
enterprises
we
didn't
know,
we
didn't
have
the
ceremonies
to
create
a
huge
backlog
of
work,
and
so
once
we
had
burned
down
through
that,
we
really
struggled
to
recreate
that.
E
Fantastic
now
we
are
actually
out
of
time
for
questions,
but
I'm
going
to
squeeze
one
last
one
in.
If
you
can
answer
it
fairly,
quick
because
it's
from
quinny
pig
so
and
he
was
wanting
to
know,
should
I
be
nervous.
E
Well,
there's
no
swearing
in
it,
which
is
why
I
can
read
it
out.
So
not
once
did
dr
fullscreen
conflate
the
number
of
pull
requests
with
productivity,
which
is
you
know,
you're
getting
a
thumbs
up.
How
can
he
convince
his
idiot
boss
and
get
them
on
board?
With
that
perspective,.
K
People
will
react
to
what
you
measure
and
you're
gonna
burn,
so
we're
we're
coming
up
with
a
new
framework
or
it's
it's
kind
of
existing.
It's
based
on
decades
of
research
on
how
we
should
think
about
productivity,
and
we
need
to
be
using
several
dimensions
right.
If
you
think
about
the
dora,
4
metrics,
they're,
speed
and
stability,
so
they
balance
you
out.
Productivity
should
have
a
few
metrics
satisfaction,
performance
activity,
communication,
collaboration
and
efficiency
and
flow,
and
you
need
to
have
at
least
a
few
to
force
that
balance
and
tension.
E
Fantastic
yeah
we
had
maya
on
yesterday
or
was
it
monday?
I
can't
remember
it's
all
blurry,
but
she's
a
fellow
physicist,
and
you
know
when
you
bring
in
quantum
mechanics
and
things.
You
always
know
that
when
you
measure
the
system,
it
affects
the
system
of
measure
kind
of
thing.
So
yeah
it's
a
great
example.
Yes,.
E
Yeah
exactly
we
could
talk
like
all
day,
so
we're
gonna
have
to
go
to
discussions,
I'm
afraid
so
nicole's
very
graciously
agreed
to
be
in
the
discussions
for
the
next
30
minutes
if
you
want
to
head
on
over
to
giluniverse.com,
but
that
was
a
superb
talk.
Thank
you
very
much.
Nicole.
Take
care,
bye.
D
I
love
hearing
dr
nicole
fortune
talk,
it's
so
soothing
and
so
so
smart
and
so
just
freaking
interesting.
You
know
just
to
hear
really
all
the
research,
because
we
have
these
these
built-in
assumptions
about
what
we
think
is
going
on,
and
I
am
a
data
nerd
so,
but
there
is
so
much
more
to
check
out
because
you
are
just
getting
going.
In
fact,
we
have.
C
D
Look
at
us.
Thank
you,
monk
champs.
We
also
have
at
sw
dev
angel.
One
of
the
things
we
love
about.
Kelsey
hightower
is
his
humanity.
Oh,
you
know
he
is
just
so
good
at
being
authentic
because
he
is,
I
mean
kelsey's,
an
amazing
human,
but
talking
about
the
emotional
impact
of
a
credit
card
transaction.
Why
not
going
through
a.
D
Act
of
breaking
a
marathon
world
record.
Yes,
and
let
me
just
tell
y'all
chelsea-
did
that
keynote
live
props
to
him.
You
would
have
never.
You
would
never
guess
so.
Yeah
definitely
feeling
it
there,
but
guess
what
we
got
more
coming
up
on
enterprise
right
now
we
got
a
dj
break
2xaas
chill
tune,
optimize,
your
mono
repo
experience
and
open
source
online,
devops,
dojo
and
then
up
next
on
the
dev
channel.
D
They
also
are
on
that
that
that
chip
tune
break
martin's
ready
to
get
out
there
and
rave,
but
they
also
have
managing
boundaries,
balance
and
funding
and
open
source,
and
then
we
have
open
source
github
docs,
how
we're
working
with
the
community
to
build
docs
as
an
interface
for
code.
We
recently
did
open
sourced
our
docs
and
it
is
so
awesome,
but
first,
let's
take
a
15-minute
break
through
some
github
magic,
we're
going.
D
D
A
A
A
A
E
E
E
And
we're
back
with
forks
back
into
two
channels
if
you
enjoyed
the
play
channel,
feel
free
to
check
out
what
they're
on
up
to
there.
You
know
I've
got
changed
now
clubbing
in
suits
it's
what
I
used
to
do
when
I
had
a
real
job
in
the
city,
but
I'd
say
the
very
best
thing
out
of
2020
is
definitely
wearing
soft
clothes
all
the
time
I
noticed
you've
changed
too
dana.
D
This
year,
with
santa
gnat
to
bring
all
the
github
presents
for
you
to
enjoy,
because
we
got
some
fantastic
releases
happening
next
week.
So
look
out,
but
less
about
that
and
more
about.
What's
going
on
right
now
in
the
play
channel
we
have
the
natural
language
processing,
key
concepts
explained
and
remember.
If
you're
flipping
between
the
channels,
don't
forget
it
auto
mute.
So
do
that
and
guess
what
speaking
of
flipping
it
looks
like
martin,
we
have
a
very
special
guest
joining
us
that
we're
going
to
flip.
Q
Hey
dana
and
martin
we're
in
the
final
stretch
of
github
universe,
and
I
hope
the
two
of
you
are
hanging
in
there
and
hydrating.
I
need
whatever
coffee
dana
is
drinking.
Join
me
for
the
final
day
of
github
universe
highlight
show
where
we'll
cover
all
the
talks
from
today
across
all
four
tracks.
We'll
show
you
a
little
bit
of
the
behind
the
scenes
view
of
what
it
took
to
put
on
github
universe
this
year
and
a
little
surprise
from
some
people,
you've
gotten
to
know
over
the
past
few
days.
Q
E
D
What
we
have
coming
up
next
on
enterprise
is
open
source
online,
devsox,
dojo,
pro
tick
productivity
plus
plus
plus
with
github
for
mobile,
desktop
and
cli,
and
then
on
this
next
session.
I
love
this
one.
We
have
optimizing
your
mono
repo
experience.
We
have
our
very
own
staff
software
engineer
at
github,
derek.
D
D
Universe.Com
discussions
and
don't
forget
to
read
the
section
we
want
to
hear
your
feedback
find
the
yellow
star
next
to
the
join
discussions
on
the
bottom
of
this
page.
Without
further
ado,
do
they
would
know
this.
R
R
Before
I
get
too
far
into
the
technical
details,
I
want
to
acknowledge
that
everything
I
talk
about
today
is
a
community
effort
myself,
I'm
a
part
of
the
get
client
team
at
github,
where
we
work
to
scale
get
to
the
largest
repositories
ever.
There
are
also
contributions
from
the
git
contrib
and
git
systems
teams
and
contributions
from
the
wider
open
source
git
community.
R
R
R
R
R
R
Let
me
drop
some
universal
advice
for
optimizing.
Your
code
code
never
gets
faster.
It
can
only
do
fewer
things,
whether
you're
talking
about
taking
an
algorithm
from
order
n
squared
to
order
n
or
just
reducing
that
value
of
n.
Everything
is
about
executing
fewer
instructions
or
transferring
less
data.
R
R
R
R
R
As
we
continue
walking
back
in
history,
we
can
see
that
every
commit
has
a
root
tree
and
these
trees
form
an
interesting
directed
graph.
I
will
come
back
to
this
picture
a
few
times,
so,
let's
recall
that
circles
represent
commits.
These
are
points
in
time.
Triangles
represent
trees.
These
are
directories
and
boxes
represent
blobs.
These
are
file
contents.
R
When
we
examine
a
typical
git
repository
by
object
type,
we
see
on
the
left
a
typical
split
by
object
count.
We
typically
see
more
trees
than
any
other
type
and
more
blobs
than
commits,
because
on
average,
more
than
one
file
is
changed
per
commit
in
the
middle.
We
have
rectangles
representing
a
good
distribution
of
the
size
these
objects
take.
Within
the
repository
I
used
the
linux
kernel
repository
as
a
good
example,
because
git
is
designed
for
the
kinds
of
changes
done
in
the
kernel.
R
This
really
relies
on
most
files
being
plain
text
source
code
that
change
only
a
few
lines
at
a
time
that
allows
git
to
delta
compress
the
blobs
very
efficiently
on
the
right,
I
have
what
is,
unfortunately,
very
typical
when
blobs
contain
binary
assets
or
generally
have
large
diffs
and
do
not
compress
well.
In
fact,
this
ratio
is
not
even
as
skewed
as
would
happen.
R
R
Think
of
sisyphus
pushing
the
rock
up
the
hill,
except
occasionally
he
gets
a
new
rock,
but
all
the
older
rocks
are
connected
by
a
long
chain.
He
has
to
pull
them
all
up
the
hill,
making
progress
even
harder
as
he
goes.
This
is
kind
of
what
happens
when
you
regularly
check
in
large
binaries
into
your
repository.
R
So
naturally,
my
first
recommendation
is
to
remove
large
blobs
from
your
repository.
One
way
to
do
this
is
with
git.
Lfs
stands
for
large
file
storage,
which
removes
the
large
blobs
from
your
git
repository
and
places
them
in
a
secondary
storage
layer.
This
allows
your
git
object
database
to
be
more
efficient,
but
you
still
need
to
download
those
large
blobs
when
you
do
a
git
checkout.
This
means
you
have
hidden
the
problem
somewhat,
but
is
still
there
causing
you
pain.
R
R
R
R
R
R
R
R
The
way
to
do
this
in
the
core
git
client
is
partial.
Clone
by
adding
the
flag
dash
dash
filter
equals
blob
colon
none
into
your
git
clone
command.
You
enable
partial
clone,
the
remote
may
not
understand
partial
clone
and
it
might
default
to
a
full
clone,
but
the
good
news
is
partial.
Clone
is
enabled
on
every
github
repository
and
in
github
enterprise,
server,
2.22
and
later
so
go
give
it
a
try
on
your
favorite
repositories.
R
Let's
recall
our
object
model
graph
in
a
full
clone.
We
need
every
reachable
object.
That
is,
if
there's
an
arrow
from
a
needed
object
to
another,
then
we
also
need
that
second
object,
partial
clone
says,
don't
give
me
any
blobs.
I
don't
need
so.
The
initial
clone
downloads
all
reachable
commits
and
trees,
but
skips
blobs
that
are
not
necessary
when
checking
out
the
tip
commit
git
makes
a
second
request
to
find
the
blobs
it
needs
for
that
checkout.
R
I
would
be
remiss
if
I
didn't
mention
an
older
clone
option
called
shallow
clone
here.
Not
all
reachable
commits
are
downloaded
instead,
only
the
commit
at
tip
and
the
trees
and
blobs
reachable
from
the
root
tree
are
downloaded.
Now
this
is
less
data
than
a
partial
clone,
but
there's
a
catch.
You
don't
have
access
to
the
commit
history,
so
you'll
have
trouble
using
things
like
git
log
or
git.
Merge.
R
I'm
not
saying
that
shallow
clones
don't
have
a
purpose.
Only
that
shallow
clone
should
exist
only
for
ephemeral
builds,
for
example,
if
you're
using
a
github
actions
public
runner,
then
you
can't
keep
a
repository
across
multiple
builds
instead
you're
going
to
throw
that
way
that
data
anyway,
so
you
might
as
well
use
a
shallow
clone.
R
After
we
focused
on
reducing
the
necessary
data
transfer
due
to
your
git
history,
let's
be
mindful
of
the
present.
Let's
focus
on
the
working
directory
at
your
tip,
commit
before
a
build
your
working
directory
matches
exactly
what
your
commit
says.
It
should
contain
the
file
contents
in
your
working
directory
match
the
blobs
it
knows
about,
but
after
you
build,
you
might
have
many
new
files
appear
that
were
generated
by
the
build.
R
If
these
are
located
inside
your
working
directory,
then
git
needs
to
inspect
them
and
determine
that
they
are
not
actually
interesting.
This
is
typically
done
via
dot
get
ignore
files,
the
more
files
your
build
generates,
the
more
work
git
needs
to
do
in
order
to
run
git
status
or
get
ad
git
needs
to
start
walking
directories
to
discover
which
files
are
new
or
modified
as
it
walks
it
discovers
all
of
these
build
files
and
compares
them
against
the
docket
ignore
patterns.
R
This
leads
to
my
next
hot.
Take.
Get
ignore.
Files
should
be
tiny.
The
get
ignore
feature
uses
an
extremely
flexible
pattern,
recognition
format,
and
the
issue
here
is
that
the
paths
must
be
checked
against
these
patterns,
one
by
one.
In
order
this
can
lead
to
quadratic
growth
in
the
pattern
recognition
algorithm,
we
recommend
that
to
improve
the
situation,
you
should
push
all
of
your
build
time:
outputs
out
of
your
working
directory,
my
projects,
typically
clone
into
a
repo
src
directory.
R
Speaking
of
builds
having
developers
wait
on
builds
is
an
age-old
problem.
You
really
want
developers
to
be
able
to
stay
focused
and
not
get
distracted
while
waiting
for
an
automated
task
for
really
large
repositories.
It
is
critical
to
have
a
way
for
a
developer
working
on
a
small
slice
of
the
repository
to
not
need
to
build
the
entire
cone.
R
One
pattern
I've
seen
and
recommend
is
to
use
a
flywheel
pattern
where
multiple
modules
or
services
within
your
monorepo
depend
on
some
common
code,
but
don't
need
each
other
to
build
a
way
to
make
this
possible
is
to
have
clear
implementation
contract
boundaries
to
build
each
service.
We
only
need
to
know
the
contract
that
the
other
services
provide,
not
their
implementation.
R
R
Just
some
quick
pointers
to
using
the
sparse
checkout
feature.
You
can
initialize
a
sparse
checkout
in
an
existing
repository
with
git,
sparse,
checkout,
init
dash
cone.
You
can
set
the
sparse
checkout
definition
using
get
sparse,
checkout
set
and
listing
the
directories
you
care
about.
You
can
also
add
directories
in
batches
and
you
can
disable
sparse
checkout
quickly
to
get
back
to
a
full
working
directory
for
more
information.
I
recommend
my
blog
post
about
the
sparse
checkout
feature.
R
Now,
let's
combine
our
earlier
recommendation
of
partial
clones
with
a
sparse
checkout.
If
we
run
the
clone
command
here
at
the
bottom,
it
contains
the
partial
clone
flag,
the
sparse
flag
and
we'll
clone
into
an
src
directory.
The
end
result
is
we
get.
This
object
database
where
we
have
all
reachable
commits
and
trees,
and
the
only
blobs
are
those
immediately
in
the
root
of
the
working
directory
by
adding
a
subdirectory.
We
care
about
to
the
sparse
checkout
definition.
R
However,
I
must
now
lean
upon
you.
We
built
the
sparse
checkout
feature
to
help
users
who
are
in
this
situation
of
not
needing
the
full
working
directory
if
they
have
it
set
up
to
do
so.
Someone
needs
to
tell
git
which
directories
are
important.
This
means
that
there's
a
connection
missing
between
your
build
system
and
sparse
checkout.
R
R
R
If
you
use
all
of
these
features,
then
you
are
truly
at
the
forefront
of
git
at
scale.
You
are
leading
the
way
as
you
lead
the
way
you
will
be
well
poised
to
take
advantage
of
new
git
features
as
they
come
out,
keep
up
to
date
with
the
latest
by
following
the
github
blog.
We
regularly
update
the
community
on
new
git
features
that
come
out
with
every
release.
We
do
deep
dives
on
important
features
and
have
some
other
important
content
as
well.
R
For
example,
I
wanted
to
leave
you
with
a
teaser
of
an
upcoming
git
feature
background
maintenance.
We
are
working
to
deliver
the
ability
to
easily
schedule
maintenance
on
your
git
repositories
in
the
background,
so
you
never
get
blocked
on
a
git
gc
auto
again.
This
will
keep
your
repositories
running
smoothly
without
blocking
user
facing
commands.
R
R
R
R
E
Guys
it
sounds
like
you
know,
some
sort
of
song.
We
should
definitely
do
that,
but
we
don't
need
to
see
us
rapping
that
that
would
be
very
cringe.
So
we've
got
a
few
questions
coming
in
on
the
discussions
forum.
If
you
want
to
head
on
over
to
google
universe.com
a
big
shout
out
actually
to
the
the
gear
team
inside
of
github,
we've
been
answering
a
bunch
of
these
questions.
Already,
we've
got
johannes
there
and
matt
as
well.
That's
brilliant,
but
a
question
from
dana
guess
who
this
question
is
from:
have
a
guest
go
on.
A
R
D
Wow,
that
is
crazy.
Huge
I
mean
you
know
it's
hard.
Moderates
are
hard
and
I'm
just
so
glad
that
we're
giving
these
tips
out
there
on
how
to
optimize
it,
because
just
because
you
have
a
monorepo
or
a
monolith
doesn't
mean
it
has
to
be
slowed,
doesn't
mean
that
everybody
has
to
be
waiting.
I
love
love
love
that
you
said
you
know
to
check
out
more
about
sparse
check
out,
and
I
know
you
mentioned
this
talk,
but
where
are
some
places?
D
People
can
go
read
up
on
that
you,
you
did
say
your
blog
post,
but
what
other
resources
can
people
learn
more
about
sparse,
checkout,
stolen.
R
Yeah
my
favorite
place
is
to
go
to
the
official
git
documentation
at
git
dash
sem.com,
and
that
includes
all
the
things
about
how
to
work
with
the
built-ins
for
the
command
line
interface,
but
it
also
includes
some
kind
of
philosophy
of
what's
going
on.
It
gives
you
a
high-level
view
of
you
know
how
to
design
these
sparse
checkouts,
and
we
continually
are
working
to
improve
that
documentation.
R
E
That's
great,
I
know
I
hadn't
heard
of
scala
before
your
talk
slowly,
so
I
was
wondering,
would
you
be
able
to
dig
in
a
little
bit
like
what
the
history
is
behind
scalar?
You
know
who's
using
it
like?
Is
this
a
battle
tested
thing
that
we
can
try
out,
or
is
this
kind
of
like
a
a
hobby
project,
run
by
a
few
people
in
a
back
room
somewhere.
R
Right
well,
scalar
is
a
relatively
new
project.
We
launched
it
in
february
of
this
year,
but
it
is
kind
of
battle
tested
because
it
is
generally
forked
from
our
previous
project
vfs
for
git,
which
is
how
windows
was
able
to
get
onto
their
monorepo
onto
git.
But
we
noticed
when
we
were
moving
office
in
the
same
way
onto
vfs.
R
Forget
that
they
didn't
need
the
virtualized
file
system,
part
of
that
they
could
rely
on
sparse
checkout
instead,
and
so
we
built
scalar
specifically
so
that
they
can
take
advantage
of
that
in
this
kind
of
painless
way,
like
their
developers
just
run,
scalar
clone
and
they're
good
to
go.
They
don't
need
to
worry
about.
You
know
how
to
do
a
partial
clone
or
how
to
set
up
sparse
checkout,
it's
already
handled
for
them,
and
so
they've
been
really
using.
E
Team
are
using
a
lot
of
mac
development.
You
know
you
don't
expect
that,
and
so,
with
things
like
catalina
not
being
able
to
hook
into
the
file
system
in
the
same
way
and
having
that
virtual
file
system,
it's
really
lucky
that
we
could
do
that
so
yeah.
I
know
that's
awesome,
hey
dana!
Any
other
questions
are
coming
in
through
the
discussions.
D
We
got
another
question
for
you
soli
and
they
want
to
know-
and
I
guess
this
is
an
opinion
question.
I
don't
know
what
are
the
worst
repos
to
host
and
why
I
don't
know
if
there's
any
bad
repos.
Personally,
I
think
all
repos
are
good
repos
just
like
humans,
but
in
your
opinion,
you
know
from
a
technical
perspective.
D
A
D
Repos,
that
may
not
be
the
best,
and
and
can
you
tell
us
why
you
why
you
think
so.
R
Well,
I've
got
good
news
for
you:
there's
an
entire
talk
about
the
worst
repositories
to
host
on
github
from
a
few
years
back
on.
Git
merge
so
go
look
at
that
in
youtube,
but
generally
the
things
that
are,
you
know
they're
very
clearly
abusive,
like
pushing
every
second.
You
know
having
hundreds
of
people
pushing
to
simultaneously,
it's
always
a
problem,
but
also,
if
you
just
start
like
trying
to
put
in
movies,
you
know
you
know
these
huge
binary
assets
that
don't
diff
at
all
and
try
to
use
git
as
a
database.
R
R
C
E
Got
time
for
one
more
question
there
dana?
Is
that
all
right,
I'm
just
saying
it's
a
again
an
opinion
question.
You
know
you
talked
about
the
sparse
checkout
stuff,
but
I've
seen
a
lot
of
projects.
You
know
like
android
and
things
like
that
they're
using
sub
modules
to
solve
this
problem
when
they're
a
large
monoreaper.
E
So
you
know
quite
often
you
think,
with
sub
modules
like
regex,
if
you
use
a
sub
module
to
solve
a
problem
now,
you've
just
got
two
problems
kind
of
thing,
but
what's
your
opinion
on
sub
modules?
And
you
know,
how
does
that
differ
from
you
can
say
something
like
sparse,
checkout.
R
Right
sub
modules,
just
like
shallow
clones,
have
a
very
focused
use.
That
is
what
they
were
designed
for,
which
is.
I
have
an
external
dependency
of
a
repo.
I
don't
control,
but
I
need
it
as
a
source
dependency
in
my
repo,
and
I
have
questions
about
why
you
need
that
as
a
source
dependency
versus
a
binary
like
linking
dependency.
But
that's
you
know.
Sometimes
people
have
to
do
that,
but
I
think
people
specifically
android
a
lot
of
it.
R
Was
they
used
sub
modules
as
a
mechanism
to
scale
you
needed
a
large
repository
but
sparse,
but
the
course
checkout
wasn't
available
and
yeah.
You
want
to
split
it
up
into
these
things.
Modules
can
give
you
that,
oh
I
I'm
going
to
select
the
components
I
care
about,
and
so
some
ways
that
was
the
best
you
could
do
10
years
ago,
but
you
know,
I
think
that
git
has
improved
significantly
in
order
to
support
monorepos
where
it's
one
tree
and
you
don't
need
the
sub
module
complications.
D
Heck
yeah,
you
know
what
soli
you
are
just
a
wealth
of
information.
I
still
remember
my
move
from
tortoise
espion
into
get
and
it's
been
such
an
awesome
adventure
to
just
follow
the
community,
and
you
know
what
not
feel
so
much
like
a
get
noob.
You
know,
but
just
remember
y'all,
that
stolen
will
be
available
for
the
next
30
minutes
and
discussions
to
answer
all
your
questions
about
git
and
how
to
optimize
your
mono
repo
or
anything
else.
You
know
you
can
ask
them
why
we
call
them.
D
E
Hey
everybody,
so
we've
got
four
channels
to
check
out
still
today,
there's
the
dev
channel,
the
universe
city
channel
and
the
play
channel
just
for
fun.
Now,
right
now,
you're
in
the
enterprise
channel
and
we're
here,
putting
the
entertainment
in
enterprise
and
giving
you
prizes
for
doing
being
on
the
enterprise
channel
kaider,
that's
not
googly
binding,
feel
free
to
pop
in
and
out
to
the
other
channels.
You
know
hit
the
unmute
button
as
you
come
in,
and
out
of
them,
and
also
I've
been
seeing
on
twitter.
E
We
posted
our
custom
marker
cats
over
on
twitter
earlier
on
in
the
week,
and
I've
been
seeing
loads
of
really
cool
ones.
Come
in,
you
can
make
your
own
in
the
swag
shop
at
myoctocat.com
and
then
please
share
your
creation
with
us.
If
you
send
it
to
at
twitter
github
on
twitter
or
if
you'd
use
the
github
universe,
that'd
be
fantastic
and
don't
forget
as
well.
E
If
you
click
on
that
same
more
tab
up
in
the
top
corner
and
check
out
the
spotify
playlist,
which
has
got
tracks
from
all
the
artists
in
the
play
channel
along
with
some
special
tracks
picked
by
us,
hosts,
it's
a
little
little
thing:
can
you
spot
which
tracks
mine?
Can
you
spot
dana's?
You
know,
let
us
know
what
you
think
at
github
on
twitter
happening
now
on
the
dev
channel.
We
have
an
amazing
session
again
from
the
over-performing
caf
who's
going
to
be
doing
open
sourcing
guild.,
not
content
with
hosting
she's
going
to.
E
E
That
should
be
good,
but
over
here
on
the
enterprise
channel
stay
tuned,
because
thank
you,
you
might
not
have
heard
of
dxc
they're
like
one
of
these
amazingly
massive
companies
that
you've
probably
not
heard
of
unless
you're
in
the
tech
space
which
a
lot
of
us
are
so
dxc,
are
going
to
come
and
talk
to
us
about
the
online
devops
dojo.
E
E
Yet
sadly,
despite
being
one
of
the
top
16
executives
to
watch
putting
business
inside,
but
maybe
one
day
he's
also
the
cto
of
modern
apps
and
cloud
native
dxc
technology
and
cloud
editor
at
info
queue
where
he
talks
about
raspberry
pi
and
does
arduino
tinkering
as
well
remember
to
engage
on
discussions.
If
you
head
on
over
to
gilbertuniverse.com
forward
slash
discussion,
so
get
involved
and
ask
questions,
we've
got
tons
of
experts
helping
out
in
there
all
day
long
and
also
don't
forget
to
rate
this
session.
E
We
really
value
your
feedback,
find
the
yellow
star
next
to
the
joint
discussion
on
the
bottomless
page
without
further
ado.
Let's
start
the
session,
we're
in
on
open
source
online
devops
dojo
takes
away.
S
Hi
there,
so
thanks
for
that
very
kind
intro.
It
touched
upon
dxe,
which
is
a
company
that
some
people
have
heard
of,
but
not
everybody.
So
I
thought
I'd
start
out
by
just
briefly
introducing
the
company
to
give
you
an
idea
of
the
things
that
we
do,
which
will
set
the
scene
for
what
we've
been
doing
in
terms
of
this
devops
dojo.
S
So
at
dxe
we
run
the
mission,
critical
I.t
systems
for
thousands
of
companies
across
the
planet,
and
we
talk
about
ourselves
as
a
full
stack
services
company,
so
that's
represented
here
and
so
on.
The
right-hand
face
it's
showing
the
types
of
services
that
we
do
so
it
outsourcing
modern
workplace
cloud
and
security
applications
and
then
finally
analytics
and
engineering
and
then
on
the
left,
face
it's
going
through
all
of
the
industries
that
we
serve
and
there's
really
too
many
for
me
to
spend
time
running
through
right
now.
S
The
number
of
employees
that
we've
got
worldwide
is
over
138
000
and
in
our
delivery
organization,
which
was
the
target
for
a
lot
of
this
devops
dojo
training
that
we've
been
developing.
That's
over
a
hundred
thousand
employees
and
then
looking
at
the
applications
area
that
I
now
focus
on.
Sixty-Five
thousand
application
professionals,
so
we've
got
a
lot
of
people
to
do
upskilling
with
and
that's
become
a
huge
challenge
for
us.
S
So
I
want
to
briefly
talk
through
the
history
of
the
dojo
and
we
started
out
in
2016
with
an
infrastructure
as
code
workshop.
So
this
was
something
that
was
based
in
our
enterprise
github
and
it
was
just
three
modules.
So
we
were
getting
people
through
doing
their
first
pull
request
using
github.
S
They
were
doing
their
first
playbook
on
a
config
management
tool
and
building
their
first
ci
and
cd
pipelines
using
jenkins,
and
I
had
a
team
of
people
going
all
over
the
planet
delivering
these
workshops.
They
would
typically
take
about
half
a
day
and
it
was
designed
to
be
viral
as
well,
so
that
people
who'd
taken
the
workshop
could
go
back
and
teach
another
one
with
their
colleagues
and
at
the
end
of
the
year,
we'd
had
something
north
of
a
thousand
people
had
gone
through.
S
That
workshop,
which
you
know
in
one
way
was
great.
But
if
we
looked
at
the
overall
size
of
the
challenge
kind
of
getting
tens
of
thousands
of
people,
hundreds
of
thousands
of
people
through
the
workshop,
it
was
a
little
bit
too
much.
It
was
going
to
take
too
many
lifetimes
for
us
to
get
there.
S
S
I
was
at
the
monkey
grower
event
run
by
the
the
red
monk
analysts
and
bumped
into
luke
marsden
there,
who
was
at
weaveworks
at
the
time,
and
he
showed
me
the
samples
and
examples
and
demos
that
he'd
built
to
show
off
what
weaveworks
was
doing
using
catacoda
and
I
kind
of
saw
that
and
thought
wow.
This
is
going
to
be
the
thing
that
will.
Let
me
take
this
workshop
and
make
it
web
scale.
S
So
we
took
the
workshop
and
put
it
onto
catacoda
and
that
then
allowed
us
to
address.
What's
subsequently
become
28
000
people
across
the
organization,
then
2018
an
inner
source
team
had
started
to
form
around
this
and
they
had
lots
of
plans
about
more
advanced
topics
to
address
and
so
from
the
white
belt.
We
grew
the
the
yellow
belt
and
there
were
so
many
modules
that
the
team
wanted
to
build.
S
We
split
it
down
into
different
stripes,
so
on
our
internal
learning
management
system,
there's
a
yellow
belt
stripe,
one
a
yellow
belt
stripe.
Two
then
later
on,
they
also
had
some
ideas
about
doing
different
types
of
dojo.
So
we've
built
things
like
the
product
management
dojo,
which
is
intended
to
help
people
who've
traditionally
been
in
project
management
roles,
think
about
the
difference
of
doing
product
management
and
then
we'd
always
plan
to
do
this,
and
we
finally
got
there.
S
So
you
might
be
wondering:
where
can
I
find
the
dojo
and
I'll
post
these
links
into
the
discussions
as
soon
as
I'm
done
with
this?
But
the
easiest
way
is
simply
to
search
for
dxe
online
devops
dojo.
S
That
should
turn
up
at
least
one
of
these
links,
and
so
I'm
going
to
be
diving
into
the
home
page
in
just
a
moment
which
is
there
on
github
pages,
and
you
can
see
also
links
there
to
the
source
code,
that's
running
on
the
cadacoda
platform
and
then
the
source
for
the
github
pages
presenting
the
the
environment
that
we've
wrapped
around
that
when
you
get
there
you're
going
to
see
a
web
page.
That
looks
something
like
this,
and
so
it's
introducing
the
the
storyline
behind
the
dojo.
S
So
we
do
a
lot
of
stuff
with
continuous
delivery
pipelines
and
those
pipelines
need
to
be
built
around
applications,
and
so
for
that
we've
used
the
spring
pet
clinic
application,
because
it
gives
us
a
sort
of
flexible
and
well-battled
tested
sample
app
that
we
can
do
interesting
things
with,
but
to
complement
that
we've
built
a
cast
of
characters
and
a
storyline
about
the
the
pet
clinic
and
the
people
that
are
working
there.
And
you
can
see
here.
S
So
it
begins
with
a
story
in
setup,
and
that
is
all
about
getting
the
pet
clinic
app
into
your
own
github
user,
so
that
you
can
start
doing
things
with
it
and
also
setting
up
the
bot.
That's
going
to
be
used
as
part
of
the
version
control
module.
So
I'm
now
going
to
jump
into
a
screen.
Share
and
get
to
the
version
control
module
itself.
S
And
so
I'm
going
to
launch
get
version,
control
module
and
that
tab
is
now
going
to
take
me
into
the
catacoda
platform
and
all
of
the
catacota
modules
begin
with
a
splash
screen
like
this.
You
can
see
that
the
estimated
time
for
running
this
module
is
30
minutes.
As
I
glance
at
the
clock,
I've
only
got
about
13
minutes
left
for
my
slot,
so
this
is
going
to
be
a
bit
of
a
speed
run.
S
So
I'm
going
to
hit
the
start
scenario
button
here
and
that's
taking
me
into
the
cadacoda
platform
and
what
you
can
see
is,
on
the
left
hand,
side.
I've
got
a
storyline
which
is
telling
me
what's
going
on
and
then,
on
the
right
hand,
side.
I've
got
a
shell
where
I
can
actually
run
commands
and
one
of
the
things
that's
useful
here
is:
this
is
a
real
live
container
based
environment.
So
people
can
come
here
and
ski
off
piste
from
the
modules
and
try
things
out
in
the
safety
of
the
training
environment.
S
Should
they
want
to
do
that?
I'm
going
to
stick
for
the
script
for
the
time
being,
and
so
here
the
scripts
explaining
the
sort
of
scene
set
on
why
some
changes
need
to
be
made
and
why
git
is
being
used
to
track
them
and
github
is
being
used
for
the
collaboration
around
that.
And
so
it's
telling
me
that
the
team's
choosing
a
branching
model
and
if
I
press
continue
it's
going
to
take
me
then
into
the
section
of
the
storyline,
where
I
can
start
actually
interacting
with
the
environment.
S
So
we
begin
with
this
preparation
script
and
that
takes
me
into
a
place
where
it's
asking
for
me
to
paste.
In
a
github
token,
I've
just
added
a
minus
s
there.
So
I
can
paste
that
in
without
it
being
echoed
to
the
screen,
because
we
don't
want
the
the
github
personal
access
token
to
be
shared
during
a
demo,
but
normally
it
would
be
probably
not
too
much
for
a
problem
for
that
to
be
echoed
on
the
screen
there.
S
S
S
But
caracoda
gives
me
the
lazy
option
of
just
clicking
on
the
button
and
that's
going
to
run
the
command
there
for
me
and
then
I
can
do
the
same
to
check
out
a
branch
which
I'm
going
to
call
us
horse
one
and
it's
now
time
to
make
some
changes.
So
it's
telling
me
to
navigate
into
this
source
main
resources,
database
hsql
and
the
data
sql,
and
I
then
need
to
go
to
line
23
and
add
an
extra
line.
So
let's
do
that.
S
So
I've
added
the
text
for
horse
and
I've
put
the
different
index
there
for
it
and
that's
all
set
to
go.
So
if
I
now
run
git
branch,
I
can
see
that
I'm
on
the
us1
horse
branch
and
if
I
run
git
status,
I
can
see
that
I've
modified
the
file.
So
there's
a
live
update
happening
from
that
editor
above
the
terminal.
S
S
S
So
this
is
a
really
basic
introduction,
but
kind
of
takes
us
past
what
we
were
originally
doing
in
white
belt,
because
at
this
stage
we're
now
getting
into
more
of
a
collaborative
interaction
with
the
bot
rather
than
people
just
merging
their
own
pull
requests,
which
is
what
we'd
originally
done.
S
S
I'm
just
going
to
accept
the
defaults
here
and
create
that
pull
request
and
sort
of
normal
stuff
happening
here
in
terms
of
mergability,
but
I'm
not
going
to
just
click
merge
there,
because
the
storyline
has
us
going
somewhere
else.
So
we're
simulating
peer
review
here
with
the
bolt,
and
so
what
I
need
to
do
is
ask
paulo
the
product
manager
if
he
can
do
that
peer
review.
So
let's
take
that
and
paste
it
in
and
I
didn't
get
the
copy
there.
S
Okay,
so
paulo's
come
straight
back
to
me
and
said
that
it's
all
looking
good
on
the
horse,
but
they
want
to
add
pony
to
it
as
well.
So
I
need
to
go,
make
some
more
changes,
and
so,
let's
jump
back
into
the
editor
here
and
I
can
make
that
change.
S
Right
so
that's
the
changes
made
and
as
before
we
can
do
get
status.
Now
we
can
add
the
file,
do
a
commit
saying
that
we're
taking
pollo's
comments
into
account
and
then
push
that
back
up
and
let's
ask
paolo
if
he's
good,
with
the
the
pony
being
added.
So
that's
already
been
pushed
and.
S
We
kind
of
close
out
here
by
saying
that
the
the
user
story
is
ongoing
and
there's
more
still
to
be
done
with
the
underlying
issues.
If
I
glance
at
my
third
screen,
I
can
see
emails
popping
in
about
that.
Merge
has
already
taken
place
and
I
could
continue
now
and
it's
giving
me
the
congratulations
splash
screen
and
inviting
me
to
carry
on
with
dojo.
So
at
this
stage
I'm
gonna
go
back
to
my
slides
and
jump
out
of
the
screen
share.
S
Now
one
of
the
things
that
happens
quite
frequently
is
people
run
into
trouble
as
they're
going
through
the
modules,
and
you
know
that
can
be
problems
with
the
underlying
platform.
It
can
be
issues
with
just
their
browser
or
something
like
that,
and
it
can
sometimes
be
especially
with
jenkins
issues
around
plugins,
having
drifted
away
from
behavior
that
we're
expecting
so,
we've
got
the
get,
help
button
that
people
can
use
and
when
they
press
that
that's
taking
them
into
github
issues
where
we've
got
as
you
can
see,
a
pre-populated
form.
S
That's
allowing
people
to
tell
us
about
what
they
see
going
wrong,
how
we
can
reproduce
that
and
what
they're
expecting
to
be
different
and
maybe
even
add
in
some
screenshots.
So
anybody
trying
this
out.
If
you
have
any
problems
with
it,
then
please
feel
free
to
raise
an
issue.
S
S
So
I
kind
of
close
out
now
with
our
call
to
action,
and
you
know
it's
really
three
parts.
The
first
part
of
the
call
to
action
is:
please
try
the
dojo,
you
know
it's
been
open
sourced
so
that
it's
there
for
everybody
in
the
community
to
use.
We
did
that
because
we
thought
it
was
something
that
was
going
to
be
useful
to
you
know
our
customers
and
our
partners,
but
more
broadly
to
the
devops
community.
S
So
please
tell
other
people
if
you
like
it
and
if
you
find
problems,
then
please
raise
an
issue
with
us.
If
you
don't
like
it,
you
know
tell
us
what
could
be
made
better.
S
The
second
part
of
the
call
to
action
is
to
please
contribute
so
we're
happy
to
take
pull
requests.
This
is
one
of
the
things.
That's
really
helped
us
polish
up.
S
The
modules,
as
we've
been
using
the
platform
internally
is
people
spot
things
that
you
know
they'd
like
to
improve,
and
they
let
us
know
about
it
through
the
medium
of
pull
request
and
some
folk
sort
of
early
on
in
our
journey
were
coming
along
to
the
dojo,
and
you
know
often
they'd
been
pushed
by
the
manager
to
do
it,
and
you
know
thought
that
the
whole
thing
was
a
waste
of
their
time
and
as
soon
as
they
got
involved
with
it
they're
kind
of
okay.
S
I
can
see
the
point
of
this
now,
but
I
kind
of
hate
these
bits
or
this
this
thing
could
be
made
better,
and
so
you
know
many
of
those
people
contributed
internally,
and
you
know
we
did
that
through
their
pr's,
but
a
lot
of
them
also
became
part
of
the
inner
source
community.
That's
helped
us
make
this
better
and
broadened
out
the
range
of
modules
that
we
had
then.
S
We
chose
the
mozilla
public
license
version
2
because
we
didn't
want
a
super
liberal
license
that
was
going
to
allow
the
the
content
that
we've
got
here
to
be
just
taken
by
our
competitors
and
blatantly
ripped
off.
So
we
just
wanted
a
license
that
made
sure
that
dxe
had
some
kind
of
acknowledgement
for
originally
creating
these,
but
we
really
do
hope
that
it's
useful
to
other
organizations-
and
you
know
they
can
potentially
build
that
around
their
own
tool
chains.
S
So
yeah
we've
originally
done
this
with
our
enterprise
github
and
some
of
our
practices
around
that
and
our
own
use
of
jenkins
and
some
of
the
associated
tools.
But
you
know
we're
moving
some
of
our
own
stuff
to
github
actions
and
making
changes
there,
and
we
understand
that
other
orgs
have
kind
of
different
approaches
to
doing
stuff
and
so
part
of
what
we
we
kind
of
expect
people
to
doing
with
folks
is
adapting
to
the
different
tool
chains
that
they
prefer
within
those
organizations.
S
All
right,
then
well.
Thank
you
very
much
for
your
time.
I
think
we're
now
going
into
questions.
So
what
else
can
I
tell
you
about
the
the
online
devops
dojo.
D
Stuff
works.
It's
awesome
to
have
this
out
there,
so
we
have
time
for
just
one
question.
Unfortunately,
so
I'm
going
to
throw
this
one
at
you,
chris,
the
the
audience
wants
to
know.
Do
you
have
any
plan
to
open
source,
any
more
modules,
they're
loving
the
modules
you
have
out
there.
Do
you
have
any?
You
know,
plans
coming
up
to.
S
J
S
We
originally
launched
with
five
modules
and
we've
already
actually
added
a
couple
around
value:
three
mapping
and
devops
kaizen
and
so
they're
already
available
we're
kind
of
looking
at
the
existing
portfolio
of
modules
that
we've
got
in
stripe,
one
and
stripe
two
and
thinking
about
which
other
ones
would
be
most
valuable
to
the
community
and
we've
also
got
ideas
about
stripe
three,
and
so,
as
we
build
out
stripe
three
and
I'm
thinking
things
like
maybe
documentation
and
yeah
documentation
as
code
and
using
github
pages
is
one
of
my
own
personal
sort
of
hot
topics.
E
That's
fantastic
looking
forward
to
it
chris
and
I
just
wanna
before
we
hand
go
over
to
the
next
session.
I
just
wanna.
You
know
thank
dxe
on
behalf
of
github,
just
for
you're,
a
massive
company
and
iep
is
at
the
core
of
your
business,
and
so
I
know
it's
like
a
non-trivial
business
decision
to
kind
of
give
some
that
ip
out
to
the
world
so
just
want
to.
E
You
know
just
say
how
much
we
appreciate
sharing
the
knowledge
and
the
training
that
you've
been
building
up
with
the
community
inside
of
dxe
and
kind
of
sharing
that
with
the
wider
community
and
yeah.
Just
thank
you
very
much
for
giving
back,
and
you
know
we
really
appreciate
it.
So.
Thank
you
very
much
for
your
time.
Remember.
Chris
is
going
to
be
in
discussions
for
the
next
30
minutes.
E
S
E
Okay,
well,
we've
got
a
great
video
coming
up
now.
Just
recently
we
had
the
stars
nova
conference,
which
was
a
kind
of
a
internal
invite
conference
for
our
top
github
stars
and
at
that
stars
conference
the
the
woman
that
won
the
star,
the
community
builder
of
the
year
award,
was
online
called
gina.
Hoiska
and
gina's
got
a
quick
video.
Now
that
she's
going
to
tell
us
all
about
the
stars
program
and
what
it
means
to
her.
T
Hi,
my
name
is
gina
hoyskel
and
I'm
a
software
architect,
and
also
the
project
lead
and
yeah
main
developer
of
a
little
project
called
octoprint
octoprint
is
an
open
source
web
interface
for
3d
printers
that
I
created
back
in
2012
and
which
I've
been
maintaining
ever
since,
and
I
am
actually
able
to
work
on
it.
Full-Time
100
crowdfunded
by
the
community,
which
is
something
that
I
never
expect,
would
work
and
which
is
yeah
an
absolutely
awesome.
T
Adventure
coding
has
always
been
one
of
my
passions
since
very
early
childhood,
I
gotta
say,
and
once
I
got
access
to
the
internet,
I
yeah
I
started
sharing
all
the
little
tools
and
apps
that
I
created
on
there
and
yeah
over
the
course
of
this
also
learned
about
open
source
licenses.
T
What
they
mean,
what
what
kind
of
things
they
allow
and
not
allow
and
and
yeah
the
the
whole
the
whole
principles
behind
them
like
like,
sharing
open
and
free
sharing
of
knowledge
and
giving
back
and
all
that
and
at
the
same
time,
also
started
then
contributing
to
the
one
other
project
and
yeah.
T
It
was
simply
just
fun
and
I
kept
doing
that
over
the
years
and
started
my
own,
so
I
yeah
I
just
gradually
descended
into
this
community
and
got
hooked
on
it
even
before
I
even
knew
it
was
a
thing
you
could
say.
Github
has
enabled
me
to
easily
and
efficiently
also
contribute
to
existing
open
source
projects,
as
well
as
allowed
me
to
collaborate
with
people
from
all
over
the
world.
T
On
my
own
projects,
it
has
turned
git
the
version,
control
system,
kind
of
mainstream
and
even
to
a
point
where
people
sometimes
sadly
confuse
gate
with
github
and
think
they
are
the
same
thing
or
something,
and
while
I
think
well
personally
think
that
it
is
very
important
to
have
decentralized
repository
and
code
storage
which
get
by
its
nature
kind
of
enforces,
because
every
git,
every
cloned
repository
is
its
own
full
featured
repository
itself,
and
that
no
single
company
or
no
single
platform
should
have
total
control
over
all
the
projects
out
there.
T
I
also
think
that
having
something
like
a
global
development
hub
that
yeah
github
de
facto
has
become,
has
made
it
extremely
easy
for
people
to
enter
the
world
of
open
source
development
and
also
take
the
first
steps
in
there
and
also
to
in
general
collaborate
and
contribute
because
yeah,
you
just
have
to
understand
how
the
github
issue
tracker
works,
how
full
requests
work
and
that
just
translates
to
such
a
huge
number
of
projects,
then
that
it
simply
has
sped
up
contributing
so
much
in
my
personal
experience
so
yeah,
that's,
that
is,
that
is
pretty
much
what
github
means
to
me.
T
T
I
really
hope
to
be
able
to
help
improve
the
platform
as
a
whole
through
my
feedback
and
my
insight,
and
what
I
also
hope
to
achieve
a
bit
is
making
open
source
female
open
source
maintainers
like
myself,
a
bit
more
visible
overall,
because,
sadly,
still
the
general
stereotype
of
das,
open
source
must
be
male
still
persists
strongly
in
the
community
and
sometimes
frankly,
drives
me
up
the
wall.
With
regards
to
what
github
features
I
love,
I
will
admit
that
I've
fallen
completely
for
github
actions.
T
I
currently
view
them
a
bit
as
a
hammer
to
every
single
nail
that
I
encounter
in
the
development
space
when
it
comes
to
a
continuous
integration
or
automation
of
any
kind,
and
I
really
enjoy
using
them
because
they
make
it
extremely
easy
to
quickly
get
results
and
reusable
ones
to
to
boot
and
another.
Another
github
feature
that
I
really
love
is
the
extremely
well
documented
api,
as
it
has
enabled
me
to
easily
interact
with
github
when
necessary
in
the
past
and
present.
So
I
built
a
bunch
of
tooling
to
help
me
with
issue
management.
T
With
regards
to
features
on
my
wishlist
wishlist
for
github,
I
would
say
that
yeah.
I
really
wish
that
the
issue
tracker
was
a
bit
more
dynamic
or
flexible.
T
With
regards
to
allowing
me
to
define
fields
that
have
to
be
filled
in
maybe
with
some
pre-filled
options
for
for
components,
for
example,
which
are
back
effects
or
something
like
that
check
boxes
that
have
to
be
set
and
if
they
have
not
been
set,
then
the
ticket
cannot
be
submitted
same
for
log
files
that
have
to
be
uploaded
or
the
ticket
cannot
be
submitted
because
right
now
I
have
this
issue
template
that
gets
pre-filled.
T
But
a
lot
of
people
just
delete
it,
and
it
is
a
bit
of
a
wall
of
text
because
it
explains
in
detail
where
to
find
the
information
that
I'm
asking
for,
because
otherwise
my
experience
has
been
that
people
just
ask.
But
where
do
I
find
that?
And
then
I
have
to
continuously
explain
it
again,
and
this
wall
of
text
actually
now
has
people.
T
Yeah
scared,
scared
people
a
bit,
so
that
is
also
not
the
perfect
solution
and
also
trying
to
validate
issues
that
are
submitted
with
a
bot
after
the
fact
is
also
a
bit
of
frustrating
experience
for
users,
because
they
just
submitted
this
thing
and
sent
it
off
and
thought
everything
was
fine
in
our
bot
comes
and
tells
them
hey
by
the
way.
This
is
not
a
bug
report
or
not
a
complete
bug
report.
We
need
this
this
this
and
this
information.
It
would
be
nice
if
this
if
there
was
some
way.
T
Maybe
why
a
younger
front
meta
or
something
like
that
for
me
to
define
some
kind
of
form
that
has
to
be
filled
in
and
yeah
instead
of
this
free
form
text
box.
That
is
a
bit
overwhelming
to
many
people.
Apart
from
that,
let
me
just
say
to
everyone
working
on
github:
please
just
keep
being
awesome
and
listening
to
your
users,
you
have
a
stellar
track
record
for
this
over
the
past
couple
of
years
and
yeah,
I'm
just
looking
forward
excitingly
to
what
might
still
come.
C
D
D
But
let
me
tell
you
about
what's
happening
right
now
here
and
this
next
section
we
have
productivity,
plus
plus
plus,
with
github
for
mobile,
desktop
and
cli,
and
speaking
to
us,
is
mr
billy
griffin
staff
engineering
manager
at
github
cto
at
base
directory
the
most
accurate
and
up-to-date
based
directory
for
every
military
base
in
the
country
from
one
veteran
to
another.
Thank
you
for
your
service
billy
and
base
directory
team
even
got
to
visit
the
white
house
with
obama.
What
I
only
got
to
see
him
on
stage.
That's
so
badass,
don't
forget!
D
U
Thanks
so
much
for
that
wonderful
intro,
all
the
hosts
are
cracking
me
up
and
I've
been
loving
all
the
talks
over
the
past
few
days,
I'm
billy
griffin
and
I'm
part
of
the
team
that
builds
github's,
client
applications
more
specifically,
github
cli
desktop
and
mobile.
We've
shipped
a
lot
of
stuff
in
the
past
year
to
bridge
the
gaps
you've
encountered
and
github
mobile
and
github
cli
are
brand
new
this
year
as
a
result
of
feedback
from
our
users.
U
U
You
may
not
have
heard,
but
github
has
a
new
command
line,
interface
or
cli.
It
just
came
out
of
beta
two
months
ago,
but
if
you
love
github
and
you
do
anything
at
all
from
your
terminal,
you
should
totally
be
using
it
to
illustrate
why
let's
walk
through
a
scenario,
to
help
demonstrate
how
github,
cli
or
gh
helps
you
reduce
context.
Switching.
U
U
U
U
So
let's
pick
the
bug
fix
template,
but
it's
important
to
note
that
any
templates
for
your
repo
will
be
populated
in
this
in
this
list
to
choose
from,
and
we
can
even
fill
out
a
more
detailed
pr
body
using
our
preferred
editor
and
write
in
markdown
and
when
we're
all
done,
we
can
add
metadata
like
labels
and
assignees
if
we
want
or
even
preview
our
pr
in
the
browser
prior
to
submitting
it
in
this
case,
especially
since
our
goal
is
to
reduce
context,
searching
we'll
just
go
ahead
and
submit
it
right
here
from
our
terminal
and
our
pr
submitted.
U
U
How
do
I
check
out
that
pr
locally
again,
I
don't
know
if
you're
anything
like
me,
but
I
always
forget
how
to
check
a
pr
out
and
get
according
to
the
stack
overflow
answer
after
furiously
googling
every
single
time.
I
guess
I
need
to
look
up
the
pr
number,
the
branch
name
and
then
remember
a
couple
steps
and
get
well.
U
U
Here
we
can
see
what's
changed,
just
like
the
files
change
tab
on
pr
page,
especially
for
smaller
pr's
that
don't
have
a
ton
of
files
or
changes.
This
is
a
great
way
to
quickly
get
your
arms
around
what
a
pr
is
doing
without
having
to
leave
your
terminal
and
if
everything
looks
good,
we
can
go
ahead
and
approve
the
pr
right
here
in
our
terminal
and
there
we
go.
It's
approved.
U
Github
cli
allows
you
to
merge
in
whatever
way
works
best
for
you
or
your
project.
As
we
know,
preferences
and
norms
differ
across
projects.
So,
if
you're,
the
type
of
person
who
always
rebases
or
always
squashes
and
merges,
then
you
can
do
that
right
here
and
if
your
project
mandates
one
or
the
other,
it's
no
problem
at
all
and
say
goodbye
to
all
those
branches.
Just
hanging
around
on
merged
prs
that
are
still
open.
U
U
U
In
addition
to
supporting
end-to-end
workflows,
as
we
just
walked
through
together,
github
cli
is
also
incredibly
flexible,
allowing
you
to
customize
it
to
suit
your
own
needs.
For
example,
one
of
our
community
contributors
shared
how
they
combined
the
alias
command
with
the
api
command
to
view
all
draft
prs
for
a
repo
using
gh.
You
can
use
the
same
pattern
to
build
custom
aliases
for
anything
you
can
do
with
the
github
api.
So
if
gh
doesn't
have
it
go
ahead
and
add
it
for
yourself
as
another
example
of
just
this,
let's
take
the
command.
U
U
U
Improving
your
productivity
isn't
just
about
getting
the
most
work
done
to
stay
at
your
best.
You
also
need
to
take
breaks
and
get
out
into
nature.
Get
up
cli.
Has
you
covered
for
that
too,
with
your
repo's,
very
own
garden,
customized,
with
each
commit
as
a
wildflower,
whenever
I'm
having
a
tough
day
at
work
or
when
I'm
confronted
with
a
particularly
tough
challenge?
I
love
to
spend
some
time
by
the
stream
check
out
my
wildflowers
and
just
unwind
with
gh
repo
garden.
It's
a
delightful
experience
and
I
hope
you'll
try
it
out
too.
U
Moving
on
to
our
second
theme,
we'll
talk
about
how
github's
apps
help
you
focus
on
what
matters
most
to
you
and
like
we
did
with
github
cli
in
the
first
theme,
we'll
use
github
desktop
to
illustrate
how
you
can
do
just
that,
if
you're
unfamiliar
with
github
desktop
it's
a
graphical
user,
interface
or
gui.
That
makes
it
easier
to
work
with
your
github
repositories
on
your
local
machine.
U
Git
is
an
incredibly
powerful
tool
that
enables
you
to
do
so
much,
but
in
the
words
of
my
colleague,
mislove
git
is
simply
too
hard.
Github
desktop
takes
all
of
the
complexity
of
git
and
distills
it
into
the
most
important
things.
So
you
can
easily
overcome
those
points
of
friction
and
focus
on
what
matters
most
to
allow
you
to
build.
The
most
amazing
things
remember
how
we
talked
about
how
cumbersome
it
is
to
check
out
a
pr
and
git
well
from
any
pr
page.
U
So
now,
we've
cloned
the
repo
made
some
changes
and
with
other
tools,
those
changes
are
pretty
transparent
to
you
or
require
you
to
navigate
somewhere
else
to
see
them
get
a
desktop.
Instead,
just
puts
the
changes
you
just
made
right
in
front
of
you
in
a
gorgeous
diff
and
if
you
prefer
split
diffs
to
unified
diffs
gitup
desktop.
Has
you
covered
there
too?
U
A
feature
I
absolutely
love
on.
Github
is
protected
branches,
it
helps
ensure
you,
don't
accidentally
push
to
a
branch.
One
thing
we'd
see
people
do
and
get,
though,
is
committing
to
a
protected
branch
locally
and
then
realizing
they
have
to
move
those
commits
to
another
branch.
Just
to
be
able
to
push
them.
Github
desktop
helps
you
avoid
that
pain
by
gently
nudging
you
to
switch
to
a
different
branch
prior
to
committing.
U
So,
eventually,
all
that
work
just
gets
abandoned,
get
a
desktop,
makes
stashing
visible
if
you're
in
the
middle
of
a
feature,
and
your
co-worker
asks
you
to
take
a
quick
look
at
their
branch.
You
can
just
choose
to
leave
your
changes
behind
and
when
you
come
back,
the
changes
are
right
there
for
you
and
you
can
decide
whether
you'd
like
to
restore
them
to
pick
up
where
you
left
off
or
discard
them
and
start
anew.
U
In
the
vein
of
not
having
to
remember
to
do
things
in
a
particular
order,
desktop
allows
you
to
do
a
chunk
of
work
and
then
afterward
gives
you
the
ability
to
organize
your
commits.
However,
you'd,
like
by
simply
selecting
a
set
of
lines
to
include
in
each
of
your
commits
in
this
case.
Amanda's
first
commit
is
one
set
of
lines
in
a
file,
and
then
her
second
commit.
Is
this
another
set
of
lines?
U
So
you
can
organize
your
commits,
however,
you'd
like
after
the
fact
one
thing,
that's
important
is
to
make
sure
you
stay
up
to
date
with
changes
from
the
default
branch,
so
you're
not
diverging
too
much.
I've
shown
you
several
features
within
the
ui,
but
another
thing
I
love
about
desktop
is
that
once
you
understand
what's
possible,
there
are
keyboard
shortcuts
for
most
actions.
So
with
just
a
couple
key
presses,
we
can
merge
the
default
branch
into
our
feature
branch.
U
U
U
U
We
just
saw
how
github
cli
helps
you
reduce
context,
switching
and
how
github
desktop
helps
you
focus
on
what
matters
most
to
you.
The
final
theme
I
want
to
show
you
is
how
github
meets
you
where
you
are
github's
mobile
app
was
released
on
ios
and
android
just
this
year
and
if
you
haven't
tried
it,
you
have
to
download
it
right.
When
my
talk
is
done.
It's
amazing.
Let's
walk
through
a
couple
scenarios
of
how
github
mobile
brings
get
up
to
where
you
are
first
and
most.
U
Obviously,
you
can
easily
triage
your
github
notifications
on
the
go
in
pre-coveted
times,
I'd
be
on
the
bus
or
on
the
train
want
to
make
sure
that
when
I
got
to
my
desk,
I'd
already
have
a
sense
of
what
I
should
work
on
and
not
get
bogged
down
in
a
bunch
of
notifications
that
aren't
important
in
the
github
mobile
app.
I
can
save
notifications
to
come
back
to
and
mark
notifications
is
done
when
I
no
longer
need
them.
U
One
of
the
things
I
love
about
the
mobile
app
is
push
notifications,
but
I
don't
want
to
be
interrupted
by
push
notifications
for
everything
just
for
things
that
truly
deserve
my
attention,
so
github's
mobile
app
only
sends
you
push
notifications
for
app
mentions
in
this
case.
Amanda
is
mentioning
me
on
a
pr
where
our
colleague,
steve
is
blocked,
looks
like
something
I
should
definitely
check
out
tapping.
U
U
U
U
To
recap
what
we
just
saw.
I
got
a
push
notification
from
my
phone
on
my
co-worker
at
mentioning
me.
I
went
right
to
the
pr
by
tapping
the
notification
I
reviewed
and
approved
it
and
I
merged
it
all
entirely
from
my
phone
github's
mobile
app,
frees
you
from
being
tethered
to
your
desk
and
puts
github
at
your
fingertips.
U
Finally,
here's
how
you
can
try
them
out.
We
only
covered
a
small
subset
of
what
each
of
these
apps
enables
for
you.
So
we
hope
you'll
see
for
yourself
how
you
can
become
even
more
productive
with
githubcli
github
desktop
and
github
mobile
and
as
of
the
last
month,
each
one
of
these
apps
is
available
for
github
enterprise
users,
as
well
as
github.com.
U
To
wrap
up,
none
of
this
would
be
possible
without
the
feedback,
input
and
contributions
from
the
users
of
github's
apps,
since
githubcli
is
open
source.
We
built
gh
credits
to
say
thanks
to
everyone
who
has
contributed,
and
I'd
also
like
to
personally
say
a
thank
you
to
all
the
engineers
and
designers
here
at
github
that
made
these
products
what
they
are
and
who
continue
to
pour
their
hearts
into
making
them
even
better
every
day
and
finally,
to
everyone
who
uses
these
products.
U
D
I
mean
it
really
is
an
interconnected
workflow
when
you
combine
the
power
of
cli
mobile
and
desktop
I'll.
Tell
you
what
you
know
I
like
to
to
think:
I'm
still
cool
and
only
you
sell
cli,
because
my
background
as
a
sysadmin
and
devops
sre.
You
know
it's
like
you
know,
cli
or
nothing
because
gooeys
are
you
know,
that's
for
those
front-end
developers,
but
I'll
admit.
D
Github
desktop
when
I
have
a
conflict
to
merge,
emerge,
conflict
yeah.
I
ain't
going
to
use
no
cli.
I
love
you,
ms
love,
but
I
am
definitely
going
in
there
into
desktop
because
it
makes
it
so
incredibly
easy,
especially
when
you
have
a
mono
repo.
You
know,
or
you
may
be
a
vp
and
and
don't
do
so
good
at
pushing
your
changes
as
fast
as
you
should,
and
you
wait
a
long
time
and
then
you
have
like
a
over.
C
D
But
enough
of
that,
enough
of
that
we
got
some
questions
from
the
people.
Adrian
wood
wants
to
know.
Is
it
possible
to
make
use
of
into
mobile
device
management
with
the
github
mobile,
app
and
billy?
If
you
don't
know
this
one,
I
will
remind
people.
We
got
github
experts
on
discussions
in
the
mobile
team.
That
can
also
answer
this,
but
billy,
maybe
you
know.
D
Oh
no
adrian
wood
wants
to
know:
is
it
possible
to
make
use
of
in
tune
mobile
device
management,
so
the
mobile
device
management
kit,
with
the
github
mobile
app.
U
D
E
E
Yeah
so,
let's
see
now,
we've
got
some
other
questions
coming
in
so
well.
This
one's
more
of
a
general
question
actually
obviously
there's
tons
of
features
in
you
know
the
different
applications
and
the
type
the
applications
you
put
them
in.
It's
kind
of
you
know
it's
interesting,
which
ones
you
put
in
work.
So
how
do
you
decide
which
features
to
build
in
which
application
the
cli
desktop
or
mobile.
U
Yeah,
I
love
that
we
do
a
lot
of
thinking
about
the
domain
that
it's
in
and
so
mobile
is
a
really
interesting
example
here
for
things
that
you're
you're
sort
of
doing
as
part
of
your
workflow
that
I
walk
through.
It's
really
sort
of
the
the
very
surface
level
things
so
triaging
your
notifications
and
sort
of
like
building
up
a
a
to
a
place
where
you
have
everything
in
in
order
or
it's
about
sort
of
like
very
high
signal.
U
Things
like
like
amanda
at
mentioning
me
that
I
needed
to
unblock
a
co-worker
or
there's
a
huge
security
vulnerability
and
like
I
need
to
know
right
now
and
go
like
merge
the
thing
and
get
it
done,
and
so
it's
not
about
sort
of,
like
necessarily
at
this
point,
your
day-to-day
workflow,
but
about
sort
of
augmenting
that
at
either
end
at
the
sort
of
very
low
signal
or
very
high
signal,
and
then
similarly
for
cli
and
desktop
it's
about
like
how
do
we
help
you
get
your
day-to-day
workflows
done
more
productively?
U
D
Definitely
I
mean
it's
always
a
trap
when
you're
making
you
know
an
application
that
looks
and
feels
like
your
main
sas
based,
like
you
know,
desktop
application
that
you're
like
I
need
every
feature
on
every
client.
No,
you
don't
people,
you
don't
need
every
feature
on
every
client.
I
I
love
a
good
mobile
experience
and
I
want
to
streamline-
and
I
want
it
to
be
a
mobile
experience.
Maybe
that's
just.
F
C
D
It's
funny
when
I
think
about
like
the
workflow,
I'm
definitely
now
one
of
those
people
that
sitting
on
the
couch,
slacking
and
hitting
you
know,
github
notifications,
while
I'm
just
chilling
out,
because
you
know
we
have
a
global
team,
I
don't
want
to
keep
people
hanging.
You
know
waiting
for
me
to
do
something
and
it's
been.
D
It's
been
really
a
nice
compliment
because
I'm
gonna
run
in
here
and,
like
you
know,
come
and
hit
hit
the
desktop
or
the
laptop,
but
we
got
a
ton
of
questions,
and
I
know
that
I
could
talk
to
you
all
day
billy,
but
I'm
lucky
I
get
to
do
that
already.
Billy
will
be
available
over
discussions
for
the
next
30
minutes
to
continue
answering
your
questions
about
anything.
Github
productivity
plus
plus
plus
mobile
cli
desktop,
and
we
also
have
some
other
experts
there
so
be
sure
to
post
your
questions.
D
It
we
did
it
it's,
we
have
made
it
to
almost
the
end.
So
I
want
to
say
a
big
shout
out
to
all
the
people
that
have
joined
us
live
that
are
joining
us
on
demand
in
all
the
community
activity.
We
couldn't
do
this
without
you,
there's
been
so
much
good
discussions
and
feedback,
but
you
know
what
that
is
all
from
us.
I'm
sure
you
have
heard
enough
of
us
and
one
quick
thing.
I
want
to
say
a
big
shout
out
to
our
sponsors.
That's
right!
D
If
it
wasn't
for
those
wonderful
sponsors,
we
would
not
be
here
doing
this
today
with
you
they're,
giving
away
demos
and
giveaways
and
prizes
go
check
out
how
you
can
use
some
of
their
cool
things
to
make
your
github
workflow
even
better
I'd
love
today.
But
you
know
what
I
can
jabber
about
that
all
martin.
What
else
do
we
have
for
the
folks.
E
Well,
just
remember
all
the
sessions
that
you've
seen
across
our
track
and
the
developer
track.
You
know
if
you
happen
to
hang
out
there
occasionally,
but
also
the
play
track.
All
of
those
sessions
are
going
to
be
available
on
demand
at
github
universe.com
forever,
for
as
long
as
you
want,
so
you
can
keep
going
back
to
the
site.
You
can
share
those
links
with
your
colleagues.
Let
them
know
which
was
your
favorite
session,
but
let
us
know
what
your
favorite
session
is
as
well.
E
You
know
we
want
to
make
github
universe
better
for
you
every
single
year
and
just
like
with
devops.
We
want
to
improve
every
single
time
and
we,
you
know,
we've
got
a
satellite
event
coming
up
soon
as
well.
So
let
us
know
how
to
make
this
better,
for
you
send
us
a
tweet.
If
you
want
to
send
us
a
message
to
at
github
on
twitter
yeah,
I
finally
got
it
right
the
first
time
in
three
days
or
let
us
know
how
you
want
to
do
by
coming
in
to
discussions.
E
But
yeah
I
mean
make
sure
you
stick
around
for
this
highlight
show
as
well,
because
we've
got
the
final
post-show
wrap-up
with
kyle.
I've
really
been
enjoying
those
the
wrap-up
shows.
You
know
I
mean
that's
kind
of
like
my
bedtime
routine,
when
I
sort
of
switch
off
get
everything
switched
up
in
the
office
and
watch
the
wrap-up
show
with
the
kids
can't
do
that
today,
though
dana
because
you
and
I
are
gonna-
be
on
the
show.
E
So
that
would
be
great,
but
I
know
right,
it
should
be
good,
but
we're
gonna
be
merging
the
stream
soon
now
in
the
stream.
We're
gonna
merge
in
with
the
play
channel,
but
please
do
stick
around
for
half
an
hour
as
I
say,
and
then
we're
gonna
go
into
the
highlight
show,
and
it's
going
to
be
a
good
one.
This
is
carl's
been
trolling
for
bloopers,
and
things
like
that
so
definitely
stick
around,
but
closing
us
today.
E
We've
got
abby
capazi
and
samarth
gulati,
who
are
both
based
out
of
india,
now
they're
going
to
be
using
a
thing
called
tidal
cycles
and
hydra
to
live
code,
the
music
and
the
visuals
and
they're
well
known
in
the
algo
rave
scene,
which
dana
you
know
what
the
algo
rave
scene
is,
of
course,
and
my
glowsticks
know
what
the
algo
rave
scene
is.
Whatever
listeners
that
don't
know
it
was
a
term
coined
by
alex
mclean
and
it's
you
know,
algorithms
and
rave.
E
E
It
was
at
a
a
github
event
in
berlin
with
one
of
our
good
friends,
and
he
was
there,
and
he
took
me
to
this
thing,
and
we
saw
some
like
live
coding
going
on
in
a
club,
and
my
life
hasn't
been
the
same
since
so
let
me
tell
you
that
a
great
night
out,
but
yeah
they
they're
described
as
this
overcoming
set
as
sounding
like
a
post-apocalyptic
party.
What
could
be
better?
I
mean
this
is
the
end
of
universe
so
and
it's
organized
by
robots
after
they've
taken
over
humanity,
which
is
good.
E
E
Remember
I
mean
this
performance
has
a
few
moments
of
flashing
light
in
the
second
half,
so
it
might
not
be
suitable
for
those
with
photo
sensitivity,
so
you
know
tune
in
for
a
little
bit
then
maybe
turn
over.
I
put
due
to
back
in
30
minutes
time
for
the
highlight
show
now
before
we
wrap
up
dana.
I
just
want
to
thank
you
for
co-hosting
the
past
three
days
with
me
and
rolling
with
all
the
craziness.
I
really
appreciate
it.
E
Thanks
to
the
backstage
crew,
it
takes
a
village
to
put
this
thing
together
and
they've
all
been
working
incredibly
hard.
Not
only
did
he
do
our
show
with
us,
for
you
know,
however
many
hours
it
is,
but
then
they
go
take
a
break
and
then
they
go
do
the
apac
show
straight
after
so
it's
been
a
very,
very
long
week
for
them.
E
So
thank
them
very
much
and
also
can't
finish
without
saying,
thanks
to
all
the
hubbers
building
the
products
that
we've
been
talking
about,
that
work
with
you
and
that
you
know
actually
build
these
things
that
we're
getting
to
show
off
this
week
and
all
the
hubbers
have
been
in
discussions.
Answering
questions
and
last
but
not
least,
thank
you
for
you.
P
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
J
Q
Q
Q
Q
Q
Q
Well,
it's
good
to
see
you
back
here
at
the
end
of
day
three
of
github
universe.
It's
been
a
jam-packed
three
days
and
today
I'll
highlight
some
of
my
favorite
talks
from
the
in
performances
from
the
week.
Then
we'll
have
some
fun
with
some
of
the
best
and
funniest
moments
of
the
last
three
days
together.
It's
time
to
celebrate
the
end
of
github
universe,
2020
on
today's
github
universe
highlight
show.
Q
Hello,
everybody
and
welcome
to
the
github
universe
highlight
show
I'll,
be
your
host
kyle
daigle,
and
hopefully
you
already
knew
that
it's
the
end
of
day
three
and
I
get
the
distinct
pleasure
of
sending
you
off
until
we
see
you
at
get
up
satellite
early
next
year,
all
right,
let's
dive
into
today,
and
then
we
can
get
to
the
after
party
all
right.
In
today's
feature
session
principal
engineer
from
google
and,
of
course,
from
kubernetes
fame,
kelsey
hightower
joined
us
to
share
a
bit
about
his
journey
to
becoming
the
person.
B
Q
B
Q
B
It's
the
humans
that
should
be
front
and
center
today,
we'll
be
talking
about
kubernetes
and
get
ops,
and
the
thing
that
kind
of
depresses
me
a
little
is
that
we
tend
to
put
all
these
tools
before
the
humans
that
use
them.
When
you
think
about
git,
it's
one
of
the
world's
best
collaboration
tools
for
writing.
Software
and
github
is
where
we
all
meet
and
collaborate,
but
it's
the
people
that
make
all
of
this
work.
Q
B
Keep
your
config
repo
separate,
so
what
does
that
look
like
in
the
github
world?
Well,
you
probably
know
what
this
looks
like
if
I
click
over
here
to
my
github
tab.
I
just
have
another
repository
where
I'm
storing
all
of
my
configs,
and
here
I
can
have
my
same
git
flow.
I
can
do
pull
requests.
I
can
review
them
and
all
of
my
configs
are
just
sitting
here.
B
Underneath
this
directory
called
kubernetes,
I
can
have
other
deployment
targets,
maybe
you're
using
a
serverless
platform
like
cloud
run,
and
in
that
case
you
may
have
another
directory
of
declarative
configs
that
you
put
there,
but
the
goal
is:
these
are
just
all
data
artifacts
that
can
be
consumed
by
some
other
system.
That
can
actually
take
your
declarative
thing
and
make
it
work.
Q
I'm
going
to
be
honest,
this
was
really
a
talk
that
you
need
to
watch
in
the
end.
Kelsey
did
an
amazing
job
of
telling
a
story
here
and
you're
really
only
getting
a
tiny
taste
in
the
clips
that
we
picked
for
you.
I
highly
recommend
that
you
head
on
over
to
githubuniverse.com
tomorrow
and
watch
the
entire
thing
the
hosts
and
I
have
been
reading
all
of
your
tweets
discussion
posts
and
it's
been
so
much
fun,
interacting
with
you
during
github
universe.
This
year,
I'm
really
gonna
miss
our
time
together.
Q
Let's
dive
in
lisa
has
a
message
for
all
of
those
yaml
haters
out
there
deal
with
it.
Kelsey's
apparent
love
for
yaml
came
through
loud
and
clear
me,
I'm
still
on
the
fence,
but
I'll
deal
with
it.
Okay
now
check
out
this
beautiful
illustration
by
carlo,
you
can
actually
sponsor
him
on
github
sponsors
right
now,
I'll
tweet
out
his
handle
after
this
to
make
it
a
little
bit
easier.
It
covers
all
the
highlights
and
announcements
in
a
beautiful
visual
format
from
the
day.
Q
One
keynote
really
excellent
work,
carlo
and
finally,
we
have
this
amazing
image
from
the
us
stream
today.
It
was
too
good
not
to
share
our
us
enterprise,
hosts,
martin
and
dana
needed
to
kick
it
into
business
overdrive,
and
not
only
did
both
people
wear
suits,
but
martin
was
sporting,
some
very
classy,
yellow
hair
to
match
dana,
never
change
youtube.
Thanks
again
to
everyone
for
sending
in
your
tweets
and
engaging
with
us
and
get
up
discussions,
it
was
so
much
fun
chatting
with
you
now.
Q
Let's
move
on
to
the
rest
of
this
jam-packed
day,
three
by
talking
about
our
talks.
Let's
kick
off
our
review
of
today's
sessions
by
looking
at
project.
Scara
openjdk
is
an
enormous,
open
source
project
that
recently
made
its
migration
over
to
github
along
the
way,
the
team
learned
some
of
the
best
ways
to
ensure
that
maintainers
focus
their
code
review
only
on
the
areas
that
they
know
best.
F
Q
If
you're
considering
migrating
your
large
project
to
github,
whether
that's
an
open
source
project
or
otherwise,
there
were
some
great
hard-earned
tips
in
that
talk,
be
sure
to
check
out
the
replay
changing
gears
a
bit
as
part
of
the
open
source
community.
We
tend
to
focus
on
the
coding,
the
building
of
the
software
on
each
of
the
projects
during
a
panel
on
maintaining
boundaries,
balance
and
funding
in
open
source
west
mckinney
shared
how
important
non-code
contributions
can
be.
N
One
of
the
things
that
I
spend
the
most
time
doing
as
a
contributor
and
a
maintainer
is,
is
you
know,
gardening,
the
issue
tracker
so
organizing
the
reports
that
come
in
getting
more
information
from
the
from
the
issue.
Reporters
closing
out
duplicates
connecting
issues
together,
setting
their
metadata
because,
ultimately,
a
project
that
is
that
is
well
organized
and
and
where
we
have
as
much
information
as
possible
about
the
the
bug.
N
Q
You
can
find
areas
to
jump
into
open
source
right
now
and
chip
in
with
issue
assistance
by
checking
out
github
explorer
or
during
the
holiday
season.
Projects
like
24
pull
requests
where
you
could
find
additional
opportunities
to
chip
in
it's
been
a
huge
year
here
at
github,
and
even
with
all
of
this
going
on,
nicole
forsgren
gave
a
talk
on
the
state
of
the
octopus
and
it's
really
worth
checking
out.
Here's
a
quick
recap
of
the
talk
from
nicole
herself.
Q
There
you
go
you're
all
set.
If
you
want
to
read
the
full
reports,
go
check
them
out
at
octavers.github.com
and
check
out
the
whole
talk
tomorrow,
github
universe.com
yesterday
we
got
a
sneak
peek
from
neha
about
today's
talk
on
how
to
customize
github
discussions
for
your
developer
community.
Here
she
is
talking
about
how
some
of
her
favorite
organizations
are
using
github
discussions.
O
So
here's
an
example
here
where
snowpack
has
used
the
a
pin
discussion
as
their
change
log
and
so
it's
kind
of
pinned
at
the
top.
You
can
see
that
fred's
got
some
spot-on
gifs
here
and
what
I
love
is
that
each
comment
is
a
new
version
and
it
details
and
it
allows
people
to
easily
reply
with
thoughts
or
words
of
thank
or
encouragement.
Q
Q
Go
catch
em,
all
monorepo
tips,
that
is
by
watching
all
of
derek's
talk
and
that's
a
wrap
on
the
over
80
sessions
from
getupuniverse2020
and
a
huge
shout
out
to
the
university
channel
and
the
play
channel,
who
had
amazing
content
as
well
that
maybe
you've
missed
out
on,
but
are
definitely
worth
a
look
a
huge
thank
you
to
all
the
speakers,
performers
and
visual
artists
from
those
channels.
You
really
made
github
universe
a
little
bit
more
special.
If
I
intrigued
you
with
any
of
the
highlights,
you
can
go
and
rewatch
all
the
sessions
tomorrow.
Q
Getupuniverse.Com
go
and
take
a
look
all
right.
We
are
in
the
final
countdown
of
github
universe
this
year
and
now
I'm
in
control,
so
I
want
to
have
a
little
bit
of
fun.
We've
spent
so
much
time
with
each
other.
I
really
think
we've
gotten
to
know
each
other,
and
I
mean
the
sign
of
a
good
friendship-
is
being
able
to
poke
fun
at
each
other
right.
Well,
the
team
was
excited
to
share
announcements
in
the
keynotes.
Q
O
W
O
Q
I've
already
pre-ordered
my
github
brand
blowtorch,
I'm
excited
to
make
some
creme
brulee
after
we
get
done
with
this
anyway.
Thank
you
for
being
such
good
sports
nat,
neha,
ryan,
diana
and
brian
and
letting
us
have
a
laugh,
hopefully
with
you.
Well,
it's
been
a
very
busy
three
days
with
all
of
the
talks,
hundreds
of
questions
being
answered
in
our
github
discussions
board
and
you
were
shepherded
through
the
entire
experience
by
a
few
stalwart
guides.
Q
These
folks
have
been
with
you
as
the
hosts
of
the
developer
and
enterprise
channels,
and
I
thought
it'd
be
only
fair
if
we
brought
them
here
to
celebrate
the
final
moments
of
github
universe,
2020.,
let's
bring
back
kath
and
brian
from
the
developer
channel
and
the
incomparable
dana
and
martin
from
the
enterprise
track.
Hello,
everybody,
hello,.
C
Q
I
know
it's
a
it's
a
brady
bunch
moment
over
here,
thanks.
A
Q
For
sticking
around
a
little
bit
longer
and
having
some
fun
with
me,
while
we
put
the
finishing
touches
on
github
universe,
2020.,
so
listen,
I
sat
down.
I
calculated
it
out
and
you
have
all
been
on
camera
for
over
15
hours
in
total
and
you've
listened
to
so
many
talks
in
questions
kath.
I
want
to
start
with
you
first.
What
was
your
favorite
moment
from
this
github
universe?.
V
Yeah
my
favorite
moment,
you
know
I
just
I
loved
today,
but
I
loved
every
single
day.
My
favorite
moment,
there's
not
just
one,
it's
interacting
with
the
community
on
twitter
on
discussions
and
hearing
all
of
these
talks
and
everything.
But
you
know
there's
something
that
takes
the
cake
and
I
think
it
actually
was
b
dougie's
joke
about
letting
the
docs
out,
because
my
dogs
were
actually
barking
during
my
talk
today
and
that
definitely
I
think
that
deserves
like
a
that's
an
oscar
moment
for
sure.
Q
B,
dougie
on
to
you,
your
setup
looks
amazing
and
I
think
a
lot
of
people
took
notice
while
going
through
all
the
tweets
directed
at
you
between
the
pizza,
beyonce,
jordan
and
your
setup
photos.
Everyone
was
really
loving
it.
Aside
from
the
excellent
talk
you
did,
did
you
have
any
favorite
moments
from
this
year's
github
universe.
G
Yeah
honestly,
this
was
quite
unique
because
normally
I
go
to
universe
and
it's
all
based
in
san
francisco
and
I
get
to
go
talk
to
talk
to
talk,
but
he
was
online
and
I
really
appreciated
the
keynotes,
not
only
because
I
was
in
the
first
one,
but
also
like
erica's
keynote
as
well
as
kelsey's
keynote.
G
It
was
just
really
packed
with
a
lot
of
information
and
I
think
github
sort
of
just
knocked
it
out
of
the
park
with
the
type
of
content
that
I
don't
know
if
everybody
was
expecting
all
the
hard-hitting
facts
and
numbers
and
relationships
to
be
built.
But
yeah
I
mean
I
just
come
away
with
like
awesome,
job,
selecting
keynotes
and
getting
these
speakers.
Q
D
I
don't
know
martin's
amazing
hair,
you
know
he
he
just
looks
so
fabulous.
I
I
heard
that
illuminati
is
a
panton
color
of
the
year.
So,
like
you
know
me
and
martin
are
trendsetters
in
case
you
didn't
know,
but
no,
it
was
great.
I
mean
we
got
some
fierce
women
talking,
I
loved.
I
love
elise
and
rocio
coming
talking
from
intuit
about
how
they
championed
inner
sourcing
and
such
an
amazing
company.
You
know
they
started
as
a
grassroots
effort.
It
was
just
so
inspiring.
Q
And
martin
you're,
no
stranger
to
these
events
either
giving
talks.
I
see
all
the
raspberry
pies
behind
you.
I
think
tell
me
from
your
perspective,
going
through
all
of
the
content
over
the
three
days.
What
does
github
universe
mean
for
all
the
developers
sitting
at
home.
E
Gosh,
it's
it's
late.
You
know
it's
been
nice
like.
Why
is
it
9
29
for
me,
or
something
like
that?
We've
been
on
air
for
50
now
straight.
You
hit
me
with
a
deep
question
like
that.
I
don't
know.
I
hope
what
developers
you
know
like
the
open
source
maintainers
you
just
showed
like
gina,
hoisinger
and
wesley
mckinney,
and
but
also
developers
and
companies,
large
and
small.
I
hope
what
you
can
take
away
from
this
week
is
the
team
here
at
guild.
The
people
too
and
they've
really
got
you
know.
E
They've
really
got
people's
backs.
You
know
they
really
try
to
look
after
the
developers
and
of
us
all.
I
think
I'm
probably
I
am
the
newest
like
github
here,
and
what
I
found
at
github
is
that
github
is
a
company,
that's
really
run
by
developers
for
developers,
for
makers,
for
creators,
for
the
love
of
building
cool
things,
and
we
just
want
to
make
tools
that
get
out
of
your
ways
get
help
you
solve
problems
and
we
want
to
work
with
the
whole
community
to
give
you
the
building
blocks.
E
So
I
said
well
your
best
ways
of
working.
I
guess
anyway,
hopefully
somebody
came
across
if
not,
hopefully,
you've
learned
something
new
and
cool
and
you've
got
a
bunch
of
ideas
about
how
you
can
make
some
cooler
stuff
next
year
or
some
some
new
hairstyle
tips.
Q
Q
I
had
so
much
fun
over
the
past
few
days,
recounting
your
work
and
your
hijinks,
the
presents
that
were
given
the
wigs,
the
glow
sticks
and,
of
course,
the
pizza
hosting,
is
not
an
easy
task
at
all
and
you
all
just
absolutely
knocked
it
out
of
the
park.
So
all
right,
I
think
it's
time
how
about
we
toast
the
end
of
this
github
universe.
Is
everyone?
Have
a
glass
raise
your
water
juice
kombucha
energy
drink?
Q
I
have
champagne,
whatever
you
want
in
whatever
glass
you
want,
you
can
play
along
at
home,
grab
a
glass
of
something
take
a
drink
with
us.
Tweet
us
your
toast,
let's
toast
to
this
github
universe,
to
our
amazing
community
of
developers
from
all
around
the
world.
Without
you
we
wouldn't
be
here.
Thank
you
so
much
for
joining
us
over
the
past
three
days
over
80
talks
and
listen.
I
only
get
to
do
this
one.
So
we're
gonna
go
out
with
a
bang.
Three
two
one
cheers.
Q
Thanks
kath
brian
dana
martin,
please
enjoy
your
well-deserved
time
off
I'll
see
you
later
have
a
great
weekend
guys
and
to
you,
our
community,
for
all
of
the
work
that
you
put
in
maintaining
open
source
projects.
All
those
last
minute
bug
fixes
for
answering
pages
for
your
apps
on
saturday
evenings.
Here's
to
all
your
hard
work,
we
build
github
for
all
of
you
and
I
can't
wait
to
see
what
you
do
with
what
we
built
this
year.
Q
I'd
like
to
take
a
quick
moment
to
thank
the
thousands
of
hubbers
from
around
the
world
who
ship
these
features
for
our
community.
Thank
you
so
much
hubbers
for
all
of
your
hard
work
and
dedication
and,
finally,
a
big
thank
you
to
the
production
team
and
the
team
that
helped
me
put
together.
This
show
every
day,
hey
y'all,
we
made
it.
I
wish
you
all
the
best
of
the
rest
of
the
year
and
here's
to
a
great,
no,
I
mean
like
a
really
great
2021
I'll,
see
you
next
time.