►
From YouTube: GitHub Universe 2021: Day 2
Description
Join us as we explore the future of software.
Join our main broadcast to catch the GitHub keynote and talks from GitHub developers, product pros and open source peers.
https://githubuniverse.com
A
A
A
A
B
B
A
B
C
C
C
C
C
C
C
D
D
D
D
D
D
D
A
A
A
A
A
A
A
A
A
A
C
C
C
C
C
C
A
A
A
A
A
A
C
E
The
biggest
moment
for
me,
you
know
as
a
dev
or
you
know,
as
someone
that
discovered
code
was
the
opportunity
for
me
to
able
to
instruct
the
computer
to
do
something.
I
took
the
game
from
the
internet
and
I
created
a
little
container
that
was
running
as
an
application
on
the
linux
desktop
were
using
back
then,
and
then
I
was
like.
Oh,
how
do
I
get
to
distribute
this
code?
H
We
start
with
this.
It's
like
a
roller
coaster
of
feelings.
You
like
you're,
like
okay
in
the
beginning,
it's
so
exciting
this.
It's
feeling
great.
How
am
I
gonna
work
on
this
task
and
then
you
hit
you
think
of
a
solution
that
doesn't
work
and
then
you
just
keep
going
down
and
down
and
down.
I
use
this
moment
to
push
me
through
other
moments
that
I'm
having
doubt
in
a.
I
J
J
Unfortunately,
modern
software
development
often
means
yanking
you
away
from
code
and
into
boring
manual
work
that
sucks
the
fun
out
of
hacking
on
software
and
building
cool
things
for
every
spectacular,
yes
moment
you
achieve
like
when
you
finally
ship
that
feature
you've
been
wanting
to
deliver
for
so
long.
There
are
sadly
many
no
moments
and
those
really
suck
more
dangerously.
J
They
jolt
you
out
of
flow
and
get
in
the
way
of
making
actual
forward
progress
like
when
ci
jobs
that
have
worked
for
years
randomly
fail
and
mashing
that
rerun
button
just
doesn't
work
or
a
colleague
interrupts.
You
hoping
you
know
the
maintainer
of
a
particular
service
just
because
you
pushed
a
commit
to
it
one
six
years
ago.
J
For
starters,
there
are
millions
of
open
source
projects
on
github
that
you
can
use
and
build
on
to
help
you
be
more
productive,
but
I'm
sure
you're
already
aware
of
that.
If
you're
joining
me
here
today,
instead
of
me
talking
about
the
theory
of
open
source,
I'd
like
to
turn
it
over
to
a
few
folks
to
talk
a
little
more
about
a
very
cool
project,
they've
been
working
on
it's
the
perfect
example
of
how
developers
come
together
to
address
a
set
of
common
problems,
share
their
work
with
the
world
and
invite
others
into
help.
K
So
king
podar
is
the
biggest
real
estate
in
brazil
and
we
are
totally
digital.
So
we
have
solutions
for
renting
and
selling.
My
team
is
responsible
to
take
care
of
the
software
scalability
tribe,
so
the
only
way
to
scale
our
organization
and
our
engineer,
team
and
quality
is
to
stay
on
the
flow
that
people
could
do
their
best,
for
example,
to
focus
on
core
on
code
or
just
on.
K
The
core
feature
help
us
a
lot,
because
we
can
develop
solutions
to
every
step
of
the
software
development
process
being
part
of
the
open
source,
2
and
open
source
community
means
for
us,
because
we
can
not
only
use
those
tools
but
to
contribute
as
well
to
provide
solutions
and
to
be
part
of
this
environment.
We
highly
use
open
source
tools
here
at
king
tundar,
so
backstage
is
it's
an
important
tool
for
us,
because
we
can
improve
our
developer
productivity.
K
L
Backstage
is
an
open
platform
for
building
developer
portals.
It
was
first
open
sourced
by
spotify
and
later
donated
to
the
cncf
in
2020
at
its
core.
A
developer
portal
unifies
all
of
your
tooling
services,
apps
data
and
docs
behind
a
single,
consistent,
ui
backstage
helps
you
understand
everything
that's
going
on
in
your
software
ecosystem,
regardless
of
how
or
where
each
individual
component
is
running.
We
decided
to
open
source
backstage
to
invite
the
community
to
help
us
solve
these
broader
challenges
of
developer
effectiveness.
Together,
the
backstage
project
lives
in
github
and
its
community
is
growing
exponentially.
L
M
My
passion
about
open
source
project
is,
like
everyone
use
your
code.
Everyone
review
your
code
right
now.
We
want
to
focus
accessibility
on
internalizations,
because
there
is
so
much
people
have
some
accessibility
problems
like
visual
epilepsy
or
sound
or
blind.
I
think
it's
more
than
important
to
creating
new
features,
because
you
can
create
your
product
everywhere.
N
So
this
was
my
first
time
contributing
to
open
source
and
even
years
into
my
career,
I
was
really
intimidated
because
I
didn't
know
where
to
start
or
I
didn't
know
what
kind
of
meaningful
contribution
I
could
possibly
make
so
with
fire,
hydrants
plug-in
and
backstage
it
actually
was
a
really
good
experience,
but
once
you
got
into
it,
you
realize,
and
you
drew
on
your
skills
that
you
already
had
working
on
your
current
project.
Your
past
projects
encourages
other
developers
to
be
able
to
contribute
and
help
grow.
This
community
as
well.
J
J
While
the
backstage
platform
is
awesome,
the
global
collaboration
behind
it
is
not
a
unique
story,
and
that
is
a
great
thing.
There
are
millions
of
open
source
projects
powered
by
remarkable
contributors
who
come
together
to
solve
common
problems
in
an
effort
to
improve
life.
For
us
all,
it's
at
the
heart
of
what
drives
us
at
github.
We
are
stronger
and
more
impactful
when
we
work
together,
the
numbers
speak
for
themselves.
J
J
J
J
We
have
so
many
great
sessions
this
week
from
developers
around
the
world
that
tap
into
the
insight
and
experience
of
others
in
the
software
community
consider
checking
out
b,
dougie's
session
on
continuous
delivery
with
actions
or
sessions
on
secure
development.
Later
today,
with
jamie
finnegan
from
hashicorp
and
github's
gray,
baker
github's,
the
readme
project
is
presenting
a
series
of
live
guides,
sharing
best
practices
by
developers
for
developers
on
topics
ranging
from
automation
for
code,
quality,
developer,
onboarding,
better
documentation
and
attracting
contributors
to
your
open
source
project.
J
Emily
freeman
will
take
us
on
a
journey
through
the
decades
exploring
what
comes
after
devops
and
how
we
should
modernize
and
improve
our
processes
to
be
cloud
native,
we're
so
glad
you're
here
and,
however,
you
choose
to
spend
your
time
at
universe.
I
hope
you
walk
away
inspired
to
keep
pursuing
those
yes
moments.
J
J
G
H
We're
working
on
this
new
project,
it's
a
fuel
management
for
airlines.
This
is
amazing,
because
not
only
are
we
saving
these
airlines
a
lot,
but
we're
also
saving
the
planet,
because
if
you
reduce
the
amount
of
fuel
that
is
being
consumed,
you're
also
reducing
the
amount
of
co2
that
is
being
emitted
into
the
environment.
P
Q
Bienvenidos
welcome
back
to
day
two
of
universe.
Are
you
all
ready
to
learn
more
about
how
we
at
github
think
about
our
interconnectedness
of
our
growing
community,
as
we
saw
in
erica's
opening
keynote?
It
isn't
just
developers.
You
know
those
folks
who
write
code
day-to-day
that
are
part
of
the
community.
The
community
includes
an
increasing
number
of
stakeholders,
such
as
maintainers
organizations,
companies
and
more
because
of
this,
the
needs
of
our
community
continue
to
diversify.
Q
Yet
something
shared
across
the
community
has
been
the
creative
ways
that
you,
the
community,
have
been
using
github
to
solve
our
biggest
challenges.
Y'all
truly
are
inspirational
as
a
refresher
to
those
of
you
who
may
be
joining
us
the
first
time
or
again.
My
name
is
lorena
mesa
and,
besides
being
a
trekkie
and
large
at
life.
I
work
here
at
github
in
data
security
products.
As
a
data
engineer.
R
And
my
name
is
jared
mccree
and
I'm
a
staff
product
manager
here
at
github
and
focused
on
the
enterprise
needs
of
our
customers.
Thank
you
so
much
for
joining
us
again
here
on
day,
two
of
get
up
universe
2021.
So,
given
that
today
is
day.
Two
yesterday
was
day
one
and
the
theme
of
day
one
was
inside
github.
There
was
an
absolutely
amazing
keynote
led
by
nat,
where
he
shared
the
github
vision
along
with
the
future
of
software
development.
R
We
then
had
some
sensational
talks
about
our
guests
on
code
spaces,
co-pilot
issues,
actions,
discussions
and
github
enterprise.
Now
remember.
If
you
weren't
able
to
make
any
of
those
sessions,
there's
no
need
for
tears,
because
I
have
some
happy
news.
All
of
those
sessions
were
recorded
and
are
available
right
now,
just
go
to
getupuniverse.com
and
check
out
all
the
talks
we
had
yesterday,
along
with
any
of
the
on-demand
content
that
we
have
available.
R
So
speaking
of
yesterday,
as
I
said
before,
we
had
some
pretty
amazing
talks,
but
funny
enough,
one
of
my
favorite
parts
of
the
day
happened
after
lorena
and
I
signed
off.
I
got
to
watch
some
of
those
on-demand
content
and
one
of
the
my
favorite
ones
was
on
the
topic
of
communities,
see
github
wasn't
around
when
I
was
in
high
school
or
college,
and
it
was
super
interesting
to
see
how
students
and
teachers
use
github
in
their
day
to
day
lorena.
What
was
one
of
yours.
R
So
speaking
of
community,
your
github
community
is
global
and
growing.
We
had
viewers
from
164
countries
tuning
in
yesterday.
I'm
going
to
say
that
again
we
have
viewers
from
164
countries
tuning
in
yesterday,
that's
more
than
three
quarters
of
the
countries
in
the
world
represented
and
since
we
are
a
global
community,
those
of
you
watching
live
with
us
today.
Don't
just
have
to
hear
this
universe.
In
english,
the
main
broadcast
is
translated
into
six
languages
and
you
can
learn
more
by
clicking
on
the
faq
button
at
the
top
toolbar.
Q
R
Well
to
me,
there's
almost
nothing
more
important
than
the
people
you
share
your
life
with
and
when
I
think
of
an
interconnected
community,
I
think
about
how
groups
of
people
come
together,
either
irl
or
virtually
in
order
to
achieve
a
shared
goal
when
those
people
are
able
to
come
together.
Anything
is
possible.
R
Remember
we
also
have
presenters
and
subject
matter
experts
in
get
up
discussions
throughout
the
day.
If
you
have
any
questions
jump
on
in
there
and
ask
and
we'll
get
you
an
answer,
are
you
having
trouble
seeing
the
video
player
or
can't
hear
the
audio?
Well,
if
you're
experiencing
any
technical
issues,
our
team
is
here
to
help
you
can
reach
support
and
discussions
under
the
live
event,
help
q
a
tab
or
via
email
at
events
github.com.
R
Q
T
Hello
world,
my
name
is
david
maylen
and
I'm
here
in
sanders
theater
at
harvard
university,
where
I
teach
cs50
harvard's
introduction
to
the
intellectual
enterprises
of
computer
science
and
the
art
of
programming.
An
introductory
course
for
majors
and
non-majors
alike.
Cs50
is
among
harvard's
largest
courses,
and
indeed
in
healthier
times.
T
Students,
meanwhile,
can
take
both
before
and
after
cs50
itself,
a
whole
suite
of
courses
nowadays
by
cs50s
team,
including
courses
on
artificial
intelligence,
game
development,
web
programming
and
more
of
all,
these
courses
meanwhile,
are
available
at
nx.org
cs50
for
free.
Now
over
the
years
have
we
had
to
provide
students
with
quite
a
bit
of
infrastructure
in
order
to
make
this
and
now
other
courses
possible,
particularly
toward
an
end
to
onboarding
them
to
the
world
of
programming
without
having
to
configure
and
install
software
on
their
own
macs
and
pcs.
T
T
Because
indeed,
if
cs50
is
the
only
proper
programming
class,
they
ultimately
take,
they
can
at
least
continue
developing
even
without
any
of
the
course's
infrastructure.
Thereafter.
So,
in
order
to
achieve
all
of
these
tools,
we
were
motivated
by
trying
to
solve
just
these
three
problems
enabling
students
to
write
code.
T
We
have
students,
log
in
via
oauth
booth,
their
own
github,
usernames
and
passwords
for
authorization.
We've
leveraged
github
support
for
teams
so
that
tas
and
students
can
have
read
and
or
write
access
to
the
same
repos
for
code
reviews.
We
leverage
the
web
ui's
interface
for
pull,
requests
or
or
commits
on
which
you
can
type
perline
comment.
Container
orchestration
now
comes
in
the
form
of
code
spaces,
online
testing
via
github
actions,
version
control
via
git
itself
and
more
and
so
within
each
of
these
environments.
T
Meanwhile,
to
distribute
students,
own
repositories
and
within
its
starter
code,
have
we
been
using
github
classroom
most
recently,
whereby
students
accept
a
assignment
which
has
the
result
of
copying
a
template
repository
for
them
into
our
own
org
that
they
and
perhaps
their
ta
then
have
read
and
or
write
access
to
underneath
the
hood.
Meanwhile?
T
We
leverage
the
web
ui
to
provide
line
by
line
comments,
as
might
be
the
case
with
a
teaching
assistant
working
more
closely
with
their
own
student
and
now,
in
our
case,
for
those
automated
tests.
Do
we
use
our
own
tool
check,
50,
which
essentially
just
wraps
a
unit
testing
suite
for
c
and
python
and
the
like,
but
that
too,
ultimately
is
backed
by
a
github
repo.
T
So
a
student
would
run
a
command
like
check,
50
owner,
slash,
repo,
slash
branch
path
that
simply
indicates
where,
in
the
web
to
go,
get
those
those
correctness
tests
from
in
order
to
run
them
locally
on
the
student's
own
code.
Now,
in
the
graphical
context,
we
also
have
provided
students
and
built
on
top
of
these
primitives,
something
we
call
cs50
lab,
which
essentially
embeds
a
text
editor
and
terminal
window
alongside
a
rendered
markdown
file,
thereby
enabling
us
and
any
of
any
teacher
online
to
create
in
their
own
github
repository.
T
A
learning
experience
for
students
that
might
have
some
starter
code
might
have
some
correctness
tests
and
might
also
have
a
narrative
alongside
it
that
ultimately
lives
in
a
repository
indicated
by
again
owner
slash
repo
slash
branch
last
path,
inside
of
which
two
might
be
a
yaml
file
for
some
minimal
configuration.
The
readme
file
for
itself
and
the
starter
code
and
within
that
yaml
file
would
just
be
a
bunch
of
key
value
pairs
that
tell
our
tool
how
to
configure
the
web
environment
exactly
as
that
teacher
wants
for
their
own
students
also
graphically
as
well.
T
T
Similarly,
have
we
built
a
vs
code
extension
that
allows
students
to
talk
by
a
chat
with
a
virtual
rubber
duck,
giving
them
hopefully
a
bit
of
prompt
for
finding
their
problems
and
then
underlying
all
of
these
tools
is
not
only
docker,
but
now
a
dev
container.json
file,
which
allows
us
to
specify
a
whole
suite
of
configurations
for
students
like
the
extensions
to
pre-install
the
docker
image
to
use
and
the
settings
that
can
customize
the
graphical
user
interface
they're.
Ultimately
using
behind
the
scenes.
T
Meanwhile,
do
we
use
a
suite
of
rest
apis
in
order
to
automate
a
lot
of
the
processes,
especially
with
regard
to
authorization,
but
ultimately,
these
and
more
tools
are
all
freely
available
to
students
and
teachers
alike
and
document
it
at
cs50.readthedocs.io.
The
courses
themselves
are
all
freely
available
at
edx.org
cs50,
and
indeed
this
was
cs50.
U
Hello,
everyone,
I'm
divya
vaishnavi
and
I
have
the
privilege
to
serve
students
and
teachers
across
the
world
with
github
education.
Thank
you,
david
for
cs50's,
inspiring
journey,
providing
the
tools
and
the
infrastructure.
Making
learning,
programming
easy
and
reducing
the
onboarding
friction
the
lives
cs50
touches
is
enormous.
U
We
have
folks
in
github
our
very
own
allison
here,
who's
taken
the
cs50
class,
but
csft
is
not
limited
to
students
only
in
harvard
and
yale.
It's
a
course
for
anyone
with
any
background
across
the
world,
from
kareem
in
egypt
to
anurag
in
india,
who've
been
able
to
enter
the
computer
science
world
with
cs50
and
build
products
and
tools
for
you
and
I
to
use
thus
partnering
with
cs50
and
having
github
solve
some
of
their
key
problems
has
been
a
privilege.
U
So
what
you
saw
was
how
cs50
used
github
classroom
for
assignment
distribution
and
management
as
well
as
auto
grading,
and
I
love
their
unique
adaptation
of
code
spaces
to
reduce
that
key
barrier
of
entry
for
students,
environment
setup.
So
what
they
did
was
created
a
singleton
code
space
with
cs50
dev
container,
all
pre-built
cs50
tools
and
dependencies
and
students
used
that
same
code
space
on
every
subsequent
visit,
ensuring
there
no
environment,
setup
issues.
U
U
You
can
use
auto
grading
to
make
grading
process
a
little
easier
and
automating
parts
of
it,
so
that
you
can
concentrate
on
the
core
pieces
of
teaching,
gives
you
the
ability
to
provide
feedback
in
line
in
code,
and
all
of
this
is
managed
in
github,
so
that
students
learn
the
industry
standard
tool
while
learning
computer
science.
Here's
an
example
of
github
classroom
where
you
can
create
and
manage
coding
assignments
share
the
link
of
the
assignment
with
the
students
and
get
them
going
once
they
accept.
U
It
creates
a
repo
for
them
with
all
the
scaffolding
that
is
starter
code,
feedback,
pr
and
actions
workflow
for
auto
grading,
so
that
all
that
the
students
need
to
do
is
write
code
and
submit
in
your
classroom.
You
can
also
import
student
roaster,
integrating
with
the
various
learning
management
tools,
canvas
moodle
or
many
more,
that
we
support
or
manage
your
tas
as
well
as
administrators.
Here's
a
view
of
assignments
to
see
students,
progress
and
review
their
code
jump
directly
in
the
id
and
run
the
code,
help
them
if
they
are
stuck.
U
Teachers
love
using
github
classroom
because
it
facilitates
that
collaborative
and
individual
work
for
students
teaches
them.
Real
world
tools
helps
them
scale,
their
coursework
to
many
students,
as
well
as
understand
the
sense
of
student
progress,
and
we
want
to
extend
this
power
of
code
spaces
in
classroom
to
a
lot
more
teachers
so
that
you
can
leverage
that
simplified
management,
the
power
of
config
as
code
to
define
setup
requirements
for
your
class
or
assignment
be
confident
that
every
student
gets
that
same
environment
no
more.
U
It
does
not
work
on
my
machine
and
students
get
that
same
seamless,
getting
started
experience
a
one-click
environment
setup.
Thus
we
want
to
partner
with
a
lot
more
teachers
like
cs50,
to
shape
this
integration,
learn
from
you
so
that
we
can
serve
more
teachers
and
students
better.
So
I
invite
you
here
to
sign
up
for
this
pilot
partner
with
us
and
when
you
once
you
sign
up
we'll
share
the
next
details.
U
You
can
also
become
a
campus
expert
and
get
github
support
and
training
or
connect
with
a
local
campus
expert
and
be
part
of
your
cs
community
on
github
global
campus.
You
can
also
view
events
local
as
well
as
global,
so
that
you
learn
from
industry
experts
around
the
world
from
campus
experts
as
well
as
hubbers.
U
There
are
events
in
various
languages,
english,
spanish
and
many
more
computer
science
is
core
to
our
existence
today,
and
empowering
students
with
these
skill
sets
opens
immense
avenues
for
them
and
learnings
that
they
can
take
in
all
walks
of
life.
We
at
github
are
here
to
help
students,
teachers
and
schools
across
the
world
with
the
tools
and
the
support
that
they
need
to
shape
the
next
generation
of
software
development,
so
discover
and
learn
with
education.github.com.
Q
How
cool
is
it
that
harvard
is
doing
this?
They
really
are
on
the
cutting
edge.
The
cs50
global
campus
is
pushing
the
boundary
of
not
only
what
education
looks
like,
but
how
folks
can
experience
education,
therefore
making
it
easier
for
all
of
us.
We
all
know
that
technology
and
software
continues
to
innovate
and
evolve.
An
example
of
some
of
the
folks
that
help
us
build
more
resilient
and
reliable
systems
are
specialists
in
the
devops
space
thinking
out
loud
here.
I'm
actually
not
entirely
sure
where
devops
comes
from.
Do
you
know
jared?
Q
V
Hello
and
welcome
to
acme
inc,
where
the
software
of
tomorrow
is
built
today
here
at
acme,
we
implement
agile
software
development,
a
brand
new
way
of
doing
things.
It
really
razzes
my
berries
so
long,
finder
of
requirements
in
agile.
All
problems
are
solved
through
sprints
chaotic
two-week
segments
of
time,
where
we
promise
to
get
10
features
done
and
delivered
to
our
developers,
write,
bug
riddles
code
and
then
pass
the
code
off
to
our
operations
engineers
via
these
mag
tapes,.
V
V
V
V
We
don't
make
cars
and
with
as
many
fires
as
we
put
out,
the
only
kind
of
car
we'd
be
delivering.
Is
the
pinto?
Well?
Actually,
no,
but
then
two
birds
of
a
feather
were
all
about
flower
power
and
they
found
each
other
in
a
hallway,
at
a
conference
to
talk
about
agile
infrastructure,
eventually
founded
a
network
of
global
conferences
called
devops
days.
These
conferences
brought
together
software
engineers
from
every
discipline
to
discuss
how
to
make
the
clickety
clack
sound
as
a
pound.
V
Devops
was
all
about
people
over
process
and
process
over
tooling
and
it
didn't
stop
there.
You
feel
me
janet
lunch
breaks
are
30
minutes,
not
32..
Gonna
need
you
to
focus.
Devops
was
all
that
and
a
bag
of
chips
over
the
next
decade.
Devops
grew
to
be
an
idea
so
pervasive
that
it's
now
a
job,
listen,
nobody
actually
knows
what
devops
really
means.
I
mean
that
would
make
them
an
expert.
Instead,
it's
a
broad
and
encompassing
philosophy
that
inspires
diverse
implementations
across
the
industry.
V
V
It
all
boils
down
to
the
five
tenants
of
devops
conveniently
expressed
in
the
acronym
calms
culture
automation
lean
hold
on.
It
must
be
this
darn
by
2k
bug.
We
forgot
to
fix
that
we'll
just
stay
calm,
there's
also
measurement
and
sharing
so
bottom
line,
devs
and
ops.
They
need
to
play
nice
and
I
learn
things
occasionally
talk
to
each
other
blame
each
other
for
things.
So
I
know
who
to
fire
yeah.
V
So
you
know,
devops
is
good
and
everything's
fine,
but
you
know
what
calm
is
hard
because
I
live
in
the
real
world
shipping
multiple
times
a
day,
learning
from
what
the
real
world
throws
at
us,
dealing
with
being
on
call
dealing
with
change,
but
trying
to
get
just
a
little
bit
better
at
building
each
and
every
day
we're
all
humans.
We
build
stuff,
we
ship
stuff,
we
sometimes
make
mistakes,
but
when
we
talk
when
we
collaborate
and
when
we
share,
we
can
build
great
things
together,
I'm
emily
freeman.
This
is
github
universe.
R
Are
we
back?
No,
I'm
just
playing
that
was
a
fun
preview
from
emily
freeman
she'll
be
back
at
the
end
of
the
day
for
a
super
interesting
talk
on
the
software
development
lifecycle.
If
you
have
any
burning
questions
about
devops
be
sure
to
add
them
into
discussions
now,
let's
take
a
look
and
see
what's
top
of
mind
for
some
of
our
viewers.
Now
so
I'm
going
to
read
a
quote,
a
comment
from
black
girl
bites
quote.
I
started
using
github
in
2018
when
I
joined
a
boot
camp
called
resilient
coders
at
first.
R
I
was
confused
about
how
to
use
github.
When
I
would
make
a
mistake,
I
would
just
open
a
new
repo
and
close
that
one
out
had
I
made
it
made
a
mistake.
I
didn't
realize
I
could
just
create
another
commit
or
revert
the
commit
like
camilo
garcia
la
rota.
I
was
determined
to
have
a
green
contribution
graph.
I
wanted
to
show
my
teacher
that
I
was
taking
github
seriously.
R
I
just
enjoyed
github
because
it
gave
me
a
chance
to
read
other
people's
code
and
see
how
I
could
make
my
code
better
over
time
after
I
got
my
first
couple
jobs.
As
a
software
engineer,
I
learned
a
ton
from
my
co-workers
about
resolve,
merge
conflicts,
rebasing
get
bisect
and
github
actions.
Apparently
I
felt
so
comfortable
that
I
applied
to
work
at
github
and
now
I'm
here.
Thank
you
so
much
for
that
comment
and
y'all
keep
them
coming.
W
Hello
github
universe,
it's
an
honor
to
be
speaking
to
you
today
from
toronto
ontario.
My
name
is
anthony
vodka.
I
am
the
senior
director
of
our
developer
experience
and
open
source
program
office
at
rbc
at
rbc.
We
are
transforming
the
way,
we're
working
and
is
through
inner
source,
which
is
our
foundational
project
towards
future.
More
active
participation
in
open
source.
W
For
those
that
don't
know
rbc
is
a
global
bank
with
our
headquarters
here
in
toronto,
canada
in
canada,
we
are
one
of
the
leaders
of
the
big
five
banks
when
it
comes
to
customer
service
offering
award-winning
products
to
our
clients.
We
have
pushed
through
into
the
digital
space,
with
over
five
million
active
mobile
users.
W
Now
being
at
150
year
old
bank
servicing
over
17
million
clients
in
over
30
countries,
our
80
000,
plus
employees,
can
become
siloed,
as
you
have
thousands
of
developers
building
our
leading
products
like
any
software
shop.
We
also
get
stuck
on
problems
and
relying
on
our
community
to
help
solve
those
problems.
Those
problems
can
range
from
interacting
with
many
internal
systems,
security,
controls
or
processes
that
no
one
have
ever
seen
before.
W
So
when
someone
asks
a
question,
they
tend
to
ask
their
team
lead,
who
has
their
manager,
who
may
know
someone
else
that
has
come
across
this
before
the
key?
Is
it's
very
ad-hoc
conversations
to
help
developers
solve
problems,
and
we
have
a
great
culture
that
enables
that?
But
what
happens
when
someone
is
in
a
remote
team
at
the
bottom
right
hand
of
the
screen
and
you're
so
siloed
that
that
team
doesn't
have
that
support
network?
W
W
People
wanted
open
source,
but
inside
the
bank
people
wanted
that
inner
source
culture
so
after
successfully
driving
an
open
source
program
in
their
previous
companies.
Our
new
leadership
didn't
need
any
convincing
about
the
power
of
open
source.
They
realized
that
having
an
open
source
program
office
led
to
better
software
engineering
practices
and
today,
open
source
actually
has
become
a
key
supply
chain
of
software
for
all
large
banks,
with
47
actually
making
contributions
back.
So,
at
rbc,
with
the
inspiration
of
the
linux
foundation,
we
came
up
with
a
four
horizon
approach
to
our
strategy.
W
W
We
need
to
bring
that
culture
of
open
source
inside
the
bank,
because
if
we
can't
work
together
inside
the
bank,
how
we
expect
it
to
work
outside
the
bank
now,
because
a
key
principle
inner
source
is
code.
Transparency,
open
source
code
is
an
obvious
supply
chain
of
software
that
comes
into
rbc,
so
our
second
horizon
is
using
open
source
safely
and
respectfully
since
we
consume
so
much
open
source.
Naturally,
we
make
enhancements
fixes
so
horizon.
3
is
about
contributing
back
to
open
source
projects.
W
It
is
the
right
thing
to
do
and
in
some
cases
the
legal
thing
to
do,
but
we
actually
want
to
give
back
because
it
doesn't
make
sense
for
us
to
decouple
our
software
upgrade
and
then
reapply
our
fixes.
We
want
to
give
back
to
the
open
source
community
because
it's
the
right
thing
to
do
and
it
feels
good
to
be
part
of
a
thriving
community
and
finally
horizon
4..
W
W
Out
of
the
gate,
we
could
not
make
all
our
repositories
public
inside
of
rbc.
Our
security
policies
didn't
allow
it
for
two
main
reasons.
The
first
being
projects
were
built
for
a
need
to
know
basis.
There
is
no
central
place,
people
could
build
and
collaborate
on
reusable
software
second
constraint
was
all
projects
need
an
official
owner
at
a
bank.
We
can't
have
orphan
software
if
someone
builds
something
it's
got
to
have
an
official
owner.
W
W
W
W
W
We
are
willing
to
admit
that
it's
not
perfect,
we're
always
looking
to
grow
and
improve
we're
energized
by
the
opportunities
and,
most
importantly,
we're
willing
to
give
instead
of
take.
This
all
sounded
good,
but
I
needed
a
way
to
measure
this,
because
you
can't
manage
what
you
don't
measure,
so
we
started
to
measure
four
things.
We
started
to
measure
the
slack
chatter.
W
Looking
at
our
collaboration,
metrics
from
github,
we
can
see
our
social
events
early
on
was
very,
very
lightly
attended.
But
as
we
had
our
big
community
events,
more
and
more
people
started
working
and
collaborating
on
projects.
Until
we
finally
launched
our
reuse
program
and
when
we
launched
our
reuse
program
in
2019,
we
actually
found
more
and
more
projects,
reusing
it
and
it
just
started
to
grow.
We
can
now
see
teams
that
are
building
in
these
dependencies
into
their
projects
and
deploying
them
to
production
as
more
and
more
apps
reuse.
W
The
amount
of
reuse
increases
as
well,
so
we
can
actually
make
better
decisions
on
what
projects
to
invest
in
which
are
critical
and
which
ones
may
be
needed
to
get
some
more
work
or
decommission
them.
So,
in
the
end,
our
apps
are
now
starting
to
look
the
same.
The
same
icons,
the
same
colors,
fonts
and
more.
W
Our
devs
are
we're
using
our
security
patterns,
mostly
because
it's
just
easy
and
saves
them
time.
So
inner
source
has
really
started
to
transform
the
way
we
work
and
if
you've
ever
read
the
book
crossing
the
chasm.
You
know
there
are
five
stages
we
track
in
adoption.
The
first
stage
is
the
early
innovators.
W
These
are
people
where
you
say
the
word,
inner
source
and
they're
hooked,
and
they
want
to
get
involved.
Second
phase:
is
your
early
adopters,
your
visionaries?
These
are
people
where
you
need
to
spend.
Maybe
two
minutes
with
someone
explain
open
source
inside
the
bank
and
they're
set,
then,
is
that
dreaded
chasm?
W
W
Moving
on
to
the
difficult
part,
this
is
where
employees
want
the
solution
handed
to
them.
They
want
the
convenience
for
that
community
collaboration
and
reuse,
and
in
our
journey
we're
now
approaching
our
chasm
as
we
take
all
the
best
practices.
We've
worked
together
with
the
community
on
and
scale
them
across
the
organization
and
for
us
to
get
started.
We
really
focused
on
building
that
foundation
and
our
strategy
has
really
been
at
first
be
pragmatic,
make
what
these
people
want
the
reality.
W
If
people
want
the
ability
to
do
more
code,
reviews
or
change
their
branching
strategy,
let's
work
with
them
to
set
all
the
foundational
components
and
prepare
to
scale
as
we're
scaling
now
we're
starting
to
look
at
building
a
reward
mechanism,
we're
making
it
easy
for
developers
to
share
and
collaborate.
We
need
to
train
developers.
We
need
to
give
them
rewards
just
to
make
sure
we
attract
that
early
majority,
the
late
majority.
W
Maybe
this
won't
work
for
all
teams,
but
we're
going
to
try
and
the
late
majority
will
focus
on
building
those
small
bespoke
solutions
and,
finally,
the
laggers,
the
skeptics
is,
you
know
we
just
may
need
to
push
in
a
different
direction.
Maybe
it's
a
management
change
or
we
just
really
need
to
try
to
dig
down
deep,
why
it's
not
working,
but
that's
what
our
strategy
is
for
the
next
few
years.
I
want
to
thank
everyone
for
listening
and
look
forward
to
the
discussion.
Q
Wow
learning
how
the
royal
bank
of
canada
is
using
inner
source
to
enhance
developer
experience
is,
to
put
it
simply,
pretty
awesome,
seeing
firsthand
how
organizations
are
learning
from
open
source
to
increase
their
overall
productivity
as
well
as
make
the
developer
experience.
Better
is
just
one
example.
Example
where
we
can
see
that
coding
is
truly
a
collaborative
and
social
experiment.
Q
What
do
you
all
think
about
the
intersection
of
inner
source
and
and
the
developer
experience
make
sure
to
post
your
thoughts
and
discussions?
Maybe
there's
something
you
learned
that
others
can
learn
from
as
well
or
maybe
you
just
have
some
questions
either
way.
Please
share
your
feedback
if
you
want
to
learn
more
about
developer
productivity
and
lots
more
check
out
the
on-demand
library
at
githubuniverse.com,
just
click
on
the
schedule
icon
at
the
top
you'll
need
to
register
for
free,
of
course,
to
access
the
content
up.
Q
Next
we
have
github's
own
resident
beyonce,
be
dougie
github's,
director
of
developer
advocacy,
who
will
be
talking
to
us
about
open
source,
maintainer
tips
with
github
actions.
However,
there's
something
really
special
about
this
session
in
the
theme
of
our
interconnected
community
bdugi
is
here
live
on
this
stage
for
this
session.
X
Thanks
for
the
intro-
and
I
am
really
excited
to
be
here-
live
in
action-
talk
about
the
two
of
my
favorite
things,
which
is
open
source
and
github
actions.
So
jumping
right
in.
I
don't
think
I
need
the
intro
github
actions
at
this
point.
If
you
haven't
got
this
far,
I
have
a
couple
different
sessions
on
universe,
github,
universe.com
that
I
can
cover
that
in
great
detail.
X
But
github
actions
is
automation
for
developer
workflows
and
one
of
the
projects
I've
been
working
on
for
the
past
couple
years
is
open.
Source
opensource
is
a
project
that
I
always
wanted
to
contribute
to
open
source,
but
never
knew
where
to
start
and
open
sauce.
Does
that
for
me,
over
the
summer
we
actually
shipped
an
entire
dock
site,
which
is
actually
powered
by
github
action
so
compiled
and
shipped
to
github
pages.
X
That's
actually
the
visual,
the
work
life
and
I'll
get
into
more
detail
about
that
really
quickly,
but
I
want
to
actually
briefly
talk
about
my
introduction
to
open
source.
So
when
I
was
a
junior
developer
quite
a
few
years
ago,
I
wanted
to
actually
solve
a
problem
and
I
wanted
to
solve
the
problem
with
node.js
and
using
web
hooks.
I
did
a
lot
of
google
and
stack
overflow
and
found
my
myself
onto
a
github
repo
and
at
the
time
I
didn't
actually
know
how
to
use
github.
So
it's
a
safe
space.
X
I
can
admit
that
on
stage
at
a
github
conference-
and
I
went
to
that
repo
found-
the
maintainer's
profile
saw
their
email
there
and
emailed
them
directly
and
lo
and
behold,
they
actually
responded
to
me
and
gave
me
all
the
sort
of
secret
sauce
of
the
project
and
how
node.js
worked
at
the
time
and
all
the
differences,
and
they
did
that
all
during
a
k-pop
concert
too,
as
well.
They
were
actually
traveling
in
thailand
for
a
k-pop
concert,
which
I
didn't
know
what
that
was
at
the
time
I
do
now.
X
So
I
wanted
to
jump
in
real,
quick-
and
I
know
jared
was
here
yesterday
and
he
was
talking
about
he's.
He
reps
atlanta
and
I
wanted
to
actually
wrap
the
east
elena
santa,
which
is
gucci
mane,
and
I
built
that
project
open
sauce
based
on
this
one
concept,
which
was
an
interview
with
gucci
mane.
If
you
don't
got
sauce,
then
you
lost,
and
I
just
didn't
know
where
to
start.
I
was
emailing
maintainers
left
and
right,
which
again,
I
didn't
say
this
before,
but
don't
do
that
just
open
up
an
issue.
X
X
Issue
forms
is
a
great
way
to
sort
of
centralize
information
to
what
we
actually
need
so
like
what
browser
you're,
using
what
version
of
the
project
you're
using
that's
all
helpful
stuff
to
actually
be
able
to
contribute
back,
or
even
you
can
pick
up
that
contribution,
or
I
can
pick
it
up,
but
all
the
context
is
right
there
in
the
issue
and
then
also
get
get
up.
Discussions
is
something
that
I'm
really
loving
right
now,
because
we've
been
heavily
using
github
discussions.
Empty
foley
actually
started
this.
X
This
contribution
with
a
discussion,
so
we
had
the
issue,
but
he
wanted
to
talk
about
this
sort
of
approach
and
how
to
build
this,
because
we
could
have
built
it
directly
inside
of
the
repo,
but
he
actually
took
a
different
path.
So
we
have
an
answered
question
on
the
discussion
and
we
actually
answer
question
with
this
github
action,
which
is
super
powerful
to
be
able
to
contribute
it
to
open
source
in
a
way
that
automates
developer
workflows,
and
I
don't
have
to
maintain
it
so
now.
X
X
The
other
thing
about
that
happened
today,
actually
a
couple
weeks
ago
is
we
have
ten
thousand
actions
in
to
get
the
marketplace,
and
I
was
joking
with
mp
fully
about
this,
because
he
was
so
close
to
being
number
ten
thousand,
but
he
didn't
end
up
getting
it
so
check
out
that
blog
post,
if
you
wanna
know
who
got
the
ten
thousand
action
and
a
couple
other
things
I
wanna
mention
briefly,
is
reusable
workflows.
So
reusable
workflows
is
something
that
got
covered
during
this
event.
X
So
I'm
super
happy
that
this
is
actually
shareable.
All
this
context
is
shareable
it's
open
source
today
and
then
finally,
something
we
shipped
just
recently
is
generating
auto
generating
release.
Notes
if
you've
ever
done
any
release
notes,
I
highly
recommend
it.
I
have
so
many
contributions
and
contributors
who
have
context
of
where
the
project
came
from
and
how
we
got
here
through
the
change
log
so
definitely
check
it
out.
There's
that
button
right
there.
X
You
can
also
power
this
through
github
actions,
just
check
out
the
docs
on
that
as
well
and
then
speaking
about
docs,
not
really
about
docs.
But
I've
got
a
couple
other
sessions
actually
today
about
setting
up
continuous
delivery
of
action.
So
definitely
there's
actually
still
space
in
this
session,
so
sign
up
for
that
and
also
check
out
my
on
demand
session
and
then.
Finally,
if
you
want
to
find
me
on
github,
I'm
b
dougie
check
out
my
myspace
parol
file.
That's
actually
powered
by
github
actions.
Q
It's
always
interesting
to
me
to
learn
how
folks
review
open
source
contributions,
there's
such
variety
from
project
to
project
community
to
community,
so
seeing
firsthand
how
you
are
using
such
features
as
discussions,
actions,
auto-generated,
release,
notes
and
more
to
build.
Reusable
workflows
is
a
great
way
to
help
people
think
about
bottlenecks
that
may
exist
in
their
day-to-day
processes.
X
There's
probably
a
solution
in
there
that
you
can
help
automate
portions
of
your
workflow,
perhaps
deploying
to
npm
or
generating
release,
notes,
that's
all
covered
in
marketplace,
but
I
also
just
kind
of
perused
a
lot
of
large
open
source
projects
and
copy
and
paste
from
their
workflows
too.
As
long
as
it's
mit.
Q
X
Yeah,
my
recommendation
is
like
and
subscribe
to
youtube
channel,
so
youtube.com
github.
A
lot
of
this
content
is
going
to
end
up
finding
its
way
over
there
in
clips.
So
definitely
check
that
out
that
as
well,
but
we
also
have
been
doing
a
lot
of
short
video
content
around
actions
and
code
spaces,
so
highly
recommend
like
and
subscribe
and
hit
that
notification
bell.
Q
X
Yeah
so
I
briefly
went
past
the
project
tables,
but
so
alex
page
who's,
a
developer
at
shopify
on
their
design
system
built
an
action
called
github
project,
automation
plus,
and
I
highly
recommend
check
that
out.
So
every
time
an
issue
is
opened
up
in
your
project,
it
gets
added
to
the
project
table
and
I've
been
using
that
to
power.
A
lot
of
my
work
on
open
source,
also
side
note
discussion,
number
207
is
an
exact
question.
So
if
anybody
has
any
other
ideas
of
good
actions,
check
that
discussion
out
to
you
as
well,
what.
Q
X
Yeah
I
mean
I
create
a
lot
of
actions,
I'm
trying
to
cut
back
going
through
going
through
a
workflow,
but
I
built
this
action
called
take
action.
So
it's
one
of
my
personal
ones,
but
it's
also
something
I've
been
using
during
hacktoberfest,
where,
if
anybody
wants
to
grab
an
issue
off
one
of
my
repos,
they
just
type
in
take
and
they're
able
to
assign
themselves
to
the
issue,
and
I
don't
have
to
worry
about
who's
taking
it
or
if
you
maybe
got
stale,
it
just
gets
unassigned
after
a
while.
X
Yeah
inspiration
comes
from
how
I
got
into
as
being
an
engineer.
All
this
information
is
available,
free,
open
source,
whether
it's
docs
or
just
seeing
how
code
works,
so
I'm
just
really
empowered
and
embodied
by
that
stuff
and
then
pizza,
detroit
style
pizza.
It's
I'm
on
a
kick
right
now,
so
don't
at
me.
I
think
it's.
It
is
the
best
pizza
right
now
I
love
the
crispy
edges.
Q
Well,
as
a
chicagoan,
I
guess
I'm
supposed
to
like
chicago
deep
dish,
but
that's
not
my
thing.
So
you
know
detroit
I
do
have
to
agree,
is
a
bit
better.
Well
on
that
note
beat
dougie.
As
always
I
wanted
to
say
I
had
a
blast
learning
more
about
github
actions
with
you.
I
remember
the
first
time
I
met
you
at
pi,
caribbean.
Q
I
knew
that
you
had
to
be
someone
that
I
introduced
myself
to,
because
how
many
people
do
you
meet
that
introduce
themselves
as
a
company's
resident
beyonce,
but
more
seriously,
I
knew
that
you're,
always
a
person
who's
happy
to
answer
questions
and
can
teach
me
a
lot.
So
I'm
really
really
excited
to
have
been
here
with
you
today.
Q
If
you
want
to
know
more
about
actions
check
out
the
live,
interactive
sessions
coming
up
later
on
day,
two,
a
reminder
that
space
is
limited,
so
please
be
sure
to
sign
up
soon.
Once
you
register,
you
can
find
links
to
access
the
sessions
in
your
my
universe,
schedule
and
also
in
your
email
coming
up.
We
have.
We
have
sessions
from
github's
chief
security
officer
mike
hanley
and
github
star
cassidy
williams.
Q
Did
you
know
that
cassidy
was
her
school's
mascot,
the
entire
time
she
was
in
university?
I
really
love
that
mike
will
share
some
best
practices,
tips
and
tricks
for
reporting
security,
vulnerabilities
and
cassidy
will
give
us
a
peek
into
what
life
as
a
github
star
looks
like
we'll
see
you
back
here
soon.
Y
In
that
mission,
we
really
need
to
leverage
the
collective
power
of
the
open
source
community
of
vulnerability,
reporters
of
security,
researchers
of
open
source
project
maintainers
working
together
to
make
sure
that
vulnerability
reports
are
really
resolved
as
quickly
and
as
completely
as
they
possibly
can
be,
and
at
github.
We
believe
that
coding
is
social,
but
so
is
the
security
work
that
happens
behind
the
scenes
to
protect
those
broader
ecosystems.
Y
Now,
we've
taken
the
time
to
go
back
and
actually
look
at
hundreds
of
vulnerability
reports
that
have
cleared
through
our
security
lab
and
our
research
team
and
disclosed
to
open
source
projects.
You
know
every
every
single
year
and
we've
conducted
a
fair
amount
of
research,
also
going
out
actually
just
talking
to
maintainers
about.
What's
the
experience
of
the
vulnerability
disclosure
process
from
their
perspective
and
what
are
those
interactions
with
vulnerability?
Reporters
actually
look
like
whether
it's
on
github
or
somewhere
else
and
through
those
conversations
that
analysis
the
data
we've
collected.
Y
We
found
really
a
lot
of
opportunities
to
improve
the
way
that
the
security
research
community
and
who
are
reporting
vulnerability,
vulnerabilities
to
projects
and
also
doing
that
original
discovery.
Work
can
work
together
with
open
source
project
maintainers
to
achieve
that
shared
goal
of
getting
to
a
good
security
fix,
and
in
this
talk,
I'm
going
to
take
you
through
a
couple
of
the
tips
there
just
to
help
assure
that
there's
a
positive
experience
on
both
ends
of
this
conversation
and
that
we
quickly
address
those
security
vulnerabilities
when
and
as
they
are
discovered.
Y
So
let
me
just
start
with
the
the
first
rule,
and
I
think
this
is
probably
one
of
the
most
important
ones
and
that's
just
to
establish
the
rules
and
norms
of
collaboration
and
on
the
maintainer
side.
This
is
probably
in
the
form
of
a
security
policy
and
on
the
reporter
side,
this
is
probably
in
the
form
of
a
disclosure
policy.
Y
This
can
actually
result
in
basically
dropping
a
zero-day
vulnerability
through
a
public
issue
or
a
public
pull
request
on
github
as
a
platform,
you've
got
the
opportunity
to
actually
go
set
a
security
policy
for
your
project
pretty
easily
and
try
to
take
as
much
of
the
ambiguity
out
of
this
process.
As
you
possibly
can
this
lets,
you
express
your
preference
on.
You
know
where
and
how
you
want
to
receive
security
reports
and
you'll
find
that
most
security
vulnerability.
Y
Y
Y
Y
So
as
a
reporter,
I
think
just
having
a
cognizance
and
appreciation
and
empathy
for
that
situation
and
experience
can
go
a
really
really
long
way
in
terms
of
working
effectively
and
collaborating
on
some
of
these
issues
and
a
mindset
that
I
would
encourage
you
to
take
going
into
this
is
think
of
a
vulnerability
report
as
a
contribution
like
in
this
capacity.
You
are
acting
as
a
contributor
to
a
project.
Y
This
is
as
important
as
the
mindset
that
you
would
take
to
a
feature
or
pull
request,
or
any
other
improvement
to
a
project
and
thinking
about
that
as
a
contributor
and
if
you're,
a
maintainer
thinking
about
vulnerability.
Reporters
as
contributors
can
go
a
long
way
to
helping
set
that
relationship
off
on
the
right
foot.
Y
What
can
vulnerability
reporters
do
to
make
a
good
contribution
right,
like
it's
helpful,
to
probably
think
through
a
certain
set
of
things
that
make
that
better
for
the
from
the
maintainers
perspective,
and
really
it's
all
about
having
a
very
actionable
report,
that's
easy
to
verify,
triage
and
fix.
I'm
going
to
take
you
through
a
quick
example
to
show
you
what
that
looks
like
we're.
Y
Looking
at
a
report
from
the
github
security
lab
and,
first
and
foremost,
let's
start
with
impact,
have
the
impact
clear
and
upfront
so
that
the
maintainer
knows
what
they're
looking
at
and
can
start
the
process
of
assessing
risk
and
prioritizing
resolution.
Here
we
see
you
know:
we've
got
a
pre-auth
rce
bug,
that's
probably
pretty
serious,
being
clear
and
upfront
with
that
helps
the
maintainer
bump
that
one
to
the
top
of
the
priority
list
in
terms
of
working
on
second,
is
having
a
poc
or
proof
of
concept.
Y
Y
Y
Third,
again
as
a
contributor
think
about
what
can
I
offer
that
help
helps
make
this
easier
to
resolve
and
one
of
those
things
can
be
pointing
out
the
specific
incriminated
code
and
providing
a
helpful
suggestion
on
remediation.
Now,
it's
important
to
remember
that
the
maintainer
is
immersed
in
this
code,
all
the
time
and
probably
has
a
different,
or
you
know,
a
differing
perspective
on
how
to
best
remediate
it.
Y
That
may
be
unique
to
you
as
having
a
security,
research
background
and
perspective
from
that
from
that
particular
role
set.
Fourth
again
going
back
and
referencing
the
disclosure
policy
that
you
have
again
just
to
set
clarity
on
the
norms
and
expectations
that
you've
got
for
the
rest
of
the
engagement
five,
I
think
proposing
your
help
so
proposing
to
review
the
fix.
Y
Last
but
not
least,
ask
for
a
private
patch
environment
on
github.
The
maintainer
can
create
that
private
github
security
advisory
and
they
can
invite
the
reporter
to
collaborate
on
that
in
private,
so
that,
when
things
are
ready
to
disclose,
the
reporter
will
have
reviewed
and
tested
the
patch
and
been
able
to
confirm
for
the
maintainer
that
everything
is
good
to
go.
Y
So
those
are
some
lessons
on
creating
an
effective
report.
Now.
Third,
big
tip
is
really
all
around
notification
and
downstream
communication
in
a
really
effective
and
clear
way.
This
tip
is
primarily
for
maintainers,
but
if
you're
on
the
vulnerability
research
side,
I
think
it's
important
to
understand
this
part
of
the
process.
I
said
earlier
that
collaborative
disclosure
doesn't
end
with
the
report
and
it
actually
doesn't
end
with
pushing
a
patch
either.
Y
It's
really
it's
really
ending
when
you've
got
broad
community-wide
awareness
and
notification
that
the
patch
is
available,
it's
critical
and
what
it's
trying
to
actually
address
in
the
ecosystem,
so
notifying
users
of
the
vulnerability
giving
them
that
path
to
upgrade
to
the
patch
version,
giving
them
that
clarity
on
what
the
underlying
issue
is
and
why
it
matters
to
them
is,
is
really
important.
You
cannot
assume
that
the
downstream
consumers
of
your
project
are
always
just
sort
of
blindly
running
the
latest
version
of
the
product.
Y
From
start
to
finish,
and
when
you
publish
the
security
advisory,
your
security
advisory
becomes
available
to
the
wider
github
advisory
ecosystem
through
the
advisory
database,
as
well
as
to
the
wider
open
source
security
software
ecosystem
through
the
cve
number.
Now
don't
forget,
of
course,
to
credit
the
vulnerability
reporter
for
their
contribution
to
your
product.
Y
Just
like
you
would
any
other
feature
contributor
who
who
provided
something
to
your
project
now
on
dependable,
if
you're
in
a
supported
ecosystem,
whether
it's
go
or
npm,
your
public
security
advisory
will
actually
automatically
trigger
a
series
of
dependable
alerts,
and
the
benefit
of
this,
of
course,
is
this.
Does
a
lot
of
the
leg
work
of
notifying
your
projects
downstream?
Y
Consumers
about
the
exposure
and
for
projects
that
have
enabled
dependent
bot
security
updates
dependable
will
actually
also
create
the
pr
that
will
do
the
update
for
you,
so
you
can
just
review
the
update
see
what's
getting
patched
makes
it
really
really
easy
for
developers
to
adopt
that
latest
and
greatest
and
limit
the
long-term
proliferation
of
the
vulnerable
versions
of
that
code,
so
to
just
kind
of
bring
things
to
a
wrap-up.
You
know
really
a
couple.
Y
Last
but
not
least,
just
the
notifications
piece,
notifying
everyone
who's
using
the
project
and
giving
credit
to
the
reporter
are
critical
steps
and
closing
that
out
on
the
research
side.
Similarly,
being
clear
about
your
disclosure
policy,
be
clear,
but
also
be
flexible
and
part
of
being
flexible,
again,
really
just
means
adopting
a
maintainer
first
approach.
Y
That's
one
of
empathy,
flexibility
being
helpful
understanding
that
maintainers
are
probably
doing
this
along
with
a
lot
of
other
jobs
and
just
staying
focused
on
the
goal,
which
is
patching
the
vulnerability
and
working
in
collaboration
with
the
maintainer
to
get
to
that
outcome.
Now
let
me
just
look
forward
to
what's
next
two
things.
I
want
to
touch
on
here.
First
off
I'd
love
to
come
back
to
you
before
next
year
and
tell
you
disclosure
doesn't
end
with
the
notification
of
the
vulnerability
in
your
project.
Y
Now
we
provide
codeql
as
github
as
a
free
tool
for
open
source
and
we
also
open
source
all
of
our
queries,
so
they're
usable
by
everyone
through
github
code
scanning,
and
we
also
provide
codeql
training
from
the
security
lab
to
help
achieve
this
particular
goal.
Last
point:
really:
around
private
disclosure.
Y
Z
All
right
stars
thanks
for
attending
this
live
session,
thanks
for
all
your
feedback
on
our
product
plans
and
for
all
the
work
you
do
educating,
inspiring
and
leading
your
communities.
One
last
question
think
back
to
what
questions
you
had
when
you
were
starting
in
tech.
What
advice
would
you
give
yourself.
O
Whoa
hey?
Oh
my
gosh.
It
took
you
long
enough
good
to
see
you.
You
have
done
pretty
well
for
yourself.
I
have
so
many
questions
for
you
shoot
ask
away:
okay,
yeah!
I
want
to
figure
out
how
I
can
get
to
this
as
fast
as
possible.
So
first
things
first,
what
programming
language
should
I
use?
It
depends
really
yeah.
You
have
to
think
about
what
is
the
rest
of
the
team
using
what
specific
problem
are
you
trying
to
solve
what
libraries
or
examples
exist
already
to
help
solve
the
problem
in
that
language?
O
O
Sometimes
you
need
to
be
much
more
low-level
with
something
like
see
or
roster
go,
but
when
you're
solving
a
problem,
you
have
to
try
to
use
the
right
tool
for
the
job
and
don't
be
dogmatic
about
it.
Get
comfortable
using
a
few
languages,
and
you
have
many
tools
in
your
tool
belt
to
use,
and
you
have
less
fear
of
picking
up
new
ones,
always
be
learning.
O
Tabs
or
spaces
it
depends
what
that
is,
not
what
the
dude
bros
and
any
of
the
news
groups
say
they
are
so
full
of
opinions.
There's
a
lot
of
opinions,
that'll
follow
you
forever,
but
think
about
it.
Are
you
writing
in
go,
or
are
you
writing
in
yaml?
Are
they
using
editors
that
allow
them
to
control
the
tab
with
or
not
it
depends.
O
What
really
is
evil
is
mixing
them
in
the
same
file
or
passive
aggressively.
Using
that
one
thing,
while
the
team
prefers
something
else,
you
gotta
be
consistent
about
it.
I
guess
I
shouldn't
be
evil.
Should
I
use
letter
const
for
my
variables
it
depends
object,
oriented
or
functional
programming.
That
depends
too.
Okay,
strict,
loose
or
static-typed
languages.
O
O
I
bet
it's
netscape,
yaml,
xml
or
json.
I
gotta
say
it
depends.
Okay,
should
I
merge
squash
or
rebase,
it
depends.
Should
I
use
semicolons
depends
on
so
many
things.
What
branching
model
should
I
use?
It
depends
okay,
how
much
unit
testing
is
enough.
It
depends
vim
or
emax.
That
depends
on
if
you
suck.
R
R
I
could
not
agree
more.
Hitting
that
flow
state
is
just.
I
love
it
so
be
sure
to
give
us
your
comments
and
tag
us
on
twitter
using
the
hashtag
github
universe.
So
we
have
some
great
on-demand
sessions
that
dive
deeper
into
the
topics
that
you've
seen
over
the
past
few
days,
along
with
some
extras.
All
you
have
to
do
is
register
at
githubuniverse.com
and
you'll
get
free
access
to
all
of
the
content.
You
can
even
add
them
to
your
own
personalized
schedule
and
watch
them
at
your
own
convenience.
Q
Up
next
we'll
hear
from
emily
freeman
author
of
devops
for
dummies
and
star
of
emily
vision,
the
delightful
devops
for
the
ages
romp
that
interrupted
our
broadcast
earlier.
Emily
has
some
fresh
and
novel
ideas
about
the
software
development
life
cycle,
so
grab
a
pen
and
a
notebook
school
is
now
in
session.
V
V
Now
I
want
to
be
clear
before
I
even
start.
I
need
your
feedback.
I
want
to
know
what
you
think.
You
can
always
find
me
on
twitter
at
editing
emily
most
of
my
work
centers
around
devops,
and
I
really
can't
overstate
the
sheer
impact
the
concept
of
devops
has
had
on
this
industry.
In
many
ways
it
builds
on
the
foundation
of
agile
to
become
a
default,
a
standard
that
we
all
reach
for
in
our
everyday
work.
V
When
devops
surfaced
as
an
idea
in
2008,
the
tech
industry
was
in
a
vastly
different
space.
Aws
was
an
infancy
offering
only
a
handful
of
services.
Azure
and
gcp
didn't
exist
yet
at
least
not
publicly.
The
majority
of
companies
maintained
their
own
infrastructure
developers,
wrote
code
and
relied
on
sys
admins
to
deploy
new
code
at
scheduled
intervals.
Sometimes
months
apart,
container
technology,
hadn't
been
invented
and
applications
adhered
to,
a
monolithic
architecture.
V
Databases
were
almost
completely
relational,
serverless
wasn't
even
a
concept.
Everything
from
the
application
to
the
engineers
was
centralized.
Our
current
ecosystem
couldn't
be
more
different.
Now,
don't
get
me
wrong.
Software
is
still
hard,
it
always
will
be,
but
we
continue
to
find
novel
solutions
to
consistently
difficult
persistent
problems
now.
Some
of
these
end
up
being
a
sort
of
rebranding
of
old
ideas,
but
others
are
a
unique
and
clever,
take
to
abstracting
complexity
or
automating
toil
or
perhaps
most
important,
rethinking
even
challenging
the
premises
that
we
have
accepted
as
canon
for
years,
if
not
decades.
V
V
For
some
it
can
be
distilled
to
continuous
integration
and
continuous
delivery,
ci
cd
for
others.
It's
simply
deploying
code
more
frequently
adding
tests
security
gates
for
others.
It's
organizational
they've
added
a
platform
team,
even
a
questionably,
named
devops
team,
or
have
created
an
engineering
structure
that
focuses
on
a
separation
of
concerns,
leaving
feature
teams
to
manage
the
development
deployment,
security
and
maintenance
of
their
siloed
services.
V
Whatever
the
interpretation
what's
really
important,
is
there
isn't
a
universally
accepted
standard
of
what
devops
is
or
what
it
looks
like
in
execution?
It's
a
philosophy,
more
than
anything
else,
a
framework
that
people
can
utilize
to
configure
and
customize
their
specific
circumstances
to
modern
development
practices.
V
The
characteristic
of
devops
that
I
think
we
can
all
agree
on
is
that
it
attempted
to
capture
the
challenges
of
the
entire
software
development
process.
It's
that
broad
umbrella.
That
holistic
view
that
I
think
we
should
breathe
life
into
again.
The
challenge
we
face
is
that
devops
is
an
increasingly
outmoded
solution
to
a
previous
problem.
V
V
I
believe
the
era
of
devops
is
waning
and
in
this
moment,
as
the
sun
sets
on
devops,
we
have
a
unique
opportunity
to
rethink
rebuild
even
re-platform.
Now
I
don't
have
a
crystal
ball.
That
would
be
mighty
handy,
I'm
not
completely
certain
what
the
next
decade
of
tech
really
looks
like,
and
I
can't
write
this
story
alone.
I
need
you,
but
I
have
some
ideas
that
I
think
can
get.
V
The
conversation
started,
I
believe,
to
build
on
what
was
we
have
to
throw
away
the
assumptions
that
we've
taken
for
granted
all
this
time
in
order
to
move
forward,
we
must
first
step
back
the
software
or
systems
development
life
cycle.
What
we
call
ubiquitously
the
sdlc
has
been
in
use
since
the
1960s,
and
it's
remained
more
or
less
the
same
since,
before
colored
television
and
the
touchstone
phone
over
the
last
60
years,
we've
made
tweaks
slight
adjustments,
we've
massaged
it
a
little
bit.
V
V
V
Nearly
everything
around
us
is
a
construct,
a
model,
an
artifact
of
a
human
idea,
the
chair
you're
sitting
in
the
desk.
You
work
at
the
mug
from
which
you
drink
coffee
and
sometimes
wine,
buildings,
toilets
plumbing
roads,
cars,
art,
computers,
everything,
the
sdlc
is
a
remnant,
an
artifact
of
a
previous
era,
and
I
think
we
should
throw
it
away
or
more
accurately,
replace
it,
replace
it
with
something
that
better
reflects
the
nature
of
our
work.
A
linear,
single-threaded
model
designed
for
the
manufacture
of
material
goods
cannot
possibly
capture
the
distributed
complexity
of
modern
sociotechnical
systems.
V
It
just
can't,
and
these
two
ideas
aren't
mutually
exclusive-
that
the
sdlc
was
industry,
changing
valuable
and
extraordinarily
impactful,
and
that
it's
time
for
something
new,
I
believe
we
are
strong
enough
to
hold
these
two
ideas
at
the
same
time
showing
respect
for
the
past
while
envisioning
the
future.
I
don't
know
about
you.
I
have
never
had
a
software
project
go
smoothly
in
one
go,
no
matter
how
small,
even
if
I'm
the
only
person
working
on
it
and
committing
directly
to
maine
like
a
maverick
software
development
is
chaos.
V
It's
a
study
in
entropy
and
it's
not
exactly
getting
any
more
simple.
The
model
with
which
we
think
and
talk
about
software
development
must
capture
the
multi-threaded
non-sequential
nature
of
our
work.
It
should
embody
the
roles
engineers
take
on
and
the
considerations
they
encounter
along
the
way
it
should
build
on
the
foundations
of
agile
and
devops
and
represent
the
iterative
nature
of
continuous
innovation.
V
V
What
I
settled
on
is
the
revolution
model.
I
believe
the
visualization
of
revolution
is
capable
of
capturing
the
pivotal
moments
of
any
software
scenario
and
I'm
going
to
dive
into
all
the
discrete
elements
in
a
moment,
but
I
want
to
give
you
a
moment
to
have
a
first
impression
to
really
absorb
the
idea.
V
V
I
don't
expect
gartner
to
build
a
magic
quadrant
around
this
tomorrow,
but
that
would
be
super
cool
and
you
should
call
me
instead.
My
mission
in
this
is
to
challenge
the
status
quo
and
to
create
a
model
that
I
think
more
accurately
reflects
the
complexity
of
modern
cloud-native
software
development.
V
The
revolution
model
is
constructed
of
five
concentric
circles,
describing
the
critical
roles
of
software
development
architecting,
developing
automating,
deploying
and
operating
intersecting.
Each
loop
are
six
spokes
that
describe
the
production
considerations.
Every
engineer
must
consider
throughout
any
engineering
work,
testability,
securability,
reliability,
observability
flexibility
and
scalability.
V
The
considerations
listed
are
not
all
encompassing.
There
are,
of
course,
things
not
explicitly
included,
but
I
figured
if
I
put
20
spokes.
Some
of
us
might
get
a
little
overwhelmed
myself
included.
So,
let's
dive
a
little
bit
deeper,
we
have
long
used
personas
as
a
default
way
to
divide
audiences
and
tailor
messages
to
group
people.
Every
company
in
the
world
right
now
is
repeating
a
mantra
of
developers.
Developers,
developers
but
personas
have
always
bugged
me
a
bit
because
the
approach,
typically
either
over,
simplifies
someone's
career
or
needlessly
complicates
it.
V
V
On
the
other
hand,
I
don't
think
we
need
to
tailor
messages
so
specifically
as
to
call
out
the
difference
between
a
devops
engineer
or
a
release
engineer,
certainly
not
between
a
security
administrator
and
a
security
engineer,
but
perhaps
most
critically,
I
believe,
personas
are
immutable.
A
persona
is
wholly
dependent
on
how
someone
identifies
themselves.
It's
intrinsic,
not
extrinsic,
their
titles
may
change,
their
jobs
may
differ,
but
they're,
probably
still
selecting
that
same
persona
on
that
ubiquitous
drop
down.
We
all
have
to
choose
from
when
registering
for
an
event.
V
I
was
a
developer.
I
will
always
identify
as
a
developer,
despite
doing
a
ton
of
work
in
areas
like
devops
and
ai,
ops
and
devrel
in
my
heart.
I'm
a
developer,
I
think
about
problems
from
that
perspective.
First,
it
influences
my
thinking
and
roles
are
very
different.
Roles.
Are
temporary
inconsistent
constantly
fluctuating?
V
If
I
were
an
actress,
the
parts
I
played
would
be
lengthy
and
varied,
but
the
persona
I
would
identify,
as
would
remain,
an
actor
an
artist.
Your
work
isn't
confined
to
a
single
set
of
skills.
It
may
have
been
a
decade
ago,
but
not
today,
in
any
given
week
or
sprint,
you
may
play
the
role
of
an
architect
thinking
about
how
to
design
a
feature
or
service
a
developer,
building
out
code
or
fixing
a
bug,
an
automation,
engineer.
V
Looking
at
how
to
improve
the
manual
processes,
we
often
refer
to
as
toil
a
release,
engineer,
deploying
code
to
different
environments
or
releasing
it
to
customers
or
an
operations
engineer,
ensuring
an
application
functions
in
consistent,
expected
ways
and
no
matter
what
role
we
play.
We
have
to
consider
a
number
of
issues.
The
first
is
testability.
V
All
software
systems
require
testing
to
assure
architects
that
designs
work
developers.
The
code
works
operators
that
infrastructure
is
running
as
expected,
and
engineers
of
all
disciplines
that
code
changes
won't
bring
down.
The
system.
Testing
in
its
many
forms
is
what
enables
systems
to
be
durable
and
have
longevity
it's.
What
reassures,
engineers
and
leadership
that
any
small
change
will
impact
current
functionality.
V
Security
is
everyone's
responsibility,
but
few
understand
how
to
design
and
execute
secure
systems.
I
struggle
with
this
security.
Incidents,
for
the
most
part,
are
what
we
call
high
impact
low
probability.
Events,
the
really
big
disasters,
the
ones
that
end
up
on
the
news
and
get
us
all
free
credit
reporting
for
a
year.
They
don't
happen
super
frequently
and
thank
goodness
because
you
know
that
there
are
endless
small
vulnerabilities
lurking
in
our
systems.
V
V
This
approach
meant
that
security
was
a
consideration
early
in
the
process,
not
something
that
would
block
a
release
at
the
last
moment.
This
is
also
the
consideration
under
which
I'm
putting
compliance
and
governance,
while
not
perfectly
aligned.
I
figure
all
the
things
that
you
have
to
call
lawyers
about
should
just
live
together,
I'm
kidding,
but
in
all
seriousness,
these
three
concepts
are
really
about
risk
management,
identity,
data
authorization,
there's
lots
of
different
aspects
of
it,
but
the
question
is
really
who
has
access
to
what
when
and
how?
V
And
that
is,
everybody's
responsibility
at
every
stage
site,
reliability,
engineering,
what
we
call
sre
is
a
discipline,
a
job,
an
approach
for
good
reason.
It
is
absolutely
critical
that
applications
and
services
work,
as
expected
for
the
vast
majority
of
the
time
that
said,
availability
is
often
mistakenly
treated
as
a
synonym
for
reliability.
V
V
Reliability
may
be
the
end
result,
but
resiliency
for
me
is
the
journey.
The
action
that
engineers
can
take
to
improve
reliability
observability
is
the
ability
to
have
insight
into
an
application
or
system.
It's.
The
combination
of
telemetry
monitoring,
alerting
all
available
to
engineers
and
leadership,
there's
an
aspect
of
observability
that
overlaps
with
reliability,
which
is
why
they're
neighbors,
but
the
purpose
of
observability
isn't
just
to
maintain
a
reliable
system,
though
that
is,
of
course,
important.
V
It
is
the
capacity
for
engineers
working
on
a
system
to
have
visibility
into
the
inner
workings
of
that
system.
The
concept
of
observability
actually
originates
in
linear
dynamic
systems
and
is
defined
as
how
well
the
internal
states
of
a
system
can
be
understood.
Based
on
information
about
its
external
outputs.
V
They
are
architected
to
enable
the
now
and
the
next
inflexible
systems
change
dependencies
are
reduced
or
eliminated
databases,
schemas,
accommodate
change,
well,
components,
communicate
via
a
well-documented
and
standardized
api.
The
only
thing
constant
in
our
work
is
change.
In
every
role
we
play
creating
flexible
systems
that
will
grow
as
applications
grow
is
critical.
V
Finally,
scalability
scalability
refers
to
more
than
a
system's
ability
to
scale
for
additional
load.
It
implies
growth
and
a
system's
ability
to
grow
over
time.
Scalability
in
the
revolution
model
carries
the
continuous
innovation
of
a
team
and
the
byproducts
of
that
team
within
a
system.
For
me,
scalability
is
the
most
human
of
the
considerations.
V
It
requires
each
of
us
in
our
various
roles,
to
consider
everyone
around
us.
Our
customers,
who
use
the
system
and
rely
on
its
services,
our
colleagues
current
and
future,
with
whom
we
collaborate
and
even
our
future
selves.
We
have
to
read
that
code
too.
Software
development
isn't
a
straight
line,
nor
is
it
a
perfect
loop.
It
is
an
ever-changing
complex
dance.
There
are
twirls
and
pivots
and
difficult
spins
forward
and
backward
engineers
move
in
parallel,
creating,
I
think,
truly
magnificent
pieces
of
art.
V
R
So
that's
it
for
our
main
broadcast
of
universe
2021
and
over
the
course
of
two
days
we've
learned
so
much.
Yesterday
we
took
a
look
inside
github
to
see
how
we're
using
github
to
build
github.
We
saw
how
easy
it
is
to
onboard
new
developers
to
our
teams
because
of
code
spaces
intuitively
track
and
manage
projects
with
issues
tap
into
the
world's
first
ai
pair
programmer,
with
copilot
and
safely
deploy
multiple
times
a
day
to
the
largest
community
of
developers
in
the
world.
Q
And
as
we
discussed
today,
github
is
all
about
community
and
the
amazing
things
we
can
accomplish
by
working
together,
starting
with
our
commitment
to
education,
to
reflecting
from
open
source
and
applying
those
best
practices
to
the
broader
development
life
cycle.
Github
is
here
to
learn
from
each
and
every
one
of
you.
It
is
each
and
every
one
of
you
that
helps
build
what
github
is
today
and
what
we
together
will
be
in
the
future.
If
you'd
like
to
revisit
any
of
the
live
stream
sessions,
they'll
be
available
to
view
soon
right
here
at
githubuniverse.com
jared.
R
Oh,
my
gosh,
just
one
don't
put
me
in
a
box.
No
I'm
just
joking.
I
think
I
think
my
favorite
part
was
the
live
sessions
that
we
had
with
mario
and
b
dougie
like
showing
a
video
of
a
demo
is
cool,
but
seeing
it
live
from,
the
people
that
are
involved
in
the
development
is
really
something
special.
It
gives
me,
of
course,
all
of
you.
The
ability
to
connect
with
the
people
who
are
on
the
ground
floor.
Q
I
could
not
agree
more.
What
have
you
all
thought
of
universe?
Let
us
know
your
favorite,
or
not
so
favorite
moment
by
filling
out
the
survey.
If
you
are
registered,
you'll
find
links
in
your
daily
recap.
Emails
or
everyone
can
find
them
in
discussions
under
event,
help
desk
q
a
it
is
your
feedback
that
helps
us
build
a
better
universe.
Experience
highlighting
the
content
that
you
want
to
hear
as
well
as
exploring
themes.
You
are
passionate
about.
Yes,.
R
Explore
there's
so
much
content
out
there.
The
on-demand
library
is
waiting
for
you,
as
are
the
interactive
sessions
which
kick
off
in
about
30
minutes,
discussion
pages
where
you
can
engage
with
your
community
and
our
experts
and,
of
course,
every
second
of
our
main
broadcast
will
be
available
in
our
on-demand
library.
For
the
next
30
days.
Q
And
although
the
event
is
not
yet
over,
we
couldn't
finish
our
broadcast
without
a
huge
thank
you
to
everyone
who
made
universe
2021
happen
and
by
everyone
we
mean
everyone
at
github,
everyone
behind
the
scenes,
our
broadcast
crew,
that
is,
keeping
the
lights
on
the
live
stream
link
up
the
graphic
artists
and
web
designers.
Our
incredible
performers
and
presenters
are
experts
taking
your
questions
and
discussions
and,
of
course,
all
of
you
watching
right
now.
You
make
this
possible
si
se
puede.