►
From YouTube: 2022-04-18 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
All
right,
hello,
good
evening,
everybody
well
good
evening
for
for
me
in
in
north
america
here,
but
if
we
have
anybody
in
asia
or
australia,
it
might
be
like
bright,
bright
and
early
in
the
morning
for
you
so
welcome
to
the
april
ctcft,
as
always
we're
going
to
be
following
the
rust
code
of
conduct
throughout
this
meeting.
A
We
have
several
of
the
moderators
here
in
the
chat
today,
but
you
can
also
reach
out
to
us
afterwards
either
on
zulip
or
I
should
have
put
the
ctcft
email
here,
but
it's
just
ctcft
at
wrestling.org,
russ,
dashlane.org,
and
so
throughout
today's
meeting
you
do
have
the
ability
to
turn
on
your
camera,
but
we'll
just
ask
that,
while
you're
not
asking
questions,
you
keep
yourself
muted,
you
keep
your
camera
turned
off
and
if
you're
going
to
be
asking
questions
and
you're
not
comfortable
with
video
or
with
talking
feel
free
to
ask
them
in
the
chat
and
I'll
be
more
than
happy
to
relay
them
to
our
speakers
today,
and
so
with.
A
As
with
the
last
few
months,
we've
been
working
to
get
more
suggestions
from
the
community
on
what
talks
we'll
be
doing
over
the
next
few
months,
and
so
this
is
not
only
just
for
like
the
talk
subjects
themselves,
but
also
the
themes
of
each
meetup
and
so
for
this
meetup
we
will
be
doing
or
the
the
theme
for
april
is
learning.
A
So
we
have
some
pretty
great
speakers
here
who
are
both
working
on
separate
initiatives
and
we'll
hear
a
little
bit
from
them
about
some
of
the
stuff
that
they've
been
doing
and
what
they've
learned.
But
we
don't
have
a
theme
for
may
just
yet.
We
do
have
some
ideas
and
we'll
be
discussing
it
as
a
ctcft
team,
but
we're
always
open
for
people
suggesting
themes
and
so
feel
free
to
either
suggest
a
talk.
A
If
you
know
something,
that's
interesting,
that's
happening
in
the
rust
world
or
within
some
rust
teams,
suggest
a
theme
for
future
months
and
yeah.
You
can
do
that
at
the
ctcft
repo
and
so
to
get
us
started
today.
We're
going
to
be
having
john
hoe,
who
is
going
to
be
talking
to
us
about
teaching
intermediate
rust
and
so
john.
I
will
pass
that
torch
over
to
you
I'll,
stop
sharing
here
and
let
you
get
going.
B
Can
you
see
the
slide,
looks
good
yes,
perfect
and
because
I'm
using
a
tiling
window
manager,
it
jumps
around
a
bit
and
there
it
should
be.
A
B
Interesting
is
that
better?
This
is
good.
Yes,
all
right.
Let's
use
that!
Instead,
that's
fine,
all
right,
okay,
hi
everyone!
My
name
is
john
and
I'll.
I
want
to
do
this
by
first,
just
like
who
am
I
just
in
case
you
don't
know,
I
wrote
russ
for
rostations,
which
is
a
book
that's
intended
to
follow
the
rust
book.
It
sort
of
intended
to
be
sort
of
you've
learned
the
basics.
Now,
let
me
teach
you
more
about
the
the
more
intermediate
aspects
of
the
language.
B
I
do
libros
programming
on
youtube
and
I
maintain
the
rust
build
tooling
at
aws
and
I'm
giving
this
talk
because
and
I'll
get
back
to
what
the
talk
is
actually
about
in
a
second,
because
I
I've
been
trying
to
teach
intermediate
rust
for
years,
but
both
through
writing
that
book,
through
the
videos
and
also
internally
at
at
amazon,
but
also
internally
at
mit
around
the
research
group.
I
was
working
on
there.
B
A
lot
of
that
was
just
like
trying
to
get
people
on
board
with
rust,
helping
them
when
they
get
stuck,
and
so
I
I've
fielded
a
lot
of
questions
from
rust
developers,
both
new
and
experienced
over
time-
and
this
has
left
me
in
a
position
where
I've
seen
a
lot
of
the
things
that
treat
people
up,
and
I
see
the
the
things
that
keep
tripping
people
up
as
they
try
to
graduate
further
into
the
language.
And
so
that
brings
me
to
today's
talk.
The
the
talk
I'm
giving
is
is
on
why.
B
Why
is
russ
still
hard
to
teach,
and
I
don't
mean
that
in
terms
of
the
language
itself
like,
there
are
obviously
things
that
are
complicated
and
that
are
hard
to
teach
in
that
way.
But
what
are
things
that
we
can
make
better?
What
are
things
where
there
is
unnecessary
friction
to
the
teaching
aspect
of
things,
and
I
I
think
it's
going
to
be
easier
to
see
what
I
mean
by
that
as
we
go
through
the
talk.
B
B
The
first
of
these
is-
and
this
comes
up
a
lot
is:
where
do
I
look
things
up
and
where
do
I
ask
questions
and
this
pans
everything
from
beginners
to
extremely
advanced
bus
developers?
This
problem
just
keeps
coming
up,
and
it's
not
that
weird,
because
if
you
look
at
it,
there
are
so
many
resources
and
the
list
keeps
growing
right.
I've
listed
some
of
them
here,
I'm
not
going
to
go
through
all
of
them.
B
And
it's
not
that
I
mind
the
dms
is
that
it
suggests
a
deeper
problem
with
how
people
learn,
how
people
pick
up
the
language,
how
they
explore
the
ecosystem,
and-
and
it's
great
that
we
have
all
these
avenues-
that
we
have
all
these
resources
different
people
have
developed.
The
problem
is
that
it's
very
hard
to
navigate
and
it's
very
hard
to
discover
what
resources
are
out
there.
So
we
end
up
with
people
repeating
questions
repeating
you
know
these
these
longer
explanations
of
how
something
works.
B
We
end
up
with
repeated
books
of
repeated
content
and
that's
unfortunate.
There
are
some
resources
to
try
to
organize
this
information
right.
We
have
the
book
of
rust
books.
We
have
the
rust
learning
repo.
We
have
the
awesome,
rust
repo.
B
We
have
the
awesome
rust
mentors
repo
for
for
mentors,
but
those
are
themselves
hard
to
find
like
how
would
you
know
to
look
for
these
if
you
didn't
know
that
they
existed
already
and
all
of
them
suffer
from
this
giant
list
problem
of
they
list
a
bunch
of
other
resources
that
then
have
lists
of
table
of
contents
or
of
other
resources,
and
it
just
becomes
this
this
feeling
seemingly
endless
supply
of
resources
where
no
one
really
knows
where
to
go.
B
If
you
just
have
a
question,
and
the
question
is,
can
we
do
better-
I'm
not
proposing
here
that
we
just
like
have
one
resource?
That
is
everything,
but
can
we
find
some
way
to
organize
this
information
to
make
it
easier
for
people
to
get
to
the
place?
That
explains
the
thing
they're
looking
for
faster.
B
And
then
to
switch
categories
completely.
The
other
thing
that
I
see
come
up
a
lot
is
that
paper
cuts
tend
to
inhibit
learning.
What
do
I
mean
by
that?
Well,
the
rust
language
has
a
lot
of
known
shortcomings
and
they're,
not
that
bad.
If
you
know
that
that's
what
they
are,
if
you're
an
experienced
developer-
and
you
know
you
know
that
that
there's
this
particular
bug
in
the
borrow
checker
or
in
the
trade
system
or
this
this
feature
hasn't
been
implemented
or
whatnot.
B
B
That
is
extremely
frustrating
and
it's
something
that
I
think
we
should
work
really
hard
on
fixing,
and
I
know
we
are
ready,
but
I
think
it's
valuable
to
prioritize
these
kinds
of
fixes
to
give
some
concrete
examples.
Here
are
some
some
tickets
that
keep
coming
up
for
me,
one
is
there's
an
issue
where
closure
arguments
need
to
be
specified
or
the
code
won't
compile
their
cases.
B
There
are
known
problems
even
with
nll
on
borrows
and
early
returns,
there's
some
confusion
between
function,
def,
f
and
def
items
and
function,
pointer
types
which
are
different
types
and
rust,
and
there's
no
automatic
coercion
between
them.
Arguably
also
things
like
trait
aliases,
gat
and
and
type
alias
infiltrate
are
also
things
where
newcomers
or
experienced
developers
will
try
something
and
it
just
won't
work,
even
though
it
sort
of
seems
like
it
should.
B
It
seems
like
a
natural
part
of
the
language,
and
you
just
get
an
error,
and-
and
I
think
that
that
causes
people
to
to
get
stuck
when
they
shouldn't
need
to
be
another
thing
that
I
see
a
lot
is
that
choices
are
hard
in
rust
and
and
I
don't
think
this
is
a
a
rust
only
problem
right.
B
This
is
arguably
a
fundamental
problem
that
sometimes
there
are
just
multiple
options
and
you
need
to
be
able
to
pick
between
them,
but
it
is
a
major
stumbling
block
and
we
see
this
all
throughout
the
rust
ecosystem,
both
in
the
standard
library
and
in
the
ecosystem.
More
broadly
right,
do
I
use
rc,
or
do
I
use
arc?
Do
I
use
mutex
or
refsell
or
cell?
Do
I
use
us
or
isis
or
non-zero
types
or
whatever
tokyo
async
stood,
is
a
classic
one.
B
All
of
the
different
error
handling
libraries,
all
the
different
command
line,
parsing
libraries
or
you-
have
the
ones
where
there
aren't
any
clear
alternatives
right
like
regex
and
rand.
There
are
some
that
are
sort
of
starting
to
creep
through,
but
realistically
these
are
the
ones
you
will
use
and
again
choices
here
is
good
right
it.
It
is
valuable
to
have
this
this
wide
array
of
possibilities.
B
That
kind
of
stuff
helps,
but
it
only
helps
to
an
extent
because
it
relies
on
a
sort
of
faithful
evaluation
of
the
other
products,
but
it
also
is
hard
to
maintain
over
time
and
keep
up
to
date,
it's
hard
to
write
in
the
first
place.
That
requires
a
lot
of
work
and
it's
not
clear
that
they're,
like
standardized.
No
very
few
people
actually
do
this
very
few
projects,
and
so
the
question
is:
can
we
encourage
that
somehow
to
to
make
these
kinds
of
choices
easier
like
in
the
standard
library?
B
B
I
see
cargo
as
a
growing
concern.
Basically,
as
rust
itself
becomes
better,
as
rust's
diagnostics
become
better
as
rusts
the
resources
for
us
become
better
cargo.
It's
clearer
and
clearer
how
far
behind
cargo
has
fallen
and
sometimes
is
due
to
known
limitations.
B
Sometimes
it's
due
to
poor
diagnostics,
poor
errors,
often
it
simply
lacked
due
to
lack
of
knowledge
that
users
just
don't
know
what
cargo
can
do
and
it's
sort
of
a
mix
of
all
of
these.
But
basically
no
one
reads
the
cargo
book.
The
cargo
book
is
pretty
good,
but
it's
a
very
long
book
about
something
where
chances
are.
You
only
really
need
a
small
part
of
it.
B
Some
examples
of
this
are
feature
merging,
so
this
is
the
the
point
that
cargo
merges
the
features
of
all
places
where
a
dependency
appears
in
your
dependency
graph,
which
is
one
of
the
reasons
why
you
can't
have
mutually
exclusive
features
in
cargo.
Build
scripts
are
very
hard
to
understand
for
people
who
haven't
like
really
dug
into
them,
but
even
if
you
feel
like
you
understand
them,
it's
not
clear
what
the
right
answers
are,
whether
you
should
use
things
like
cc
or
package
config
to
emit
all
the
right
cargo
magical,
standard
output,
things.
B
If
you
have
a
native
dependency,
should
you
use
git
submodule?
Should
you
vendor
what
are
the
right
patterns
here,
and
this
is
something
that
I
think
we
don't
even
have
good
documentation
for
in
the
cargo
book?
How
should
you
do
inter
workspace
dependencies?
Should
you
specify
path
or
version
or
path
and
version
what
you
do
do
on
a
release,
not
entirely
clear?
B
The
fact
that
you
should
probably
specify
dependencies
with
default
features
equals
false
if
you're,
a
library
that
kind
of
stuff
is
not
really
taught
anywhere
same
things
like
foot
guns
around.
You
know
how
rust
flanges
are
and
aren't
propagated
in
different
parts
of
cargo,
especially
around
cross
compilation,
and
it
doesn't
have
to
be
these.
B
My
point
is
more:
there
are
a
lot
of
rough
edges
to
cargo
and,
as
rust
becomes
more
pleasant
to
deal
with
that
those
pain,
points
and
cargo
become
even
more
visible
to
users
as
they
develop
into
rust,
and
I
think
diagnostics
could
help
with
many
of
these.
Both
you
know,
errors
in
cargo
could
get
better,
but
I
want
like
clippy
for
cargo.
B
I
want
to
run
clippy
on
my
project
and
have
it
tell
me
things
about
my
cargo.tommel
that
maybe
I
should
be
different
doing
differently
or
my
build.rs
unsafe
remains
unclear,
and
this
is
something
that
I
think
is
relatively
well
known,
but
basically
everyone
is
either
too
scared
or
not
scared
enough
about
unsafe,
and
there
are
some
people
in
between
this
is
a
little
bit
extreme,
but
but
in
general
the
problem
we
have
with
unsafe
is
that
there's
just
constantly
changing
ground.
B
B
The
rules
are
under
or
entirely
undocumented
that
the
unsafe
code
guidelines
working
group
was
great,
for
you
know
trying
to
document
the
really
fundamental
assumptions
that
rust
had
around
unsafe
code,
but
progress
has
been
really
slow
and
that's
unfortunate
because
it
means
that,
even
if
you
really
try
to
understand
unsafe,
you
sort
of
hit
a
wall
where
there
aren't
answers
deeper
down
or
you
need
to
track
down
the
right
person
to
ask-
and
that's
that
means
that
it's
really
hard
to
pick
things
up
on
your
own.
B
B
B
This
is
a
safety
invariant
that
I
I'm
signing
off
on
having
done
and
have
that
like
checked
by
the
compiler
somehow,
but
it
doesn't
really
matter
what
matters
is
currently
it's
painful
because
it's
hard
to
know
what
the
rules
are
and
there's
very
little
enforcement
of
those
rules.
It's
really
unsafe
or
not
unsafe,
and
I
don't
think
it
has
to
be
quite
that
binary
myria
is
great,
but
but
the
analysis
there
is
kind
of
limited
right,
especially
if
you
don't
use
any
of
the
c
flags.
B
It
only
checks
the
test
that
you
wrote
it
doesn't.
You
know
just
check
all
your
code,
it's
not
static
analysis
and
the
fact
that
it's
nightly
only
is
a
little
bit
of
a
problem.
It
means
that
in
in
cases
like
especially
at
large
organizations
where
you
can't
use
nightly,
you
just
don't
have
access
to
miri
and
that's
something
I
think
we
should.
We
should
work
on
improving
and
I
think
a
sort
of
corollary
to
this
is
we
should
work
really
hard
to
stabilize
unsafe,
removing
functions
right.
B
In
the
meantime,
I
think
we
need
to
have
some
some,
like
forward
momentum
on
trying
to
stabilize
these
things-
and
I
know
there
is
some
already
but,
but
I
think,
there's
sort
of
outsized
value
in
trying
to
stabilize
things
that
that
allow
users
to
not
have
to
write
unsafe
and
if
you
thought
I've
I've
gone
quickly
so
far,
I'm
going
to
do
a
quick
fire
round
at
the
end
here
of
just
single
slide
things
that
I've
also
observed-
and
I
think
I
have
the
time
for
that
so
I'll
be
quick.
B
The
first
is
that
I
think
the
survey
the
rust
survey
should
ask
what's
hard.
We
need
data
for
this
kind
of
stuff.
We
should
ask
what
users
do
not
understand
or
what
they
later
realize
that
they
misunderstood,
because
the
teaching
resources
currently
are
just
sort
of
me
and
other
educators
just
sort
of
going.
I
think
this
is
hard.
I
should
do
something
on
it.
Having
data
here
would
be
super
valuable.
B
I
think
what
is
a
breaking
change
is
a
question
that
comes
up
a
lot
in
the
community
and
usually
because
people
didn't
realize
something
was
a
breaking
change
and
then
it
breaks
someone.
We
need
central
documentation
for
this.
There's
like
a
bunch
of
rfcs
that
collectively
describe
this,
but
we
need
something
better.
B
We
also
don't
really
have
like
one
particular
pain
point
here
is
dependencies
that
leak
into
your
public
set
of
dependencies,
your
public
api
and
therefore
breaking
changes
to
them
or
breaking
changes
to
you,
even
though
you
didn't
really
intend
for
that
to
be
the
case,
I
want
more
documentation
to
explain
why
I've
found
the
developers,
don't
believe
necessity.
Claims
like
if
someone
just
says
you
know,
sentencing
saves
you
in
a
lot
of
cases.
B
It's
just
good
or
you
know,
static
is
necessary
here
that
they
have
to
like
the
docs
need
to
start
to
show
why
it
matters
give
concrete
counter
examples
in
the
docs
for
what
goes
wrong.
If
this
bound
wasn't
here,
that's
how
we
teach
people,
how
that's
how
we
make
them
remember
why
these
things
are
important
and
what
they
do.
B
Also
as
a
separate
point
here,
does
anyone
actually
read
dash,
explain
or
run
it
and
then
read
the
text
that
comes
out,
because
I
know
I
very
rarely
do
because
it's
extra
steps
is
there
some
way
we
can
repeat
these
in
docs,
so
they
become
more
visible
and
more
people
read
them
because
there's
a
lot
of
valuable
content
in
there
procedural
macro
docs
are
are
really
lacking.
B
We
need
end-to-end
examples,
and
there
are
very
few
of
these
there's
the
great
david
tolney
workshop,
and
there
are
like
some
examples
here
and
there,
but
we
really
need
something
more
thorough
and
ideally
in
the
standard
library
docs
I
want
ecosystem-wide
search.
I
want
the
ability
to
search
for
a
method
or
a
method,
signature
throughout
the
crates.I,
o
ecosystem
and
the
standard
library
that
these
things
exist
for
r
and
they
really
help
with
discoverability
when
users
are
just
like
looking
for
a
thing
I
want
for
understanding,
slow
builds.
B
So
in
conclusion,
I
think
our
resources
need
organizing
our
paper
cuts
need
fixing
our
choices,
need
better
comparisons,
cargo
needs,
love
and
unsafe
needs
rules,
and
I
think
that's
all.
I
have
time
for
so:
I'm
gonna
stop
there,
but
thanks
for
listening.
A
Thank
you
so
much
john
and
so
we'll
open
up
the
floor
to
questions.
I
think
we
do
have
about
five
minutes
here
and
so,
if
you're
interested
in
asking
a
question,
either
feel
free
to
ask
in
the
chat
or
you
can
raise
your
hand
in
the
chat
and
speak
up.
A
Nico,
I
notice
you
unmuted
yourself
there.
I.
C
C
It
is
what
if
we
could
try
to
frame
like
all
the
borrow
checker
errors
as
here's
a
concrete
counter
example:
either
here's
code
that
actually
goes
wrong,
like
here's,
how
your
code
is
broken
or
if
it's
not
quite
broken
now,
but
it
could
be
broken
by
a
small
change.
You
know
here's
something
this
function,
that
you're
calling
could
do
that
would
mess
up
your
code.
Do
you
think
people
would
respond?
Well
to
that.
B
I
think
that
would
be
fantastic
at
least
what
I've
seen
so
far
is
that.
B
For
my
streams
in
particular
that
comes
up
a
lot
where,
if
I
just
try
to
use
words,
to
explain
why
you
know
I
need
this
bound
here
or
something
it
helps
a
little,
maybe,
but
the
when
it
really
starts
to
like
stick
for
people
is
when
I
show
here's
where
this
goes
wrong,
like
I
write
code
that
they
can
read
and
see
is
wrong.
B
D
Yes
will
feel
free.
Thank
you,
so
yeah
fabulous
talk
very
deeply,
interesting
problem
to
me.
I'm
curious
just
what,
on
the
topic
of
organizing
resources,
what
kinds
of
organization
do
you
think
would
be
most
effective
for
helping
match?
I
guess
the
individual
resources
with
people's
problems,
because
I
guess
I'll
say
from
my
perspective,
having
thought
about
this
a
little
bit
on
things
like
you
know
how?
How
do
you
find
a
relevant
method
in
a
giant
docs,
rs
page,
for
instance
like
there's?
D
B
I
think
we
need
to
figure
out
some
use
user
stories,
basically
here
right,
like
what
kind
of
people
or
what
kind
of
situations
are
developers
in
where
they
currently
are
not
served
well
by
what
we
do
right,
and
I
think
there
are
a
couple
that
come
to
mind.
The
first
is
I
want
to
do
this
thing
and
I
don't
want
to
write
the
code
for
it
myself
right
like
th.
This
is
the.
How
do
I
find
hashmap
now
for
hashmap?
That's
not
a
problem.
B
It's
in
the
standard
library,
that's
where
people
search
first,
but
you
know
if
I
want
to
find
the
library
to
do
x11
window
management
right.
What
do
I
do?
I
go
to
crates.io
I
search
for
x11
and
then
I
like
sort
by
recent
downloads.
B
It's
not
not
a
great
experience
and
very
hard
to
actually
find
good
results,
and
for
for
that
kind
of
I'm
just
looking
for
a
thing
that
solves
problems
in
this
space.
I
think
we
could
do
a
lot
better,
even
just
by
you
know,
categorizing
the
crates
that
we
have
crates.I
o
does
do
some
categorization,
but
I
think
it's
a
space
where
we
could
do
a
lot
better.
B
The
second
one
is
I'm
already
using
this
library,
and
I
want
to
figure
out
how
to
do
this
thing
and
that
one,
I
think
comes
more
down
to
you
know,
I'm
looking
for
a
method,
signature,
that's
kind
of
like
this
people,
don't
generally
think
in
terms
of
method
signatures.
I
don't
think
I
sometimes
do,
but
for
me
at
least
the
way
I
solve
this
problem
currently
is
I
go
to
docs
rs.
I
open
the
type
that
I
have.
B
It
would
be
nice
if
it
was
better
and
then
I
think,
the
third
one-
and
this
is
maybe
the
one
you're
getting
on
getting
at
with
the
taxonomy
question
or
point
rather,
which
is
you
know,
I
I
want
to
learn
about
how
this
thing
works
in
rust
or
how
to
do
this
thing
in
rust,
and
here
too
we
have
a
lot
of
resources
right.
We
have
rust
by
example.
We
have
the
rust
patterns
book,
we
have
the
rust
cookbook.
We
have.
Oh
there's
one
more
that
I
forget
now.
B
We
also
have
cheats
rs,
which
arguably
falls
in
the
same
category
and
they're
all
trying
to
get
at
the
same
problem
in
slightly
different
ways.
I
don't
have
a
great
answer
for
for
how
those
should
be
organized.
What
I
really
want
right
is
like
I
want
to
just
type
my
search
and
have
it
give
me
the
right
answer
which
google
works
pretty
well
for
for
rust,
resources
right,
I
could
type
rust
and
then
sort
of
type.
B
My
question
and
I
might
get
some
of
the
good
ones,
but
but
I
think
here
we're
sort
of
searching
for
a
login
solution
right
where,
rather
than
having
to
search
through
all
the
resources,
I
can
like
walk
a
tree
or
something
and
every
time
I
get
slightly
closer.
But
but
ultimately,
I
think
we
need
to
categorize
what
what
are
the
underserved
use
cases.
That's
where
we
need
to
start.
I
don't
know
if
that
answers
your
question
quite
but.
D
Yeah
yeah.
No,
it
does
it's
very,
very
satisfactory
answer.
I
I
will
say
I
think
another
interesting
set
of
resources
that
would
be
worth
categorizing
as
blog
posts,
so
so
for
those.
B
D
D
The
prevailing
comments
were
like
I
read
the
rust
book
and
then
I
started
a
hobby
project,
but,
like
the
top
comment
was
I
read
the
book.
I
started
a
project
and
then
I
read
the
rust
subreddit
every
day
for
three
years,
which
I
think
is
very
indicative
of,
like
you
just
you're
in
the
thick
of
all
of
the
great
content
that
people
are
producing
and
you
you
catch
it
when
it,
you
know
zips
by
your
feed
right,
but
then
for
everybody
else.
D
You
either
didn't
it
didn't
they
didn't
stumble
across
it
organically
in
order
they
have
the
keyword
terms
to
to
fetch
it.
They
then
miss
it
unless
it's
collated
in
one
of
these
awesome
lists
and
so
thinking
about
ways
in
which
you
know
that
really
high
quality
content
that
a
lot
of
rust
folks
have
written.
But
it's
now
just
like
gone
to
the
ether,
bringing
that
back,
I
think,
could
be
quite
valuable.
B
Yeah,
I
think
russ
currently
has
very
little
institutional
knowledge
and
it's
a
problem,
or
rather
it
has
a
lot
of
institutional
knowledge.
That's
not
written
down
anywhere
right,
so
these
are
all
of
the
great
blog
posts
that
have
been
written.
All
of
the
great
discussions
that
have
happened.
You
know
on
users.rustlang
or
just
in
zulip
or
in
discord
where
this
just
it
just
gets
lost,
because
if
you
weren't
there
at
the
time,
you're
not
going
to
find
it
again.
B
This
is
a
problem
that
I
think
applies
to
a
lot
of
languages
and
we
don't
have
an
obvious
answer.
But
for
me
an
example,
this
is
there's
some
really
good
blog
posts
like
a
couple
of
years
back
on
zero-sized
types
that
I
still
go
back
and
read
every
now
and
again
and
they're
fantastic.
But
if
you
tried
to
find
them
now,
you
wouldn't
even
know
that
they
existed
and
I
don't
know
how
to
solve
that
problem.
But
it
is
a
problem.
A
I'm
just
taking
a
look
at
some
of
the
chat
questions
here
or
just
like
some
of
the
comments,
and
one
comment
points
out
that
it'd
be
nice
to
have
a
place
that
you
can
go
and
find
paper
cuts
more
easily.
A
B
B
As
known
bugs
about
this
implementation,
I
wonder
if
we
could
do
something
similar
for
even
just
for
diagnostics
right
like
if,
if
this
is
I'm
like
mentally
pinging
esteban,
which
is
you
know
if,
if
my
code
doesn't
compile
for
a
reason,
that's
a
known
shortcoming
in
the
language.
Can
you
please
link
me
to
the
tracking
issue
or
the
issue
for
that
bug?
That'd
be
fantastic!
That's
one
way
to
you
know.
Let
people
know
that
this
is
a
known
problem.
A
Yeah,
so
I
think,
there's
a
lot
of
stuff
in
the
chat
that
you
can
take
a
look
at
afterwards,
but
I
think
we'll
move
on
here.
So
thank
you
so
much
john
for
answering
these
questions.
It's
really,
I
think
great,
to
have
these
interactions.
So
thank
you
very
much.
No
thanks
for.
A
Absolutely
nico,
I
will
hand
it
over
to
you
for
phase
two
of
the
russ
reading
glove.
C
Yeah,
so
this
was
supposed
supposed
to
be
doc
jones,
but
I
don't
know
I
don't
see
her,
so
I'm
just
gonna
pinch
it,
which
is
too
bad,
because
all
the
good
ideas
that
I'm
at
least
what
I
think
are
good
ideas
that
I'm
about
to
talk
about
are
all
really
hers.
So
I
want
to
make
sure
she
gets
the
credit,
but
let's
pull
it
up.
C
So,
as
I
mentioned,
I'm
not
in
fact
dr
johns,
I'm
niko
matsakis,
but
I
wanted
to
talk
about
some
of
our
experiences
and
that
that
doctrines-
and
I
had
running
this
rusty
reading
club
and
some
of
the
things
where
we
think
would
be
cool
to
do
next
and
you
can
kind
of
get
a
hint
from
the
title
where
this
is
going,
the
rust
contributor
program,
but
so
so
what
was
this
rusty
reading
club?
C
If
you
didn't
hear
about
it?
Well,
the
idea
was
we
thought
we.
We
saw
these
these
code
reading
clubs
that
that
are
all
the
rage,
by
which
I
mean
there
are
a
few
of
them
where
people
kind
of
get
on
zoom
and
read
code.
C
That's
about
it,
there's
different
variations,
but
the
idea
is
to
kind
of
get
practiced
at
learning
to
read
code
since,
actually
it's
something
we
rarely
train
you
for,
but
you
know
you
spend
most
of
your
life
as
a
coder
doing,
and
so
we
thought
it'd
be
cool
to
just
sit
and
read
the
rusty
sources.
You
know
and
there's
parts
of
rusty,
so
I've
been
working
on
the
compiler
for
10
plus
years
and
there's
plenty
of
parts
that
I
don't
really
understand,
and
I
assume
that's
true
of
others
too.
C
So
we
thought
it
might
be
a
good
way.
You
know
get
some
people
who
have.
The
original
idea
was:
let's
just
get
a
bunch
of
people
together
and
read
the
source
and
ask
questions
and
talk
about
it,
and
some
people
will
have
deeper
knowledge
and
some
will
have
no
knowledge
and
that
will
be
kind
of
useful
because,
first
of
all,
the
people
with
no
knowledge
will
see
that
the
people
with
deeper
knowledge
actually
also
have
huge
gaps
in
their
understanding
and
in
hearing
the
questions
and
thoughts
of
people
with
less
knowledge
that
usually
helps.
C
Sometimes
uncover
surprising
insights
actually
because
you're
kind
of
coming
in
the
fresh
eyes.
So
that
was
the
idea.
It
did
not
work.
Quite
as
we
hoped,
the
mixing
of
skill
levels
was
more
confusing
than
helpful
and
we
we
stumbled,
as
we
went
on
some
really
cool
ways
to
to
work
through
like
reading
code
by
itself,
especially
for
some
of
the
more
complex
parts
of
the
compiler
was
challenging,
but
we
started
using
this
really
neat
debugging
tool
that
I'm
a
big
fan
of
called
pronosco.
C
The
idea
here
is
you
capture
a
trace
of
your
execution
and
you
can
replay
it
it's
sort
of
like
a
debugger
but
much
better,
because
you
can
jump
to
any
point
in
the
execution
and
see
what
the
exact
state
of
the
program
was,
and
you
can
do
things
like
say.
Oh
I'm
here
in
the
output.
Let
me
click
in
the
output
and
get
exact
get
taken
to
the
state
of
the
program
when
that
output
was
generated.
C
So
if
you
generate
a
bunch
of
log
statements
that
lets
you
sort
of
find
the
place
you're
interested
in
and
then
jump
right
in
there,
and
so
it
seemed
like.
Oh
well,
we'll
just
we
started
walking
through
example,
programs
with
pronosco,
so
we
would
read
the
code,
get
an
idea
of
what
it
does
then
come
up
with
an
example
that
we
think
might
help
us
understand.
C
It
better
run
the
example
that
was
really
cool,
but
there
was
a
problem
that
pronosco
itself
is
a
fairly
complex
tool,
and
you
know
most
people
if
they
didn't
show
up
every
week
and
they
just
hit
pronounce
for
the
first
time.
They
wouldn't
really
know
how
to
use
it
and
they
would
get
stuck
there.
So
you
kind
of
had
this
learning
curve
that
that
was
causing
problems.
So
overall
I'd
say
it
was
fun.
It
was
a
good
success
in
some
ways,
but
we
had
to
retool
it.
C
It
wasn't
the
the
the
program
we
hoped
it
would
be,
and
so
that's
where
this
slide
comes
in,
oh
well,
okay,
I
guess
that
that's
what
I
just
talked
about.
There
was
some
interesting
chaos
because
the
first
time
we
posted
it,
we
said
we
kind
of
just
posted
it
far
and
wide,
and
then
so
many
people
showed
up
that
we
had
to
cancel
because
we
literally
couldn't
start
the
zoom
room.
So
if
you
want
to
get
more
details
of
all
that
stuff
doc
jones
has
a
great
post
doing
a
retrospective.
C
But
so
let
me
let
me
step
back
and
say
here's
what
we're
thinking
as
a
as
a
refined
version
of
the
reading
club.
This
is
the
future
think
of
it
like
a
user
story.
This
is
what
I
would
like
to
see
happen
when
you
show
up
as
a
russ
contributor
right,
so
suppose,
you're
a
gonzo,
and
you
say
I
want
to
learn
to
code.
I
want
to
learn
to
code
in
russia
right.
I
want
to
hack
on
the
compiler
and
become
a
compiler
contributor
today.
What
happens?
C
I
don't
know
if
you
go
find
some
issues,
maybe
there's
some
easy
bugs
that
are.
Maybe
you
can
find
something
to
work
on
or
find
a
mentor,
but
it's
a
little
bit
chaotic
right.
It's
kind
of
like
the
thing
john
was
talking
about.
There's
101
resources,
it's
a
little
hard
to
figure
out
where
to
where
to
get
involved
and
what
the
right
place
is
so,
but
in
this
future
we're
imagining.
C
Instead
of
that,
there's
a
very
clear
place,
you
can
start
there's
a
let's
say
twice
a
year
program
called
rus
contributor
new
and
you
can
essentially
apply
right
and
it
doesn't
take
as
many.
C
It
takes
a
kind
of
fixed
set
of
people,
so
you'll
apply
and
maybe
you'll
get
selected
for
this
program,
and
maybe
you
won't
but
and
then
what
happens
then
is
the
reason
it's
a
fixed
set
of
people
is
because
each
person
who's
in
there
is
going
to
get
a
bug
of
their
very
own
that
we're
going
to
hold
for
them
there'll
be
a
dedicated
stream.
C
So
the
idea
is
that
you'll
group,
together
with
other
people
who
are
trying
to
learn
how
the
compiler
works
and
you'll
form
a
kind
of
cohort
all
right
and
you'll,
have
a
stream
on
zulip,
where
you
can
chat
to
one
another
and
there
would
be
fixed
times
office
hours,
where
some
members
of
the
compiler
team
would
be
available
to
help
you
to
fix
those
bugs
right.
C
So
the
idea
is
these
members
of
the
compiler
team
will
essentially
find
bugs
and
then
help
you
learn
how
to
fix
them,
and
so
the
idea
would
be
then
that
you
kind
of
over
the
course
of
a
month
or
two
months.
You
you
leave
having
fixed
some
bugs
and
done
some
work
on
the
compiler.
C
So
at
that
point
after
got
well,
I'm
telling
the
story
out
of
order
and
so
gonzo
hears
about
this
program.
Gonzo
joins
in
gets
accepted,
gets
excited,
meets
the
other
people
in
his
cohort
and
they
get
to
work,
fixing
the
bugs
right
and,
like
I
said,
every
once
in
a
while.
They
they
hit
some
problems.
So
the
nice
thing
is
they're
able
to
talk
to
one
another
because
they
have
this
cohort
in
this
dedicated
stream.
So
maybe
gonzo
has
a
problem
and
he
can
say:
hey
you
know,
miss
piggy.
C
Did
you
figure
out
how
how
it
works
to
add
a
new
log
statement
and
miss
piggy
says:
oh
yeah
yeah.
I
know
how
to
do
that.
I
found
a
good
example.
This
is
how
you
do
it
right,
but
some
of
the
questions
are
harder.
It's
not
something
that
they're
able
to
figure
out
working
together.
C
So
then
they
contend
the
office
hours
where
the
team
members
are
there.
People
who
you
know
who
are
experienced
with
rust
the
rust
compiler
and
have
a
better
idea
how
it
works
and
they
can
kind
of
answer
questions
and
help,
get
you
back
on
track,
and
so,
finally,
at
the
end
of
the
program,
you've
kind
of
fixed
your
bug
and
understood
how
the
compiler
works.
Maybe
we
play
pomp
and
circumstance.
Let's
see,
will
you
hear
it?
C
I
don't
know
it's
this
song,
oh
yeah.
Well,
maybe
you
can't
hear
that
cause
it's
playing
really
loud
in
my
headphones,
that's
the
one
that
goes
so
we
played
that
and
and
you've
kind
of
graduated,
and
the
idea
then
is
now
you've
got
a
basic
idea
of
how
the
compiler
works
right
and
you
know
you're
still
learning
but
you've
fixed
a
bug.
You've.
You
know
how
to
run
the
tools.
C
You
know
how
to
get
the
log
output.
You
know
how
pronosco
works,
and
so
now
the
question
is:
let's
say
you
liked
it
and
you
want
to
do
more,
compiler
hacking.
Well,
how
could
you
do
that?
Well,
first
of
all,
you've
still
got
your
cohort
right,
so
probably
a
lot
of
them.
If
we're
successful
have
enjoyed
their
experience
too
and
they're
kind
of
hanging
around
and
that
stream.
That
was
there
for
you
that
stays
there
and
you
can
chat
and
help
each
other
fix
bugs
and
stuff.
C
But
then
the
idea
is
that
also
there
would
be
another
stream
of
learning
events.
So
we
talked
about
russ
contributor
new.
This
was
kind
of
the
onboarding
path
where
you
go
from
no
experience
with
the
compiler
to
some
experience
with
the
compiler,
then
there
would
be
rust,
contributor
grow
and
looks
like
you
can't
see
this
whole
slide.
Let's
fix
that.
Can
you
see
it
now?
Okay
and
so
russ
contributor
grow
is
a
regular
series
and
this
one
is
targeting
intermediate,
like
actually
probably
a
variety
of
levels.
C
C
Some
of
them
would
be
a
little
less
advanced
right,
and
so
maybe
this
month
that
big
fish
is
explaining
how
the
trade
system
works
in
a
way
that
gonzo
thinks
he's
he's
ready
for
so
gonzo
joins
in
on
on
the
russ
compiler
grow,
that's
starting
this
month
and
for
the
next
eight
weeks
at
big
fish
was
hold
of
one
essentially
kind
of
like
the
rusty
reading
club
that
we
tried
to
do
right
once
per
week
at
big
fish,
we'll
we'll
walk
through
some
of
the
like
walk
through
an
example
or
two
of
the
trade
system
show
how
that
code
works
in
detail,
take
questions
and
explain
it
and
and
just
kind
of
teach
people
how
it
works,
and
this
happens
a
few
times
right.
C
C
So
this
is
this
is
essentially
the
path
we'd
like
to
see
right.
Let
me
let
me
give
it
in
less
story
form.
There
would
basically
be
two
tracks
and
these
numbers
might
not
be
right,
but
this
seems
maybe
right
about
twice
per
year.
C
If
we
could,
that
would
be
great
and
then
also
in
a
kind
of
steady
stream.
There
would
be
this
rust
contributor
grow
every
eight
weeks,
somebody
from
the
compiler
team
talking
about
something
and
more
targeting
intermediate
levels,
and
I
think
this
doesn't
this.
This
seems
really
ambitious
to
me,
but
I
also
think
it's
achievable
with
some.
Without
that
much
work.
The
idea
would
be
that
to
run
the
russ
contributor
new
program,
you
need
about
three
compiler
team
members.
C
So
I
think
we'd
have
to
have
some
mechanism
for
putting
bugs
on
hold.
Sometimes
we
get
easy
bugs
and
they
just
get
fixed
really
fast,
because
there
aren't
enough
easy
bugs
out
there.
Unfortunately,
so
maybe
we
can
hold
some
and
reserve
them
and
say
don't
fix
this.
It's
it's
not
too
hard
to
fix.
It's,
let's
hold
it
for
the
rest
contributor,
new
program
and
then
in
the
second
month.
They
would
attend
these
these
office
hours
and
help
people,
but
only
for
fixed
times
right.
C
They
can
answer
at
any
time
any
question,
but
they
only
promise
to
be
there
at
a
certain
time
window
and
for
russ
contributor
grow.
Well
that
you
just
kind
of
need.
One
person
who
agrees
for
about
two
months-
two,
you
know
for
eight
sessions
to
spend
an
hour
a
week,
walking
through
the
the
code
of
some
code
that
they
know
well.
I
think
we
have
a
pretty
good
idea
of
what
that
structure
looks
like
we
mentioned
this
pronosko
tool
and
some
other
stuff.
C
I
mean
I
think
everyone
could
do
whatever
they
want
best,
but
there
we
could
also
give
a
recommendation
of
like
the
first
time.
You
should
give
a
lecture
the
second
time
you
should
work
with
people
work
with
some
of
the
people
in
the
thing
to
find
some
good
example.
Programs
then
walk
through
two
of
those
programs
and
and
you're
about
done
that
takes
about
eight
weeks.
C
So
that
would
be
the
idea
and
then
there's
one
last
thing:
that's
really
important.
So
I
mentioned
we
would
need
some
mentors
to
collect
bugs
hold
office
hours.
I
mentioned
that
somebody
will
have
to
spend
some
time
walking
through
examples.
I
think
we
really
need
a
full-time
or
at
least
employed
person
who's
like
dedicated.
C
I
guess
I
don't
have
to
be
employed
just
dedicated,
but
we
need
somebody
to
organize
and
make
sure
this
actually
happens,
someone
to
kind
of
go
and
recruit
people
for
the
program
to
find
those
three
mentors
twice
a
year
to
line
up
the
next
couple:
people
who
have
agreed
to
do
the
intermediate
path
every
eight
weeks
and
we
need
so
that's
a
crucial
role
that
I
think
we
don't
have
today
and
it's
often
pretty
hard
to
find
someone.
C
But
maybe
this
could
be
well,
I'm
not
sure.
Maybe
the
foundation
might
be
interested
in
that
or
maybe
we
could
find
some
other
way.
It
could
be
a
good
thing
for
the
community
grant
program,
I'm
not
really
sure,
but
I
think
it'd
be
a
great
role
to
have
and
then
we
can
use.
You
know
various
wonderful
ways
to
help
recognize
the
people
who've
put
in
this
time
right
so
badges
a
list
of
mentors.
C
I
think
it's
excuse
me.
I
think
it's
a
really
cool
thing
to
do
to
help
grow
and
keep
the
rest
community.
You
know
welcoming
and
healthy
so
that
that's
kind
of
all
I
wanted
to
say,
but
I
think
if
you
were
going
to
take
away
something
from
this
talk,
it's
that
I
think
we
should
design
an
active
education
program
right.
Not
just
kind
of
passive
people
show
up
and
learn
how
the
compiler
works
by
having
the
wherewithal
to
suffer
through
it.
C
But
where
was
actually
a
structured
thing
that
you
can
do
to
learn
and
understand
it
better
that
we
would
have
some
programs
targeting
really
inexperienced
new
contributors
and
some
programs
targeting
a
broader
spectrum
of
contributors
and
that
we
would
be
making
a
commitment
as
a
team
and
as
a
project
that
we're
going
to
invest
active
effort
in
bringing
new
people
in
right.
So
running.
C
These
things
is
definitely
work,
mentoring,
new
contributors,
we're
doing
a
talk
every
eight
weeks,
that's
work,
and
the
idea
would
be
that
we
try
to
make
sure
that
that's
something
we
all
commit
to
and
take
a
share
in,
or
at
least
maybe.
B
C
All
of
us,
I
think
there
are
many
people.
There
are
some
people
who
will
enjoy
this
more
than
others
and
we'll
be
better
at
it
than
others,
but
that
you
know
as
a
team.
It's
something
we're
focused
on
ensuring
happens.
C
So
thank
you.
Let
me
leave
you
with
one
last
muppet
picture
and
happy
to
take
any
questions
or
thoughts
about
it.
A
A
One
thing
I
was
sort
of
wondering
about
is
like
when
it
comes
to
the
aspirants
as
part
of
like
the
the
new
program,
what
are
like
the
ideal
type
of
people
like
in
their
sort
of
like
progress,
they've
been
learning,
rust,
they've
been
doing
some
things,
but
who
exactly
would
be
looked
for
as
part
of
the
criteria.
C
That's
a
good
question
and
something
we
have
to
figure
out.
I
mean
I
do
think
in
terms
of
rust
skill.
I
would
think
you
should
probably
have
probably
no
rust
like
it's
not
really
meant.
I
wouldn't
think
as
a
way
to
learn
rust
itself.
You
know,
but
I
guess
there
might
be
some
people
who
have
a
lot
of
domain
knowledge
that
you
know
want
to
learn
russ
and
that
might
be
also
okay.
C
I
think
it
would
be
a
great
way
for
us
to
bring
in
and
broaden
the
community
in
terms
of
underrepresented
groups
or
less
well-represented
groups,
and
things
like
that
right
that
that's
a
really
great
conversation.
We
should
be
having
what
I
do
feel
I
don't
know
the
exact
criteria
and
but
what
I
do
think
is
really
important
is
that
we
do
sort
of
limit
it
that
it's
a
small,
manageable
size
like
it'll,
be
better
for
everyone.
It's
too
bad.
C
We
can't
do
it
for
infinite
participants,
but
the
experience
will
be
a
lot
better.
If
I
think
it's
like
a
manageable
size
where
people
can
get
to
know
one
another
and
make
friends
and
have
a
cohort
that
can
support
each
other
than
if
it's
just
kind
of
open-ended
but
doesn't
actually
work
for
anyone.
A
One
comment
in
chat
describes
curating
a
list
of
already
fixed,
easier,
bugs
and
then
having,
I
suppose,
people
who
are
part
of
the
the
new
program
go
through
and
so
like
walk
through
those
bugs
before
having
them
start,
and
so
I
mean
just
kind
of
turning
this
into
a
question
when
we're
looking
at
what
the
breeding
club's
goal
is
as
like
running
a
reading
club.
Why
might
this
or
might
this
not
work
as
a
way
of
like
getting
people
together
to
walk
through
stuff.
C
It's
a
really
good
idea.
Actually
I
like
that
idea
of
walking
through
fixed
bugs.
I
also
think
makes
me
wonder
if
you
know-
maybe
I
think
in
the
past.
I
I've
forgotten
about
this,
but
in
the
past
I
remember
having
discussed
with
people
the
idea
of
well.
Why
do
we
have
to
have
a
bug
like
what,
if
we
just
make
a
bug
and
fix
it
right,
like
you,
don't
necessarily
have
to
fix
a
bug?
That's
in
the
real
compiler.
C
I
guess
it's
somewhat
less
satisfying
to
kind
of
fix,
an
artificial
bug
or
to
to
replay
fixed
bugs,
but
it
does.
It
does
make
sense
to
me
that
we
could
have
an
introductory
course
that
isn't
necessarily
oriented
actually
landing
a
fix
to
a
bug,
but
is
oriented
at
doing
a
variety
of
exercises
that
will
help
you
get
to
know
parts
of
the
compiler
like
different
kinds
of
challenges.
That
might
be
better
because
I
do.
C
A
Perfect
and
we'll
you
have
your
hand
up
so
I'll,
let
you
speak
if
you
like.
D
Yeah,
so
one
thing
I'm
curious
to
talk
about
is
this
distinction
between
say,
like
feature
contributors
versus
reviewers
so
and
how
and
how
that
relates
to
the
program
you're
proposing.
So,
in
my
experience,
contributing
to
russ
compiler,
I've
definitely
very
much
been
in
the
make
feature
space
like
there's
a
couple
specific
things.
D
I
am
interested
in
improving
in
the
rest,
compiler
like
rust,
stock
or
other
stuff
related
to
my
thesis
work,
and
so
you
know
I
implement
those
features,
and
then
I
get
the
expert
help
from
reviewers
who
know
way
more
about
the
client
than
I
do
to
fill
in
all
the
edge
cases
that
I
missed
like
this
was
especially
true
in
rust
stock
where
there
was
like.
Oh,
I
forgot
about
themes.
D
I
need
to
implement
stuff
for
dark
mode,
or
I
forgot
about
like
xyz
features
or
these
random
use
cases
or
whatever,
and
I
think
one
reason
why
that's
relevant
is
because
a
I
don't
know
if,
like
people
come
into
the
project
wanting
to
like
only
contribute
features
versus
eventually
become
reviewers
or
not
and
b,
I
think
reviewing
is
like
exceedingly
important
to
make
sure,
of
course,
that
the
code
meets
a
high
quality
standard.
But
it
seems
like
it's
not
a.
D
I
don't
know
how
desirable
job
it
is
amongst
many
people
right
I
mean
certainly
I
know
my
brother
right
was
basically
just
full-time
good
reviewing
for
a
lot
of
his
time
in
rust
in
the
in
the
later
years
when
he
wasn't
working
on
like
crates
and
stuff.
So
I,
like,
I,
don't
know
if
there's
something
relevant
to
that.
D
That's
worth
working
like
think
thinking
about
in
the
structure
of
the
program
about
like
either
funneling
people
in
one
of
these
directions
or
trying
to
otherwise
just
like
make
sure
that
there
will
always
be
that
reviewing
base
and
we're
not
just
prepping
people
to
be
feature
contributors.
Does
that
make
sense.
C
It
does
make
me
also
wonder,
I
think,
a
good
like
something
that
I've
found
really
useful
is
when
people
come
and
do
a
pre-review
on
prs
right,
even
if
they're
not
an
expert
in
the
code,
if
they
can
kind
of
go
through
and
and
read
through
the
pr
first
and
get
a
lot
of
the
simple
obvious
bugs
fixed,
then
what
and
like
highlight?
Oh,
this
is
a
really
tricky
part.
Maybe
niko
can
take
a
look
at
this.
C
That
can
be
a
great
time
saver
and
so
that
that
might
be
another
kind
of
thing
that
could
be
part
of
this
would
be
like
all
right.
Maybe
that's
not
your
first
rust
contributor
newest
time,
maybe
there's
another
program
of
like
let's
work
through
the
reviewing,
and
you
know
you
can
shadow
review
and
help
this
person
by
first
doing
first
round
review
and
getting
practice
and
used
to
that
way.
That
works.
I
don't.
C
It's
kind
of
like
shadow
interviewing
at
a
company
john,
you
had
your
hand
up,
or
I
don't
know
if
other
people
do.
B
Yeah
I'm
for
the
grow
thing.
I
think
one
thing
to
keep
an
eye
out
for
is:
if
you
keep
telling
people
to
give
presentations,
then
what's
going
to
happen,
is
their
content
is
going
to
get
more
advanced
over
time
or
more
complicated
over
time
because
they've,
given
it
so
many
times
before
that
they
feel
like
they've,
covered
that
ground
already
and
so
there's
a
question
buried
in
here,
which
is:
do
you
expect
that
these
grow
sessions
will
be
recorded,
or
do
you
expect
that
they
will
all
be
sort
of?
B
You
know,
curated
to
the
individual
group.
C
I
I've
wondered
about
that
same
thing
and
I'm
not
sure
I
do
expect
them
to
be
recorded,
because
it
just
seems
well,
I've
gone
back
and
forth,
but
it
just
seems
useful.
I
mean
it
does
make
question
asking
a
little
people
sometimes
get
self-conscious.
Some
people
don't
like
to
participate
in
recorded
streams.
C
B
C
C
Pretty
much
the
model
I
mean
it
works.
A
All
right,
well,
actually,
one
more
question
nico
that
I'm
sorry
curious
about
myself
from
chat.
What
type
of
type
of
time
commitments
would
we
be
looking
at
for
people
in
the
different
parts
of
the
programs.
C
I
I
don't
have
a
great
answer,
but
I
definitely
think
that
there
would
be
one
okay,
yes
like
it's,
not
it's
not,
I
think,
that's
part
of
the
whole
application
process
and
I
think,
we'll
sort
of
all
right
enough
as
well
or
someone
in
the
comments
who
mentioned
it.
But
oh,
no,
maybe
it
was
you.
C
C
Sometimes,
where,
like
you,
invest
a
lot
of
energy
and
teaching
someone
how
something
works
and
then,
for
perfectly
understandable
reasons,
you
know
they
get
a
new
job
and
they
don't
have
time
to
work
on
the
compiler
or
something
and
it's
kind
of
like
okay.
Well,
that's
I'm
not
upset,
but
it
is
a
lot
of
work
that
I
would
love
to
see
leading
upwards.
C
So
if
we
can
kind
of
pair
it
with
at
least
an
expectation,
you
know
reasonable,
no,
no
ironclad
commitments
but
clear
expectations
of
how
much
time
people
put
in
so
that
they
really
get
the
most
out
of
it.
I
think
that
would
be
good.
A
Perfect,
so
I
think
we're
good
to
end
the
question
session
here
and
so
I'll
just
grab
the
slides
back
for
a
second
year
just
to
finish
up,
and
so,
as
I
mentioned
earlier,
the
the
theme
for
may
we
haven't
decided.
Yet
we
do
have
a
couple
candidates
that
I
will
mention
though
so
I
know
one
possible
theme
was
global
and
another
one
was
having
to
do
with
embedded
systems,
and
so
I
think
there
is
definitely
some
exciting
topics
on
both
of
these.
A
And
so,
if
you
have
interest
either
or
you
can
think
of
any
talks
relative
to
these
topics
feel
free
to
reach
out
and
make
issues
for
them
for
the
next
meeting
in
may,
it
will
be
on
the
16th,
which
is
nice
and
early
in
the
month.
I
think
it's,
the
earliest
one
we've
had
in
quite
a
while
and
so
it'll
be
running
at
3
p.m,
u.s
eastern
standard
time
and
so
accessible
mostly
to
north
america
and
europe.
A
And
then
I
guess,
if
you
live
in
sydney
and
you
wake
up
nice
and
early,
maybe
it's
for
you
we'll
see,
but
yeah
we'll
end
off
the
meeting
here.
So
we'll
do
the
social
hour
for
anybody
who
can
stick
around
and
thank
you
so
much
to
all
our
speakers
and
we'll
see
you
next
time.