►
From YouTube: 2021-10-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
So
welcome
to
the
october
18th
russ
ctcft,
I'm
your
host
nico
matsakis,
and
today
we
have
a
wonderful
lineup
for
you,
we're
going
to
be
going
through
different
ways
and
things
that
have
been
happening
around
empowering
and
organizing
open
source
contributors.
We
have
tyler
manderie
talking
about
some
of
the
work.
That's
been
happening
in
the
async
foundations
working
group.
A
We
have
some
people,
we
I'm
not
sure
who
from
rust,
analyzer
you're
here
right,
hopefully
cool
lucas,
excellent
talking
about
rust,
analyzer
and
the
approach
that
some
of
the
approaches
that
they've
been
taking
there
esteban
giving
a
short
notice
on
community
metrics,
some
details
about
contributing
to
the
ctcft
itself
and
jane
talking
about
the
contributor
survey.
A
B
Want
to
make
a
quick
mention
from
the
rust
game,
gamedev
working
group,
we
ran
our
first
rust,
graphics,
meetup
at
the
beginning
of
october.
So
if
you
want
to
check
that
out,
you
can
see
what
it
looks
like
on
our
youtube
channel.
If
you
just
look
up
rust
game
dev,
it
should
be
right
there,
and
I
wanted
to
just
say
that
it
was
a
very
interesting
format
where
we
just
had
some
people
come
and
give
talks.
B
There
wasn't
like
a
whole
bunch
of
overhead
of
like
call
for
papers
or
anything,
but
we
got
some
pretty
cool
results
out
of
it.
So
if
other
teams
are
interested
in
running
something
like
this,
I
have
a
lot
of
the
infrastructure
set
up
and
I
would
love
to
see
more
initiatives
like
this
from
a
lot
of
the
working
and
interest
groups.
B
Hackathon
or
what
exactly
took
place
during
the
so
for
the
graphics
meetup,
it
was
just
three
different
presentations
about
the
state
of
graphics
generally
in
rust,
and
so
this
month
they
revolved
a
lot
around
wgpu
usage,
and
so
there
was
like
a
one
talk
about
sort
of
deprecating,
gfxrs
and
moving
towards
the
future.
There
was
a
talk
about
rent
three,
which
is
an
engine
on
top
of
wgpu,
and
then
one
talk
about
or
no
sorry
by
wumpf
about
a
project.
That's
like
fluid
simulations
and
in
rust,.
A
Cool
that
sounds
cool
all
right,
then,
before
we
go
any
other
announcements.
A
If
you
want
to
talk,
please
feel
free,
but
the
best
thing
is
to
turn
on
your
video
so
that
we
see
you
kind
of
cute
up
there,
but
otherwise
you
can
drop
something
in
the
chat
and
we'll
we'll,
let
you
know
when's
a
good
time
or
raise
your
hand
using
the
zoom,
raise
hand,
feature
and,
of
course,
we're
abiding
by
the
roast
code
of
conduct,
and
with
that
I'll
hand
it
over
to
tyler
the
question
tyler
is:
do
you
want
me
to
drive
the
slides
or
do
you
want
to.
C
Can
try
it
with
you
driving
then,
let's
just
do
that.
That's
a
little
easier!
Yeah,
okay,
cool,
hey
everyone!
I'm
tyler!
I
am
one
of
the
leads
for
the
async
working.
D
C
Niko
being
the
other
one,
and
you
can
go
to
the
next
slide,
so
niko
actually
gave
a
talk
in
the
very
first
ctcft
about
kind
of
async
vision
process
that
we
were
doing,
and
you
know
I
wanted
to
give
people
an
update
on
that.
Of
course,
I
know
not
everyone
was
there.
So
you
know
very
briefly.
C
We
asked
people
to
write
narratives
that
kind
of
captured
their
experience
of
using
async.
Today
you
know
people
are
actually
using
it
sort
of
in
the
wild
so
to
speak,
and
yeah
niko
wrote
a
blog
post
on
the
main
rest
blog,
and
we
got
actually
a
huge
response
from
it.
Then
we
got
about
50
stories
that
represented
kind
of
different
aspects
of
people's
experience
with
using
async
and.
C
Let's
see
sorry
yeah
and
so
from
those
50
posts,
we
were
able
to
kind
of
build
up
like
a
meta
narrative
kind
of
a
summary
narrative
of
what
it's
like
to
use
async
today.
So
you
can
go
to
the
next
slide
or
show
that
I'm
not
going
to
dive
into
this,
but
like
these
are
kind
of
some
of
the
high
level
points
that
we
gathered
and
then
within
those
there's
a
lot
of
like
sub
bullets.
And
you
know
you
can
point
to
individual
stories
that
that
demonstrate
this.
C
So
next
thing
we
asked
people
to
do
was
to
imagine
the
future
of
async
and
write
narratives
about
how
things
should
the
experience
should
be
actually
in
the
future,
and
this
turned
out
to
be
a
little
bit
harder
for
people.
You
know
complaining
about.
The
president
is
easier
than
designing
the
future,
and
you
know
it
turns
out
that,
like
because
the
status
quo
stories
mostly
kind
of
contain
like
implicit
complaints
about
the
way
it
is
today.
You
know
it
turned
out
to
be
kind
of
a
good
direction
to
just
pick.
C
The
opposite
of
that,
which
was
which
was
helpful,
so
was
all
of
this
a
success
I
would
say.
Definitely
we
got
the
feedback
that
we
were
looking
for.
We
were
able
to
identify
like
a
lot
of
recurring
themes
and
and
kind
of
get
a
feel
for
the
challenges
that
people
have
today.
C
It
was
definitely
a
lot
of
information.
You
know.
One
of
the
things
that
we've
been
wanting
to
do
is
roll
up
these
50
different
stories
into
like
three
or
four,
that
kind
of
summarize
everything
and
kind
of
capture
the
essence
of
all
of
them
that
we
could
like
realistically
expect
people
to
who
are
like
really
involved
to
kind
of
have
some
familiarity
with.
You
know
something
that
we
can
kind
of
link
back
to
as
we
do
design,
but
we
haven't
had
the
time
to
do
that
yet
so.
C
So
after
we
got
all
of
that,
we
talked
about
what
to
do
next,
and
you
know
we
had
a
lot
of
discussions
around.
You
know
the
next
slide.
You
know
what
you
know,
what
which
things
to
do,
which
things
to
fix.
What?
What
do
we
want
to
build?
C
What
are
the
interdependencies
between
those
and
you
know
which
things
should
we
prioritize,
because
there's
a
lot
of
things
to
do,
and
you
know
these
are
kind
of
hard
to
define
when
you
don't
quite
know
exactly
what
you're
building
it's
kind
of
a
vague
idea,
but
eventually
we
piece
together
a
roadmap
and
yeah
you
can
click
on
it.
I'm
also
going
to
go
through
kind
of
the
structure
of
it
of
the
next
few
slides,
so
how
to
roadmap.
C
High
level
goals-
and
these
are
focused
around
the
end
user
experience
that
we
want
to
create-
which
I
think
is
important-
it's
not
just
around
like.
Oh
these
cool
language
features
that
I've
been
wanting
for
forever.
C
Now,
like
you,
you
focus
on
the
actual
user
experience
and
like
the
aspects
of
that
that
you
want
to
enable
for
every
goal,
we
would
state
the
specific
impact
that
that
that
we're
trying
to
achieve-
and
we
also
recruited
owners
for
each
of
these
goals,
who
are
responsible
for
making
progress
on
that
which
took
some
time
but
was
definitely
worth
it.
E
C
You
know,
first
of
all
means
that
you
are
able
to
create
async
iterators
yeah
yeah.
They
literally
copied
the
text
from
from
the
website
there,
so
you
can
create
async
iterators,
you
can
you
can
compose
them,
you
know
they
obviously
can
always
you
can
await
things
within
them
and
then
you
can
also
create
these.
You
know
large
data,
computation
graphs
where
things
work
in
a
predictable
manner,
and
you
know
you
aren't
really
surprised
by
weird
issues
that
involve
buffering
and
things
not
being
pulled,
etc.
C
So
that's
the
high
level
goal,
and
you
know
this
is
basically
a
preview
of
that's
right.
So
this
is
a
preview
of
the
goals
they
don't
actually
all
fit
on
the
slide,
but
all
the
ones
that
are
actually
you
know
staffed.
C
D
C
C
So
the
goal
defines
what
we're
trying
to
accomplish,
but
not
exactly
how
to
do
it,
and
so
for
the
how
we
need
initiatives.
You
know
the
next
slide,
so
here's
the
tooling
goal
from
the
roadmap,
and
then
we
have
the
two
initiatives
below
it.
C
So
we
have
the
console
which
currently
is
under
tokyo,
but
eventually
wants
to
be
kind
of
a
more
general
thing
for
like
inspecting
the
the
async
tasks
that
are
actually
running
and
and
then
scratch
that
debugging,
which
is
basically
being
able
to
see
all
of
your
async
tasks
that
are
in
progress
from
a
crash
jump.
So
this
is,
you
know,
post
hoc,
debugging
and
see
like
which
tasks
are
relating
which
other
tasks
and
things
like
that.
C
C
This
is
going
to
be
a
lot
more
clear-cut
than
the
goals
which
kind
of
high
level
and
may
never
be
done,
and
often
the
initiatives
are
like
really
high
context
work.
So
you
know
you'll
have
one
person
driving
that
initiative
and
there
might
be
a
lot
of
like
a
bundle
of
things
that
are
kind
of
interdependent
on
each
other,
and
so
we
define
milestones
for
each
initiative
that
are
like
the
high
level
things
that
we
want
to
accomplish.
C
So
I
hope
that
makes
some
sense,
but
the
the
point
is
that
we
we
break
this
initiative
down
into
these
different
milestones,
and
you
know
this
is
like
a
pretty
high
level
kind
of
small
set
of
milestones
that
I
think
will
get
longer
over
time
as
we
progress
and
like
identify
like
new
milestones
on
the
way
to
stabilization.
C
So,
to
kind
of
help
think
help
you
think
about
goals
and
initiatives
and
milestones
and
like
which,
how
big
should
these
things.
D
C
You
know
that
the
the
rule
that
I
kind
of
followed
actually
nico
and
I
kind
of
followed,
was
you
know:
goals
can
be
worked
on
in
parallel,
they're,
not
like
too
dependent
on
each
other.
Initiatives
can
have
dependencies
between
them,
but
they're
high
level.
It
shouldn't
be
like
initiative.
A
depends
on
like
these
six
things
from
initiative
b
and
these
three
other
things
from
initiative.
C,
it's
more
like
initiative,
a
depends
on
b,
which
depends
on
c
and
then
milestones
within.
C
Lot
more
intricate
sequencing
because
it's
more
high
context
like
I
was
saying,
yeah
next
yeah,
so
the
most
important
thing
for
all
of
this
is
that
there's
a
lot
of
transparency
and
like
the
pr,
the
you
know
where
we
are
in
the
process.
The
thinking
process
is
all
documented
somewhere.
So
nico
is
showing
the
road
map
that
we
have
online
and
yeah.
There
are
also
a
lot
of
so.
This
is
the
async
fundamentals,
initiative
repository.
It
has
its
own
dedicated
website.
C
You
can
see
you
know
in
the
center,
the
you
know
set
of
sub
projects
and
kind
of
like
the
high
level
progress
on
those,
and
then
you
have
on
the
sidebar.
You've
got
a
lot
of
the
design,
docs
yeah,
regular
updates,
and
so
like
someone,
you
know
who's
not
involved,
can
actually
go
in
and,
like
is
wondering
like.
Oh,
I
wonder
how
they
dealt
with
this
x-issue
and
you
know
dig
through
the
sidebar
and
find
it
and
what's
really
cool
is
that
people
can.
C
You
know
who
actually,
you
know,
know
what
they're
talking
about,
but
like
aren't
necessarily
up
to
speed
on
what
we're
doing
can
get
up
to
speed
and
contribute
in
a
meaningful
way.
Potentially,
and
we
actually
did
have
someone
open
a
pull
request
out
of
blue
the
other
day
to
add
a
design
dock
which
is
really.
D
C
Let's
see
so
yeah
so
niko
made
this
template
for
initiative.
So
if
you
want
to
make
an
initiative,
repo
yeah,
I
think
originally,
this
was
for
language
team
initiatives,
but
like
this
idea
is
kind
of
generalizable,
so
you
can
just
fork
this
repo
and
put
up
a
website
like
really
easily,
and
I
already
showed
you
this
so
next.
I
want
to
talk
about
the
actual
process
that
we're
using
to
to
make
progress.
C
C
Yeah
I
mean
there's
some
overhead,
but
I
think
it
would
be
just
for
the.
A
For
the
recording,
I'll
read
the
question,
I
really
love
how
this
working
group
website
looks.
I'm
wondering
how
much
overhead
there
is
to
keeping
it
feeling
very
dynamic
for
a
static
site,
for
example,
keeping
the
roadmap
up
to
date
or
just
putting
in
the
time
to
keep
the
documentation
up
to
date.
Is
this
a
task
that
is
put
on
the
leads?
Are
all
members
encouraged
to
edit
it
frequently.
C
Yeah
so
for
the
initiatives-
and
I
should
have
said
all
each
initiative
has
an
owner
that
may
not
be
the
same
as
the
goal
liner
and
yeah.
I
mean
it's,
it's
up
to
them
to
keep
it
up
to
date,
but
I
would
say
you
know
like
for
the
async
fundamentals,
like
we've
just
been
pushing
directly
to
master.
We
don't
like
we're.
C
Typically,
we
do
it
in
the
repo,
that's
not
100,
true,
sometimes
it's
in
hackendy
and
and
then
we
transfer
it
to
the
repo
but
like
that's,
that's,
basically,
our
scratch
pad,
and
so
that
keeps
the
overhead
down
a
little
bit,
and
you
know,
like
some
things,
might
not
always
get
updated
immediately
and
that's
okay,
but
like
the
idea
is
that
you're
very
frequently
updating
the
website,
and
so
this
kind
of
naturally
just
gets
updated
over
time.
A
I
wanted
to
add
one
thing,
which
is
that
at
least
the
way
I've
been
thinking
about
it
is
that
there's
like
some
a
using
it
as
a
scratch
pad,
as
tyler
said,
but
b
like
we
have
this
updates
column
for
monthly
updates
to
the
laying
team,
and
so
that
gives
us
the
kind
of
natural.
That's
a
good
time
when
preparing
that
update.
It's
also
a
good
time
to
do
a
sweep
over
the
page
and
tweak
any
other
things
that
may
have
fallen
a
little
out
of
date.
That
way
it's
not
too
far.
C
Yeah
good
point,
so
hopefully
I
answered
the
question.
Oh
you
go
back,
so
I
want
to
talk
about
the
process
that
we're
using
actually
drive
forward
on
this.
We
have
bi-weekly
sprints,
and
you
know
at
the
beginning
of
every
split
sprint,
we'll
have
like
a
sprint
planning
meeting.
We
do
these
in
zulip.
C
So
all
the
goal
goal
owners
are
expected
to
attend
and
then
you
know
others
are
so
welcome
as
well,
and
you
know
for
the
meetings.
The
first
thing
we
do
is
we
always
do
a
retrospective
on
the
last
sprint.
So
I
asked
you
know
which
things
worked.
Well,
what
didn't
work
well?
Which
things
can
we
can
iterate
on
and
improve
on?
C
The
next
thing
is
assigning
polish
issues
which
I'll
talk
about
in
a
minute
and
then
finally,
we
plans
the
goals
for
the
next
sprint.
So
one
important
thing
to
keep
in
mind.
D
C
You
know,
and
this
takes
a
couple-
took
us
a
couple
of
sprints
to
get
right,
but
you
know
actually
having
goals
that
are
like
both
well-defined
meaning
that
you
know
exactly
when
you're
done
and
are
achievable
within
that
two-week
time
frame
is
important
and
it
can
be,
you
know,
really
motivating
to
have.
You
know
both
these
regular
meetings,
where
you're
checking
in
and
having
like
these
two
roles
that
you
can
take
off
one
at
a
time.
C
Yes,
thank
you.
So
I
mentioned
polish
issues
earlier.
What
these
are
are
basically
small
little
issues
or
they
can
be
big
issues,
but
usually
issues
that
you
know
could
be
conceivably
fixed
in
a
couple
of
weeks.
That
usually
are
like
issues
with
error.
C
Messages
are
like
the
biggest
problem
that
we
have
today
and
we
decided
not
to
make
this
like
any
one
person's
responsibility,
because
you
know
honestly
like
training
through
these
can
be
a
little
bit
of
a
drag,
and
I
mean
there's
a
lot
of
them,
so
we
decided
to
make
it
a
shared
team
responsibility.
So
you
know
all
of
the
goal
owners
every
two
weeks.
They
pick
up
one
polish
issue
that
they're
going
to
work
on,
and
I
think
this
has
been
working
really
well.
C
Actually,
we've
been
making
a
lot
more
progress
on
this
stuff
than
we
ever
really
have
before.
C
So
it
is
a
little
bit
of
you
could
say
overhead
in
addition
to
the
like
the
actual
goals
that
people
are
driving,
but
I
mean
at
the
end
of
the
day
we
want
to
deliver
a
really
good
polished
experience
to
users
and
like
in
order
to
do
that,
we
need
to
fix
these
issues,
so
that
really
adds
up
over
time.
C
Things
seem
to
be
working,
we've
had
good
feedback
from
people
who
are
participating
in
the
process,
and
so
you
know
we've
had
like,
I
think,
three
or
four
sprints
at
this
point.
So
looking
forward
to
what
happens
next,
I
guess
it's
only
three
yeah
we're
in
the
fourth,
so
there's
one
other
thing
that
we're
going
to
tackle
next,
which
is
stakeholders
for
the
various
initiatives
so
for
async
fundamentals
we
identify,
like,
I
think,
there's
around
eight
different
people
who
kind
of
represent
different.
C
You
know
users
of
async
and
again
this
is
like
this
is
like
pretty
fundamental
stuff,
we're
doing
easy
punch
functions
and
traits
and
dentrate
and
ace
enclosures,
etc.
So
there
are
a
lot
of
different
use
cases
that
are
really
different.
C
Web
services,
you
have
operating
systems,
you
have
embedded,
and
so
we
came
up
with
a
list
of
people
who
could
kind
of
represent
these
different
perspectives
and
asked
if
they
would
do
it,
and
so
the
plan
is
to
have
like
monthly
meetings
with
the
set
of
stakeholders
where
we
update
them
on
what
we're
doing
and
we
ask
for
their
feedback.
C
This
can
help
solve
the
problem
of
it.
Being
like
really
like.
All
of
these
people
are
interested
in
what
we're
doing,
but
it's
really
hard
to
keep
up.
They
don't
have
time
to
like
follow
every
commit
that
we
push
through
repo
or
anything.
That's
like
it's
not
really
practical.
So
instead
we're
kind
of
going
out
to
them
and-
and
you
know,
soliciting
their
feedback
and
and
kind
of
asking
them
specific
questions
about.
You
know.
C
Will
this
thing
work
for
you,
so
we
haven't
actually
done
this
yet
we've
reached
out
to
the
stakeholders
we
haven't
followed
through
on
any
of
that
other
stuff.
So
I'm
looking
forward
to
seeing
how
that's
going
to
go
cool-
and
that's
all
I
had
for
today.
So
if
we
have
time
yeah
happy
to
answer
any
other
questions
that
people
have.
A
I
guess
I
have
one
comment
on
the
stakeholder
thing:
the
way
that
I've
been
thinking
of
it,
at
least
for
a
long
time.
We've
talked
about
how
the
rfc
process
and
so
on,
is
a
great
way
to
get
feedback,
but
it
comes
kind
of
a
kind
of
late
in
the
design
cycle.
A
lot
of
times,
you've
already
gone
through
all
the
trouble
to
write
the
rfc
then
and
b.
A
It's
not
something
that's
accessible
to
everyone,
especially
production
users
or
other
people,
don't
have
time
to
keep
up
with
the
thread.
So
we're
trying
to
kind
of
add
to
that
with
this
extra
process,
where
we
go
out
and
bring
in
people
who
might
not
have
been
able
to
participate
in
that
and
whose
input
we
might
just
otherwise
not
have
gotten.
C
But
yeah
yeah,
that's
something
I
meant
to
bring
up
is
that
I
mean
async.
Rfcs
historically
have
been
a
lot
to
keep
up
with
and
you
know
they
could
get
pretty
contentious
because
of
the
fact
that
they're
so
late
in
the
design
cycle
and
so
we're.
A
C
A
E
E
Roster
latter
started
out
as
a
as
an
error
resilient
parser,
which,
over
time
just
accumulated
more
and
more
language
server
features
until
it
reached
the
state
where
it
was
actually
usable
as
a
second
for
ids
or
for
for
an
actual
language
server
implementation,
which
then
sparked
the
idea
of
replacing
the
official
rust
language
server
with
russell,
as
it
said,
which
is
currently
still
in
the
works,
but
we
are
getting
there
soon,
so
differences
between
the
language,
server,
the
current
rust
language,
server
and
ross
analyzer,
for
example.
E
The
main
points
would
be
that
the
ros
language
server
is
using
plus
c
itself
to
get
semantics
semantic,
infos
and
so
on.
Like
what
does
this
resolve
to
and
all
the
interesting
things
while
rust,
analyzer,
we
don't
depend
on
the
compiler
internals
at
all.
We
only
use
it
to
basically
generate
diagnostics
and
links
from
the
compiler
itself,
so
everything
is
basically
re-implemented
in
rust,
set
cell.
E
E
We
use
the
same
lexa
src,
but
we
use
our
custom
our
own
custom
parser,
because
our
parser
needs
a
bit
different
from
what
the
compiler
has.
So
we
had
to
basically
hand
wrote
that
ourselves
and
there
are
currently
also
plans
to
lift
out
the
russell
passer
into
a
proper
standalone
crate
that
can
be
reused
itself.
E
Then.
The
main
part
russellizer
is
built
upon
is
the
salsa
incremental
database
crate,
which
is
similar
to
rusty's
query
system
and
which
is
used
to
basically
store
the
entire
information
about
the
the
project
you
you're
working
on
right
now,
basically,
and
we
use
the
chalk
rate
for
trade
solving.
For
those
that
don't
know,
chalk
is
basically
a
re-implementation
of
the
rust
trade
system,
so
we
are
reusing
that
for
our
trade
trade,
so
we
needs
which
also
makes
us
a
great
test
bed.
E
I
guess
for
well,
if
you're
finding
bugs
of
shark,
since
it's
not
really
used
by
default
in
the
original
compiler
yeah,
then
we've
got
a
few
big
milestones.
We
managed
to
get
over
the
past
years,
one
of
which
being
semantic
highlighting.
E
This
is
pretty
interesting,
because
this
is
actually
the
part
or
one
of
the
parts
in
the
russell
code
base.
That
is
the
most
advanced
when
it
comes
to
semantic
understanding
like
knowing
what
unsafe
operations
and
similar
things
and
the
nice
the
the
problem
is
currently
a
lot
of
users.
E
Don't
really
use
it
because
most
themes
in
editors
don't
have
semantic
tokens
for
the
rust
language
specific
stuff,
so
most
of
them
just
rely
on
the
old
known,
regex
based
syntax,
highlighting
which
has
a
slight
disadvantage
with
which
can
be
seen
in
the
screenshot
here.
E
Basically,
all
the
different
colors
in
the
imports
are
different
types
of
items
like
functions,
traits
instructs
and
semantic
highlighting
enables
you
to
be
able
to
highlight
all
of
these
differently
and
use
statements,
for
example.
But
if
this
was
simple
regex
space
highlighting
everything
would
have
to
be
have
the
same
color
since
you
couldn't
differentiate
them
just
by
their
identifier,
as
the
semantic
info
is
basically,
then
one
probably
one
of
the
most
light
features
that
rust
eliza
ship
pretty
early
compared
to
other
extensions.
E
E
This
is
quite
quite
a
huge
point,
because
a
lot
of
crates
depend
on
these
to
generate
items
generate
impulse
and
similar
things.
So
without
the
support
a
lot
of
crates,
just
don't
really
work
well
with
ides
an
example
would
be
the
bevy
crate,
I
think,
which
uses
a
proc
macro
to
implement
traits
on
tubers,
on
a
like
a
different
heritage
to
this
to
support
with
a
function
calls
on
them
and
without
those
inputs,
for
example,
using
the
bevy
crate
is
quite
difficult
because
the
ide
can't
infer
any
types
of
functions.
E
Error
calls
anymore
because
a
lot
of
it
goes
through.
These
implementations
and
rasterializer
itself
actually
had
a
similar
problem
in
that
without
attribute
support
using
it's
a
bit
tricky
because
the
sites
are
great,
the
database
grid
we
use
use
the
attributes
to
define
the
queries
and
the
database
signatures
basically,
and
that
meant
without
having
these
expanded
russell.
E
As
I
couldn't
really
figure
out,
what
was
the
the
function
call
on
the
database
object
for
example,
what
does
return
can
be
those
because
it
can't
see
them
properly,
so
a
lot
of
code
actually
just
didn't,
have
type
inference
or
even
fun.
Completions
because
we
couldn't
see
these
kind
of
things
yet
so
having
this
support
enabled
made
working
rastalizer
a
lot
nicer
as
well.
E
Of
course,
russell
is
not
perfect,
so
we
do
have
some
problems
some
more
serious.
Unless,
for
one
we
don't
have
error,
checking
as
you
type
so
we
have
to
run
cargo
check
every
time
we
want
to
see
actually
rust,
c
diagnostics
and
lintz.
E
We
don't
have
a
lot
of
the
diagnostics
employed
in
russell
itself,
yet
there's
no,
no
persistent
state
yet
so
whenever
you
restart
your
russianizer,
it
has
reindex
everything
from
the
start,
which
is
kind
of
slow
for
some
projects
which
hinders
productivity.
Of
course,
then
completion
completions
are
slower
than
we
would
like,
which
can
be
quite
annoying,
because
some
clients
refuse
to
show
completions
if
they
take
too
long
and
macro
abi.
Well,
the
prop
macro
api
is
unfortunately
unstable.
E
So
whenever
something
changes
in
it
or
nightly
it
just
breaks
for
every
use
of
that
knife,
because
the
micro
server
server
is
likely
to
crash
when,
when
this
sounds
this
unfortunately
forces
us
to
support
different
apis,
usually
about
three,
which
is
later
stable,
latest
nightly
and
better.
I
think
so
anything
using
another
abi
than
these
three
will
usually
result
in
a
crash
which
is
not
something
we
can.
Of
course,
at
the
moment,
address.
E
Our
type
insurance
does
not
always
agree
with
russ.
It's
not
quite
feature
complete,
so
we
can't
fully
show
our
own
site
mismatches
yet,
but
we
are
getting
there.
E
Similarly,
we
don't
support
constant
eric's
yet,
which
is
a
problem
for
some
crates
like
niagara,
where
a
lot
of
concentricness
is
used
for
mattresses
and
so
on,
and
similarly
we
don't
support
lifetimes.
At
the
moment,
though,
that's
not
really
a
problem,
since
we
can
just
replace
everything
every
lifetime
with
static
and
it
usually
works
for
everything.
E
Basically,
to
help
getting
started,
we
have
architecture,
docs
and
videos
explaining
these
things
and
the
style
guide.
Basically,
the
architecture
docs
are
more
about.
How
does
russell
either
work
in
the
big
picture
and
the
style
guide
is
basically
do's
and
don'ts
about
specific
patterns,
whether
we
like
them
or
not,
the
nice
part
about
the
style,
guide,
architecture.
Doc
thing
is
when
we
review
something
and
we
see
something
that
looks
like
a
mistake
or
something
that
goes
against
our
style.
E
E
This
way
and
another
point,
is
we
don't
really
use
clippy
actively,
because
some
defaults
are
style
wise
at
least
questionable
subjectively,
so
we
prefer
specific
patterns
that
clippy
does
not
like
that
much,
which
is
why
we
accept
clippy
pr's,
usually,
but
sometimes
we
reject
some
of
the
lines
that
were
fixed
because
we
don't
agree
with
them.
E
We
target
the
latest
stable
rust
at
any
time,
so
we
don't
rely
on
compiler,
internals
or
nightly
features.
This
has
the
effect
that
it's
easier
to
reuse
as
a
library
for
people
as
well
as
building
for
the
for
for
new
contributors,
because
you
can
usually
expect
people
to
to
have
the
latest
stable,
ros
or
be
able
to
target
later
stage
than
it
is
for
them
to
have
a
knife
installed
with
the
feature
set.
What
we
would
that
we
would
need.
E
E
Yeah
then
short
thing
about
our
meetings.
We
basically
have
two
types
of
meetings,
weekly
sync
meeting,
which
is
just
well
a
meeting
that
we
have
every
monday
where
we
just
shortly
talk
about
what
happened
the
last
week,
any
major
issues
that
appear
anything
interesting
that
have
someone
worked
on
just
to
well
get
everyone
on
on
consume,
of
what
the
week
basically
cover.
E
And
then
we
also
have
a
six-week
meeting
recurring
six
meet
a
week
meeting.
E
That
is
our
steering
meeting
and
in
that
we
basically
just
plan
ahead.
What
what
is
what
should
we
prioritize
for
the
next
six
weeks?
Is
there
anything
that
might
be
nice
to
work
on
for
the
next
time?
This
isn't
really
strict
in
a
sense,
though,
that
we
have
to
work
on
these
points
that
we
put
down
now
but
more
more
fit
directional
things.
E
So
we
try
to
push
these
points
forwards
forward,
but
if
it
doesn't
work
out,
that's
fine
as
well,
then
a
quick
showcase,
I
said
russell
can
be
used
as
a
library,
though,
with
an
unstable
api
and
that
what
is
already
being
used
for
some
things,
just
a
small
list
of
things
that
we
know
of
including
a
jupiter
kernel
and
rapper
and
other
fun
things
like
playground,
playground,
integration
and
so
on
and
lastly,
well,
what's
next
in
ship
for
one,
we
should
probably
try
getting
constant
lyrics
further,
though
this
is
unfortunately
quite
quite
a
big
issue,
so
that
might
take
might
take
a
big
bunch
of
time.
E
Then
we
are
pushing
for
librifying
rusty's,
exhaustionist
checking,
which
is
actually
making
some
progress
last
I've
seen
so,
ideally
that
would
mean
we
could
replace
our
own
copy
of
the
exhaustiveness
check,
which
is
quite
not
quite
working.
There
are
a
few
parts
that
are
just
failing
on
even
the
standard
library
there's
one
match
that
we
don't
properly
check,
I
think
so
having
this
replaced
with
the
actual
rc
implementation
would
be
quite
a
step
forward.
With
this.
E
And
lastly,
we
have
a
small
request
for
procedural
attribute
macro
authors.
Basically,
since
we
ship
attribute
expansion
by
default
now
there
was
a
bunch
of
problems
that
appeared
due
to
how
macro
authors
write
their
macros
in
terms
of
errors,
including
how
sim
handles
it
basically
try
to
recover
on
past
errors.
Don't
just
discard
the
input
compiler.
The
problem
with
this
is
basically,
if
there's
a
function
that
has
an
attribute
annotation
on
it
and
the
user
types
any
expression,
the
function
that
causes
a
temporary
syntax
error.
E
The
entire
item
gets
replaced
by
the
compile
error,
because
that's
how
the
proc
marker
was
written
and
due
to
this,
we
basically
lose
all
ide
features
for
the
time
until
the
syntax
error
is
6.,
so
ideally
try
it.
Maybe
try
consider
considering
not
using
syn
unless
you
really
need
to
and
handle
errors
properly
by
not
discarding
everything
or
maybe
explore
an
alternative
system
that
is
affordable.
That
has
better
recovery
in
that
sense,
yeah.
That
was
all
I
had
basically.
A
D
A
Don't
know
how
to
pronounce
your
name,
sorry,
but
any
other
questions,
or
should
we
move
forward.
C
Tyler
yeah,
I
I
was
wondering
if
you,
if
there
are
any
plans
to
make
or
stabilize
any
part
of
the
rest,
analyzer
api.
E
Not
for
the
near
future,
as
far
as
I
know,
because
a
lot
of
parts
are
still
moving
quite
a
lot
since
we
don't
really
have
figured
out
what
is
the
best
api
for
this?
What's
the
best
api
for
this,
so
it's
constantly
changing
for
our
internal
needs.
Basically,
so
there's
probably
gonna
be
quite
some
time
until
end
of
that
becomes
somewhat
stable.
E
Quite
important,
I
think,
because
being
able
to
just
invoke
cargo
for
everything
makes
things
of
course
easier,
and
I
think
it's
a
lot
more
friendly
for
new
contributions
for
contributors,
especially
people
that
are
quite
new
to
russ
still,
because
they,
of
course,
don't
want
to
have
to
invoke
some
other
script.
That
has
nothing
to
do
with
how
rust
usually
works
in
regards
to
building
right.
So
I
would
rate
that
quite
highly.
I
guess.
E
A
D
Cool-
and
so
I'm
stephen
most
of
you
will
have
will
know
me
by
either
being
a
member
of
the
compiler
team
or
being
very
annoying
on
twitter
asking
for
people
to
file
tickets.
I
wanted
to
talk
about
community
metrics,
which
in
I
I
I'm
going
to
be
blazing
past,
because
I
only
have
five
minutes,
but
it's
you
may
be
intrigued
about
what
I
mean
by
that,
but
before
actually
talking
about
the
metrics
themselves,
I
want
to
talk
about
the
state
of
the
project.
As
I
see
it,
we've
had
a
very
eventful
year.
D
We
er
rust
is
as
big
as
ever.
The
foundation
was
created.
The
edition
2021
was
delivered
by
a
lot
of
by
a
lot
of
great
work
that
a
lot
of
people
did
and
if
you
look
beyond
just
what
we
may
call
the
rust
compiler
and
the
associated
tooling.
If
we
look
beyond
that
rust,
if
you
look
at
what
rust
itself
is,
is
the
surrounding
tooling
next
slide
the
documentation,
the
ecosystem
and
most
important
of
all?
D
Next
slide
the
problems
of
being
able
to
know
what
the
current
state
of
things
are,
and
particularly,
if
you
look,
if
you
want
to
get
a
global
view,
if
you,
if
you
look
at,
for
example,
what
tyler
was
showing
earlier,
there
is
a
lot
of
a
management
work
that
is
required
in
order
to
figure
out
what
one
specific
project
is
doing,
and
we
currently
don't
really
have
any
good
way
of
looking
at
what
the
entire
ecosystem
is
doing
and
where
are
resources
needed
where
people
that
may
be
burning
out
are,
and
you
can
ask
one-on-one
the
people
one-on-one,
how
they
are
and
how
their
projects
are
going,
but
that
doesn't
really
scale
beyond
a
certain
size
and
next
slide,
and
because
of
that,
there
is
some.
D
There
is
a
management
management
tool
that
we
could
use
in
the
ecos
in
the
project
for
ourselves
next
slide,
which
is
what
I
meant
by
community
metrics,
trying
to
collect
data
hard
numbers
that
can
let
us
see
and
answer
those
questions.
Of
course,
any
automated
tool
is
not
going
to
really
give
you
it's
not
the
the
beginning
and
end
next
slide.
It's.
D
The
idea
is
just
to
have
a
way
of
measuring
whether
we're
actually
making
an
impact
when
we're
trying
to
make
a
change
like,
for
example,
if
we
want
to
drive
down
the
time
that
prs
are
left
open
without
a
review
we
having
metrics,
for
that,
would
give
be
very
valuable
to
real
to
know
if
we
are
actually
making
an
impact,
but
it's
also
a
way
of
shining
a
light
on
a
spotlight
on
some
things
that
may
be
problematic
like,
for
example,
we
could
identify
somebody
who
is
putting
in
a
lot
of
work,
and
we
can
then
follow
up
with
them
and
talk
with
them
one-on-one
and
actually
figure
out
whether
they
need
help
if
they
are
fine.
D
The
way
they
are
but
having
metrics
will
actually
helps
us
shine.
The
light
and
focus
on
where
to
ask
follow-up
questions
next
slide
the
work
that
people
have
been
doing
an
optically
optically
was
presented
a
few
meetings
ago.
It
collects
it's
a
tool
to
collect
metrics
from
a
curated
set
of
github
projects.
D
It
was
started
by
an
ecoductions
that
I
believe
is
present
and
keiker
did
a
lot
of
great
work
on
that.
I
think
it's
one
of
the
things
that
we
need
to
be
investing
heavily
in
and
that
can
let
us
answer
some
of
the
questions
I
showed
earlier,
of
course,
any
questions
that
we
may
come
up
with.
They
are
not
going
to
be
necessarily
right
at
the
beginning.
D
D
I
do
think
that
as
a
community,
it's
something
that
is
going
to
be
very
valuable
to
all
of
us,
as
I
mentioned
earlier,
I'm
concerned
that
maybe
we
are
reaching
the
limits
of
our
organ,
our
existing
organization
schemes,
and
I
really
want
us
to
be
able
to
tackle
bigger,
a
more
ambitious
project,
not
that
we
haven't
in
the
past,
but
thinking
back
to
28
the
2018
edition
that
burned
a
lot
of
people
up,
and
I
want
to
avoid
that.
I
want
to
make
sure
that
rust
is
healthy
and
sustainable
over
time.
I
want
rust.
D
I
want
everybody
that
is
in
the
community
to
be
comfortable
with
the
contributions
that
they
make
and
I
want
more
and
more
people
to
join,
and
I
believe
that
this
is
something
that
is
going
to
help
us.
Of
course,
I
only
have
five
minutes
and
I
may
have
blown
past
them,
but
if
you
do
have
thoughts
about
this,
please
seek
me
out
in
during
the
social
hour.
I
really
I'm
looking
for
feedback
about
this
and
I'm
going
to
be
trying
to
reach
to
more
and
more
people
in
the
community
for
feedback
after
this.
A
B
Yeah
for
sure-
and
so
we
can
just
go
to
the
next
slide.
So
this
is
an
update
about
the
ctcft,
so
we're
almost
a
team
we're
working
on
seeing
if
you
can
become
like
a
sub
team
of
the
rust
community
team.
B
If
you
so
right
now,
we
have
several
people
who
are
sort
of
working
in
different
roles
to
make
the
ct
cfts
happen
and
if
you're
interested
you
can
reach
out
to
me
on
zulu,
I'm
just
angel
on
fire
or
forest
either
way
next
slide,
and
so
the
items
that
we're
working
on
primarily
we're
trying
to
just
take
as
much
of
the
workload
off
of
nico
as
possible.
B
And
so
what
this
means
is
working
collectively
together
to
find
people
to
give
talks
each
month
and
then
also
just
figuring
out
how
to
get
more
teams
and
more
people
involved
from
our
collective
experiences
next
slide.
And
so
the
big
item
that
we
want
to
try
and
work
on
right
now
is
starting
a
lot
more
of
the
planning
in
the
open
and
so
for
people
who
don't
want
to
invest
on
like
doing
a
lot
of
the
organizational
side
of
the
team.
B
We're
hoping
that
they
can
still
contribute
and
say
this
is
a
talk
that
I'd
like
to
see,
or
I
think
you
should
reach
out
to
this
person
and
see
if
they'd
be
willing
to
to
to
give
a
talk
and
next
slide,
and
so
for
yourself.
You
can
participate
with
this
in
a
few
different
ways.
B
We
have
several
different
sections
of
each
ctcft
so
for
the
announcements,
we're
looking
for
announcements
about
practices
that
other
teams
might
like
to
adopt,
changes
to
teams
just
general
updates
that
would
be
relevant
to
people
on
other
teams.
We
have,
when
you're
suggesting
a
talk,
we're
very
often
looking
for
talks
that,
like
whose
audience
would
ideally
be
other
rust
teams,
and
so
not
necessarily
anything.
B
That's
too
technical
that
you'd
find
at
a
conference
or
something
like
that,
but
when
you're
able
to
address
all
of
these
different
people
on
like
so
many
different
teams,
there's
a
lot
of
subjects
that
we
tend
to
see
that
fit
really
well
in
the
but
then
also
calling
us
out
a
little
bit
figuring
out
what
we
can
do
better
and
so,
for
example,
in
the
next
slide,
we
have
we.
B
We
should
be
working
on
more
outreach,
and
this
was
something
that
was
brought
up
recently,
how
we're
not
really
checking
to
see
who's
attending
the
ctcfts
and
so,
for
example,
teams
who
might
never
have
heard
of
it
before
or
just
don't
have
a
lot
of
members
on
it.
A
And
I
want
to
just
add
that
in
the
pound,
ctcft
stream
in
zulu
people
can
jump
in
we're
already
talking
a
bit
about
what
to
do
for
next
time.
Jane.
Did
you
want
to
talk
briefly
about
the
contributor
survey.
F
So
contributor
survey
for
everyone
who
is
not
already
familiar-
I
have
been
working
on
this
survey
for
the
rust
foundation
and
the
the
goal
of
the
survey
is
or
first
like,
let's
go
back
yeah.
The
the
home
of
the
survey
is
in
wrestling
surveys
under
the
2021's
contributor
survey
and
then
next
slide
goals.
So
the
goal
of
the
contributor
survey
is
it's
very
similar
to
what
esteban
was
talking
about.
F
Where,
like
you,
can
have
this
information,
you
can
get
these
metrics,
but
you
also
need
to
talk
to
people
and
so
we're
trying
to
like
system
it
to
systematically
talk
to
everyone
and
basically
get
an
idea
of
what
the,
how
how
everyone
is
feeling
not
so
much
like
it's
like
we
have.
You
know
we
have
the
community
survey,
that's
talking
about
how
people
use
rust.
This
is
more
about
the
development
experience.
What's
it
like
maintaining
the
rust
project
itself,
what
are
the
problems
people
run
into
when
maintaining
the
project
like
what
are
like?
F
What
are
the
biggest
issues
that
we
should
be
addressing
cetera,
et
cetera
and
so
next
slide,
so
just
kind
of
got
ahead
of
myself
a
bit,
but
you
know
these
are
the
the
the
issues
like
what
are
the
biggest
issues?
What
are
the
issue
cause?
The
issues
that
we're
already
aware
of
like
there's,
I
think,
a
general
feeling
that
burnout
is
relatively
common
either
currently
or
historically.
So
we
want
to
basically
anything
that
we
kind
of
know
about
also
ask
questions
to
kind
of
figure
out
the
causes
of
those.
F
Similarly,
there
are
some
teams
that
seem
to
be
doing
better
than
others
and
trying
to
figure
out
what
you
know.
What
are
the
elements
of
the
teams
that
are
healthy
versus
the
teams
that
are
unhealthy
and,
like
all
together,
gather
all
this
information
about
the
contribution
experience
to
guide
pro
to
guide
the
work
the
foundation
is
doing
like
the
the
program,
so
I
guess
the
next
one
the
audience
like
who
is
this
work
for
this?
F
This
is
mostly
for
the
foundation,
but
also
just
anyone,
who's
doing
governance
or
any
other
kind
of
high
level
planning
for
how
to
run
the
project,
and
we
want
to
make
this
information
available,
so
they
can
like
basically
like
make
changes
like
if
you're
team
leads,
if
we
figure
out
like
these
are
the
things
that
work
well,
that
you're
not
doing
that,
we
think
might
help.
We
want
to
get
that
information
to
those
team
leads
as
well
and
just
generally
kind
of
improve
the
the
sustainability
of
the
project.
Overall.
F
That's
it
sorry
that
was
like
really
fast,
but
there
will
be
a
lot
more
time
for
talk
during
the
the
social
hour.
So
I
am,
I'm
really
excited
to
see
what
everyone
thinks
of
the
survey
and
get
feedback
and
hopefully
get
it
launched
soon.
So
that's
it.
A
Awesome
then
thanks
everybody
for
coming
and
that's
the
end
of
our
scheduled
content.
I'm
gonna
stop
the
recording,
but
after
this
we're
gonna
have
social
hour
time
to
talk,
ask
questions
and
just
relax,
so
they
can
be
discussing
about
kind
of
different
topics.
Whether
you
want
to
follow
up
on
some
of
the
things
that
were
brought
up
here,
like
the
contributor
survey
or
esteban,
would
like
to
talk
about
metrics
or
if
you
just
want
to
get
to
know
some
people
from
the
west
community
better.