►
From YouTube: JupyterLab Team Meeting - June 15, 2022
Description
A meeting to share and discuss features, ideas, issues, and pull requests in JupyterLab and other Jupyter frontends. This meeting is open to anyone and everyone.
Join future calls via the Jupyter community calendar: https://docs.jupyter.org/en/latest/community/content-community.html#jupyter-community-meetings
Notes for upcoming meetings can be found on the agenda: https://hackmd.io/Y7fBMQPSQ1C08SDGI-fwtg
Past notes can be found on the JupyterLab team compass: https://github.com/jupyterlab/team-compass/issues?q=is%3Aissue+label%3A%22Dev+Meeting+Minutes%22
A
Okay,
welcome
to
the
june
15th
weekly
jupiter
lab
call.
Today
we
have
16
people
on
the
call
right
now
and
you
should
find
the
agenda
linked
in
the
chat.
A
I
guess
I
should
say
for
people
who
come
to
this
for
from
the
recordings.
The
meeting
minutes
are
also
in
the
jupiter
lab
team,
compass,
repo
and
a
pinned
issue.
So
if
you
ever
are
curious,
what
these
meeting
minutes
we
refer
to
are
that's
where
the
archive
of
them
is
so
with
that
said,
let's
get
started
today.
First
on
the
agenda
is
jeremy.
B
Yeah.
The
first
item
is
the
new
prerelease
for
4.0.
So,
if
you
want
to
give
it
a
try,
I
will
post
a
link
to
a
gist
on
the
notes.
B
The
other
thing
I
wanted
to
bring
was
a
pull
request
that
adds
kind
of
iterates
on
the
gitbot
configuration
that
was
added
a
while
ago
to
be
able
to
also
work
on
the
documentation.
So
sometimes
people
don't
want
to
go
through
the
whole
setup.
Luckily,
just
to
work
on
the
docs
make
some
edits
and
then
see
the
the
rendered
documentation.
So
instead
they
can
use
online
environments
such
as
kit
bots.
So
it's
just
iterating
on
the
previous
setups.
B
If
someone
is
interested,
it's
ready
for
for
review
and
another
thing
also
is
the
code
mirror
6
per
request
by
johan.
B
So
there
is
a
link
to
pull
request
and
now
it's
building
and
working
on
the
on
binder.
So
if
you
want
to
give
it
a
try,
please
feel
free.
So
it's
just
to
get
a
feeling
of
you
know
what
it
is
to
use
the
chrome
mirror
6..
I
think
there
are
still
a
couple
of
things
to
fix
in
a
test
and
maybe
some
css
tricks
as
well,
but
although,
apart
from
that
seems
to
be
working,
so
that's
good
news
and
that's
it.
A
On
that
page,
thank
you,
jeremy,
okay,
so
isabella
says
she
won't
be
here
until
the
last
half
of
the
call.
I
just
had
a
quick
update
on
the
conversation
we
had
last
week
about
getting
and
setting
the
service
manager
instance,
and
I
came
to
a
few
conclusions
based
on
the
questions
that
came
out
of
this
call,
and
also
just
thinking
about
how
looking
at
how
extensions
use
the
service
manager.
A
A
A
But
the
service
manager
class
is
a
true
singleton
that
always
exists
so
that
we
can
give
runtime
apis
for
people
to
swap
out
where
those
services
are
hitting,
but
so
that
the
signal
management
is
proxied,
basically
by
a
singleton
that
never
goes
away.
That
might
be
a
thing
we
consider,
maybe
not,
but
the
uncontroversial
part
to
me
seems
like
giving
people
a
way
to
access
that
singleton
and
not
introducing
a
way
to
break
jupiter
lab
beyond
how
you
could
currently
break
it.
So
so
yeah,
that's
that's.
A
If
you
are
writing
an
extension
yeah,
because
introducing
the
new
idea
comes
with
all
that
baggage
and
signal
management,
and
we
don't
have
an
answer
for
that.
So
I
don't
think
this
would,
strictly
speaking,
make
it
a
better
api.
It
seems
like
it
would
make
it
a
more
dangerous
api.
A
So
yeah,
so
because
of
that,
I
don't
believe
this
will
be
a
controversial
new
api.
I
think
it'll
be
fine,
it
doesn't
allow
you
to
do
anything
differently
than
now.
It
just
gives
you
basically
a
helper
function,
but
it
does
set
us
up
for
a
world
where
maybe
we
can
write
service
manager
in
a
way
that
allows
you
to
modify
it
at
runtime
without
having
to
write
your
whole,
your
own
application
and
instantiate
your
own
service
manager
within
that
application.
A
I
don't
know
what
the
answer
to
that
yet
is,
but
but
yeah
that
that
seems
like
another
possible
extension
point
in
a
future
pr,
not
this
one,
so
robert
we
service
manager,
singleton,
will
work
for
me.
I
need
to
replace
a
default
drive
in
my
case,
so
when
you
say
the
singleton
will
work
for
you
or
are
you
even
if
you
cannot
modify
well,
you
can't
modify
the
service
manager
to
be
a
different
one
in
this
model.
The
same
way,
you
already
cannot
like
there's
no
new
capability
introduced
here.
A
A
What
I
hadn't
considered
was
extensions
that
have
already
relied
on
signal
connections
and
there's
no
mechanism
now
for
them
to
reconnect
to
a
different
thing,
and
I
think
it
would
be
too
big
an
imposition
to
ask
extension
authors
to
worry
about
when
a
service
manager
has
been
disposed.
I
think
that
actually
is
the
domain
of
the
application
to
deal
with
and
not
extension
authors.
A
So
I
think
the
answer
here
would
be
for
service
manager,
maybe
to
have
a
register
an
unregistered
api,
or
something
like
that.
So
you
can
say
actually
your
events
implementation.
I
don't
care
about
that.
I
want
you
to
use
this
events
implementation,
but
the
service
manager
persists
it's
and
it
proxies
through
the
signals
so
that
no
one
has
to
reconnect,
disconnect
and
connect
to
a
different
set
of
signals.
A
They
can
write
their
extension
logic
in
a
way
that
just
believes
the
service
manager
always
exists
so
yeah,
I
think
that's
going
to
have
to
be
in
a
future
day.
A
So
I
think.
A
If
it's
an
attribute,
people
were
relying
on
to
never
be
modified,
then
merely
adding
a
new
signal
might
not
be
sufficient,
so
say,
default
drive
is
meant
to
be
like
a
read-only
and
there's
no
default
drive
change
signal.
Adding
a
default
drive
change
signal
might
not
be
enough,
because
your
extension
sorta
looks
like
it's
working,
but
it's
now
able
to
break
in
a
way
that
wasn't
before.
A
So
this
probably
requires
some
careful
thought
about
how
to
make
the
apis
not
work,
against
extension
logic
that
currently
works
with
semantics
that
look
nearly
identical
but
have
different
consequences.
So
I
think
we
just
need
to
think
this
through
a
little
bit,
but
it's
like
a
reasonable
thing
to
want
to
swap
out
your
service
manager.
A
So
the
answer
might
be
that,
actually
you
don't
swap
out
your
service
manager
with
an
extension
like
a
classic
jupiter
front-end
plug-in,
but
instead
we
put
in
a
different
extension
point
in
the
application
life
cycle,
for
this
specific
use
case
or
something
I'm
not
sure,
but
because
it
wasn't
obviously
the
way
that
my
current
pr
was
headed.
I
don't
now
feel
confident
about
what
the
mechanism
for
doing
this
is,
I
think,
there's
a
lot
of
ways
of
coming
at
it
and
because
it's
like
a
thing,
a
few
things
already
have
to
do.
D
A
Sure
so
there
is
a
pr
that
was
merged
into
jupyter
server.
That
exposes
a
websocket
that
publishes.
A
Json
blobs
that
contain
descriptions
of
various
events
that
have
occurred
in
your
environment,
so
they
could
be
things
like.
A
new
user
has
logged
in
or
a
message.
A
comment
was
added
to
the
notebook
you're
looking
at,
or
it
could
be
something
like
an
extension
has
published
a
mouse
click
event
occurred
in
these
coordinates
because
that
extension
cares
about
telemetry
or
it
could
be
something
like
a
thing.
A
That's
pushed
by
the
server
like
the
server
says,
I
don't
know
running
out
of
ram
or
something
like
that
and
pushes
that
event
up,
and
so
the
the
jupiter
server
endpoints
are
a
websocket
that
you
subscribe
to
and
a
endpoint
that
you
could
do
a
post
to
to
push
an
event
into
this
event,
bus
that
will
then
be
published
up
the
websocket
there's
a
new
package
called
jupiter
events
that
the
server
relies
on
that
exposes
an
event
bus.
A
That's
just
a
generic
thing
that
collects
all
events
and
allows
users
subscribe
to
them
as
an
extension
on
the
back
end,
and
that
is
the
basis
for
building
things
like
telemetry
as
an
add-on
extension,
and
it's
also
the
basis
for
thing
building
things.
Like
notifications,
inside
jupiter
lab
and
just
like
any
other
rest
and
websocket
endpoints
that
the
server
ships
with
we
have
a
package
in
jupiter
lab
services,
so
the
bit
that
I'm
saying
is
uncontroversial
is
basically
an
event
manager.
A
Just
like
we
have
a
settings
manager
lane
asks
in
the
chat.
Will
events
cover
user
facing
things
like
errors
or
all
cells
completed?
So
events
is
a
very
generic
system.
It'll
cover
anything
an
extension
decides
to
push
into
it.
So
if
the
extension
that
you're
talking
about
so
so
the
notebook
extension,
for
example,
could
execute
a
cell
finished
event.
A
If
it
wants
right
and
then
anything
else
can
be
listening
and
saying
oh
cool,
I
care
about
when
cells
execute,
because
I
want
to
compare
them
to
like
cells
that
some
user
right
clicked
on
and
said
I
care
about
this
one
or
whatever,
and
I
want
to
pop
up
a
an
alert
or
maybe
just
all
of
them
pop
up
alerts.
Who
knows
that
might
be
configurable,
but
yes,
it
is
intended
for
that
particular
use
case,
among
others,.
A
A
I
just
looked
in
the
chat
as
well,
and
so
this
describes
some
of
what
I
just
said,
but
it
also
describes
like
the
what
a
use
case.
A
potential
use
case
of
this
is,
which
is
the
jupiter
lab
notifications
package
that
we
would
like
to
migrate
eventually
from
the
jupiter
cal
poly,
or
into
jupiter
lab
and
into
core.
A
So
this
is
like
how
do
you
use
these
building
blocks
to
build
some
extension
like
this
in
the
ui,
which
I
think
is
what
lane
was
getting
at,
and
we've
had
a
long
series
of
conversations
about
this
in
jupiter
server
and
now
that
some
of
that
has
been
hashed
out
and
landed
in
server.
It's
going
up
the
stack
to
jupiter
lab.
D
Is
there
so
I
see
the
issue,
I
see
the
discussion
etc.
Is
there
a
final
like
user
end
user
level,
documentation
for
it
versus
wading
through
a
discussion
and
ideas
here
or
ideas
there
that
may
or
may
not
be
implemented.
A
So
the
idea
was
that
this
top
level
comment
actually
comes
from
a
hackmd,
that's
probably
somewhere
deep
in
that
thread,
the
top
level
comment
is
meant
to
be
the
distillation
of
all
that
discussion.
So
hopefully
you
can
refer
to
that
as
the
thing,
but
this
isn't
like
api
docs.
Api
docs
are
just
going
to
ship
with
server
just
like
anything
else.
A
A
I
don't
think
yet
because
there's
no
release
of
jupiter
server.
That
has
it
yet,
but
there
will
be
as
soon
as
it's
released.
I
think.
Okay
thanks!
Thank
you
yeah.
So
I'm
working
off
of
a
jupiter
server
self
install
like
off
a
branch
on
my
machine
right
now.
A
Okay
is
isabella
here.
If
not,
we
can
skip
and
go
to
david.
F
It
doesn't
look
like
she's
here,
yeah
all
right.
I
have
a
pull
request
in
I'm
just
gonna
post
it
in
the
chat
as
well,
but
basically
I
fixed
these
markdown
and
python
logos.
I'm
not
really
sure
if
anybody
else
noticed,
but
they
do
look
kind
of
weird
by
default,
and
the
general
idea
is
that
I
believe
we
should
seriously
consider
re-hauling
the
way
that
we
handle
css
classes
in
jupiter
lab.
So,
specifically,
a
lot
of
the
css
classes
that
we
are
using.
F
Half
of
them
are
going
unused.
So,
for
example,
we
have
jp
icon
zero
through
four.
We
have
jp
icon,
accent,
jpa
icon
brand,
and
all
of
these
are
not
actually
being
used
in
the
manner
that
they're
intended
to
so,
for
example,
we
see
icons
that
are
using
jp
icon
accent,
basically
just
to
color
something
purple
which
works
totally
fine
in
the
light
and
dark
themes
that
ship
by
default.
But
when
themed
developers
override
these
colors
thinking
that
they're,
you
know
being
used
appropriately,
they're
actually
not
and
they
break
a
lot
of
the
colors.
F
So,
for
example,
if
they,
I
believe
right
now,
if
a
theme
developer
were
to
override
what
is
it
jp,
icon
brand
it?
Actually?
Oh,
no
sorry
jp
icon
worn.
So,
ideally,
this
class
would
only
be
used
for
you
know
areas
in
the
front
end
that
were
showing
warnings,
but
no
we're
actually
using
them
to
color
the
jupiter
logo.
So
this
css
class
is
being
used
in
the
icons
for
jupiter,
the
jupiter
logo.
F
The
jupiter
lab
word
mark
the
favicon
yeah,
all
things
jupiter,
so
what
I
suggest
is
basically
getting
rid
of
these
generic
classes
that
are
not
really
being
used
appropriately
and
instead
replacing
them
with
a
with
icon,
specific
classes.
So,
for
example,
for
the
python
icon,
we
would
have
jp
icon
python,
and
that
way
we
sort
of
separate
the
icons
from
each
other
and
they're,
not
all
sharing
from
this
generic
class.
So
to
speak,
yeah
and
also
for
monochromatic
icons.
F
Instead
of
what
we
have
currently,
which
is
you
know,
jp
icon
3
is
like,
for
example,
there's
jp
icon
0
through
4
and
right
now,
by
default
in
the
default
themes,
they
actually
just
represent
various
shades
of
gr
of
gray.
So
a
lot
of
icons
in
the
ui
have
very
slightly
varying
shades
of
gray,
because
I
think
a
lot.
It's
not
really
made
clear
that
it's
not
really
clear,
which
should
be
the
standard,
so
I've
sort
of
replaced
most
instances
of
the
monochromatic
icons
with
a
jp
icon,
mono
yeah.
F
So
just
I've
addressed
a
few
comments
from
frederick
and
all
the
tests
are
passing.
I
reviewed
all
of
the
made
sure
that
there's
no
unintentional
ui
regressions
yeah,
so
I'm
totally
welcoming
review
and
thoughts
on
this.
C
I'll
for
sure
make
sure
to
take
a
look
at
it.
Since
I
was
part
of
the
original
discussion,
I
don't
know
if
I'll
have
time
this
week,
though
I'll
probably
get
to
it
early
next
week,
yeah,
that's
fine.
I
think.
F
It
will
take
some
time
for
the
discussion
on
this,
since
it's
a
pretty
big
change,
it
does
affect
the
the
view
that
shows
up
when
you're
opening
jupiter.
So
this
is
a
pretty
big
change.
I
expect
there's
going
to
be
a
bit
more
discussion.
C
Just
to
confirm,
without
reading
the
diff
you're,
not
removing
any
of
the
old
css
classes,
definition
wise,
you're,
just
replacing
their
uses
right.
I
think
the.
F
Idea
is
that
this
will
be
followed
up
eventually,
after
this
yeah
like
this.
Will
there
be
a
follow-up
to
this
that
will
hopefully
re-haul,
but
this
this
pr
itself
does
not
remove
the
styles
for,
like
all
the
generic
css
classes,
we're
using.
C
F
F
F
So
now
that
I've
switched
that
class
over
to
jp
icon
mono,
I
believe
that
any
styles
that
are
targeting
that
that
are
using
jp
icon
three
as
a
selector,
would
break.
So
I'm
not
really
sure.
If
yeah,
I'm
not
really
sure
if,
like
what
the
approach
is
here
to
like
whether
we
maintain
backwards
compatibility,
because
if
I
recall
correctly,
we
this
is,
we
are
working
on
jupiter
lab
4
right
like
that
is
in
development.
F
C
Yeah
now
that
you
bring
that
up,
I
would
agree
we
could
break
the
backwards
compatibility,
but
in
this
particular
case
we
would
need
to
be
very,
very,
very,
very
thorough
in
documenting
how
to
transition,
because
a
lot
of
people
who
do
use
this
feature
don't
understand
it
like
they
literally
like
copied
and
pasted
something
from
core
a
long
time
ago,
and
just
said:
oh,
it
works
good
yeah.
Css
is
definitely
not
something.
Most
people
bother
to
learn
the
intricacies
of.
A
Well,
the
the
other
problem
with
css
is:
we
have
to
concede
that
our
css
is
a
public
api,
because
it's
just
the
nature
of
the
language.
So
then
that
binds
us
to
api
contracts
just
like
any
other
api
has
been
released.
Even
though
we
don't
get
the
sort
of
encapsulation
you
might
want.
If
you
were
truly
designing
it
yourself,
unless
we
switched
to
like
a
preprocessor
language
or
something,
but
we
made
a
choice
not
to
use
a
preprocessor
language
in
this
way
and
yeah.
This
is
the
time
when
we
can
change
those
apis.
A
It
would
probably
be
the
like.
The
bare
minimum
would
be
to
put
this
in
the
extension
migration
guide
that
we
offer
for
each
new
version,
but
on
top
of
that,
if
there
were
oh
and
our
own
extensions,
of
course,
that,
like
we're
responsible
for
you,
know
prs
to
those
that
update
them.
So
at
least
we
have
some
examples
of
here's
how
you
update
your
extension
css
to
the
new
thing
like
if
we
had
a
list
of
a
couple.
Extensions
like
say
that
the
jupiter
lab
get
one,
for
example
right.
A
If
we
could
point
to
the
pr
that
upgraded
that
thing's
use
of
these
apis,
I
think
that
would
be
good
to
put
in
say
either
those
extension
migration
guide
or
docs,
or
in
even
a
blog
post
or
something
but
but
now's
the
time,
because
if
we
don't
do
it
now,
we'll
have
to
wait
until
jupiter
five
to
do
it.
F
And
I
do
think
this
is
an
important
feature
because
it
stops
theme
developers
from
accidentally
overwriting
important,
important
css
classes,
because
right
now,
developing
your
own
custom
css
for
jupyter
lab
is
almost
like
walking
through
a
mine
field.
Isn't
it
because
some
of
these
classes
unintentionally
change,
for
example,
the
python
logo,
the
jupiter
logo,
icons
that
really
don't
want
to
be
changed.
So
I
do
think
this
is
important
and
we
should
try
to
get
this
in
for
jupiter
lab
four
and
you're
right.
This
is
definitely
the
time
to
do
so.
F
Yeah,
I'm
I'm
totally
welcoming.
Like
documentation
suggestions.
I
did
add
some
documentation
for
what
jp
icon
london
does.
F
I
have
not
added
any
documentation
yet
for
migrations,
so
like
how
to
migrate
from
the
old
css
system
towards
new
one.
So
I'm
not
sure
if
that's
something
we
tackle
in
a
future
pr
or
if
we
bundle
it
in
this
one,
because
this
one's
already
getting
pretty
pretty
large.
F
Yeah,
if,
if
this
pr
does
get
approved
and
emerged,
I
will
write
a
tracker
issue,
because
there
are
a
few
there's,
a
few
other
icons
that
need
migration,
that
I
didn't
touch,
because
they
would
need
a
bit
more
work.
F
But
yeah
are
there
any
so
there's
a
few
questions
in
the
zoom
chat,
it
looks
like
jp
icon.
3
does
not
get
removed.
Is
this
correct
not
yet?
I
think
the
idea
is
that,
after
a
bit
more
discussion,
we
can
decide
whether
we
want
to
get
rid
of
the
old
generic
classes,
but
this
pr
that
I
posted
and
I'm
discussing
right
now
does
not
remove
the
styles.
F
It
just
switches,
it
switches
the
icon,
svg
files
to
use
the
jp
icon,
mono
class,
so
even
though,
like
the
class
itself
is
not
being
removed
like
entirely
from
the
code
base,
I've
removed
the
I've
like
the
class
is
no
longer
the
icons
no
longer
have
that
class
and
are
there
any
accessibility
implications?
F
G
A
Cool,
thank
you
and
working
on
this
stuff
must
be
lots
of
fun
because
we
now
have
these
visual
regression
tests
that
you
have
to
update
all
the
snapshots.
Didn't
you
yeah!
Thank
you.
Well,
thanks
for
doing
it.
Okay,
so
isabella
is
here
and
you
are
up.
If
you
are
ready
to
talk,
if
not,
we
can
do
a
different
thing.
First,.
G
Yeah,
no,
I
I
just
have
my
usual
announcements,
but
I
wanted
to
make
sure
y'all
know
that
things
are
always
happening.
One,
the
jupiter,
lab
accessibility
call
will
be
15
minutes
after
this
one.
It's
one
of
those
weeks.
I
do
know
some
things
that
I
hope
we're
going
to
talk
about
today.
So
we're
going
to
talk
a
little
bit
about
automated
testing
updates
and
some
related
testing
things.
G
If
that
gets
you
excited
and
or
jupiter
lab
accessibility
statement,
understanding
like
how
we
can
report
our
current
status
to
people
since
that's
like
commonly
a
requirement
that
people
ask
so
yeah.
That's
there's
your
teaser
for
the
meeting
after
the
other
thing
is
the
jupiter
community
call
is
coming
up
in
two
weeks.
They
usually
do
two
week
and
one
week,
announcements
so
get
your
shares
ready
for
that
it's
this
july.
It
is
it's
later,
though.
G
I
think
it's
actually
kind
of
a
european
unfriendly
time,
because
I'm
cycling
through
a
few
different
times,
so
we
can
see
if
there's
something
that's
better
to
alternate
between,
since
that
was
a
request,
so
we're
still
in
my
experimental
cycle.
I
believe
it's
3
p.m,
pacific.
So
the
middle
of
the
night
for
some
for
some
places
but
we'll
see
if
we
get
a
different
group
of
people,
that's
my
goal
but
yeah.
Thank
you.
A
Thanks
isabel
so
brian
wanted
to
join
this
call,
but
he
couldn't
today-
and
I
don't
have
links
to
share
with
you,
but
he
is
going
to
open
team
compass
issues
for
discussion
and
vote
around
the
organization
of
data
models
and
the
entities
they
model,
so
cell
and
cell
model
notebook
and
notebook
model,
and
what
the
place
you
import,
those
things
from
where
that
should
be
in
the
future.
A
In
the
real-time
collaboration
feature
where
models
are
more
complex
and
there's
a
few
ways
we
could
go
here,
I
think
he'll
be
making
a
recommendation,
or
at
least
presenting
a
case
for
a
way
of
doing
this,
and
the
background
for
this
is
to
try
to
land
what
the
actual
architecture
of
rtc
looks
like.
There
are
some
sort
of
base
level
fundamental
questions
like
where
should
the
notebook
model
be
now
that
the
notebook
model
is
a
collaborative
thing?
A
And
I
think
those
questions
are
the
kind
of
thing
where
in
the
past
we
might
have
got
into
lots
of
bike
shutting
over
and
now
we
have
a
jupiter
lab
council,
and
hopefully
we
can
use
the
council
to
resolve
questions
that
seem
to
have
an
endless
discussion
around
them.
Otherwise,
and
what
I
would
say
is
for
all
the
people
who
are
going
to
be
asked
to
answer
questions
like
this
and
don't
have
an
opinion
but
are
on
the
council
like
not
having
an
opinion
is
fine.
A
You
can
choose
to
abstain,
which
is
still
a
vote,
but
at
least
it's
not
a
vote
with
content,
but
at
least
it
is
a
vote
for
quorum
purposes,
so
be
on
the
lookout.
For
that,
I
think
when
he
posts
it,
he'll
probably
tag
the
jupiter
lab
council
team
on
github
and
he'll
probably
send
an
email
to
the
mailing
list
too.
A
The
reason
I'm
bringing
it
up,
even
though
the
issues
don't
exist,
is
because
the
rules
are
written
to
be
a
weak
for
a
vote,
and
I
didn't
want
to
have
to
wait
until
next
week,
if
brian
can
offer
these
issues
today.
So
I'm
just
pre-announcing
them
and
hopefully
you'll
see
that
soon
yeah.
I
think
that's
all.
I
really
have
to
say
about
that.
A
Okay
is
there
anything
anyone
else
wanted
to
bring
up
because
we're
at
the
end
of
the
agenda.
D
For
those
people
that
haven't
been
following
along
but
would
like
to
make
an
informed
choice,
will
the
issue
comprehensively
summarize
the
options
and
ramifications.
A
I
think
the
issue
is
actually
meant
to
be
the
opposite
of
a
comprehensive
summary.
It's
instead
meant
to
be
a
foundational
question
of
fairly
simple
organization
of
what
kind
of
apis
do
we
want,
so
that
we
can
create
constraints
around
which
to
build
rtc
on
top
of,
rather
than
so
in
a
way
this
is
to
solve
our
question
of.
How
do
we
do
this,
but
more?
It
is
to
say:
okay,
as
a
team,
we've
decided.
A
These
are
the
constraints
around
which
we'll
build
apis,
and
so
no,
I
don't
think
it'll
be
a
a
big
background
context.
Sort
of
thing
I
think
it'll
more
be
here,
are
two
models
of
ways
we
could
organize
these
things
of
those
you
know
brian
will
probably
express
an
opinion
and
say
this
is
the
one
this
vote
is
advocating
for
what
do
you
guys
think
you
agree.
A
E
A
If
we
don't
have
anyone
else
who
wants
to
speak
on
the
regular
agenda,
we
do
have
two
pr's
that
have
been
added
to
the
pr
standing
review.
So
it
would
be
really
helpful
if
anyone
on
this
call
wants
to
assign
themselves
as
a
reviewer.
A
It's,
I
guess,
a
good
time
to
announce
that
24
hours
from
now
no
24
hours
and
18
minutes
from
now.
We
have
the
weekly
triage
call
that
jason
weil
hosts
and
we
look
at
issues
that
have
come
into
jupiter
lab
and
try
to
make
sure
nothing
falls
through
the
cracks.
So
if
you
can
make
that
that
would
be
really
helpful
and
it's
been,
it's
been
really
good.
Jason's
been
running
this
for
a
while
now,
and
I
think
this
is
the
most
responsive
we've
ever
been
to
issues
coming
in.
A
So
it's
it's
great,
but
more
people
would
be
better.
Okay,.
H
Thanks
yeah,
I
appreciate
the
shout
out
like
I've.
I've
done
some
of
these,
where
we've
had
just
one
or
two
people
on
the
call
which
makes
it
go
very
fast,
but
it's
not
very
well
informed.
H
Our
goal
is
to
triage
every
issue,
which
is
to
say
either
accept
it
close
it
or
ask
for
more
information
within
a
week
of
its
filing
and
as
of
right
now,
we've
got
14
open
issues
in
jupiter
lab,
and
so
even
if
you
don't
feel
like
you're
tremendously
qualified,
this
is
a
great
way
to
learn
more
because
I'm
certainly
not
knowledgeable
about
100
of
all
these.
But
the
the
big
question
is
like:
should
we
accept?
An
item
is
something
potentially
doable
is
an
issue.
A
Yeah
and
and
don't
feel
the
pressure
of,
I
don't
know
how
to
solve
this
person's.
Just
that's
not
what
triage
is
triage.
Is
this
issue
one
we
need
to
try
to
solve.
Is
it
one
that's
already
been
solved?
Is
it
a
duplicate?
It's
work
that
any
one
of
us
could
do
by
just
searching
previous
issues
or
by
trying
to
and
get
the
really
low
hanging
fruit
like
hold
on
a
second.
They
didn't
even
tell
us
what
browser
they
were
using
like
those
sorts
of
things,
it's
just
to
make
sure
that
nothing
that
gets
posted.
A
That's
a
good
faith
contribution,
even
if
it's
just
a
question
gets
ignored
like
it's.
It's
really
good,
for,
I
think,
giving
community
the
the
confidence
that
the
project
is
paying
attention.
D
I
just
want
to
add
a
thanks
to
jason
and
others
that
have
participated.
Often
a
comment
will
come
in
from
the
triage
that
will
prompt
me
to
look
at
an
issue
and
make
another
comment
or
two
so
having
a
comment
from
the
triage.
Like
is
a
second
note
in
the
inbox,
so
it
doubles
or
triples
the
visibility
that
issue
for
others
that
aren't
participating
but
can
contribute
asynchronously.
H
Yeah,
I'm
usually
the
one
who
who
adds
comments
on
triage
issues,
which
means
that
sometimes
I
get
positive
comments
back
more
often,
I
get
criticism
because
I
like
didn't,
understand
an
issue
or
I
closed
it
prematurely.
But
to
be
honest,
I
would
much
rather
say
something
that
is
wrong
than
say
nothing
at
all,
which
is
the
normal.
The
track
for
a
lot
of
open
source
projects
where
you
you
open
an
issue
and
just
seems
to
disappear
into
the
void
and
so
you're
less
likely
to
file
another
issue.
A
Yeah
no
and
another
aspect
of
this
that
I
think
is
worth
pointing
out
is
we
do
often
get
asked
what,
if
I
don't
want
to
make
code
contributions,
but
I
want
to
help
you
out.
This
is
how
you
help
out.
You
know,
like
people
are
asking
questions.
You
probably
know
the
answer.
Come
answer.
If
you
don't
know
the
answer,
but
you
know
it's
a
legit
question
mark
it
as
a
legit
question
right.
These
are
things
that
are
easy
to
time
box.
A
A
It
would
have
been
really
beneficial
to
have
done
this
earlier.
To
be
honest,
but
I'm
glad
it's
happening
now.
Okay,
I
guess
I
will
stop
the
recording.