►
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).
B
We
onboarded
a
new
collaborator,
toony
siren
who
has
been
involved
in
the
project
forever.
Just
has
never
needed
or
wanted
to
be
a
collaborator
before
so
now
he
is
okay.
A
A
If
not,
we
follow
the
standard
agenda
in
issue
number
1136
in
tst
repo.
To
start
with
the
first
one
is
remove
thunderbolt
support,
force40773.
C
There
we
go,
I
think
that
was
discussed
last
meeting.
C
A
C
A
A
B
Right
yeah,
I
don't
think
it's
particularly
time
urgent
and
I
think
we
should
probably
wait
unless
somebody
else
has
something
they
want
to
say
about
it.
I
think
we
should
probably
wait
until
at
least
matteo
is
here,
okay,
which,
which
might
might
mean
waiting
until
january,
which
I
think
is
fine.
I
don't
think
it's
people
should
re,
read
it
get
familiar
with
it
weigh
in
on
it
if
they
have
opinions,
but
I
I
don't
think
we
need
to
come
to
any
resolution
on
it
anytime.
You
know
in
the
next
several
days.
A
A
A
A
So
I
I
was
absolutely
the
last
esc
but,
as
I
understand
the
next
action
on
this
is
to
agree
on
a
set
of
voting
options
within
the
purview
of
dsc
and
then
go
for
voting.
But
then
the
options
itself
was
not
edged
on
stone.
A
People
such
as
ruben
had
concerns
or
opinions
on
what
should
be
the
right
set
of
options,
etc.
So
I
requested
ruben
to
discuss
that
in
the
previous
tlc
and
then
move
on.
I
I
don't
think
we
should
go
back
to
the
wider
collaborator
base
for
discussion
on
this
at
this
point
of
time,
because
the
the
state
at
at
which
we
are
is
to
zero
down
on
set
of
options
within
the
dsc
purview
and
go
forwarding.
C
Yeah
I
mean
the
there.
I
don't
know
last
time,
but
last
time
I
was
here,
we
had
like
a
list
of
three
options
that
was
proposed,
but
then
I
think
the
consensus
was
that
those
options
were
too
ambiguous
and
we
need
to
have
more
explicit,
concrete
options
right
and
then
I
don't
know
what's
happening
there
after
that.
D
D
So
in
this
case
we
would
have
like
a
multiple
iterations
of
voting,
because,
like
first
of
all,
we
would
have
to
maybe
know
like
what
goals
are
actually
there
and
with
which
approach.
Is
it
actually
also
possible
to
reach
that
goal?
In
fact,
and
that
makes
the
voting
process
more
difficult,
so
I
suggested
to
have
very
clear
suggestions
like
that
already
outline
both
of
these
things-
and
I
asked
all
the
tsc
members
to
mention
their
opinion
about
what
options
would
be
good
or
not,
but
the
feedback
so
far
has
been
very
little
to
none.
A
Okay,
so
looking
back
to
the
problem
statement,
the
bandits
came
originally
to
the
dsc.
Tsc
was
unable
to
take
a
call,
because
the
the
the
subject
of
primordials
was
not
very
well
known
to
all
the
members
of
the
dlc
so
as
to
converge
to
a
specific
option.
So
that's
when
we
started
a
sma
discussion
involving
people
from
the
project
who
are
who
has
specific
opinions
on
this
and
then
we
came
back
to
the
dsc
with
you
know,
one
two,
three
discrete
options
which
have
space
which
addresses
specific
goals,
and
things
like
that.
A
So
now,
that's
where
I
was
concerned,
are
we
circling
back
again
within
the
dsc
and
looking
for
options
where
tse
is
looking
for
the
smas
to
give
them
two
or
three
options
to
pictures.
B
E
Yeah,
I
have
have
opinions,
but
I
don't
know
if
I
think
I've
already
stated
everything
I
had
to
say
so
I
could
try
to
write
my
thoughts
more
clearly
the
option.
If
that
helps
people
but
yeah,
I
don't
have
much
to
contribute
to
the
conversation.
A
B
So
well
so
it
seems
like
we
had
three
options
and
and
reuben
doesn't
believe
that
that's
the
the
three
options,
at
least
as
they
as
they
were
presented,
would
be
the
best
way
to
make
this
decision
and
reuben
proposed
an
alternative.
B
But
I
don't
I
don't
know
how
I
I
don't
know
how
concrete
the
alternative
is
like.
I
don't
know
if
it's
first
we'll
vote
on
these
seven
things
as
goals
and
then
we'll
vote
on
the
or
anything
like
that.
But
I
wonder
if
I
mean
I
I
I
hate
to
suggest
this
kind
of
meta,
but
I
don't
really
know
how
else
to
approach
this.
B
I
wonder
if,
if,
if
it
makes
sense
for
the
tsc
to
make
a
decision
about
about
you
know,
okay,
we
have
these
three
options
or
we
have
the
the
more
complete
and
comprehensive,
less
ambiguous,
hopefully,
path
that
reuben
is
proposing
and
choose
between
those,
and
I
see
that
reuben
has
his
hand
up.
So
I
will
stop
talking
and
let
him
speak.
D
So
my
suggestions
were
very
concrete
and
I
had
hoped
that
it
would
lower
the
ambiguity
in
general
and
that
people
would
be
fine
with
that,
and
but
I
understood
that,
like
at
the
moment,
I
have
a
list
of
let's
see
nine
different
points
on
that
I
could
think
of,
and
I'm
not
certain
if
we
have
to
limit
it
below
that
and
if
anyone
believes
one
of
these
options
is
bad
or
if
it's
good.
Let's
just
say
this
is
a
good
option
or
not
like
I'm
not
like.
I
totally
agree.
D
D
A
So
after
listening
to
all
the
sme
talks,
for
I
don't
know
how
many
hours
we
spend,
one
of
the
conviction
I
got
is
there
is
no
single
option
which
is
foolproof
or
the
best
option.
Every
option
has
a
trade-off.
A
The
the
question
is
which
trade-off
work
better
for
us,
for
example,
if
you
are
looking
for
robustness,
you
compromise
on
performance,
you
look
for
performance,
you
compromise
on
something
else.
So
if
we
have
that
conviction
across
the
board,
then
I
think
list
out
all
the
options
and
see
if
we
can
prioritize
that
or
which
options
are
most
reasonable
to
take
and
then
to
put
it
forward
rather
than
bringing
all
the
combinations
all
the
combinations
of.
A
The
only
challenge
is
that
many
tfc
members
I
mean
the
the
voting
options
can
completely
get
distributed
and
it
can
bring
out
inconclusive
results.
That's
my
only
worry.
C
C
Again,
I
don't
think
that's
practically
doable
because
it
takes
so
much
time
and
effort
to
check
these
performance
things.
It's
like
a
last
time
we
had
a
huge
regression
on
http
and
I
don't
know
how
many
hours
mateo
spent
on
chasing
those
down.
So
I
I
don't
see
that
via
viable
option
and
then
we
have
something
else.
So
as
the
way
I
see
it
we're
you
know
we're
voting
between
tamper-free
module
loading
and
something
else
is
this:
something.
F
C
Do
nothing?
No,
there
is
something
else,
other
than
tamper,
free.
B
Okay
guide
reuben,
unless
your
hand
is,
was
never
lowered.
D
Yeah
and
put
it
up
again,
and
so
that's
also
my
like.
Thank
you
very
much
for
for
these
words,
because
I
also
have
that
problem.
You
know
like
what
is
even
something
else
like
this
is
very
ambiguous
like
I
have
no
idea
what
something
else
might
be
and
if
we
just
go
through
these
options
like,
why
is
it
like?
D
We
can
define
the
list
of
things
that
we
want
right
now.
You
know
what
we
want
to
vote
upon.
What
options
we
believe
might
be
a
way
to
go.
Is
there
anything
standing
in
our
way
to
just
look
at
that
right.
C
B
I
mean,
if
there's,
if
there's
willingness
to
do
that
now
I've
I
mean
this
issue
has
been
you
know,
so
much
work
has
gone
into
it
and
there's
been
so
much.
You
know
time
spent
on
it
that,
if
we're
going
to,
if
we're
willing
to
like
dive
in
and
make
progress
now
I
would
I
would
I
would
be.
I
would
be
totally
fine
with
that.
I
don't
know
how
yuri
should
feel.
A
Yeah,
I'm
good
with
that.
Also,
but
just
thinking
do
we
have
the
stakeholders,
whoever
took
part
in
the
discussion
from
the
tsa.
Are
there
on
this?
Michael
is
not
there,
but.
C
E
In
the
tsc,
because
there
are.
B
D
So,
first
of
all,
I'd
like
or
let's
first
come
to
the
thc
members,
so
there
were
besides
people
being
in
this
call
and
walt
was
mateo
and
mikhail.
I
believe
so,
and
those
two
were
are
not
here
now,
but
I'm.
D
You're
welcome
and
yeah,
otherwise.
I
I
second
opinion
that
probably
antoine
and
me
are
like
those
on
on
the
strongest
edges,
so
to
speak
of
the
discussion.
Oh
that
also.
E
Bradley,
which
is
bmec
on
github.
G
D
All
right,
but
let's
go
through
the
list,
so,
first
of
all,
we
have
the
possibility
to
fully
migrate
module,
loaders
and
policy
code
to
primordials
and
undo
everything
else.
Code
used
from
other
modules
would
not
be
temper
proof.
So
in
this
case
we
would
have
the
question:
what
is
my
module
load
various
in
this
case
and
policy
code?
D
We
would
have
to
probably
define
this
more
closely
as
antoine
did
in
an
in
the
main
issue
and
to
check
all
the
dependencies
from
module
loaders
and
while
that
dependency
and
list
might
not
be
really
necessary
to
maintain
the
loaders
like.
Maybe
there
are
a
couple
of
apis
pulled
in,
for
I
don't
know
some
things
that
are
not
absolutely
necessary
for
module
real
loaders
to
work,
and
so
we
might
have
to
check
that
list
again
and
probably
attach
it
to
that
option.
That
would
be
my
first
option.
D
The
second
one
would
be
fully
migrate:
module
loaders
and
policy
code
to
the
c
plus
layer
and
undo
undo
all
primordials.
That
way,
there
is
no
ambiguity
in
what
code
has
to
be
migrated
or
not,
because
all
code
would
be
just
c
plus
plus,
and
that
is
not
temper.
That
is
temper
proof,
so
that
would
probably
work
third
option
would
be
migrate,
all
modules
to
primordials.
D
C
D
C
D
E
I
guess
that
was
the
point
I
was
going
to
raise.
Also,
I
think
both
options
are
not
very
interesting
for
the
tsc
to
vote
on,
because
moving
to
the
c,
plus
plus
layer
or
using
private
yours
I
mean
it
depends.
Who
is
putting
the
work
into
it
and
I'm
not
sure
we
as
tsc
care?
E
B
Got
you
you
got
exactly
where
I
was
going,
which
is
that
maybe
we
don't
worry
about
the
implementation
but
but
decide
if
which
of
these
options?
Are
you
know
if
options,
one
and
two
both
do
the
same
thing,
but
the
implementation
details
are
different.
At
least
we
can.
We
can.
You
know,
agree
that
those
options
as
a
bundle
are
acceptable
or
not,
and
I
don't
know
richard,
were
you
gonna
say
something.
D
I
personally
believe
it
is
possible
to
also
outline
in
our
like
documentation
about
where
to
write
on
what
code
in
what
part
and
like
we
could
argue
that
module
loaders
would
have
to
be
written
in
c
plus
plus,
at
least
in
the
future,
without
like
telling
anyone
else,
and
that,
like
you,
don't
have
to
rewrite
this,
of
course
from
at
the
moment,
but
we
could
tell
like,
if
you
want
to
work
on
it,
you
would
have
to
probably
port
some
code
to
c
plus
there
would
be
one
option,
so
that's
why
I
still
believe
it
as
a
viable
option,
but
I
believe
it's
also
good
to
add
another
option
that
was
brought
up
to
make
it
tamper
proof,
while
having
like
tamper-proof
modules
like
what
would
be
really
important
for
me
in
this
case,
is
to
have
a
complete
list
of
parts
that
we
would
have
to
port.
E
D
I
believe
that's
a
possibility
so
and
that's
something
that
I
would
argue
might
be
something
as
a
to
do
for
for
next
time,
but
we
could
still
go
through
if
we
and
we
are
fine
with
with
other
options.
D
D
G
Thanks
virg,
I
I
believe
one
problem
with
the
first
two
points
that
we've
come
across
in
the
past
is
that
the
module
loader
and
the
policy
code
depend
on
other
parts
of
core
and
sure
we
can
determine
those
more
aesthetically.
The
way
javascript
allows
a
little,
but
then
every
time
we
change
code
anywhere,
even
if
it's
not
in
policy
or
the
module
loader.
G
We
have
to
check
if
it's
a
dependency
of
the
module
loader
and
have
to
check,
do
we
need
to
use
primordials
then,
when
we
change
the
module
loading
or
the
policy
implementation,
we'll
have
to
recheck
all
the
dependencies
that
we
introduce
and
then,
conversely,
when
you
look
at
code,
for
example,
a
fixed
debug
in
the
policy
loader
that
was
affected
by
a
dependency
in
the
crypto
module,
because
the
crypto
module
used
a
default.
That
would
then
affect
the
policy
module
or
the
policy
implementation.
G
I
should
say-
and
now,
if
you
look
at
the
cryptocode,
it
might
not
be
clear
why
the
cryptocode
is
using
primordials
and
the
truth
is
because
it
is
used
by
the
policy
implementation.
So
there's
a
lot
of
back
and
forth
dependencies
in
there
and
it
might
be
difficult
to
justify
those
if
it's
not
clear
to
everyone
that
it
is
a
dependency
of
the
policy
implementation
and
one.
E
Yeah,
just
I
second
that
and
that's
why
I
think
test
is
a
better
choice
than
just
a
list,
because
test
tests
will
tell
us
if
something
is
affected
or
not.
G
C
G
D
And
thank
you
very
much
for
the
point.
So
if
I
understood
that
correct,
we
need
a
list
again
of
modules
that
should
not
be
used
not
like
in
the
not
be
used
by
by
the
modules
and
by
the
module
loaders,
because
that
list
yeah.
We
could
actually
test
for
these
modules
not
being
included
during
the
loading
part.
That
would
be
a
possibility
out
of
my
perspective
and,
like
writing,
all
the
tests
individually.
D
I
agree
with
tobias
that
this
is
not
only
a
very
tedious
job,
but
it
would
also
be
very
difficult
to
achieve
it
for
the
future
like.
If
there
is
a
change,
we
would
not
be
able
to
test
it.
We
probably
cannot
think
of
all
possibilities
how
to
monkey
patch
things
or
or
to
manipulate
it.
E
C
D
C
B
G
I
I
just
want
to
add
to
that
point
that
there
are
a
few
people
who
believe
that
primordials
or
any
technology
that
has
the
same
effect
is
vital
to
a
proper
security
model
for
node.js
and
that
technically
doesn't
have
to
cover
all
code.
But
if
it
covers,
let's
say
50
of
all
node
modules,
then
it's
going
to
be
really
difficult
to
draw
lines
depending
on
dependencies
between
modules.
So,
depending
on
bradley's
idea,
for
example,
of
a
security
model,
we
might
end
up
going
somewhere
close
to
our
code.
If
you.
B
G
D
G
It's
more
about
extending,
for
example,
if
we
were
to
implement
file
system
permissions,
then
we'd
have
to
make
sure
that
all
our
file
system
apis
are
correct
and
cannot
be
tampered
with.
If
we
try
to
implement
restrictions
on
fetch
or
uris
or
anything,
we'd
have
to
make
sure
that
that
part,
of
course,
tamper-proof
yeah.
So
it's
more
about
a
more
complicated
security
model
than
policy
alone.
B
Real
quick,
I
didn't
capture
any
of
that
last
part
for
the
minutes.
If
they
need
to
be
in
there,
somebody
else
needs
to
put
them
in
there,
because
I
it's
already
left
my
brain
go
on.
D
Yeah
option
four
migrate:
all
node.js
code
to
c
plus
plus.
B
Wait
number
five,
the,
which
is
which
is
undo
all
primordials
I
mean
yeah.
I
I
mean,
if
they're,
if
there's
someone
willing
to
advocate
for
that
sure,
but
I
maybe
you
are
ruben,
I
don't
know
but
yeah.
My
sense
is
that's
kind
of
off
the
table,
at
least
in
the
in
the
short
and
medium
term,
but
okay,
yeah,
let's,
let's,
let's
leave
it
on
okay:
let's
go
on
option
six.
D
Just
in
general,
I
believe
all
of
these
options
are
not
about
medium
or
or
long
term,
pretty
much
it's
like
our
perspective
on
how
we
want
to
continue
with
it
in
general
for
the
future
yeah.
Okay,
I
mean
I.
B
D
Six
ask
the
community
in
a
similar
fashion,
as
we
did
with
unhandled
rejections
to
just
give
a
short
reminder.
In
this
case,
we
send
out
a
couple
of
options
out
to
the
community
asking
what
they
personally
would
like
as
a
behavior
for
node.js
in
specific
situations.
B
I
think
there's
been
plenty
of
conversation
about
this
and
I
think
that
I
I
I
I
I
yeah
I
I
I
I
think,
as
the
tsc,
we
really
need
to
actually
like
occasionally
make
decisions
that
aren't
that
aren't
crowdsourced,
and
this
might
be
one
of
those
cases.
But
maybe
that's
just
my
opinion.
F
F
It
was
reasonably
explained
as
to
what
the
choices
people
were
given.
So
so
you
know
the
voting
could
be
done,
whereas
I
don't
think
we
were
in
at
that
state
where
you
could
pose
a
question
with
sim
like
abc
answers
to
ask
the
wider
community
to
vote
on.
I
could
be
wrong,
but
that
that
that's
from
my
perspective,
of
where
this
conversation
is
currently
stuck
at,
is
that
if
we
had
those
options,
we
could
probably
make
a
tsc
vote.
F
G
Yes,
I
believe
I
I
agree
richard
and
I
believe
that
primordials
are
very
technical
way
of
looking
at
this.
It's
not
really
primordial,
it's
not
the
problem.
They
are
trying
to
address
the
problem
and
if
we
just
ask
twitter,
if
they
want,
you
know
to
be
tamper,
proof
they'll
just
say
yes,
probably
if
the
only
alternative
is
not
being
tamper-proof.
G
C
Robert
yeah,
I
mean
this
goes,
and
I
don't
really
have
a
sense
here
on
on
the
priority
of
things
like
this
is
about
robustness,
developer,
experience
versus
performance.
C
We
have
these
three
aspects
of
it
right
that
primordials
affect,
and
you
know
how
do
we
weigh
those
that
also
is
relevant
to
which
option
we
chose
like
if
the
developer
experience
is
the
absolute
most
important,
and
I
don't
think
primordials,
but
if
robustness
also
is
you
know,
weighted
against
that,
and
you
know
so.
I
I
think
we
have
those
three
things
that
we
are
trying
to
weigh
and
make
a
decision
based
on
that
right
and
that
that's
where
the
our
disagreement
come
a
little
bit,
because
we
we
feel
these
things
are
in
different
importance.
C
I'm
just
saying:
maybe
the
community
can
help
us
with
weighing
those
three
things
but
yeah
as
the
other
things
the
other
people
said,
I
think
primordials
are
very
technical.
So
it's
difficult
to
ask
a
direct
question
about
primordials,
but
I
guess
it
is
possible
to
ask
a
question
on
a
more
general
sense.
You
know
indirect
sense.
What
do
you?
What
do
you
feel
we
should
be
focusing
on?
But
I
kind
of
we
have
that
in
that
you
know
technical
priorities
list
that
michael
worked
on
yeah.
A
Yeah
their
primordial
questions
may
be
a
little
difficult
for
the
community
to
answer,
whereas
the
the
trade-off
in
terms
of
general
developer
experience
versus
performance
was
the
security,
that's
something
which
the
community
can
come
up
with
in
a
conclusive
manner.
So,
and
we
can
do
that,
always
we
don't
need
to
fit
it
in
this
exercise.
D
G
Yeah,
I
I
believe
you
just
said
it
in
a
different
way,
which
might
be
more
clear,
so
the
developer
experience
as
it
was
phrased
previously
really
is
just
about
the
experience
for
node
developers
working
on
core
right
primordials,
don't
really
affect
the
developer
experience
at
least
not
in
a
negative
way,
as
we
probably
intend
to
mean
here.
D
D
To
give
you
another
perspective
on
this,
so
most
like
I,
I
try
to
find
a
mentions
where
people
struggled
with
manipulating
the
code
that
they
would
have
an
actual
issue,
and
I
could
pretty
much
only
find
issues
that
were
about
the
rebel
code
where
people
did
that
and
at
the
moment,
if
someone
would
manipulate,
for
example,
let's
say,
delete
an
array
prototype
for
each
and
then
and
probably
node.js
or
would
crash,
and
the
rebel
would
close.
D
We
could
overcome
that
and
improve
the
rebel
design
a
little
bit
by
recovering
from
that
in
a
specific
state,
but
it
would
forget
all
the
former
input
from
the
user.
So
it's
not
an
ideal
state
either,
but
the
rebel
as
it
is
written
in
javascript
at
the
moment
with
node.js
it's
difficult
to
get
it
hundred
percent
right.
D
E
Yeah
sorry
running
the
mute
button.
I
don't
think
this
option
should
be
part
of
the
vote,
because
I
I
don't
think
it
has
anything
to
do
with
the
I
mean
everyone
would
would
like
to
have
something
like
that:
a
stronger
rapport,
but
just
we,
I
don't
think
we
have
a
implementation
ready
for
that,
so
who's
going
to
put
the
word
for
it
and
it
doesn't
really
address
the
issue
at
hand.
D
There
you
go
so
why
and
just
to
give
you
another
again
why
I
put
it
on
the
list
was
because-
and
people
mainly
reported
it
about
rappel
code
and
not
about
a
code
that
was
run
in
their
actual
application,
especially
because
most
code
would
probably
crash
in
that
case
anyway.
B
I
I
I
think
we
can
remove
it
and
and
remove
it
from
this
list,
but
but
obviously
you
know
we
can
leave
it
as
something
that
that
someone
can
implement
if
they
think
it's
valuable.
B
Yes,
I
know,
I
don't
think
that's
a
good
idea,
I
mean
I
I
well,
I
guess
the
question's,
not
if
I
think
it's
a
good
idea.
The
question
is
whether
it's
viable
as
something
someone
might
want,
and
I
I
guess
it
is.
Although
I
would
argue,
I
would
argue
that
that
is
a
that
is
a
major
abdication
of
decision
making
responsibility.
B
B
That
sorry,
no,
I
wanted
to
check
first
that
ruben
had
gone
through
all
of
it.
Oh
yeah.
He
said
he
had
nine
options.
That's
right!
Go
ahead,
antoine
we're
all
real
good.
Sorry.
E
Okay,
another
option
could
be
to
try
to
use
the
there's
a
proposal
buying
this
prop
tc39
proposal,
which
is
on
stage
one.
So
it's
very
early,
so
I
don't
know
if
it's
worth
adding
an
option
for
the
vote,
but
we
could
decide
to
use
this
proposal
today
which
doesn't
really
address
the
problem
but
helps
the
readability
of
fraud
modules
and
we
could
decide
that
in
our
build
chain.
We
pass
our
javascript
code
through
this
proposal,
so
it's
more
readable.
D
I
I
believe
we
discussed
that
before
and
it
does
not
address
the
situation.
That
is,
for
example,
still
a
performance
issue
and
it
would
only
partially
improve
the
readability
and
therefore
the
maintainability
of
the
code.
So
I
personally
believe
it's
not
really
an
option.
That
was
at
least,
if
I
remember
correct
the
discussion
so
far
about
it.
C
E
Sure,
but
there
was
also
an
issue
of
readability
of
the
current
code,
so
if
we
decide
to
embrace
this
proposal
early
before,
v8
actually
implements
it.
At
least
it
does
address
this
issue
in
a
non-perfect
way.
As
reuben
said.
A
I'm
just
checking
on
the
time
we
just
got
10
minutes
in
which
rich
has
a
private
topic
also
to
discuss.
So
probably,
I
think
within
this
10,
the
idea
is
to
deliberate
and
look
at
what
are
the
options
that
should
be
published
for
voting.
B
Or
we,
I
think,
I
think,
if
reuben
is
willing,
I
think
maybe
the
next
step
is
for
reuben
to
with
the
feedback
from
this
meeting
about
what
options
need
can
be
rejected
out
of
hand
and
what
options
need
to
stay
on
the
list.
Reuben
can
can
push
that
list
into
a
comment
or
an
email
to
the
tsc,
and
we
can
go
from
there.
C
Just
one
question:
does
anyone
have
any
other
ideas
or
option
that
you
know
could
be
feasible
to
add
on
this
list?
Otherwise
I
think
that's
a
great
step
forward.
D
Thank
you
very
much
for
taking
the
time
here
I
would
like
before
we
continue.
I
would
like
to
like
discuss
once
not
not,
maybe
now,
but
in
general
again
the
if
it's
actually
possible
to
reach
specific
goals
with
one
two
or
like
with
with
specific
things
in
general
and
to
have
a
general
discussion
about
that
in
the
tsc,
so
that
everyone
has
the
same
view
of
reachability
of
specific
goals
and
then
vote
on
it.
D
B
Yeah
and
if
you
want
to
include
include
you,
know
a
sentence
or
two
saying
that
you
know
we
ts
next
step.
Tsc
needs
to
decide
on
prioritization
of
robustness
versus
maintain
our
experience
versus
performance
and
vote.
You
know
that.
Might
that
might
help
that
people,
you
know
remind
people
that
that
they
don't
necessarily
need
to
dig
into
all
the
all
the
particulars
of
these
options
if
they
have
an
opinion
about
the
general
prioritization
of
those
things.
Although,
although
someone
pointed
out
we,
we
also
have
that
in
the
technical
priorities
doc.
D
B
A
B
We
do
have
six
minutes
left.
I
would
actually
propose
that
we,
we
term,
we
just
end
the
meeting
and
not
I
I
did
a
quick
glance
over
the
remaining
items.
It's
about
tsc
calendars,
tsc
meeting
times,
which
is
important,
but
we
can
discuss
that
in
the
issue
or
an
email,
the
security
triaging
stuff,
which
I'll
just
say,
is
moving
along
fine
and
and
moving
a
repository
which
you
know.
These
are
all
things
that
need
discussing,
but
we're
running
out
of
time,
and
we
do
have
some
private
business.