►
From YouTube: Create:Editor - Milestone Kickoff for 14.2
Description
In this meeting we discuss the plans and issues scheduled for the upcoming milestone.
A
All
right,
hello,
everyone!
This
is
the
editor
group
kickoff
meeting
for
14
2
milestone
and
it
is
july
15th
yeah,
let's
jump
right
into
it.
I
linked
to
the
planning
issue.
We've
all
been
asynchronously
working
on
that,
and
this
is
been
the
first
planning
milestone,
planning
effort
that
I've
done
with
david
and
I've
really
appreciated
all
your
feedback
and
david's
help
on
it.
So
I
think
it
went
really
well.
A
A
We
can
leave
that
read
only
so.
I
do
want
to
highlight
some
stuff
that
we
did
on
the
last
milestone.
14
1
was
a
great
milestone
because
we
could
return
from
focusing
for
the
past
quarter
on
settings
and
navigation
work
and
we
delivered
some
really
impactful
and
meaningful
changes
there,
and
we
could
shift
our
focus
back
to
our
other
categories
in
14
1..
We
shipped
a
lot
of
great
work
and
there's
some
more
that
may
or
may
not
ship.
A
So
if
there's
anything,
I
missed
feel
free
to
add
it
to
the
highlights
or,
if
there's
anything,
that
wasn't
necessarily
a
feature
that
we
shipped
that
you
want
to
highlight
as
a
success
from
the
last
milestone
feel
free
to
do
so
in
the
agenda
or
call
it
out
here.
We
also
have
a
retro
where
we
can
talk
about
this
more,
but
the
milestone.
Fourteen
one
had
a
lot
of
great
improvements
and
iterations
to
the
content,
editor
jumanchu
and
enrique
paired
up
on
adding
strikethrough
formatting
horizontal
rules.
A
B
Thank
you.
It
was
60
60
when
I
tested
it
locally,
but
I
had
I've
tested
on
the
double
like
on
the
twice
as
a
small
blob
as
it
is
in
production
and
in
the
production
it's
70
plus
yeah.
It
was
absolutely
amazing.
Amazing
result
in
terms
of
numbers,
not
so
not
so
exciting
for
in
the
in
terms
of
technical
implementation,
because
it
it
actually,
it
has
been
achieved
with
a
very,
very
simple
fix.
B
B
A
That's
awesome
and
I
mean
I
think
as
it
as
it
relates
to
shifting
the
focus
to
something
like
the
single
file,
editor
and
and
web
ide.
Obviously,
performance
and
speed
and
getting
access
to
your
source
files
is
super
important,
so
anything
we
can
do
to
to
render
and
display
the
code
as
fast
as
possible
is
a
win
for
everybody.
B
There's
just
one
thing:
just
just
one
simple
remark:
this
fix
won't
be
needed
for
the
source
editor
once
things
once
the
blob
viewer
content
in
source
with
using
source
code
source
editor,
the
fix
won't
be
needed
because
performance
is
in
the
core
of
source
editor
and
it
technically.
Even
if
you
feed
it
a
file
with
32
000
lines
of
code,
it
won't
won't
be
processing
more
than
the
lines
you
actually
show
in
the
editor.
B
A
Well,
that's
yeah,
that's
great
context
and
and
still
amazing
work
so
and
speaking
of
updates,
we
have
updated
the
monaco
version,
which
came
with
some
fixes,
specifically
around
mobile
support,
which
has
upgraded
our
usability
from
completely
broken
to
slightly
less
awful.
So
we
can
all
celebrate
that
our
mobile
support
in
our
editors.
B
B
A
A
So,
let's,
let's
talk
a
little
bit
about
14
2
we've
been
chatting
about
this
in
the
planning
issue,
but
to
elaborate
a
little
bit
on
the
strategy
and
how
it
relates
to
the
next
few
milestones
as
well.
This
milestone,
we
will
be
focusing
a
little
bit
on
the
settings
and
navigation
work
friends
going
to
be
working
on
the
back
end
to
round
out
the
sidebar
refactor
in,
in
particular
the
group
sidebar,
which
didn't
get
completed
as
part
of
140,
but
that's
completely
transparent
to
the
end
user.
A
It
looks
the
same
because
dennis
you
applied
the
style
to
both
the
old
code
base
and
the
new
code
base,
so
in
the
back
end,
fran
will
be
updating
the
group
sidebar
to
keep
consistent
and
just
clean
up
that
part
of
the
code
base.
I
think
that's
going
to
be
super
valuable
for
long
term
maintenance
and
for
consistency.
A
So
I'm
excited
that
we
can
prioritize
that
work
as
far
as
features
that
we
are
going
to
like
be
able
to
see
or
end
users
will
be
able
to
see
content.
Editors
got
a
quite
a
bit
of
work,
planned,
there's
some
documentation
and
sort
of.
Maybe
housekeeping
work
you
could
say
like,
but
there
are
a
few
features
that
we
have
planned
for
14
2,
including
the
ability
to
upload
attachments,
which
will
take
a
very
similar
user
flow
to
uploading
images.
But
it
is
something
obviously
you
can
do
in
issues
and
wikis.
A
A
Himanshu
has
a
proof
of
concept
that
wasn't
actually
requested
to
be
prioritized,
but
it
seemed
like
it
was
just
too
anxious
to
get
the
ability
to
upload
and
insert
block
elements
inside
a
table
cell,
so
this
could
include
like
unordered
lists
or
more
nested
tables,
a
great
slack
thread
where
he
showed
table
within
a
table
within
a
table
within
a
within
a
table.
It's
great
to
see
that
support.
We
might
be
able
to
pull
that
poc
across
the
line,
if
not
we'll
get
that
in
soon.
A
But
that
is
that's
like
the
next
evolution
of
our
our
editing,
support
for
tables
and
I
think,
would
be
really
valuable.
I'm
not
going
to
stop
you
all
from
working
on
that,
but
just
know
it's
a
maybe
a
stretch
goal
one
of
the
things
two
other
things
we
do
want
to
do
in
14
2.
If,
on
the
content,
editor
would
be
introducing
an
mvc
for
a
formatting
menu
and
enrique,
I
don't.
A
In
this
case,
the
mvc
is
really
bringing
like
bold
italic
strikethrough
code
formatting,
the
the
text,
type
formatting
tools
closer
to
your
cursor
and
when
you
highlight
text,
show
those
above
in
a
floating
bubble
and
then
from
there
we'll
expand
into
other
contextual
ui
for
things
like
editing,
table
rows
or
changing
the
properties
of
an
image
or
replacing
an
image.
But
enrique
you
had
a
really
well
researched
comment.
I
don't
know
if
you
want
to
maybe
share
with
the
team
your
findings
there.
A
C
C
For
example,
in
the
case
of
images
and
tables
like
how
we
want
to
provide
an
experience
for
adding,
in
the
case
of
tables,
new
columns
or
removing
rows
in
the
case
of
images,
how
we
want
to
provide
18
tools
to
change
the
the
url
or
the
alternative
text.
So
at
this
stage
we
are
just
providing
like
this
basic
menu.
C
A
It's
just
going
to
get
more
and
more
real
estate
on
your
screen
for
you
to
be
going
back
up
and
up
and
down
between
the
toolbar.
Until
we
get
to
the
point
where
we're
confident
we're
shipping,
a
a
block,
style,
editor
or
or
you
know,
being
able
to
affect
areas
of
the
content
in
in
line
with
the
content
itself,
the
toolbar
is
here
to
stay.
We
should
we
should
make
it
easier
to
get
to
some
of
the
more
common
formatting
things,
so
I
think
it's
a
great
valuable
nvc
to
get
into
14.2.
A
A
and
so
there.
The
focus
is
really
just
on
finding
a
way
to
bridge
the
gap
between
our
two
categories
and
and
take
a
a
reusable
code.
Snippet
embed
it
in
a
wiki
page
through
the
content
editor
so
that
it
can
stay
up
to
date
and
you
don't
have
to
write
a
code
block
and
and
then
maintain
that
in
multiple
places.
A
So
it's
really
replacing
that
specific
use
case
of
like
in
code,
documentation
or
something
you
could
have
a
code
block,
that's
reused
and
that
takes
the
shape
of
a
snippet
there's
a
I
can.
I
should
have
added
links
to
all
of
these,
but
I'll
go
back
and
do
that.
There's
an
epic
that
he's
that
I'm
working
on
with
him
and
and
the
mvc
issue
is
something
that
we
will.
I
actually
have
it
up
here.
So
let
me
add
it
to
the
agenda.
A
Links
the
other
big
piece
of
work
in
fourteen
two
dennis
is
gonna,
be
working
on
the
source,
editor
toolbar
mvc,
and
we
were
refining
this
a
little
bit
in
our
backlog,
refinement
session
yesterday,
yeah
and
we've
kind
of
scoped
it
down
nicely
to
encompass
specifically
markdown
live
preview
is
the
first
button
that
will
be
displayed
in
the
toolbar.
This
was
already
loosely
defined
in
the
issues,
but
we
we've
defined.
This
is
exactly
what
we
want
to
ship
for
14
to.
A
Basically,
when
the
source
editor
opens
up
a
markdown
file,
the
toolbar
will
become
visible
and
in
that
toolbar
will
have
a
button
for
your
markdown
live
preview
panel.
So
these
two,
these
two
extensions
work
well
together.
It
is
a
way
to
to
begin
to
introduce
the
concept
of
a
toolbar
and
extensions
being
able
to
add
items
into
the
toolbar
of
the
source
editor
and
from
there
we
can
work
on
additional
toolbar
actions
that
need
to
be
added
to
the
source
editor.
A
But
the
markdown
live
preview
is
something
we're
very
excited
about,
and
we've
actually
seen
feedback
in
the
source
and
the
content,
editor
feedback
issue
that
have
reinforced
our
direction.
Here
for
the
source
editor,
which
is
that
some
people
are
more
comfortable
and
we
knew
this
writing
in
raw
markdown,
but
would
appreciate
a
live
preview
on
the
side.
So
I
think
this
is
a
very
worthy
place
to
invest
our
time,
and
it
goes
well
with
with
our
our
overall
strategy
and
chad
is
intimately
familiar
with
the
work
involved
for
the
side
by
side.
A
A
This
was
what
we
carved
out
as
our
initial
minimally
viable
change
for
editing
the
handbook
in
a
more
friendly
way.
We
said
a
side-by-side
live
preview
would
be
a
great
first
step
turns
out
that
was
more
challenging
than
expected
and,
as
we
understood
the
problem
more
and
more,
it
was
also
potentially
not
as
helpful
as
as
it
needed
to
be,
so
it
wasn't
actually
the
kind
making
the
impact
we
hoped
it
would.
So
it
was
eventually
abandoned
it's
nice
to
see
it
come
back,
though,.
A
C
I
I
think
that
I
described
in
an
issue
before
the
basics
for
attachment
for
images
and
file
attachments
or
the
backend
is
the
same
across
all
of
the
attachment
types.
So
what
changes
is
actually
the
what
we
display
in
the
content
editor
like
we
are
uploading
something
and
then
we
have
to
display
like
an
audio
or
a
video
or
another
type
of
file,
while
the
loading
process
is
happening.
So
what
I
mean,
what
I
want
he
mentioned
I
doing
for
this
milestone
is
like
create
a
generalize.
A
Hey,
I'm
not
going
to
hold
you
and
jumanji
back
from
over
delivering.
It's
generally
been
the
theme
over
the
past
couple
milestones.
So
if
you
can
do
that,
that
would
be
amazing.
I
I
think
it's
interesting
to
point
out
the
the
similarities,
and
I
guess
this
all
points
back
to
our
our
back
end:
existing
endpoints
for
frequent
flavor,
markdown
and
there's
commonalities
there
that
I
didn't
realize.
A
So
that's
great
the
the
thing
I
would
say
is
like:
let's
just
keep
it,
let's
keep
it
conservative
and
just
try
and
ship
what
we
want
to
ship.
But
if
that
becomes
possible
like
please
include
it
in
an
mr
and
if
you
need
to
refine
the
issues
as
they
are
to
to
better
reflect
that
I'm
happy
to
help
there
and
and
re
reword
things
or
close
issues
that
aren't
necessary
anymore
if
you're
just
solving
all
in
one.
A
Mr
something
like
that
yeah,
that's
great,
I
mean
video
and
audio
are
important
tools,
especially
as
we
look
towards
the
ability
to
move
this
into
issue,
descriptions
and
epic
descriptions.
I
think
those
those
are
really
effective.
Communication
tools
within
the
wiki
and
in
issue
description,
so
support
for
that
as
early
as
possible
would
be
fantastic.
A
I
guess
this
is
probably
a
good
time.
This
is
not
related
to
the
14.2
kickoff,
but
more
of
our
monthly
quarterly
strategy.
But
I
was
just
talking
with
david
and
michael
about
this
in
a
in
a
call,
and
we
should
we
should
discuss
as
a
team,
a
quarterly
okr
that
I
propose,
which
is
a
hundred
percent
support
for
gitlab
flavored
markdown
by
the
end
of
quarter
three,
and
I
want
to
hear
about
how
ambitious
that
may
be.
What
are
what
are
the
specific
roadblocks
and
how
can
we?
A
C
C
Or
we
can
be
a
little
bit
more
ambitious
and
say
we
want
to
provide
you
know
some
basic
aiding
tools
like
I
there
are
like
well,
there
are
content
types
that
are
very
like
very
complex
to
edit,
let's
say
mermaid
diagrams
plant
uml
diagrams,
like
they
want
to
provide
editing
tools
for
that.
So
I
think
that
it's
just
like
trying
to
like
to
scope
very
well
how
we
want
to
support
each
content
type
as
part
of
the
definition
of
okr.
A
Yeah
that
makes
a
lot
of
sense
and
I
think
definitely
some
more
refinement
of
that
epic
and
the
issues
inside
will
help
in
having
your
input
to
separate
the
scope
and
separate
the
concerns
where
we
can
and
and
ship
mvcs.
I
think
I'm
more
in
line
with
like
100
percent
rendering
so
that
it
can
be
used
and
it
won't
room.
It
won't
get
confused
by
anything.
That's
in
any
page,
and
it
could.
A
You
know,
there's
less
risk
of
data
loss
and
stuff
like
that,
and
then
we
can
create
follow-up
issues
for
custom,
ui
and
custom
editing
controls.
I
do
think
the
exception
there
is
like
where
it's
it's
related
to
the
usability
of
a
feature
like
adding
rows
and
columns
of
tables.
That
probably
I
would
consider
in
scope,
but
potentially
not
like
advanced
tools
for
editing,
mermaid
diagrams
or
something
like
that.
A
The
way
I
kind
of
imagine
and
michael
and
I
need
to
talk
through
this,
and
we
need
to
make
sure
this
is
what
we
actually
want.
But
my
my
vision
is
like
you've
got
a
rendered
mermaid
diagram,
you
click
an
edit
button
and
it
switches
over,
to
instance,
of
of
the
source
editor
embedded
in
the
content,
editor
where
you
can
make
changes
to
the
code,
hit,
save
and
then
it
re-renders
the
diagram
in
the
in
context
there.
That
would
be
the
ideal
state
right,
that's
not
to
say
that's
end
of
q3.
C
C
C
C
I
think
that
even
for
the
for
the
snippets
nbc,
that's
something
that
we
should
explore.
Okay,
I
don't
know
if,
if,
if
using
highlighted
years
like
the
current
solution,
for
anything,
is
a
is
the
right
option?
Probably
it's
like
better
to
start
replacing
that,
with
with
the
source,
either
immediately.
A
Sounds
good,
I
I
like
that
approach
and
definitely
keep
pushing
on
that.
I
don't
know
if
that
needs
to
be
scoped
further
to
enable
any
of
the
other
work
or,
if
that's
something,
that
we
can
refine
in
the
context
of
code
blocks.
I
know
we
we've
created
a
couple
issues
to
follow
up
on
code
blocks,
in
particular
around
highlighting
and
formatting
and.
A
Consistency
and
how
it's
rendered
and
following
the
themes
and
stuff
like
that,
so
you
know
in
in
theory,
I
completely
get
where
you're.
What
you're
saying
is
is
using
source
editor.
We
kind
of
inherit
all
that
work
that
we've
done
in
source
editor
and
improve
the
bundle
size
which,
which
makes
a
ton
of
sense.
A
Similarly,
we
were
just
discussing
yesterday
in
when
we
were
refining
the
backlog
for
the
source,
editor,
the
idea
of
panel
widgets,
and
what
that
means,
and
and
trying
to
plan
for
the
introduction
of
of
a
new
extension
type
for
source
editor
that
would
allow
you
to
have
entire
panels
of
content
for
your
extension
to
live
in,
and
dennis
mentioned
that
there
was
a
proof
of
concept
a
while
back
where
the
content
editor
was
added
as
a
source.
Editor
extension.
A
So
I
feel
like
this
is
the
mirror
image
of
that
conversation
where
we
were
talking
just
then
about
having
the
source
editor,
but
potentially
on
a
markdown
file
like
load
the
content
editor
in
a
panel,
we
could
have
the
same
thing
on
our
side,
which
is
on
the
content
editor
side,
which
is
loading
the
source
editor
instance
inside,
and
then
you
could
have
a
panel
in
that
source
editor
that
loads.
The
content
editor.
B
B
Into
this
inception
mode,
yep
yeah,
but
they're,
just
just
one
thing
like
the
this-
the
panel
widget
is
not
intended
to
be
the
separate
extension
type.
It's
it's
just
the
widget
type
that
any
extension
can
add
any
number
of
pound
widgets.
It's
just
it's
just
some
type
of
information
that
is
controlled
by
other
extensions.
It's
it's
not
this.
This
separate
type
of
extension.
A
B
Yeah
those
it's
like
two
pieces
of
of
information.
There
is
the
source
editor
and
there
is
some
sort
of
representation
of
what
what's
going
on
in
the
in
the
editor.
So
there
is
the
the
whole
point
is
to
build
this
bridge
between
editor
and
its
and
the
representation
of
its
content,
technically
representation
of
the
model
of
what's
going
on
in
the
editor
at
the
moment.
B
So
real
time
changes
and
that's
the
whole
point
is
just
building
this
bridge
and
bake
it
in
to
source
editor,
so
that
the
extensions
authors,
if
they
need
to
create
the
panel
widget,
they
wouldn't
need
to
worry
about
building
this
bridge
manually
every
time.
So
it
will
be
just
baked
into
the
source
editor
and
it
will
be
just
simple
api
to
to
use
to
add
one
two,
three
four
any
number
of
panel
widgets.
In
my
proof
of
concept.
B
There
was
also
like
the
every
panel
widget
accepted
the
parameter
where
to
render
it
like
above
the
source,
editor
on
the
left
on
the
right
at
the
bottom,
any
some
random,
some
random,
dom
element
where
the
the
this
panel
might
live.
If
you
want
to
create
a
separate
panel
outside
completely
outside
of
the
context
of
source
editor,
but
still
keep
this
bridge
between
editor
and
and
the
panel.
A
B
A
A
D
D
C
C
A
All
for
it,
thank
you
for
bringing
that
up.
I
didn't
have
the
right
words
or
approach
for
this,
but
when
we
were
early
on
in
defining
these
epics
for
markdown
support,
I
was
chatting
with
enrique
like
because
there's
something
I
can
do
to
like
pass
a
file
or
paste
a
file
into
the
editor
and
see
things
render
and,
like
you
know
like.
D
B
D
D
A
E
A
A
There
there
are
a
couple
here.
It
looks
like
I
think
that
we're
stretch,
maybe
on
our
on
our
spreadsheet,
that
look
like
they're,
probably
meant
for
paul,
because
they're
related
to
some
css
and
the
top
nav
and
then
there's
a
security
issue.
That's
unassigned,
so
yeah,
I
think
we'll
just
we
need
to
round
those
out
a
little
bit,
but
when
in
doubt
I
just
assigned
frame.
D
A
Oh
well,
probably
one
of
the
ones
that's
not
assigned
to
you
because
we're
still
refining
it
is.
We
would
like
you
to
work
on
the
embedding
snippets
mvc
and
the
content
editor
since
yeah,
since
you
helped
me
so
much
iterating
and
refining
and
breaking
down
mvcs
for
the
early
static
site.
Editor
work.
A
A
Let's
see
yeah,
it
doesn't
have
any
labels
on
it,
so
it's
not
showing
up
on
the
board,
but
it's
linked
in
the
agenda
above
on
when
I
mention
the
mvc
I'll,
I'm
gonna
be
providing
feedback
on
the
issue
today
and
hopefully
refine
it
a
little
further
but
I'll
ping
you
on
the
issue.
We
can
start
immediately
or
whenever
you're
ready,
diving
into
it.
So
I
think
that
would
be
the
other.
That
would
be
why
it
looks
a
little
light
on
your
side.
A
When
you,
when
you,
when
you
phrase
I'm
gonna,
take
two
weeks,
you
gotta
be
real
real,
careful
that
you
don't
say
the
wrong
verb
there
and
give
two
weeks
instead,
because
it
really
sounds
like
you're,
giving
your
notice
for
quitting
yes
you're,
taking
two
weeks
of
paid
time
off,
which
is
very
well
deserved,
and
you
should.
But
please
return
after
that
two
weeks
to
come
back
and
continue
working
for
us.
B
B
A
Well,
that
that
wraps
it
up
thanks
everyone
for
your
feedback
and
input
on
our
milestone,
and
we
will
see
you
next
week,
for
I
think
next
week
is
a
retro
call
and
yeah
otherwise
I'll
see
you
around
in
other
various
meetings
and
async
issues
throughout
the
week
keep
an
eye
out
for
the
kickoff
video.
This
is
actually
the
first
time
we've
had
one
of
these
team
kickoff
videos
before
I
record
my
my
product,
kickoff
video,
so
it's
kind
of
nice
to
be
able
to
practice,
kicking
it
off
with
you
before.