►
From YouTube: Lang Team Triage 2020.07.27
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,
everyone
welcome
to
this
lame
team
meeting
2020
july
27th.
Let
me
quickly
look
at
if
there's
anything
new.
Yes,
one
new
mcp,
so.
A
Josh-
and
I
were
just
before
this
meeting
talking
about
refining
the
mcp
procedure
and
trying
to
actually
like
move
things
along,
and
we
could
discuss
that
briefly.
If
we
get
to
it,
hopefully
we
will
and
also
the
backlog
session
and
that
sort
of
intersects
in
the
meantime,
there's
this
new
mcp
that
I
haven't
really
looked
at.
I
don't
understand
what
it
is
something
about
privacy
and
test.
A
But
people
should
look
at
that
on
their
own
time.
I
guess
so.
Let's
look,
I
guess,
there's
also
a
newly
created
rfc.
That's.
A
Arguably
it
could
be,
but
maybe
it's
t-lips
the
way
it
was
categorized.
No,
maybe
it's
just
not
been
categorized.
Yet
it's
the
one
to
create
an
error
handling
project
group.
I
see
nobody
put
any
teams
like
which.
A
A
Let's
see
one
at
least
is
nominated
working
through
this
is,
to
some
extent
the
backlog
plan
and
how
to
handle
these
rc's
so
I'll
skip
over
it
for
now,
but
let's
go
down
through
updates
on
the
line
team
project
board.
One
quick
update
is
that
I
started
restructuring
this
slightly
to
introduce
a
better
notion
of
phasing.
A
So
we
have
the
incoming
proposals
and
then
I
started
breaking
up
the
active
projects,
a
bit
you
can
play
with
this,
but
depending
on
their
phase
and
in
particular
brainstorming
means
not
yet
no
rses
design
means
like
we're
in
the
creation
of
rfcs
and
or
other
similar
things.
A
Oh
boy
having
some
issues
and
then
evaluation
is
basically
just
waiting
on
people
to
use
the
feature
and
stabilization.
So
we
can
have
things
in
there
as
we
go.
I
think
in
particular
there's
a
it
just
I'll
come
back
to
it.
I
thought
of
a
stabilization
thing,
but
I
think
it's
nominated.
So
in
terms
of
updates,
async
foundations,
I
would
say:
there's
two
updates
here
to
be
given.
One
is
I
mentioned
this
last
time,
but
we're
still
working
towards
this
stream
rfc.
I
have
a
meeting
proposal.
A
Then
the
other
is
that
boats
proposed
an
async
drop
proposal
which
would
extend
the
drop
trait
with
a
kind
of
async
version
of
drop
that
runs
sort
of
a
pre-pass.
That
optionally
runs
to
help
people
do
async
activities
before
the
real
drop
runs.
They
ended
up
withdrawing
that
rfc
for
various
reasons,
but
among
them
was
well.
Basically,
there
were
some
significant
issues
raised.
A
There's
nothing
else
that
we
want
to
look
into,
in
particular
how
to
manage
panics
as
well
as
some
concerns
about
whether
it's
the
right
approach,
though
I
think
the
alternative
of
full
linear
types
is
probably
a
challenging
one.
To
really
do
the
usual
concern
about
drop,
I
guess,
but
anyway,
that's
sort
of
stable
for
now,
but
may
come
up
later.
B
I
didn't
realize
I
was
muted
but
yes
same
status.
Okay,.
A
So
tainted
fallback-
and
only
I
think
I
may
have
said
this
already,
but
I'm
working
with
blitzer
on
it.
There
was
a
comment,
but
it's
a
pretty
dramatic
proposal
to
introduce
this
inhabited
market
trade.
I
didn't
respond
yet,
but
I
think
that's
a
lot.
I
don't
think
we
want
to
go
there,
or
at
least
I'm
not
ready
to
do
that
real
updates
other
than
that
no
updates
on
this
one
const
evaluation.
We
don't
have
anyone
here
from
that
group.
Yes,.
A
A
That
rfc
is
in
fcp,
so
once
that's
done,
this
will
move
over
to
the
next
category.
I
guess
so
in
that
topic
we
I
landed
this
instruction
set
rsc.
I
made
a
tracking
issue.
I
think
logothor
said
that
they
were
gonna,
try
to
find
someone
to
implement
it.
They
had
some
candidate
in
mind.
A
A
A
A
This
is
just
a
proposal
to
make
everyone
aware.
I
guess
I
don't
think
we
have
to
decide
this
right
now
or
anything,
but.
A
Happening
there
was
this
rfc
to
let
you
write
it
in
a
more
concise
way.
You
all
know
context.
Does
anyone
not
remember
yeah,
but
today
this
throws
a
stick
stack
at
least.
A
So
the
proposal
here
is
basically
to
add
a
second
macro
for
edition
2021.
this,
since
the
behavior
of
this
will
change.
The
idea
was
why
don't
we
say
that
the
standard
panic
macro
always
throws
a
string?
A
This
is
in
edition.
2021,
panic
always
throws
a
string,
no
matter
what
and
panic
box,
or
some
other
name
throws
the
value
you
give
it
so,
and
this
would
not
be
a
macro
I
guess
it
doesn't
have
to
be.
It
would
just
be
something
like
this:
there
were
some
other
names
proposed
like
start
unwind
or
something,
but
you
know
it
doesn't
always
unwind
panic
with
which
is
okay,
except
that
I
I
pointed
out
that
we
often
use
whiff
to
mean
closures
like.
B
Right
also,
I'm
curious,
you
said,
throws
a
string,
but,
strictly
speaking,
we
I
mean
it
should
just
print
a
string
and
then
unwind,
and
it
doesn't
actually
ever
need
to
fully
materialize,
that
string
by
maleking
right.
A
Well,
catch
unwind
can
up
gets
a
value,
that
was
the
sort
of
panic
value,
and
so
it
can
have
to
materialize.
It.
A
A
I
think
the
proposal
here
was
to
still
create
a
string
capital
string
because
otherwise
it's
sort
of
you
were.
You
would
get
this
like
surprising,
edge
case
where
sometimes
it's
antique
static
stir
and
sometimes
it's
capital
strain,
and
you
can't
like
control
when
you
don't
can't
predict
which
you'll
get.
A
So
there
is
a
sort
of
meta
question
here.
First
of
all,
there's
the
details
which
we
could
discuss,
but
I'm
a
little
bit
also
interested
in
the
this
ties
into
like
edition
2021
planning
and
don't
have
to
go
into
it
right
now.
But
at
some
point
I
would
like
to
figure
out
like
I
feel
like.
We
need
to
be
tracking
these
things
and
deciding
them
or
just
making
sure
that
we're
making
progress
and
actually
I
think,
aaron
made
a
project
work.
This
probably
isn't
like
purely
linkedin
that
I
created
specifically
proposes.
B
I'm
curious
how
this
interacts
with
no
standard
I
was
just
making
a
note.
Is
there
a
fundamental
reason
that
this
needs
to
involve
box
and
string
and
allocation,
because
it
seems
like
you
could
have
a
no
standard
platform
that
nonetheless
supports
unwinding
and
just
prints
the
message
and
then
throws
away
the
message
so
that
it
doesn't
have
to
allocate
and
then
unwinds?
B
A
D
Yeah,
I
don't
remember
what
core
panic
does.
I
think
that
sort
of
one
concern
I
would
have
is
that
in
some
sense
this
is
sort
of
stable
api
in
that,
like
what
panic
2
does
if
we
start
making
that
do
like
start
making
that
return
a
tick
static,
string
versus
a
capital,
s
string
then
creates
the
currently
downcast
to
just
take
that
extra,
for
example,
because
they're
no
stood
would
stop
working
in
functions.
A
D
Sort
of
I
I
guess
in
some
sense
the
the
fundamental
aspect
of
this
is
that,
like,
even
if
we
address
the
surface
api
like
what
how
you
panic
physically,
you
still
have
the
sort
of
edge
of
when
you're
catching
that
value.
Currently,
it
matters
a
lot.
What
the
type
was,
even
though,
ideally
like
what
I
think
josh
is
getting
at,
is
that
in
some
sense,
ideally,
what
we
would
be
throwing
is
something
like
arguments
from
format
so
that
we
don't
actually
like.
A
B
I
want
to
clarify
something.
What
I'm
talking
about
is
there's
a
compatibility
concern
here,
which
is
that
today
you
can
panic
with
a
simple
string
and
it
will
always
work
no
matter
what
that
string
is
what
I'm
suggesting
is
not
that
we
prevent
that
from
working.
It's
more
that
we
specifically
look
for
format,
string
arguments
like
this
and
in
the
new
addition.
B
B
B
B
I'm
gonna
double
check
that
on
the
playground,
because,
honestly,
it's
surprising
behavior,
but
I'm
gonna,
but
I
I
think
the
only
thing
we
might
need
to
change
in
the
compatibility
boundary
on
the
edition
is
just
single
argument.
Panic
could
still
be
special,
but
only
if
single
argument,
panic
doesn't
have
any
format
string
specifiers
in
it.
Otherwise
will
error
out
yeah.
It's
just
that,
then.
That
just
seems
like
a
usability.
E
A
B
That's
my
point,
I'm
saying,
as
far
as
I
can
tell,
there
is
no
compatibility
issue
across
that
requires
an
addition
boundary
except
that
today,
if
you
do
a
single
argument,
panic
with
a
thing
that
looks
like
a
format
string,
we
don't
give
you
an
error,
because
you
might
have
meant
to
throw
a
string
that
had
curly
braces
in
it
and
on
an
addition
boundary.
We
could
say
no,
it's
always
a
format
string
and
if
it
contains
any
format,
string
specifiers
we'll
check
it
at
compile
time
and
give
you
an
error.
B
A
A
Right,
I
think,
yeah
I
agree
we
could
do
that.
I
think
the
reason
to
make
it
the
reason
that
first
of
all,
this
maybe
is
a
little
bit
of
a
libs
concern,
but
the
reason
that
it
was
I'm
not
totally
100
sure
how
much
this
is
linked,
but
the
reason
that
it
was
proposed
to
change
this
latter
case
was
basically
that
it's
confusing
to
some.
A
It's
like
a
a
bug
waiting
to
sometimes
use
an
answer
and
sometimes
a
string
that
people
don't
really
expect
that,
and
so
it
would
be
better
to
just
have
a
uniform
of
hammock
macro
always
raises
a
string.
Panic
box
always
raises
exactly
what
you
gave
it
and
now.
B
A
D
That
is
currently
the
case.
So
if
you
panic
with
like
a
formatted
like
the
let's
see
this
this
case
here,
no,
I
put
x's
in
front
of
in
core
that'll
never
allocate
because
we
can't
and
then,
if
you
use,
stood
and
then
you
don't
actually
have
a
catch
unwind
anywhere
in
your
call
stack
that'll,
just
you
won't
allocate
or
just
do
the
format,
arguments
thing
and
then,
if
you
actually
sort
of
examine
it
and
try
to
get
a
string
out
of
it
or
any
other
type
right.
D
If
you
do
catch
unwind,
we're
forced
to
allocate
a
box
and
then
we
fill
in
the
string.
A
Okay,
let's
step
back
a
little
bit,
because
I
think
we
need
to
box
this
and
move
on.
Josh
leave
some
comments,
but
I
feel
like
it
seems
clear
that
we
should
have
somebody
open
up
a
exact
proposal
and
we
should
fcp.
B
Okay,
one
thing
that
I
think
be
valuable
would
be
to
talk
about
where
the
relative
scope
of
lang
and
lib
here
is.
I
would
propose
that
within
it
is
entirely
lib's
scope
to
decide
what
the
behavior
of
single
argument
panic
should
be
in
terms
of.
Should
this
be
a
static
stir
or
a
string.
That's
a
usability
change
that
if
they
want
to
make
that
across
an
addition
boundary,
I
don't
think
we
need
to
say
anything
about
that.
B
I
it
makes
sense.
The
argument
makes
sense,
but
there
are
trade-offs
there.
I
would
propose
that,
because
panic
is
a
built-in
macro
that
has
kind
of
magic
behavior
that
can't
today,
as
far
as
I
know,
be
implemented
entirely
in
the
library,
it
may
make
sense
for
us
to
specify
the
change
from
panic
with
single
string.
Even
if
it
looks
like
a
format,
is
you
know
not
an
error
to
panic
with
a
format.
String
is
an
error.
If
you
can't
satisfy
the
format
string,
oh
it
is
purely
library
code.
D
B
Entirely
in
library
code,
I'm
assuming
it
just
has
two
branches,
one
for
single
argument,
which
doesn't
even
check
if
it's
a
format
string
and
one
for
multi-argument
which
calls
format
args,
essentially
yeah,
okay.
So
this
does
seem
then,
like
it's
mostly
a
libs
question,
but
I
would
propose
that
it
seems
like
an
addition.
Boundary
would
be
a
good
place
to
try
to
change.
B
A
I
think
that's
right,
I
take
the
lanes.
The
laying
side
of
this
is
like
most
of
these
trade-offs
feel
more
like
libs
and
we
can
advise,
but
it's
ultimately
not
the
lips,
but
the
laying
part
is
probably
just:
is
it
a
flat
string
or
not?
If
it's
and.
A
A
I
don't
know
if
we
even
need
to
make
a
comment
at
this
point
I'll
make
a
comment
on
the
effect
of
this
is
really
lipscroll.
B
Would
it
be
fair
to
say
that
lang's
general
suggestion
is
we'd
like
consistency
with
print
and
beyond
that,
whether
you
know,
however,
it
gets
to
handle
that
then
that's
fine,
yeah.
A
Okay,
so.
A
A
A
A
What
do
we
ought
to
know
nominated
issues,
probably
right
so
raw
ref
macro?
I
like
to
add
this
to
the
project
board.
Actually,
so
I
we
proposed,
we
encouraged
ralph
to.
A
A
Comments:
okay,
let
me
remove
the
nominated.
A
A
A
A
Periodic
compatible
functions.
I
did
this.
This
seems
like
an
interesting
old
thing.
I
was
just
wondering
if
anyone
has
any
idea
what's
happening
here
and
if
we.
B
Some
point
it
is:
there
was
a
little
recent
act
on
this
where
somebody-
you
already
noted
this
in
a
comment,
but
we
should
mention
in
the
meeting
that
somebody
realized
that
you
can't
actually
do
this
with
functions
that
are
inside
of
a
object,
non-free
functions
and
they
are
currently
implementing
support
for
associated
functions
and
similar.
B
So
that
should
probably
bake
for
a
little
bit
and
we
shouldn't
immediately
stabilize
that
support
immediately
after
it
goes
in.
But
if
we
separated
that
out,
I
think
the
regular
variatic
support
has
already
baked
for
a
while,
and
I
think
it's
probably
ready
to
have
somebody
make
a
stabilization
pr
and
a
stabilization
report.
B
A
I
would
josh.
Do
you
want
to
leave
a
comment
about
that.
B
Far,
oh
you're
sharing
froze
there
for
a
second,
but
it's
working
now,
I'm
checking.
B
Yes,
I
did
so
I
wanted
to
give
a
quick
explanation
for
what
this
was.
So
the
proposal
was
to
have
a
new
configuration
predicate
to
go
with
all
in
any,
which
is
exactly
one
of
these
things
is
enabled,
and
no
more
or
less.
B
This
is
useful
when
doing
things
like
here
are
some
mutually
exclusive
features
you
may
wish
to
enable
and
or
very
commonly,
mutually
exclusive
platform
tags
like
you
either
need
this
feature
enabled
or
you
need
to
be
on
this
platform,
that
kind
of
thing
that
is
really
painful
to
implement.
Otherwise,
because
you
end
up
doing
a
combinatorial
explosion
of
a
and
not
b
and
not
c,
and
not
d,
or
a
not
a
and
b,
and
not
c
and
not
d,
and
so
on.
It's
r.
B
It
would
be
nice
to
have
a
built-in
predicate
for
this.
There
was
some
discussion
around
it
to
cover
the
fact
that
the
majority
use
case
is
just
erroring
out.
There
isn't
normally
a
case
for
like
config
one
off
blah
blah
define
a
function,
it's
much
more
commonly
config
one
of
these
compile
error,
otherwise,
not
one
of
rather
so
there's
a
question
of.
B
Is
this
the
right
predicate,
or
should
it
be
more
specialized
for
error
if
these
aren't
mutually
exclusive
and
then
just
semantically
define
them
as
mutually
exclusive,
but
nonetheless
I
I
still
think
this
is
worth
doing
and
it
seems
remarkably
small
as
a
change
to
the
surface
area
of
the
language,
so
I'm
wondering
if
it
could
be
taken
through
the
mcp
process
as
a
a
simple
case
of
we'd,
like
a
solution
to
this
problem,
is
this
the
best
solution
to
this
problem?
A
B
It
seems
small
enough
that
sure
I
would
ideally
love
to
see
somebody
else
pick
it
up
and
run
with
it.
I
think
we
have
a
couple
of
other
people
interested,
but
I
was
more
nominating
it
because
I
felt
like
it
was
simple
and
straightforward
enough.
I
could
do
it
if
nobody
else
does
it
wouldn't
be
the
top
thing
on
my
backlog.
A
B
All
right,
I'm
sorry,
the.
A
B
A
Have
two
thoughts
I
mean
the
first
thing
I
thought
was
what
you
just
said:
that
is
this
really
a
predicate
in
the
same
sensor
is
this
more
of
a
declaration
and
my
second
thought
that
at
least
with,
like
cargo
features,
people
often
there's
a
kind
of
can
I
say
this
people
often
make
mutually
exclusive
features,
but
that's
kind
of
a
bug,
because
cargo
assumes
it
can
union
together
any
sets
of
features
right.
I
guess
this
is
not
the
case
for,
like
other
sorts
of
cfgs,
that
cargo
doesn't
manage.
A
B
If,
if
we
want
to
do
this
in
cargo
tamo
instead
of
rust,
then
it
would
make
sense
to
bring
in
cargo
folks,
but
given
that
we're
talking
about
something
that
would
be
arbitrary
cfgs
as
opposed
to
just
feature
flags
like
if
this
were
just,
I
want
to
declare
a
set
of
mutually
exclusive
feature
flags.
Then
that
should
be
cargo,
but
this
is,
you
know,
mutually
exclusive
config
possibilities,
which
could
be
things
like
target
pointer
size
like
one
of
the
reasons
I
wanted.
This
recently
was
a
compile
time
error.
B
A
Which
seems
like,
I
guess,
that's
awkward
express
today,
but
not
you
could
certainly
imagine
a
macro
that
especially
don't
we
have
an
error
like
a
compilation,
error
macro
or
something
you
could
certainly
imagine
writing
that
kind
of
statement
right
make
such
declarations,
and
maybe
even
maybe
I
agree
with
this.
A
C
Of
yeah,
I
think
the
rfc
thread,
like
even
cover,
like
somebody,
suggested
a
separate
macro,
a
separate
macro.
That
would
be
a
way
of
saying
these
sets
of
things
were
exclusively
like.
You
know:
shouldn't
have
these
combination,
these
things
combined
together,
which
I
kind
to
think
for
some
reason
in
my
head.
I
see
the
error.
Detection
is
orthogonal
to
the
you
know
the
config
flag
business.
C
It
would
unless,
unless
someone
can
show
me
a
case
where
you
actually
want
a
non-error
behavior,
when
you
have
more
than
one
of
them
set,
you
know
it's
something
where
you
have
two
different
non-error
behaviors
and
one
is
for
one
oven.
One
is
for
every
other
case,
but
it
seems
like
from
the
examples
I've
seen
it's
usually
more
like
there
should
be
an
error.
If
you
don't,
if
you
have
more
than
one
of
these
things
set
for
the
examples
I've
seen.
A
Even
we
know
that
the
error
behavior
is
by
far
more
common
right,
or
it's
like
it's
at
least
a
distinct
use
case
to
error.
If
these,
if
some
combination
of
these,
if
one
of
these
things
is
not
met,
the
other
thing
about
pointer
size
example
is
that
those
things
are
mutually
exclusive,
like
for
exterior
reasons.
It
could
never
be
true
right
that
they're
both
true.
A
Like
you
could
offer
error,
if
not
anyway,
anyway
long
story,
short
josh,
I
think
I'm
fine
with
mcp
process.
If
we
find.
E
A
A
So,
which
brings
up
the
end
of
our
let's
see,
rc
almost
the
end
of
our
official
legend,
so
ref
macros
checklists
for
things.
People
could
use
raw
ref,
macros,
weak,
ass,
pointer
t
felix.
Do
you
want
me
to?
I
don't
know
if
you
look
for
josh,
if
we
wanted
to
discuss
that
pointer
off.
A
Which
brings
us
to
these
other
things,
so
I
kind
of
already
covered
what
I
want
to
talk
about
edition
2021
just
we
should
well.
I
guess
I'll
point
to
the
rc
again
that
we
had
I'm
planning
to
make
this
into
a
real
rc.
A
But
one
of
the
things
I
wanted
to
do,
which
I
haven't
quite
finished,
doing.
A
I
added
like
a
brief
agenda.
A
brief
okay
go
through
some
of
the
migrations
that
might
occur,
and
I
wanted
to
go
make
sure
that
was
complete.
I
thought
we
hit
some
notes,
but
the
short
version
I'll
read
the
rfc.
I
already
talked
about
it
prior
meeting
unless
anyone
has.
A
A
A
But
what
we
ended
up
deciding
was
that
we
would
go
for
one
of
these
next
step
buttons
either.
We
would
try
to
move
it
if
we
felt
it
didn't
fit
our
priorities
or
that
we
would
suggest
filing
an
mcp,
because
we
thought
a
project
group
would
be
a
good
fit.
A
This
would
occur
if
we
thought
the
problem
was
either
small
or
self-contained
or
higher
priority,
and
if
we
thought
that
potential
solutions
like
were
not,
this
wasn't
obviously
the
right
answer
that
there
might
be
some
room
to
explore
the
possible
solutions
first
and
then
that
would
mean
then
we
have
to
like.
We
may
end
up
closing
that
because
there's
no
liaisons
around
which
josh
and
I
were
separately
discussing
but
come
back
to
that,
but
otherwise
we
might
suggest
merge
in
some
cases
where
there's
we
kind
of
knew.
A
Who
would
want
to
do
it
and
we
thought
the
solution
was
the
correct
one.
This
would
probably
be
unusual,
and
the
final
thing
we
noted
is
a
few
times.
It
seemed
like
some
of
the
things
that
were
proposed,
as
lane
could
really
just
go
to
compiler
team,
so
I
haven't
actually
acted
on
these,
but
I
think
I
will
soon
I
don't.
I
guess
I
won't
run
over
them.
A
Just
give
an
example
or
two.
So
there
was
a
proposal
for
allowing
macro
like
back
traces
and
macros
to
better
integrate,
and
we
kind
of
felt
like
that
was
more
of
a
compiler
team
like
quality
of
tools
more
than
online
team
thing,
so
that
like
we
could,
we
would
say
it's
better
to
experiment
and
they
can
compile
ncp
and
maybe
decide
whether
to
stabilize
or
any
language
changes
after
the
fact
but
stuff
like
eager
macro
expansion.
A
This
was
a
tough
one.
This
is
a
tough
one
to
get
some
opinions
from
people,
but
this
one
would
be
like.
Ideally,
we
would
have
wanted
to
encourage
an
mcp.
I
guess,
except
that
I
don't
know
that
we
have.
A
These
are
some
tweaks
to
derive
these
seem
like
they
could
fit
an
existing
priority
of
a
targeted,
ergonomic
win.
That
was
in
our
list
of
priorities,
but
we
would
want
an
mcp
because
it's
not
clear
who
would
want
to
do
it
and
the
only
one
I
think
where
it
was
like.
Maybe
we
would
merge
it
as
I
kind
of
thought
I
would
be
willing
to
help
push
this
along,
which
was
simone's
old
proposal.
A
A
Any
thoughts
on
that
should
we
go
on
there,
so
the
last
thing
was
mcp
procedure,
so
josh-
and
I
were
just
talking
about
this
before
the
meeting-
trying
to
get
a
little
more
hammered
down
on
exactly
what.
How
does
this
some
a
major
change
proposal
get
approved,
and
what
do
we
actually
do?
This
was
also
discussed
some
on
zulip.
A
I
think
what
we're
going
to
propose.
What
we
were
saying
was
that
we
would
say
potential,
so
I've
been
reaching
out
to
some
of
the
external
liaisons
we
talked
about,
but
potential
liaisons
would
assign
themselves
or
be
assigned,
and
in
this
meeting
we
would
look
quickly
and
tag
with
sort
of
the
charter
needed
or
something.
If
we
had
a
generally
positive
note-
and
we
had
some
ideas
of
what
the
point
of
that
looking
would
be
basically
we'd
be
looking
for
things.
A
We
thought
the
charter
should
cover
like
concerns
that
we
might
have
that
we
would
specifically
want
to
make
sure
get
don't
get
overlooked,
but
also
potential
gotchas
in
this,
in
the
form
of
like
you,
may
not
realize
it,
but
that's
a
really
complex
area.
That's
been
discussed
a
few
hundred
times,
and
maybe
we
don't
want
to
do
that
or
maybe
you
want
to
make
sure
you
have
this
person
or
that
person
as
stakeholders.
A
Some
of
that
discussion
we
might
want
to
do
more
in
private,
it
depends,
but
I
think
it's
good
to
have
it
officially
down
as
like
things
so
missing,
stakeholders,
no
prior
attempts
and
precedent
missing
stakeholders
and
the
other
concern
would
be
not
a
either
that
the
it's
too
much
work
and
not
a
good
fit
for
the
moment.
A
So
this
would
be
kind
of
if
we
felt
like
the
work
is
too
big
a
job.
We
should
be
able
to
know
that
at
this
time,
but
the
idea
would
be
then
that
the
liaison
works
with.
C
A
Yes,
I
think
it's
specifically
like
that's
right,
technical
debt
incurred
and
and
kind
of
like
and
or
maybe
this
fits
under
missing
expertise,
but
I
think
it's
sometimes
the
case
where
you
can't
do
that.
Work
like
the
work
will
end
up
being
right.
You
will
get
involved
because
it's
going
to
impact
different
parts
of
the
language
and
so
on,
and
it
can't
be
isolated.
A
So
I
think,
a
classic
my
classic
go-to
example,
for
this
is
the
never
type
which
we
had
a
really
willing
person
who
was
pushing
on
it.
But
it's
that's
turned
out
to
affect
like
everything
in
the
language
in
some
way
or
another,
and
it
was
just
not
in
retrospect.
I
don't
think
we
realized
what
a
big
job
we
were
taking
on
right.
So
the
idea
would
be
then
that
the
liaison
works
with
the
p
author
to
write
a
charter.
This
doesn't
have
to
be
a
lot.
A
This
can
just
be
a
copy
of
the
mcp.
If
it's
I'm
going
to
write
a
little,
I'm
going
to
write
a
little
template
but
like
it
shouldn't,
be
a
big
job
and
opens
a
pr
to
close
the
to
add
charter
and
close
the
issue.
So
that's.
This
is
the
stage
where,
like
we
currently
have
some
pending
mcps,
we
have
some
that
are
even
assigned,
but
we
haven't
had
this
meeting
and
we
haven't
seen
anyone
like
actually
write
a
charter.
So
that's
where
we're
at.
A
I
think
right
now
and
then
from
there
that
would
open
an
issue
that
we
track
and
they
work
towards
an
rfc.
A
A
One
thing
I
I
have
I'm
having
some
pretty
severe
doubts
about
the
whether
we
should
try
to
push
all
the
chat
to
zulip
or
not,
but
on
the
other,
it's
something
I
would
like
to
go
back
and
forth
about
a
little
bit.
I'm
a
little
concerned
about
it,
narrowing
out
the
range
of
people,
there's
pros
and
cons,
but
narrowing
out
the
range
of
people
who
comment
and
making
it
harder
to
follow
along
on
the
other
side
of
it.
A
C
A
A
That
it
could
wind
up
being
too
much
discussion
and
we
can't
sort
through
it.
The
zulip
feels
more
usable
now
because
it's
kind
of
focused
and
if
it
gets
too
much,
you
know
arguments
happening
that
will
be
lost,
but
I
don't
know
I
guess
we
can
only
try
it
and
see
perhaps,
but.