►
From YouTube: 2021-07-19 Cross Team Collaboration Fun Times (CTCFT)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
welcome
to
the
crossteam
collaboration,
fun
times,
number
three
and,
as
usual,
we're
gonna
do
well.
So,
first
of
all,
let
me
bring
it
to
the
agenda.
We've
got
three
really
interesting
talks
lined
up
and
as
usual,
I'm
gonna
run
this.
A
So
first
we'll
have
the
people
speak
and
if
you
wish
to
at
the
end,
we'll
have
some
some
questions
and
if
you
want
to
ask
a
question,
you
can
just
turn
on
your
video
and
kind
of
pop
up
and
wave
your
hand
before
I
was
having
people
leave
comments
in
the
chat.
I
think
we've
not
done
that
much
of
that
it's
not
been
as
important.
A
So
I'm
going
to
just
try
to
just
try
to
say
turn
on
your
video,
otherwise
keep
your
video
off
and
muted
so
as
not
to
not
to
make
it
harder
to
hear
the
speaker.
So
today
we're
going
to
start
with
a
talk
on
mentoring
by
doc
jones
and
then
josh
will
talk
about
the
new
lang
team
initiative
process
and
I
think
felix
and
wesley
wiser
felix.
Is
that
right
or
was
there
anyone
else
planning
to
speak,
I'm
not
sure
about
driving
discussions
via
postmortem
analysis.
A
I
guess
we'll
find
out
and
then
finally
we'll
have,
at
the
end
a
kind
of
social
hour
that
jane
can
talk
about
which
we
tried
last
time
and
it
was
really
fun.
So
any
questions
about
that
stuff
or
shall
we
get
started.
A
All
right,
then,
let's
start
doc,
do
you
wanna
come
on.
B
Yeah,
can
you
can
I
share
my
screen.
You.
A
B
Okay,
so
hi
we're
going
to
talk
about
mentorship
in
its
amazing
incarnation
today
and
it's
my
wish
for
its
shiny
future.
My
name
is
doc
jones.
If
I
seem
nervous
it's
because
I
am
okay,
so
membership
currently
has
many
forms,
as
you
all
know
way
better
than
I
do,
but
so
there
are
mentored
issues.
There
are
there's
the
awesome
mentor
list
and
there's
discord
in
zulu
and
probably
a
couple
of
other
that
are
not
on
this
on
this
slide.
B
Is
that
they're
designed
to
be
one-on-one,
which
is
great,
but
there
might
be
a
good
way
to
be
additive
to
what
already
exists,
and
so
I
want
to
talk
about
mentorship
in
terms
of
how
it
would
work
with
groups
of
people
or
cohorts
for
one
thing,
there's
an
advantage
in
that.
B
I
was
actually
talking
to
ernest
about
this,
who
is
working
on
trying
to
create
onboarding
for
people
with
imposter
syndrome
and
and
kind
of
what
we
resolve
to
is
that,
in
order
for
people
to
to
take
that
step
forward,
the
outcome
has
to
be
worth
the
risk,
and
so
that
becomes
easier
when
there
are
other
people
joining
you
you're,
not
on
your
own.
B
B
So
everybody
here
will
know
how
attractive
this
is,
because
we've
all
experienced
social
hours,
which
is
people
getting
together
in
groups
and
and
talking
to
each
other
and
working
on
things
together
and
sharing
things,
and
so
there's
an
opportunity
not
only
for
great
learning
experience
for
bonding
between
the
members
of
the
cohort
and
also
a
continuous
sort
of
accomplishment
for
to
in
in
for
the
rest
organization
did
I
say
I
was
nervous
okay,
so
sean
chen
is
in
the
room
and
sean
chen
was
my
instructor
for
rust
and
he
actually
ran
two
iterations
of
this
like
four-week
class,
and
what
was
really
interesting
are
some
interesting
observations
that
he
and
I
both
came
away
from
orbit
with
from
this
experience,
is
that
in
the
first
class
there
was
a
lecture
in
the
morning
and
then
students
had
one-on-ones
with
sean,
which
initially
I
thought
was
like
a
great
idea,
because
I
get
personal
direct
attention
from
him.
B
In
the
second
iteration
of
the
class,
sean
decided
to
use
lifeshare,
which
had
all
of
us
working
on
exactly
the
same
code
base
at
the
same
time,
and
so
we
took
turns
like
writing
code
and
either
you
know
getting
correction
or
direction
from
sean
and
at
the
same
time,
our
cohort
colleagues
could
ask
questions,
and
so
we
were
learning
from
each
other
and
learning
from
him
and
also
sharing
this
ability
to
to
learn
how
to
write
code
and
and
not
only
was
it
fantastic,
a
learning
experience.
B
B
Okay,
so
there
actually
are
already
a
couple
of
examples
of
mentorship
with
cohorts
that
I
wanted
to
talk
about.
One
is
the
writing
sessions
that
nico
ran
for
getting
status
quo
stories
and
those
had
a
bit
of
what
I'm
talking
about
about,
but
not
completely.
B
So
it
was,
you
know,
very,
a
very
targeted
person,
a
purpose,
and
there
were
you
know
it
was
a
definitely
a
group
of
people
that
got
together,
but
we
weren't
necessarily
on
common
purpose,
because
the
experts
were
at
were
operating
at
one
level
and
one
set
of
goals
and
the
rest
of
us
who
are
not
experts
were
operating
at
a
different
level
with
a
different
set
of
goals.
Another
example
is
a
project
that
nico's
running
right
now
called
octopodi,
and
I
think
ryan
is
aware
of
this
one
too.
B
I
don't
know
if
he's
here,
but
anyway,
this
is
there's
a
group
of
rust
padawans
who
we're
we're
working
under
the
tutelage
of
nico
to
get
some
metrics
out
of
github
regarding
the
rest
organization,
and
so
we
don't
sort
of
like
the
the
description
of
the
first
rust
class
that
I
had
with
sean.
This
group
doesn't
really
interact
together.
B
We
don't
there's
no
like
icebreaker,
we
don't
talk
on
zune,
it's
strictly
like
zulub
and
and
the
and
mentored
issues,
however,
because
we
are
in
a
group
in
zulu,
there's
it's
kind
of
like
a
50
50
sort
of
arrangement,
if
that
makes
sense,
but
these
two
projects
are,
at
my
wish
level
hat
tip
to
felix.
B
B
If
anybody
else
wants
a
link
to
that,
let
me
know
they
have
over
the
last
three
years
or
four
years
rather
they've
partnered,
with
various
conferences
like
pycon,
piscocades
and
scipy,
to
run
these,
in
conjunction
with
the
conferences
mainly
to
drive
attendance
and
because
of
a
lot
of
the
maintainers
were
already
present.
B
B
So
they
have
two
goals:
one
is
to
assist
contributors
becoming
contributors
and
completing
their
first
pr
in
in
an
open
source
project
and
second,
is
to
give
a
a
place
for
maintainers
to
come
and
pitch
their
projects
and
to
solicit
more
experienced
contributors.
B
My
favorite
thing
I
actually
attended
one
of
these
for
scipy
on
saturday,
and
I
have
to
say
my
my
favorite
thing
about
the
experience.
Was
this
application
called
duckly
and
duckly
like
lifeshare?
Is?
This
is
most?
This
is
like
there's
a
website
for
duckly,
but
what's
great
about
this
is
that
you
can
share
code.
You
can
share
your
terminal.
You
can
share
your
screen,
regardless
of
your
os,
regardless
of
your
ide
or
your
editor,
which
I
just
found
amazing.
B
So
this
particular
screen
is
being
shared
through
the
terminal,
but
it's
a
a
ven
file.
So
if
you
use
vim
I'm
on
vs
code,
it
doesn't
matter.
I
can
work
in
your
code.
If
I
bring
up
my
vs
code,
you
can
work
at
it,
even
though
you're
not
using
vs
code
again
just
just
kind
of
amazing
there's
one
tab,
that's
available
for
duckly,
that's
not
here
and
that's
co-browsing,
but
sharing
the
screen.
B
The
only
difference
is,
I
don't
have
control
over
your
browser.
We
can't
co-browse
okay,
so
here's
just
what
it
looks
like
if
you're
actually
using
an
ide
and
it's
just
it's
a
great
experience-
and
this
is
the
sidebar
where
this
is
what
it
looks
like
when
you
have
this
list
of
projects
that
are
participating
in
the
sprint.
B
It's
simple
to
just
go
here.
Click
on
this
and
there's
a
button
down
here
that
says:
go
live
when
you
select
this
project,
you
just
hit,
go,
live
and
suddenly
all
that
stuff
that
I
showed
you
earlier
is
on
the
screen,
and
I
also
have
the
ability
to
share
my
code
share
my
terminal
co-browse
and
share
my
screen.
B
So
it's
not
just
the
mentor
that
can
do
that
if,
if
it's
necessary
or
it
works,
so
I
along
so
there's
been
a
couple
of
discussions.
This
is
pilot,
but
this
is
also
my
dream
and
sort
of
wishy
talking,
so
I'm
gonna
call
it
a
pilot
there's
nothing.
This
is.
This
is
like
what
a
pilot
would
look
like
if
everybody
agrees
and
we
can
confirm
and
move
forward.
B
I
had
a
discussion
with
felix
and
also
wes
along
with
nico,
and
we
were
talking
about
what
mentored
sprints
might
look
like,
and
the
issue
came
up
of
like
okay.
So
how
do
I
teach
people
how
to
fix
bugs,
and
so
I
sort
of
created
this
as
a
as
an
example
of
what
that
might
look
like
this
is
not
in
fact,
a
pilot.
This
is
a
discussion,
but
one
idea
would
be
you
know.
B
The
first
step
would
be
to
have
a
pre-recorded
video
on
russia
just
describing
the
system
and
how
things
work
and
then
at
the
very
end
of
this
tutorial
would
be
some
way
of
sharing
a
message,
whether
it's
the
chat
or
whatever,
of
how
to
submit
a
comment,
pr
showing
that
they
had
completed
the
tutorial
and
then
they
would
be
eligible
for
the
next
step,
and
the
next
step
would
be
a
a
live
workshop
or
actually
streaming
of
a
video
on
various
tools
that
one
would
need
to
know
about
in
order
to
be
a
successful
bug,
basher
and
then
at
the
end,
there
would
also
be
people
present
to
answer
questions
in
the
live
chat,
but
the
video
would
not
be
would
not
be
like.
B
Would
it
be
street,
streamed,
pre-recorded,
video
and
then
at
the
end,
there
would
also
be
an
assignment
given
out
for
accomplishment
for
attendees
that
wanted
to
move
to
the
next
phase,
and
so
they
would
be
given
directions
on
here's
a
list
of
bugs.
B
You
know,
if
you
close
three
of
these,
then
you
know
you'll,
move
on
to
the
next
stage,
that
sort
of
thing,
and
so
then
they
would
be
invited
to
the
the
actual
mentored
sprint,
which
would
run
through
duckly,
as
I
showed
you
earlier,
and
they
would
be
able
to
work
with
one
or
two
there's
still
discussion
around
like
how
this
work
would
be
broken
down
in
order
to
actually
get
all
of
the
videos
recorded
and
also
this.
This
mentored
sprint
staffed.
B
But
in
any
case,
so
the
people
who
had
accomplished
their
assignment
would
be
invited
to
a
mentored
sprint
and
then
that
mentored
sprint
could
also
be
streamed.
So
that
people
who
were
not
qualifying
but
wanted
to
watch
and
learn
would
be
able
to
do
that.
B
And
finally,
a
mentor
sprint
like
this
could
serve
as
a
qualifying
gate
for
participation
in
actual
compiler
team
sprints.
B
A
A
The
goal
is
to
kind
of
produce,
documentation
right
and
one
example
might
be
the
rusty
dev
guide.
The
idea
would
be
to
pair
up
somebody
who
really
knows
the
code
well,
and
they
could
kind
of
do
a
come
in
maybe
once
a
month
or
infrequently
and
kind
of
explain
how
things
work
and
record
a
video,
ideally
so
that
that
knowledge
can
be
captured
and
people
can
watch
the
video
and
get
immediate
value.
A
And
then
you
would
have
a
group
of
people
who
are
trying
to
learn
how
the
code
works
and
what
they
would
do
is
spend
the
rest
of
the
time
kind
of
when
they
meet
trying
to
write
and
produce
documentation
and
understand
the
code
right
and
then
that
would
be
something
they
can
produce.
And
when
the
expert
comes
back,
he
they
can
sort
of
review.
What
got
produced
and
check
like
correct
any
misconceptions.
A
That
was
the
rough
idea
and
naru
remo
was
named
after
ano
rimo
national
rust
writing
month.
I
guess,
but
we
had
a
bunch
of
crazy
names
for
it
different
kinds,
but
so
I'm
trying
to
think,
whereas
I
think
I
kind
of
covered
most
of
these
points
I
think
yeah.
This
is
the.
The
general
idea
is
to
come
together
and
use
documentation
and
act
in
trying
to
understand
instead
of
just
fixing
books,
all
right.
B
Okay,
so
what
would
be
the
next
steps
so
for
for
mentored
sprints?
If
we're
gonna,
I
mean,
I
think
that
we're
gonna
move
forward
with
the
compiler
team.
We
need
to
recruit
some
organizers
to
handle
coordination
and
communications
around
the
mentored
sprint.
Ideally,
the
reason
I
had
november
is
because
it
would
be
great
to
leverage
all
the
attention
that
rust
is
getting
around
the
new
edition.
B
I
always
want
to
sing
that
now
when
I
say
it
because
of
nico's
video,
but
I
don't
dare
so
record
recruit
working
groups
that
would
want
to
participate
in
mentor
sprints,
so
we
can
do
there
could
be
multiple
groups
going
as
long
as
they're
staffed.
B
B
B
We
need
to
have
some
people
who
are
knowledgeable,
you
know
standing
by
because
or
some
kind
of
a
help
desk
sort
of
vibe.
If
that
makes
sense
again,
I
just
explained
the
target
date,
and
then
we
also
need
to
engage
with
mentored
sprints,
who
has
all
of
these
tools
and
experience
in
delivering
these?
We
don't
have
to
create
that
on
our
own.
B
We
can
rely
on
them
they're,
they
consider
themselves
open
source,
so
there's
nothing
that
they
offer
that
they
charge
for
and
again
relying
on
their
their
experience
with
this
is
would
be
super
helpful
for
us
next
steps
for
nehru,
remo
nico
has
already
volunteered
to
act.
As
the
expert.
B
B
The
expert
of
the
words
is
what
I
should
say
and
then
for
we
need
to
recruit
a
mid-level
compiler
person
who
can
lead
the
cohort
and
basically
interact
with
them
as
they
go
through
their
work
sessions
on
a
weekly
basis,
and
this
person
would
also
be
the
single
point
of
contact
with
the
expert.
B
So
if,
for
some
reason
we
needed
them,
then
the
cohort
lead
could
reach
out
to
them.
The
cohort
lead
can
report
on
our
progress.
That
sort
of
thing,
but
that
would
be
a
one
source,
one
source
of
contact
for
niko,
we're
in
very
early
discussions
with
some
other
possibilities.
Here
I
think
there's
been
some
discussion
on
zulip
about
a
sort
of
a
larger
umbrella
for
the
same
process
for
developing
other
books.
B
B
And
then
this
would
be
their.
My
cohort
mentorship
wish
our
shiny
future,
the
sun
that
was
created
for
neo
and
so
doing
more
of
a
getting
to
know
you
style
of
cohort
mentorship
where
there
would
be
not
only
expert
to
mentee,
but
also
peer
mentorship,
going
on
creating
easier
future
collaboration
among
the
the
cohort
members
and
continuous
contribution
to
rust,
org
and
there's
my
und
indecipherable.
B
A
So
I
am
gonna
sorry
struggling
with
zoom,
okay.
Thank
you
very
much
doc.
I
already
suggested
that
we
should
put
the
the
mentoring
as
a
topic
for
the
social
hour,
so
I'm
gonna
move
forward
with
the
agenda
rather
than
take
a
lot
of
questions
now,
but
I
hope
we'll
have
some
more
discussion
and
I'm
particularly
interested
in
you
know.
I
think
this
could
be
a
great
like
we
should.
We
should
experiment
and
try
to
find
cool
and
new
structures
for
bringing
people
in
at
different
places.
C
C
If
I
have
any
audio
difficulties,
then
I
may
have
to
switch
over
to
dialing
into
the
zoom
meeting
by
phone.
C
C
Perfect
yeah
feel
free
to
just
go
ahead
and
advance
slides
as
soon
as
it
seems
like
that's
the
topic,
I'm
talking
about
so
yeah.
I
want
to
talk
about
how
we
can
better
scale
the
rust
language,
and
to
talk
about
that,
I
want
to
go
over
what
that
means
and
what
types
of
scaling
we
have
to
deal
with,
so
the
rust
community
is
growing
very
rapidly.
This
is
widely
well
known.
C
At
most,
it
tends
to
grow
logarithmically.
So
if
you
get
two
times
as
many
or
ten
times
as
many
people
in
the
community
or
development,
you
might
be
adding
one
new
team,
member
or
one
new
governance
team
to
cover
a
specific
area
and
that's
at
most
often
we
expect
to
grow
the
governance
team
little
if
any,
within
a
single
team,
because
there
are
upper
bounds
to
how
much
coordination
you
can
do
magical
number,
seven,
plus
or
minus
two
or
other
metrics.
C
C
The
number
of
people
in
the
community
for
each
person
in
governance
used
to
be
a
lot
smaller
than
it
is,
and
it
is
becoming
less
and
less
feasible
to
scale
direct
conversation
with
every
single
community
member
within
the
broader
rust
community
about
the
development
of
rust-
and
this
does
not
mean
with
we-
don't
really
value
the
ability
to
coordinate
with
people
and
get
input
and
all
of
those
things,
and
we
don't
want
to
become
any
less
responsive.
C
But
we
need
to
figure
out
how
we
can
give
people
effective
answers,
effective
feedback
and
respond
to
the
needs
of
the
community.
So
the
language
itself
by
design
should
grow
slowly
that
and
it
makes
sense
that
the
governance
grows
with
the
language.
C
So
we're
not
looking
to
scale
the
rust
language
to
where
we
are
linearly,
increasing
the
complexity
of
the
basic
language
syntax
over
time.
We
do
need
steady
growth
in
the
sense
that
there
is
no
end
to
the
things
people
may
want
to
apply
rust
to
and
a
language
that
stops
growing
starts
dying,
but
it's
okay
that
it
grows
slowly.
C
And
that
is
the
sense
in
which
we
need
to
scale.
We
should
not
become
less
responsive
to
the
community
to
the
needs
and
interests
of
the
community
to
the
new
things.
People
want
to
work
on,
and
we
want
to
empower
people
to
have
more
design,
work
and
design
authority,
rather
than
just
investing
all
of
that
exclusively
with
the
governance
teams.
We
want
the
people
who
are
experts
in
these
areas,
like
the
experts
in
async
or
the
experts.
C
There
are
two
kind
of
closely
related
goals
here.
We
want
to
make
more
reversible
decisions,
meaning
that
whenever
a
decision
is
reversible,
we
want
to
go
ahead
and
make
the
opportunity
like
make
that
decision
and
move
on
and
always
have
the
opportunity
to
reverse
it
later,
including
something
in
nightly
rust,
is
not
irreversible.
C
There
is
no
reason
we
can't
let
that
proceed
and
let
people
play
and
experiment
and
try
things
and
on
the
flip
side,
the
more
things
we
make
reversible,
the
more
we
can
do
and
the
more
we
can
experiment.
We
have
a
flag
in
the
compiler,
for
this
is
a
really
experimental
feature
and
you
should
not
mess
with
it
and
depend
on
it
even
in
nightly
rust,
because
it
might
change
wildly.
This
helps
avoid
the
problem
where,
even
with
it
being
unstable,
so
many
people
wanted
async
that
the
await
bang
macro,
like
syntax,
was
felt.
C
People
felt
like
we
needed
to
keep
that,
even
though
it
was
nightly,
because
so
many
people
had
built
on
it,
we're
right
now.
Only
using
the
experimental
feature
flag
for
things
like
advanced
specialization
or
advanced
type
system,
features
that
very
few
people
necessarily
understand
and
can
work
with
easily.
We
should
more
widely
use
that
feature
to
give
people.
The
warning
of
this
is
super
experimental.
If
you're
not
working
on
it,
you
might
not
want
to
poke
at
it.
C
So
with
that
in
mind,
we
want
to
add
a
new
language
team
initiatives,
process
that
expands
on
previous
efforts
and
involves
those
to
make
them
scale
better,
and
I
want
to
talk
about
both
the
process
involved
and,
first,
the
roles
that
go
into
that
process,
and
so
starting
with
the
roles,
we
have
two
major
roles.
Here
we
have
the
owner
of
the
initiative
and
the
liaison
for
the
initiative.
C
The
owner,
we
invest
with
a
large
amount
of
design
influence.
Their
job
is
to
prepare
the
menu
of
design
options,
to
make
recommendations
from
that
menu
to
show
us
the
analysis
and
the
alternatives
that
went
into
those
recommendations,
so
that
we
understand
the
area
and
to
do
all
of
the
coordination
work
with
others
as
needed.
They
are
in
charge
of
this
area
driving
this
with
other
people
working
with
them
we're
ex.
C
This
should
be
the
person
who
is
doing
the
design,
doing
the
selection
working
with
others
and
so
on,
and
this
is
a
substantial
investment
of
time
anywhere
from
you
know:
4
8
40
hours
a
week,
depending
on
how
complex
and
rapid
the
process
is,
then
the
language
team
liaison
role.
We've
previously
talked
about
this
role.
In
other
contexts,
we
had
a
project
system
and
the
liaison
there
had
a
much
larger
and
more
time
consuming
role.
C
Here
we
are
pairing
that
back
and
saying
the
primary
job
is
to
work
with
the
owner,
as
the
single
point
of
contact
provide
language
team
guidance
in
the
form
of
feedback
on
the
design
menu,
the
need
for
further
exploration
or
expansion,
and
in
general,
is
this
going
in
the
right
direction?
Is
time
being
wasted
down
a
a
line
of
thinking
that
won't
really
be
panning
out
and
then
deciding
when
to
escalate
things
to
the
full
language
team
design
meeting,
so
any
actual
design
work
any
status
and
coordination
work.
C
Then
you
take
that
idea
to
the
language
team
via
next
slide.
The
language
team,
repository
and
file
a
proposal
will
have
a
template
and
a
language
team.
Member
can
second
that
proposal
and
in
doing
so
is
volunteering
to
be
the
liaison.
So
this
is
a
notable
change
in
the
past.
We
have
had
people
second,
without
also
committing
to
be
a
liaison
and
part
of
the
issue
with
that
was
that
the
liaison
was
a
much
larger
and
more
time-consuming
role.
C
Now
that
we
expect
the
liaison
to
primarily
be
a
point
of
contact
and
guidance
rather
than
a
partial
owner
themselves,
then
we
believe
that
it
makes
sense
to
say
if
you
want
to
second
this,
you
need
to
be
prepared
to
do
the
work
within
the
language
team
and
then,
as
soon
as
that
gets
seconded
without
like.
If
there
are
no
objections,
then
we
want
to
go
ahead
and
move
forward,
because
again,
this
is
a
very
reversible
thing.
C
So
then,
as
soon
as
that's
done,
people
can
start
exploring
the
design
space,
both
by
like
drafting
rfcs
drafting
text
poking
at
ideas
on
zulip,
but
also
starting
to
land
code
under
an
experimental
feature
gate.
Previously,
we
have
pushed
back
on
the
idea
of
developing
code
until
you
have
your
first
draft
rfc,
except
with
some
rare
exceptions.
C
We
want
to
say
more
often
as
long
as
it's
flagged
as
really
experimental,
you
should
get
to
play
an
experiment
within
the
compiler
land
code.
As
long
as
it's
behind
an
experimental
feature
gate.
This
helps
people
get
a
much
better
idea
of
what
they
should
do.
So
then,
you
finish
the
development
process,
you
land
code,
that
removes
the
experimental
flag
and
you
feel
like
the
feature,
is
more
or
less
complete.
C
You
have
some
explainer
documentation
and
you
get
it
marked
as
feature
complete
by
the
liaison
when
you
feel
like
it's
ready
for
broader
experimentation
and
then
from
that
point
you
stabilize
it
as
usual,
you
get
a
stabilization
report
ready
when
people
have
put
enough
experimentation
into
this
and
they
understand
here's
how
the
space
works.
Here's
why
this
is
the
right
design
of
that
we
chose
we're
comfortable,
going
ahead
and
stabilizing
it.
We
have
enough
experience,
reports
and
so
on
and
then
going
on
to
the
next
slide.
C
The
one
other
thing
we
want
to
get
out
of
this
is
that,
while
we
don't
necessarily
expect
the
owner
to
follow
all
the
way
through
from
design
to
implementation,
not
everybody
who's
doing
design.
Work
should
also
have
to
be
the
person
hacking
on
the
compiler
to
make
it
happen.
We
really
want
the
persistent
expertise
of
the
owner
and
others
in
the
initiative
sticking
around
after
the
design.
C
We
want
to
have
more
people,
we
can
call
on
to
say
hey.
How
does
this
feature
interact
with
this
feature?
Let's
get
the
experts
talking,
so
that
is
the
major
thrust
of
the
new
initiative
process
and
at
this
point
nico,
do
you
want
to
do
questions
now
or
at
the
end
of
the
social
hour?
Let's.
A
Let's
hold
it
till
the
end,
because
I
kind
of
packed
the
agenda
and
I
want
to
get
through
it
in
an
hour.
So.
A
C
An
idea
of
what
we've
been
hoping
to
change
over
to
in
order
to
scale
better
and
to
help
guide
the
process
in
ways
that
let
people
do
more
design
and
not
just
bring
things
to
us
as
something
that
we
need
to
solve
and
design
ourselves.
A
Great,
thank
you
very
much
dash
and
I
see
some
clapping
in
the
comments
thanks.
Everybody
last
last
talk
for
today
wesley.
If
you're
gonna
drive
it,
do
you
want
to
share
your
screen.
D
D
Okay,
cool
so
felix,
and
I
wanted
to
talk
a
little
bit
about
post-mortem
analysis
so
recently,
russ
152,
shipped
in
rus
152.
We
added
some
extra
metal
compilation,
validation
that
looked
for
errors
that
had
previously
been
reported
in
some
sort
of
rare
situations
that
were
hard
to
debug
and
things
like
that,
and
so
we
added
always
on
validation
for
those
things.
D
As
a
result,
some
pre-existing
issues
that
rusty
were
discovered
and
the
net
result
for
users
were
ics
for
the
compiler
so
that
shipped
on
friday
may
6.,
we
discovered
the
issue
pretty
quickly
after
it
shipped
and
users
started
reporting.
B
D
We
deployed
to
mitigation
on
monday
to
disable
incremental
compilation.
Since
then,
we've
been
working
on
resolving
issues
discovered
from
this
and
we're
on
track
to
re-enable
incremental
compilation
in
1.54,
so
because
this
was
a
really
high
profile
issue,
it
got
tweeted
about.
We
got
a
lot
of
issues
reported
on
the
issue
tracker.
A
lot
of
users
ran
into
this.
We
wanted
to
do
a
post-mortem
or
a
retrospective
correction
of
error,
whatever
you
want
to
call
it
to
figure
out
exactly
what
went
wrong
and
how
can
we
improve
things
in
the
future?
D
So
felix
wrote
a
post-mortem
document
as
a
template
that
we've
kind
of
filled
out
and
gone
through
in
some
of
our
weekly
steering
meetings.
We've
used
three
of
those
friday
meetings
so
far
to
hold
discussions
about
the
postmortem
and
so
like.
I
said
we
really
want
to
understand
what
happened
and
why
it
happened.
So
part
of
the
discussion
is
exactly
what
occurred.
D
What
the
error
was,
what
the
impact
of
users
were
and
then
the
chain
of
events
that
caused
it
to
happen,
and
then
the
goal
coming
out
of
this
is
that
we
want
to
fix
our
processes
so
that,
hopefully
we
can
prevent
similar
issues
from
occurring
in
the
future.
But
we
also
we
realize
that
we're
not
going
to
be
able
to
stop
100
of
issues.
So
we
want
to
figure
out
what
we
can.
B
D
To
mitigate
the
severity
of
future
incidents
from
occurring
again-
and
so
this
post-mortem
dock
has
nine
sections
in
it,
it's
kind
of
long
we're
using
it
to
describe
the
efforts
I'm
going
to
go
through
these
briefly.
D
D
So
it
bears
worth
repeating.
A
lot
of
the
focus
here
is
trying
to
prevent
future
incidents,
and
the
focus
is
on
processes
to
prevent
future
incidents,
not
blaming
people
or
things
like
that.
One
of
the
things
that
came
out
of
this
was
that
kind
of
at
each
step.
The
process
that
led
to
the
issue.
D
So,
as
I
said
like
this
really
isn't
about
20
fingers
at
anybody.
In
particular,.
B
D
Anything
like
that,
we
just
wanted
to
figure
out.
You
know
what
happened
and
what
can
we
do
in
the
future
to
prevent
those,
and
so
we
kind
of
want
to
lay
all
the
cards
out
on
the
table
and
see
exactly
what
what
happened
and
without
pointing
fingers
or
shaming
anybody
or
whatever,
because
you
know
as
soon
as
we
do
that
like
one,
that's
just
not
really
healthy
and
two,
it's
gonna
hide
facts
and
it's
gonna
just
cause
us
to
repeat
the
future
so
getting
to
the
template.
D
D
Things
like
you
know
how
many
issues
require
on
wrestling
rest
or
how
many
replies
to
tweets
we
sent
out
this
weekend
or
things
like
that,
a
summarization
of
the
user
impacts.
You
know
for
users
that
hit
this
issue.
They
got
ics
or
code,
wouldn't
compile.
They
couldn't
really
do
anything
unless
they
ran
cargo,
clean
and
rebuild
their
code.
D
And
then
we
also
want
to
look
at
our
response
to
that.
So
how
did
we
learn
about
the
issue
you
know
if
we
wanted
to
have
the
time
to
detect
the
issue?
What
would
we
have
to
do?
How
did
we
get?
How
did
we
find
a
mitigation
for
the
issue
and
then
how
quickly
you
know
in
the
future?
What
can
we
do
to
get
the
mitigation
out
faster
and
then
having
a
timeline
that
kind
of
goes
through?
When
was.
B
D
Initial
issue
shipped:
when
was
it
first
discovered?
How
long
did
it
take
before
we
shipped
a
patch
or
a
fix,
or
whatever
is
also
really
useful?.
D
So
then,
like
I
said
earlier,
we
want
to
dig
into
why
the
event
happened.
The
main
strategy
here
is
the
five
wise
terms.
People
are
probably
familiar
with
that,
but
basically
the
idea
is
you
keep
asking
the
question
why
you
know.
Why
did
we
shift
this
issue?
Why
do
things
go
wrong
et
cetera,
et
cetera
until
you
reach
kind
of
core
causes
for
each
problem
that
you
talked
about
and
this
typically
kind
of
each
answer?
There's
a
lot
of
answers
to
each.
D
So
finally,
we
get
to
you
know
what:
how
are
we
going
to
fix
this
in
the
future
and
so
there's
a
couple
different
sections
here.
There's
lessons
learned
which
are
sort
of
general
things.
Like
you
know
in
this
situation,
maybe
we
shouldn't
have
switched
it
on
so
quickly
or
maybe
we
should
have
been
more
careful
about
tracking
what
released
this
fix
went
out
and
things
like
that.
But
those
are
just
sort
of
abstract
things.
F
D
D
One
of
the
five
why
questions
we
came
up
with
was:
why
did
the
beta
channel
fail
to
catch
this
issue
and
so
part
of
the
answer?
There
was
that
a
lot
of
users
that
do
run
beta
only
run
beta
in
continuous
integration
services,
where
incremental,
isn't
really
used,
and
so
they
didn't
catch
the
issue
there.
Another
answer
is
that
a
lot
of
end
users
don't
actually
use
beta
other
than
that,
like
they
don't
develop
with
beta,
because
either
they
like
the
stability
guarantees
stable.
D
On
nightly
features
on
beta
anyway,
so
then
you
know
there's
another:
why
why
don't
we
incentivize
developers
to
use
data,
and
so
that's
you
know
you
can
continue
going
further
and
further
down
this
path.
D
So,
in
terms
of
outcomes,
our
five
why's
turned
into
21
wise
answers.
We
had
six
lessons,
learned
nine,
correct
actions,
11
action
items-
some
of
these
are
pretty
large
items.
So
if
you
are
interested
in
participating
in
this
or
you
know
trying
to
get
involved,
compiler
team.
D
So,
overall,
I
think
we're
actually
very
pleased
with
the
results
of
the
process.
We've
learned
a
lot.
We've
had
good
discussions
about
the
principles
we
use
to
make
difficult
decisions.
Like
I
said
earlier,
all
of
the
local
decisions
leading
up
to
this
were
basically
correct,
but
there
were
some
things
missing
in
terms
of
process
that
really
caused
things
to
fall
through
the
cracks.
D
So
having
discussions
about
the
principles
we
used
to
make,
these
difficult
decisions
was
really
valuable.
We
came
up
with
some
new
strategies
that
we're
going
to
employ
in
the
future
to
try
to
avoid
similar
issues
and
then,
like
I
said,
there's
a
link
to
the
template
for
the
postmortem.
Felix
actually
has
a
longer
slide
deck,
with
more
information
about
the
specific
results
of
this
postmortem
that
might
be
interesting
to
people
and
then
there's
also
just
the
raw.
I
think
postpartum
issue
as
well,
and
that's
it.
A
A
So
that
was
the
three
presentations
we
had
I'd
like
to
just
we
have
a
little
bit
of
time,
so
I
want
to
open
the
floor
for
a
little
while
either
comments
about
things.
People
said
if
you
want-
or
let's
say
five
minutes
or
any
announcements
or
other
things
that
people
want
to
say,
feel
free
to
either
jump
on
video
or
raise
your
hand
in
the
chat
and
then
we'll
we'll
go
from
there.
E
I
want
to
quickly
chime
in
with
something
just
to
be
clear,
but
the
thing
buzzy
presented,
one
thing
that
I
I
can't
stress
enough
is
that
the
postmortem
document
was
super
super
helpful
for
structuring
conversation
like
it
really
helped
us,
even
though
we
had
three
separate
meetings,
and
that
is
a
lot
of
time
like
three
hour
long
meetings,
it
also,
I
think
they
were
incredibly
productive
meetings,
like
sometimes
those
steering
meetings.
E
Without
you
know
the
structure
of
a
document
or
a
well-written
document,
they
can
go
off
the
rails
or
just
not
be
hard
to
get
engagement
here.
We
saw
super
amounts
of
engagement,
so
that
was
a
really
great
thing
about
it:
to
get
that
to
have
that
structure,
to
guide
things
and
have
people
really
digging
into
those
y's
and
elaborating
that
branching
structure.
The
drawback,
though,
is
that
it's
a
lot
of
work
making.
That
document
was
also
a
lot
of
work.
E
A
E
That
is
an
interesting
theory.
I
would
have
to
review
the
past
point
releases
to
figure
that
out.
I
think
whether
that
makes
sense,
but
my
gut
is
that
it
might
make
sense
like
you
would
think
a
point
release
just
should
be
such
a
major.
The
way
things
are
right
now.
Point
releases
seem
like
they're,
pretty
major
events
and
thus
will
be
justified.
F
Daniel
go
ahead,
so
I
just
wanted
to
to
ask
if
the
intention
on
the
the
the
language
situation
that
josh
described
is
to
be
extended
out
to
all
of
the
tooling
eventually
or
is
it
meant
to
be
only
really
the
compiler.
C
So
I
can
answer
that
one
initially,
we
are
trying
this
for
the
language,
because
we
have
had
specific
scaling
issues
there.
A
Just
to
add,
I
think
I
think
that
the
shape
of
the
process
probably
fits
pretty
well,
the
details
may
change,
so
I
think
that,
like
the
libs
team
has
in
a
sense,
been
doing
a
similar
process
already,
where
you
can
kind
of,
I
think
josh.
You
can
correct
me
if
I'm
wrong,
but
any
member
of
the
libs
team
can
kind
of
r
plus
a
pr
that
lands
in
lightly
and
the
barrier
comes
more
around
stabilization
and
so
forth.
C
Absolutely
yes,
we
have
been
already
adopting
the
be
quick
to
make
reversible
decisions
process
and
very
much
been
going
based
more
on
objections
than
full
team
consensus.
Until
we
get
to
the
point
of
stabilization,
I
think
there
are
other
parts
of
this
process
that
we
are
debating
within
the
libs
team,
whether
to
adopt
or
not,
but
that
portion
has
gotten
almost
universal
appeal.
A
G
Yes,
I
had
a
question
about
what
you
just
said:
josh
based
on
the
fact
that
you're
using
objections
should
there
is
there
or
should
there
be
like
a
minimum
amount
of
time?
G
C
We
hope
that
at
least
seven
to
ten
days
go
by
there's
nothing,
of
course
that
stops
someone
from
starting
to
do
design
work
in
parallel
at
any.
Given
time.
It's
just
the
longer.
You
wait,
the
less
risk
that
you
have,
but
we
in
general
want
to
allow
for
a
little
little
bit
of
time
for
objections.
The
other
thing
we
have
commonly
talked
about
doing
is
one
way
to
skip
that
process.
C
Time
is
that
if
you're
actually
doing
something
with
the
whole
team
involved-
and
you
actually
get
a
sign
off
from
everyone
on
the
team,
then
you
obviously
don't
need
to
wait
for
objections,
because
if
everybody
has
given
an
affirmative
response,
you
don't
really
need
to
wait.
So
we've
talked
about
that
for
rfcs
on
occasion.
H
Sure
so
let
me
see
if
I
can
build
the
slides
from
last
time.
I
don't
think
there's
much
to
it,
but
you
know
we're
going
to
create
a
bunch
of
rooms.
It
looks
like
right
now
we
have
three
and
then
there
will
be
some
three
or
four
looks
like
four
and
then
we'll
have
some
default
rooms
where
people
can
just
basically
hang
out
for
the
next
hour
and
talk
about
whatever
they
want.
A
So
I'm
actually
on
that
note,
I'm
going
to
end
the
recording.
I
want
to
say
thank
you
to
everybody
for
attending
and
especially
thank
you
to
to
doctor
josh
to
wesley
and
felix
for
presenting
and
jane
I'll
make
you
host
and
you
can
set
that
up.