►
From YouTube: Lang Team Meta WG 2019.05.02
Description
The Kickoff Meeting for the lang team meta working group.
Topics discussed:
Goals of the working group
A
Resend,
it
I'm
great,
so
what
I
thought
so
what
I
was
expecting
to
do
in
this
meeting,
but
we'll
see
where
we
go?
How
far
we
get-
and
you
want
to
go
further
I
don't
know-
was
to
talk
some
about
the
problems
and
good
points
and
try
to
make
sure
we
kind
of
are
all
sort
of
an
aware
of
what
we
see
as
problems
or
things.
We
want
to
change
and
probably
discuss
some
in
there.
You
know
examples
of
those
or
things
like
that.
A
A
C
A
Okay,
now
I
can
share
well
I
always
want
to
get
it
off
to
its
own
window,
so
I'm
not
sharing
on
my
AIIMS
and
everything
at
the
same
time.
Okay,
so
this
is
the
paper,
so
yeah
I,
guess
I'll
just
do
that.
First
of
all,
what
before
we
do
this
we
could
there's
not
that
many
of
us
could
do
a
little
introductory
round.
C
A
G
D
Yeah
I
think
one
specific
issue
which
exemplifies
this
is
the
infiltrate
one,
which
is
like
a
huge
block
of
difference
discussions
and
it's
unclear
what
the
state
of
the
issue
is.
Some
parts
are
stabilized,
some
parts
are
not,
and
we
have
sort
of
smushed
together
my
different
dog
season
to
one
and
one
issue,
and
it's
not
clear
that
it's
actionable.
The
concession
issue
had
a
similar
problem
and
that
we
split
up
and
it's
more
manageable
now,
so
that
one
was
bad
and
it
became
good
I.
A
I
think
that's
true.
It's
gotten
better,
but
actually
constant
on
brings
up
another
point
that
I
don't
see
written
down.
Just
that
I
think
a
lot
of
times.
It's
hard
to
get
clarity
on
sort
of
the
use
cases
that
were
targeting
I
think
even
feature
why
we're
doing
it
and
which
things
are
most
important
and
which
are
less
I,
feel
like
in
cost
FM.
That's
very
evident
to
me:
cuz
I!
Don't
don't
have
that
fresh
to
mind
what
it's
like
the
canonical
thing.
A
So
I
put
down
like
document
and
track
use
cases
I
feel
like
that.
Well,
knowing
those
kind
of
things
also
helpful
for
when
you're
trying
to
face
and
break
up
a
design
having
an
idea
what
the
pieces
should
so
something
else,
I
added
in
here
lack
of
clarity,
around
scheduling,
I
think
this
has
been
on
my
mind
lately
with
async/await,
but
it's
I
think
it
also
came
up
with
like
rest,
2018
and
so
on.
So
we
did.
A
It
did
an
okay
job,
but
basically
the
we're
not
always
clear
about
that
when
we
will
stabilize
things
and
what
our
expectations
are
about.
That
and
I
think
like
setting
goals
of
we're
gonna
stabilize
this
by
that
time
and
then
really
figuring
out
what
that
means
and
making
sure
we
actually
either
do
it
or
know
why
we
didn't
wash
seems
like
it
would
be
useful
at
least
sometimes.
D
A
D
E
D
Very
I
think
that's
quite
important,
but
it
feels
different
than
the
than
the
issue
Jonathan
rota.
Yeah
I,
put
it
as
a
separate
point.
Mary
I
think
the
issue
jonathan
rozelle
they're
working
group
seeing
assumed
importance
like
you,
we
want
to
have
a
working
group
or
perhaps
be
some
some
of
the
users
aren't
there
or
have
been
involved
in
some
of
the
faces
so
that
you
understand
the
impact
at
that
point,
and
maybe
you
can
do
the
coordination
in
the
working
group.
E
E
So
if
you
look
at
Ross
capability
and
that
the
teams,
especially
the
design
teams,
implementation
with
compiler
team,
are
unlocking
new
abilities
in
rust,
then
users
may
be
waiting
for
those
abilities
to
be
unlocked.
They
sneak
away
more
specifically
asynchronous
programming
and
locking
that
in
unlocks
whole
scenarios
and
those
scenarios
unlock
users
to
create
products
to
create.
You
know
new
software
using
those
techniques
sure.
D
E
F
So
so
something
that
I've
noticed
as
a
person
who's,
not
super
involved
with
like
RFC's
but
sometimes
I,
see
one
and
like
oh,
it
sounds
interesting,
is
I,
know
very
little
about
the
process
and
discovering
that
process
by
entry
into
the
RFC
can
be
very
hard.
Example.
I'm
like
oh,
is
this
like
the
right
process
in
people
yeah.
It's
super
good
and
look:
oh
okay,
cool
right,
but
there's
especially
with
like,
for
example,
ASIC
away
people
coming
in
there.
They
have
like
no
idea
what
the
process
is.
F
I
think
the
first
time
around,
like
the
issue
where
everyone
commented
that
it
was
very
clear
that
people
had
like
no
idea,
I
think,
like
the
second
time
around
now
that
boats
on
the
internal
staying
there
was
a
very
clear
post
like
this
is
the
process.
This
is
the
timeline
that
seems
to
work
a
lot
better,
I'm,
not
quite
sure,
at
the
frame.
This
into
like
a
question
but
but
just
know,
I
think.
A
A
Think,
oh,
is
this
a
good
poster
child
for
this,
because
it's
very
recent,
but
we
had
to
come
up
right
central
like
around
the
future
stabilization
I.
Think,
like
you,
had
what
my
mom
is
a
really
reasonable
proposal.
But
then
there
was
this
debate
about
like
he's,
not
all
the
time
to
raise
this
proposal,
or
should
it
have
been
another
time
and
I
think
the
same
thing
is
true
in
this
context
thread
around.
A
D
This
is
a
probably
approach
there,
there's,
probably
an
issue
with
everyone
not
being
up
to
speed
with
what
we
can
do.
What
we
can't
do
and
with
respect
to
staging,
seems
to
me
that
there
are
different
sorts
of
our
seas
where
some
are
more
like
there
are
not
so
many
design
questions.
There
is
not
so
much
experimentation
to
do.
D
D
A
G
G
In
relation
to
like
just
a
tuning,
it's
also
sometimes
I'm
clear
on
the
opposite
side,
like
my
a
sink
away,
is
a
highly
popular
RFC.
So
a
lot
of
people
are
raised,
which
is
also
our
CSS,
have
been
very
unclear.
What
their
states
is
for
a
very
long
time.
I
think
one
is
like
the
actual
box
syntax
they
took
me.
I
have
to
go
through
like
three
different
threads
actually
find
an
inclusive
answer,
and
what
the
transpose
we.
A
Like
bucks
index
is
an
unstable
feature,
that's
hung
around
forever
right
and
I
think
there
are
also
rfcs
that
have
been
opened
and
just
hanging
around
for
a
long
time.
I
think
it's
a
not
a
feature,
although
it's
not
terrible
you'd
ever
like
it
seems
like
there's
a
it's
good
to
have
discussion
that
is
in
advance,
but
it's
bad
to
set
the
expectation
like
it's
an
RFC
that
might
land
in
the
shorter
and.
D
D
H
Think
all
these
points
we've
never
collected
in
original
point
about
like
not
being
able
to
figure
out
what
the
current
it
is
of
something
when
you
aren't
already
involved
like
it's
all
about
communicating
what
we
have
consensus
already
and
but
the
justification
for
that
is
yeah
I.
Think
that
all
of
it
like
pretty
much
everything
we've
been
talking
about.
It's
really
around
that
point
that
we're
not.
D
Well,
one
point
that
I
feel
you
to
make
is
that
we
we
have
a
lot
of
decks
in
in
terms
of
making
communication
clear
and
we
have
a
lot
of
debt
in
terms
of
our
FCS
that
are
still
opened
in
tracking
issues
and
stuff.
But
we
become
just
focus
on
all
the
debt
that
we
have.
We
still
need
to
do
active
design
work,
and
we
I
mean
you
can't
just
get
off
done
in
administration
of
the
things
of
the
meta
stuff.
I
mean.
H
That
actually
I
don't
know
if
I
agreed,
I
mean
I.
Think
that
there's
some
design
work.
It's
not
like.
It,
wouldn't
really
be
that
bad
for
us
to
like
drop
a
lot
of
things.
Basically,
what
we
could
need
to
work
on
having
a
better
process
for
doing
designs
like
I,
think
they're,
not
lot
of
things
that
are
super
urgent
to
do,
and
the
process
is
pre-broken
and
so
I
think
that
we
should
like
have
expectations
that
were
not
going
to
even
come
forward
a
lot
of
different
things.
Oh.
D
A
D
A
That's
when
I
jump
back
into
I
think
this
one
position
of
lane
team
somewhat
unclear
what
I
meant
was
I,
think
that
it's
not
mostly
I
mean
I.
Think
this
is
kind
of
same
as
RFC's
and
unstable
features
are
hanging
around
and
I'm
unclear
status
like
it
should
be
easier
to
tell
what
is
the
link
team
actively
working
on
and
then,
if
there
are
things
that
are
not
in
that
list
and
people
are
interacting
with
them
in
their
own
capacity?
That's
fine!
That's
good
I'm!
A
A
So
interesting
point
I
like
that.
That's
something
we
talked
about,
and
it
wasn't
on
my
list
that
there's
like
if
I
understood
you.
Basically
the
design
has
certain
values
that
we
in
decisions
we
have
made
and
I
feel
like.
We
want
to
communicate
those
and
know
what
those
are
both
to
new
link
team
members,
but
also
at
large
yeah.
D
Know
and
and
that
it
may
happen,
for
example,
if
we
take
non-exhaustive
as
an
example,
there
was
a
discussion
about,
should
we
use
naturally-occurring
mean
stopped
out
instead
of
syntax
and
just
like,
for
example,
I.
Think
that
perhaps
we
should
revisit
that
question.
There
were
some
other
people.
New
people
as
well
I
thought
that,
just
as
a
as
an
example
yeah,
what
may
happen
I
think.
A
An
example
where
this
came
up
recently
was
also
around
specialist
and
sort
of
the
value
of
parameter
city,
and
to
what
extent
are
we
bound
by
that
one
I
think
in
terms
of
reporting
about
changing
one
other
thing,
I've
been
neglected
to
say,
but
around
staging
that
I
might
that
I
wanted
to
put
some?
Where
was
this
I
feel
like
we
have
as
a
language
been
willing
to
change
our
minds
even
late
in
the
design,
sometimes,
and
while
I
don't
want
us
to
do
that?
A
A
lot,
because
it's
very
stressful,
I,
don't
know
it's
good
like
knowing
which
things
are
hyper
and
which
are
not,
may
also
help
us
decide
when
we
can
do
that,
and
when
we
shouldn't
a
lack
of
feedback
from
nightly
features
so
I.
This
is
I
think
we
may
be
in
self-evident.
We
have
nightly
features.
Sometimes
we
get
feedback.
Sometimes
we
don't.
We've
talked
it
on
and
off
about.
A
A
I'm
not
sure
I
think
a
lot
of
times.
This
happened,
I,
don't
think
this
is
only
a
lengthy
thing,
like
I
think
the
compiler
team-
it's
this
from
time
to
time
like
we
want
to
do
some
change
to
make
the
compiler
run
in
parallel
and
we're
gonna
want
people
to
gather
data
for
us,
but
maybe
the
same
mechanism
might.
D
E
D
A
Think
it
yeah
I
guess
another
related
thing
would
be
regarding
unstable
features
that
I
feel
like
right.
Now,
you
just
see
feature
it's
all
one
big
box,
and
maybe
it
would
help
us
to
clarify
it
like
this
is
a
feature
that's
really
not
stable.
You
should
expect
massive
changes
versus
one
where
it's
like
all
the
code
that
works
today
should
be
for
a
portable,
minimal
effort.
We've.
D
Moved
actually,
we've
sort
of
moved
in
that
in
that
direction,
if
you
recall
Canaries
and
gaps,
and
they
produce
a
warning
because
they
are
likely
to
just
ice
all
the
time
right
right,
that's
one
way
to
do
it.
Yeah,
that's
a
new
thing.
We've
been
doing
and
I
actually
made
a
small
change.
So
it's
easier
to
to
add
to
that
list.
We
can.
D
Like
one
thing
you
could
say
is
that
okay,
now,
if
something
has
been
implemented,
it's
well
tested,
the
only
thing
we
want
to
do
now
is
just
to
wait
like
six
or
nine
weeks
or
something,
and
then
we
will
stabilize
unless
something
strange
happens,
and
we
can
probably
note
that
mark
what
you
communicate,
communicate,
just
I
think
some
take
some
time
to
actually
get
to
it
and
so
funny.
I
think.
A
A
Okay,
that
makes
sense,
I
feel
like
there
would
be
it
would
be
nice,
sometimes
to
also
be
able
to
drive
attention
on,
like
hey
here's,
the
day's
question
of
the
week
like
when
you
use
this
this
feature,
and
it
has
this
precedence
like.
Is
that
confusing
you
find
yourself
stumbling
on
it
or
why
does
it
feel
to
you.
A
A
So
here
I
had
lack
of
clarity.
This
is
sort
of
a
I
think
this
is
somewhat
true
today,
I
think
it
may
become
were
true
around
who
makes
which
decisions
I
was
I
was
it
I
was
a
what
what
I
think
is
true
today
is
sometimes
like.
We
ourselves
might
be
unclear
about
how
much
consensus
do
we
require
from
thread
participants
versus
from
team
members,
and
when
is
when?
Is
it
okay
like?
When
is
the
right
time
for
team
to
make
a
decision?
A
Even
if
it's
controversial
and
I
imagine
that
if
we
get
functional
working
groups
where
we
have
will
sort
of
have
more
people
deeply
involved
in
the
process
that
it
will
be
also
kind
of
confusing?
Well,
what
is
the
power
of
a
team
member
who's
not
been
deeply
involved
as
compared
to
a
working
group
person
who
has
been
first
and
I?
Think
this
ties
in
with,
in
my
view,
a
little
bit
around
to
staging
kind
of
questions
too,
because
I
think
that
probably
changes
over
the
course
of
them.
A
D
A
That
you
don't
think
some
conflicts
don't
get
that
far,
because
people
were
managing
feedback.
This
this
was
I,
think
covered
already.
I
was
I,
was
thinking
about
things
like
the
syntax
thread,
and
how
can
we
get
more
rather
than
of
aimless
open
comments?
Can
we
kind
of
get
directly
feedback
on
questions
better,
but
in
general,
like
just
volume,
will
feedback
can
be.
A
A
The
last
thing
I
wanted
to
point
out,
though
josh
is
not
here,
but
this
has
been
a
big
point
of
Josh's.
Is
that
RSC's
have
been
like
a
really
good
way
that
people
get
involved
in
the
project,
sometimes
for
all
of
their
flows.
They
have
lots
of
strengths.
It
got
only
enlisted
one
here.
The
other
ones
are
maybe
self-evident,
like
science
getting
better
and
we
don't
want
to
lose
that
I
think.
So.
If
we
have
too
much
well,
I
don't
know
if
it
matter.
D
A
F
I
guess
it's
kind
of
like
a
thing
of
like
how
do
you
deal
with
like
people
they're
trying
to
sabotage
the
process?
I'm,
not
really
seeing
anything
they're
like
if
there's
a
bad
actor
that
chooses
not
to
engage
in
the
process
or
I,
don't
know
like
stuff
around
that
feel
yeah.
We
should
talk
about
that.
Yeah.
A
That's
good
I
mean
I,
think
it
doesn't.
Even
bad
faith
is
like
one
part
of
it,
and
it
can
also
just
be
as
their
own
point
of
view
about,
but
we're
vulnerable
to
a
certain
extent
to
like
just
a
good
hearted
participation
or
something.
Sometimes
we
don't
have
that
style.
However,
for
whatever
reason,
I.
D
F
Sorry,
sorry,
sorry,
sorry
I'll
go
first.
I
I
was
having
a
very
different
example
in
my
mind
that
doesn't
quite
fall
under
the
like
easy
or
difficult,
but
just
actively
people
having
a
different
opinion
and
not
engaging
with
the
process
and
yeah
like
they're
they're,
not
being
a
good
way
forward.
Out
of
that,
I
think.
H
I
think
one
thing
that
this
isn't
obviously
like
if
someone
is
like
a
co
like
pretty
actively
I'm
there,
there
are
some
things
for
like
I,
believe
moderation.
Basically,
right,
we
need
moderation
direction,
but
I
think
there
are
also
a
lot
of
things
that
are
frustrating
where
a
person
is
not
necessarily
acting
in
bad
faith,
but
they
just
like
don't
know
what's
going
on,
and
so
they
will
like,
engage
very
actively
but
like
in
a
way
that
is
like
counterproductive,
like
they're
starting
from
square
like
zero.
H
H
D
H
And
then,
then
we
can
like
not
only
we
then
be
able
to
like
yeah
like
it's
something.
We
can
actually
go
back
on
these
things,
but
then
it
wouldn't
be
fair
for
us
right
now
to
like
basically
like
no,
you
cannot.
That
comment
is
not
important
like
because
they
don't
like
it's
totally
fair.
They
don't
understand.
So
if
we
make
it
easy
for
people
to
understand
what
this
is
we've
made,
and
we
can
then
moderate
more
strongly
a
discussion
to
keep
it
focused
on
the
right
or
perhaps
just
heated,
resolve
or
something
that's.
A
To
add
a
twist
to
this,
that
I
don't
know
if
it's
exactly
yes,
it's
just
a
starting
point,
but
it's
something
that's
been
on
my
mind,
I've
been
doing
a
lot
of
reading
about
consensus
processes
and
things,
and
one
of
the
things
that
I
found
in
that
read
is
that
ours
is
quite
simple
compared
to
one
of
them
and
one
one
respect
to
way.
It's
simple
is
that
we
sort
of
have
this
idea
of
blocks
and
not
blocks,
but
a
lot
of
processes.
A
One
judicial
decision
and
I
think
the
reason
I
bring
these
up
is
I
think
sometimes
we
also
have
had
challenges
around
kind
of
trying
to
decide.
What
do
you
do
when
you
don't
agree
about?
The
rest
of
the
group
seems
to
it
just
comes
up
in
lots
of
context
and
we
have
a
relatively
narrow
palette
of
options,
and
it
might
help
us
to
think
about
having
more
I.
A
D
A
D
A
Nothing
else,
I
would
add,
is
the
reference
and
I
forget
if
we
said
this
year,
I
think
I
said
it
under
live
at
night
here
that
I
think
like
it
would
I
think
we
don't
do
we
don't
really.
We
have
traditionally
not
seen
it
as
our
job
to
write
the
documentation
for
the
things
that
get
designed,
but
I
think
that's
that
actually
should
be
our
job
and
is
our
job.
A
Yes,
especially
with
the
docs
team,
not
really
being
too
active
right
now,
but
I
think
that's
just
like
a
good
thing,
because
I
don't
think
it
ever
was
the
docs
team
job.
Instead,
we
should
have
documentation
people
in
the
lane
team
or
it
into
doing
that
kind
of
thing.
Yeah,
yes,
and
that
it
takes
the
form
of
Iseman
I,
take
explainers
and
reference
material
and.
E
Know
how
much
these
have
been
discussed,
but
just
to
kind
of
float
them
here
to
go
along
with
improving
the
process.
So
a
lot
of
what
I
was
hearing
in
the
previous
sections
were
around
not
knowing
with
the
status
of
something
is
not
knowing
why
certain
things
were
decided
on
or
what
level
they
were
decided
on.
I
was
wondering.
H
E
We
could
capture
in
the
RFC
itself
the
state
of
the
decisions
up
to
that
point.
You
know
if
you
can
kind
of
think
of
it
from
the
top
down
to
the
bottom,
at
the
top
would
have
the
motivations
and
the
use
cases
and
once
the
Vosges
login
and
those
become
you
know,
signed
off
by
the
team.
And
then
you
look
at
the
RFC
draft
and
you
can
see
that
the
team
has
signed
off
up
to
that
point,
then
the
next
stage
and
so
on.
So
when
people
jump
into
the
conversation,
you
can
just
say
it.
E
E
E
A
Thing
oh
I
was
gonna
say
that
what
came
up
again
save
code
guidelines
that
I
thought
was
interesting
in
which
we've
sort
of
failed
to
execute
on
them
was
a
request
that
we
just
for
lack
of
time
that
rather
been
not
only
justified,
only
documenting
the
consensus
but
documenting
the
motivations
more
in
line.
I
was
like.
Why
are
the
rules
this
way?
What
were
the
things
that
were
considered
yeah.
H
E
A
E
One
of
the
nice
things
that
that
leads
to
is
that
not
only
is
the
team
building
it
with
the
consensus
of
not
the
team,
but
also
the
external
conversations,
but
anyone
coming
in
has
one
single
place.
If
they
go,
they
read
and
they
know
exactly
what
the
conversation
is
up
to
that
plan.
So
that's
always
the
context
in.
D
Terms
of
technical
changes
to
our
seatbelt
and
how
we
actually
run
the
the
RFC
process,
I
mean
like
thoughts
end
and
all
that
sort
of
stuff
where
we
put
the
documents
and
and
that
sort
of
stuff
I
don't
think
there
needs
to
be
that
might
changes.
We
could,
instead
of
just
having
like
one
text,
why
we
could
just
switch
to
folders
and
put
everything
in
there
and
that
should
probably
work.
D
I
was
mostly
thinking
in
terms
of
how
we
could
implement
your
idea,
and
it
seems
to
me
that
if
you
want
to
sign
up
on
different
parts,
then
you
want
to
merge
one
part
like
we.
We
have
this
RC
and
then
we
are
merging
motivations
of
MD
into
that
folder,
and
that
way
we
have
more
and
more
parts,
I
think.
H
H
A
Do
look
forward
to
brainstorming
these
things,
but
we're
almost
at
the
end
of
the
hour
anyway,
so
I
thought
we
might
talk
about
like
what's
the
next
step.
So
one
thing
I
would
like
to
do
is
take
this
these
notes
and
try
to
turn
them
into
some
sort
of
summary.
I
think
it
doesn't
need
to
be
much
deeper
than
what's
on
here,
but
I
don't
know
if
anyone
would
like
to
volunteer
to
do
that.
A
A
Yeah
all
right
stays
stay
is
my
and
and
back-to-back
meeting
days.
It's
okay,
I
have
three
meeting
dates.
I
would
like
to
know
how,
for
but
I
could
I
mean
I
guess
I
can
run
a
doodle.
That's
like
the
easiest
way
to
address
this
problem.
Yeah
I'll
float
a
doodle
out
to
the
those
of
you
who
were
here
and
whoever
else,
and
in
terms
of
the
next
meeting
like
what
we
I
guess,
we
can
decide
a
little
bit,
but
do
we
feel
like
we
kind
of
covered
the
ground
of
the
problems
today?