►
From YouTube: IPython/Jupyter Dev Meeting, April 5, 2016
Description
Meeting of the IPython/Jupyter development team.
A
A
But,
as
we
said,
a
world
domination
as
a
service
makes
it
hard
to
make,
makes
it
hard
to
say
no
to
things.
But
we
are
going
to
work
over
the
next
few
weeks
on
on
actually
drafting
sort
of
a
mission
and
vision
statement
for
the
project
where
we
make
explicit
and
we
communicate
explicitly
sort
of
what
it
is
that
we're
trying
to
do
we're
working
on
basically
absorbing
all
of
the
outcome
of
the
dead
meeting
into
a
roadmap.
A
B
A
But
but
we
will
be
working
on
that
repo
over
the
next
or
the
next
few
days
to
to
have
a
fully
fleshed-out
world
map
for
the
next
development
cycle.
We
are
deciding
sort
of
how
to
improve
our
communication
practices,
especially
with
regards
the
real
time.
So
this
is
a
heads
up
that
we're
prob
more
likely
going
to
reduce
significantly
our
use
of
of
Gator.
A
We
have
created
a
new
repo
called
Jupiter
/
help
that
is
really
encouraged,
as
as
a
central
point
for
where
any
question
is
welcome
and
all
help
questions
can
be
posted
in
that
way,
you
can
basically
use
them
effectively.
The
repo
has
a
threaded
mailing
list
where
you
can
easily
subscribe
and
unsubscribe
from
and
as
for
the
real-time
communications,
were
sort
of
sorting
out
exactly
how
we
are
going
to
do
that,
but
we
know
that
we
want
to
do
less
decision-making
in
real
time
so
that
it's
easier
to
to
follow.
A
What's
going
on
on
the
entire
project,
we're
going
to
try
to
make
more
explicit
the
areas
of
the
project.
This
is
part
of
the
finally,
the
roadmap
and
and
mission
and
vision
statement,
so
that
we
can
break
down
the
decision-making
workflow
and
give
more
autonomy,
two
teams
so
that
we're
not
bottle
making
as
much
as
we
are
right
now
put
a
lot
of
time
into
our
community
pipeline.
Basically,
from
I'm
new
to
this
project,
I
need
a
little
bit
of
help
all
the
way
to
have
become
a
core
developer.
How
do
we
improve
that
process?
A
We're
thinking
about
it
roughly
18
month
timeline
and
the
idea
of
drafting
sort
of
them
Python
to
end
up
life,
manifesto
that
that
multiple
projects
could
sign
on
to
and
have
a
coordinated
plan
that
that
also
gives
us
enough
time
to
work
with
all
of
the
various
channels
that
distribute
these
tools
so
that
they
have
they
have
a
suitable
transition
plan.
For
that
there
was
a
lot
of
discussion
about
the
dashboarding
work
that
the
IBM
team
has
been
doing,
and
that's
already
there's
already
a
link
to
that
on
the
on
the
road
map.
A
There's
this
is
going
to
be
most
likely
one
of
the
next
things
coming
down
the
pipe
for
graduation
from
incubation.
The
work
has
been
really
high,
quality
and
I.
Think
everyone
is
pretty
excited
about
it.
The
IBM
team
also
gave
us-
and
this
was
actually
done
as
an
example
was
done
with
a
dashboard
but
a
rundown
of
the
UX
survey
that
indicated
that
there's
a
lot
of
interest
in
ID
like
features,
there's
a
link
there.
We
encourage
everyone
to
play
with
that
dashboard
and
play
with
the
data.
A
That
is
not
only
for
the
end
users
of
how
the
how
the
functionality
is
going
to
come
into
the
the
UI,
but
also
how
we're
going
to
make
as
smooth
and
as
possible-
and
we
know
there
will
be
some
bumps
along
the
way,
but
as
smooth
as
possible.
The
transition
for
extension
authors
so
that
we
build
basically
bridge
ap,
is
that
let
people
get
from
here
to
there
without
simply
having
to
drop
their
entire
code
base
and
rewrite
it
and
the
full
notes.
A
This
is
just
a
very
quick
skim
of
the
high-level
bullet
points
and
five
and
five
six
minutes.
Anybody
who's
interested
there's
a
link
to
the
dev
meeting
minutes
there
are
and-
and
we
will
be
digesting-
that
into
roadmap
and
teamwork
and
and
and
specific
so
delivery
plans
in
the
future
and
but
before
we
get
into
individual
people.
I
want
to
welcome
the
newest
member
of
the
team.
We
have
hired
a
new
project
manager.
Her
name
is
Daniel
Whittaker
and
happy.
A
Started
officially
at
Berkeley
as
of
yesterday,
and
so
most
of
you
were
on
the
detonating
call
met
her
last
week,
but
she
will
be
a
new
regular
face
at
the
project
and
we're
very
excited
to
have
you
Jamie.
So
I
don't
know
it.
Does
anybody
else
have
any
any
other
high
points
that
that
they
want
to?
They
want
to
flag
from
the
dead
meaning
for
this
quick
summary
and
otherwise,
I'm
done.
I
wasn't
planning
on
doing
any
more
detail.
B
So
I
will
start.
One
thing
we
decided
was
to
move
and
try
to
move
the
guitar
channel
to
Jupiter
/
help
and
the
question
I
have
is:
do
we
want
to
do
something
similar
with
ipython,
or
do
we
redirect
the
ipython
bitter
to
also
Jupiter
/
help?
It
feels
to
me
like
rejecting
people
for
from
the
ipython
channel
contributor.
/
help
is
the
wrong
things
to
do.
As
you
are
trying
to
explain
to
people
the
difference
between
Jupiter
and
I
Python
on.
D
B
D
A
Or
they
can
or
they
can
redirect
people
to
their
own
communities,
but
there's
a
different
Haskell
kernel
and
the
ipython
kernel,
which
is
that
we
write
a
Python.
We
don't
write
the
hassle
one
and,
and
so
the
the
reason
for
ipython
to
being.
There
is
because
I
python
is
sort
of
a
wholly
owned
subsidiary
of
Jupiter
sure.
B
That's
kool
is
not
it's
a
vicious
circle.
If
you
get
the
people
from
the
ipython
Colonel
to
ask
question
on
the
Jupiter
organizations
and
overlap
between
the
Jupiter
and
I
patent
asian
stay
high
and
then
you
have
no
separation.
So
it
was
just
why
I
asked
the
question
because
we
didn't
explicitly
ask
for
that:
no.
A
I
I
think
we
I
mean
just
like
we've,
been
encouraging
that
that
most
ipython
discussions
happen
on
that.
The
Jupiter
mailing
list
is
a
kind
of
an
all-encompassing
space
for
for
for
the
project.
The
repo
should
mimic
that
we
occasional
questions
from
other
kernels
were
most
likely
to
be
able
to
say
you
should
talk
to.
The
experts
were
in
some
other
channel
and
those
communities
are
going
to
have
their
own
practices,
we're
not
going
to
impose
impose
our
communication
model
and
other
on
other
communities.
B
B
A
You
out
I
used
to
have
the
OP
the
OP,
the
channel,
whatever
that
thing
is
called
kind
of
the
channel
control
passwords,
but
I
literally
lost
those.
Probably
eight
years
ago,
I
I
once
tried
to
dig
through
my
various
passwords
and
I.
Didn't
have
that
one
in
the
password
manager.
It
was
because
of
me
before
I
become
more
organized
with
passwords
and
I
I
could
not
get
the
OP
control.
B
B
Yes,
these
are
not
the
Commission
you're
looking
for
and
did
I
seems
to
provide
nice
api's,
and
we
are
already
thinking
about
changing
the
shape
of
the
computer
in
diamond
I.
Python
have
a
column
with
the
actual
completion,
a
column
with
some
hint
of
the
type
of
the
object
and
the
third
area
where
you
would
have,
for
example,
a
duck
string
of
the
completion
you're.
Currently
selecting
if
you're
interested
in
that
you
can
come
on
the
issue
in
the
ipython
repo
and
subscribe,
we
will
probably
disk
is
that
in
the
next
few
weeks.
A
B
We
want
to
do
the
same
kind
of
completion
internet
book
for
the
long
term
want
to
discuss
the
design
and
how
we
do
that
exactly
yeah.
But
basically
many
people
who
are
explored
completion
are
coming
up
with
the
same
IDs.
We
had
we'll
work
on
that
last
year
and
we
are
trying
to
converge
on
some
yeah.
A
B
B
F
F
So,
sometime
today,
after
this
meeting
we're
going
to
get
together
and
can
I
hash
out
what
pieces
of
decorative
widgets
can
graduate
into
ipy,
widgets
and
Jupiter
jeaious
widgets,
and
what
other
pieces
need
to
go
elsewhere
and
where
they
should
go
and
I
think
actually
Thomas
since
you're
in
the
room
I
should
let
you
know
we'll
probably
be
talking
to
you
at
some
point
about
possibly
moving
decorative
widgets
into
ir
or
somewhere
else.
Discoverable.
F
G
And
I
would
be
interested
in
potentially
participating
that
discussion
if
we
are
talking
a
little
bit
about
the
installing
extensions
from
Bauer
story
and
how
we're
going
to
how
we're
going
to
handle
marshalling
those
those
assets,
because
I
think
that's
that's
going
to
be
really
important
long-term
story,
whether
we
build
something
that
works
with
Bauer
today,
because
that's
what
polymer
needs
over.
That's
something
that
we
want
to
look
at.
Supporting,
NPM
and
other
stuff
too
I.
Don't
know.
H
Sorry
I
was
muted.
You
couldn't
find
the
right
window
to
amuse
myself
and
yes,
so
yeah
we're
having
discussions
with
a
mighty
es
carlos
and
two
months
and
the
way
to
move
forward
with
inline
65
the
communication
without
breaking
stuff
in
Nitin,
and
so
another
question
is
on
the
front
and
side
what
is
the
best
mechanism
to
render
mathjax,
but
maybe
you're
so
in
languages,
in
the
documentation.
H
A
A
H
It's
the
documentation
window
to
have
live
widgets
in
that
they
are
job
and
rendered
by
the
JavaScript
widgets
engine.
So
currently
we
have
a
mechanism
to
have
a
default
fallback
image
and
when
I
tie
widgets
javascript
is
on
the
page
to
dynamically,
replace
that
image
with
a
live
version
of
the
widget.
H
H
H
Isn't
it
great
so
yeah
and
then
there
was
also
the
longer-term
discussion
about
read
and
be
in
that
book
and
the
execution
model
where
you
can
a
dress
code
by
ID,
rather
than
sending
exhibition
request
with
the
actual
code,
content
and
I
haven't
received
much
feedback
and
fit
on
this
meaningless
past.
So
if
anyone
has
an
opinion.
H
H
F
A
I
think
somebody
said
oh
I'll
continue
talking
on
the
issue,
but
there
was
no
link
to
the
issue,
but
it's
144,
okay,
that's
it
yeah
and
the
reason
you're
not
getting
feedback.
Yet
I
think
is
that
we're
all
everybody
is
digging
themselves
out
from
the
backlog
hole
that
they
carved
last
week
and
so
for
the
for
the
next
couple
days.
It's
going
to
be
a
little
slow.
A
A
A
E
Our
wish
lists
so
we've
sort
of
culled
through
them,
we've
kind
of
figured
it
out,
but
there's
nothing
actionable
in
the
short
term
on
them
other
than
they
might
be
input
for
future
release.
Planning
so
I'm
wondering
if
we
want
to
close
them
with
sort
of
a
nice
message
or
you
know
what
we
wanted
to
do
as
a
team.
So
I
just
thought.
I'd
raise
the
issue.
B
Generally,
I'm
for
decreasing
the
number
of
issues
and
open
PR
by
experience
when
I'm
going
to
another
repository
that
I,
don't
know
about,
and
I
want
to
dig
into
what's
happening,
I
prefer
to
see
almost
like
a
really
slow
number
of
issues
and
open
PR.
Otherwise,
it
feel
like
the
project
is
like
not
moving
forward
slow
down
to
a
stop,
so
I
would
be
in
favor
of
closing
most
of
these
issues
with
a
nice
message,
message
and
Evan
stole
yours,
close
them,
possibly
with
a
specific
tags
that
we
can
find
them
again.
B
A
This
this
sounds
like
a
good.
We've
talked
about
this
in
the
past,
about
being
more
aggressive
about
just
closing.
If
it's
not
actually
going
to
be
implemented,
closing
it
might
be.
So
this
is
a
good
opportunity
for
a
canned
message
so
that
you
write
the
nice
message
once
and
then
you
can
just
use
it
pretty
much
automatically
and
second,
it
might
be.
A
We
might
want
to
come
up
with
a
very
specific
tag
for
this
action
that
is
applied
to
anything
that
is
closed
in
this
way,
as
in
its
being
closed,
not
because
we
said
we
didn't
want
it,
not
because
we
said
we're
not
going
to
do
it
simply
because
it
hasn't
been
acted
on
basically,
so
that
it's
easy.
If
we
want
to
tell
someone,
oh
you
want
to
look
for
wishlist
items
that
are
kind
of
have
been
proposed.
Better
off.
The
radar
simply
add,
add
label
Colin.
A
This
word
to
your
filter
and
then
those
will
surface
quickly,
so
they're
all
easy
to
find
together
whether
it's
issues
or
PR
or
PRS,
but
they
get
out
of
the
main
view
and
we
could
set.
We
could
set
a
clock
limit
on
things.
It
could
be
I,
don't
know
if
anything
goes
stale
for
what
do
I
know
a
month,
two
months,
three
month,
three
months,
whatever
whatever
we
decide,
just
get
it
out
of
the
way,
and
that
way
at
least
the
window
of
things
in
our
frontline
radar
is
is
more
actionable
because
I
agree.
A
A
On
your
plate,
then
you
don't
do
anything
right.
There
is
getting
stuck
in
trees,
people
exactly
exactly
where,
as
a
limited
at
least
like
oh
I
can
tackle
that.
So
does
that
sound
I
mean
that
this
is
getting
in
that
into
your
turf.
Does
that
sound
like
her,
so
John
proposed
and
addressed
which
pieces
unaddressed
sure
I
would
I
wouldn't
include
the
word
wish
list
in
it
because
it
could
be
also
for
PRS
or
something
but
yeah
kind
of
a
one-word
type
on
a
dress
could
be
finer,
I,
don't
care
who.
A
C
A
Say
we
let
them
linger
and
I
mean
typically,
you
encourage
searching
for
things
so
the
the
message,
the
nice
closing
message,
should
also
communicate.
We're
going
to
work
on
this,
reopen
it
right
or
pink
or
pink,
pink
someone
to
reopen
it.
If
you
don't
have
reopening
privileges,
because
if
somebody
finds
one
of
these
things
and
said
I
actually
care
about
this
wishlist
item,
I'm
gonna,
do
it
fine,
we
reopen
it,
but
that's
where
that
way,
a
few
pop
back
up
to
life
every
now
and
then
and
they
only
pop
up
to
life.
A
If
someone
is
actually
going
to
do
something
about
them.
Otherwise,
they're
just
left
on
the
on
the
shelves
and
they
will
they'll
gross
Taylor
and
staler
over
time.
So
I'm
totally
I'm
totally
happy
you
with
that
plan.
I
think
the
only
two
decisions
that
need
to
be
made
are
the
one
that
just
a
label
itself,
but
let's
not
get
into
that
right
now.
Our
time
the
people
think
I
is
22
months
of
staleness,
too
aggressive
three
months.
I.
Think
six
months
is
too
long.
I
think
six
months
is
way
too
deep.
A
B
A
B
A
Just
how
which
is
now
we
could
start
with
wish
list
and
I
mean
we
could
say
that
for
major
for
other
for
actual
bugs,
we
could
say
a
little
bit
of
a
longer
timeline,
but
but
do
the
same
thing
I
mean
even
for
even
for
actual
bugs.
The
same
problem
occurs.
I
think
the
point
is
calling
these
lists
down
to
actionable
work.
A
E
I'm
kind
of
thinking
putting
a
time-bound
on
it,
like
maybe
Jamie
and
I,
can
work
on
it
over
the
next
week
or
so
and
then
come
back
at
a
dev,
meeting
and
sort
of
say,
okay.
This
is
what
we
think
we'd
like
to
do,
and
just
you
know,
because
this
way
we'll
have
some
more
data
on.
You
know
how
sort
of
the
time
frame
of
how
long
these
wish
lists
have
been
sitting
out
there
or
the
no
actions
or
whatever,
but
a
closer
look
at
actually
the
data
itself.
A
Okay,
okay
and,
and
so
it
seems
like
the
the
remaining
questions
are
labeled
to
use
timeline
timeline
for
wishlist
items,
which
could
be
a
little
bit
more
aggressive
a
month
or
two
and
a
timeline
for
other
things,
bugs
and
regular
bugs
in
PRS
that
maybe
maybe
it's
a
month
or
two
for
wish
list
items
and
three
or
four
or
whatever
for
other
bugs.
But
applying
this
systematic
record.
The
project
right,
yeah
well,.
A
And
one
one
question
is:
how
much
of
this
could
be
done
by
a
bot
where,
literally,
if
it's,
if
we
set
a
hard
limit
of
anything
older
I,
mean
honestly
anything
older
than
six
months
is
probably
not
going
to
get
work
done
so
having
a
bot
go
through
and
just
wipe
them
kind
of
sweep
a
Roomba
a
room,
but
for
all
for
all
the
for
all
bugs.
We.
A
Okay,
any
anything
else
that
people
would
like,
discussed
and
so
from
next
week
on,
will
try
to
go
back
to
this
mode,
where
people
do
type
their
little
bullets,
but
but
we
assume
that
the
bullets
are
kind
of
at
the
bottom
and
that
they
can
be
left
there
for
a
quick
scan
and
we
can
all
check
out
what
what
we
did
and
we
can
ask
questions:
hey
Carol.
What
is
this
thing
that
you
put
in
your
list?
Can
you
tell
us
about
it,
but
other
than
that?
We'll
just
put
at
the
top?
A
If
I
have
something
that
I'd
like
to
discuss
or
ask
questions
or
I,
you
need
help
with
or
I
want
to
flag
to
the
team.
Hey.
This
is
happening
or
this.
This
is
important.
We
put
that
at
the
top
and
the
rest,
the
the
reporting
is
is
just
on
in
writing.
Okay
and
that'll
trickle
meetings,
even
more
compact,
I'm,
sorry,
Jason,
I
cook,
you
off
I.
I
A
No
one
should
dump
a
problem
where
they
need
an
hour's
worth
of
in-depth
technical
discussion,
because
that's
exactly
what
wasn't
working
in
the
past,
though
it's
more
if
in
two
or
three
minutes
we
can
make
a
quick
decision
or
it's
a
good
way
of
rounding
up
the
right
people
to
say,
and
now
we'll
continue
this
on
a
thread.
This
is
the
issue
where
we'll
continue
the
discussion
on
the
repo,
etc.
I
think
that's
the
only
criteria,
a
broad
interest,
be
it
should
be
confined
in
your
head.
A
You
should
estimate
that
that
should
take
no
longer
than
five
minutes
right,
because
that's
the
whole
point
is
to
have
a
few
of
these
discussions
on
the
key
topics
and
keep
the
meeting
short
and
not
waste
anyone's
time,
at
least
that's
how
I'm
thinking
of
it.
If
anyone
disagrees
with
me
by
all
means,
taisa.