►
From YouTube: Create:Editor - July 2021 Monthly Meeting
Description
In this video, we'll talk about the longer vision for the Editor teams work and what we'll tackle in the next few milestones.
A
All
right
welcome
everyone
to
the
editor
group
monthly
meeting,
it's
july
8th
and
let's
jump
right
into
the
em
updates
with
our
new
official
em
david.
Take
it
away.
B
Hi
everybody
thanks
eric
super
cool
to
join
it
for
the
first
one,
hopefully
first
of
many,
some
updates
from
my
end.
So
this
is
across
the
last
month,
they're
from
the
first,
the
sixth,
the
first
and
the
seventh
our
say:
do
ratio
was
down
slightly
from
the
last
time,
65
percent,
not
counting
re-prioritized
issues,
but
this
looks
to
be
mostly
around
just
the
open
items
that
are
still
stemming
from
14.1.
So
I
don't
think,
there's
anything
too
too
worrying
or
pressing
there.
B
The
really
exciting
one
is
our
narrow,
mr
rate,
and
say
what
you
will
about
it.
We
absolutely
killed
it
in
the
last
milestone
or
the
last
month
there
14.5,
but
it's
actually
coming
in
across
as
15.5
and
the
create
metrics,
which
means
we're
one
of
the
highest
performing
teams.
So
give
yourself
a
round
of
applause.
That's
absolutely
awesome,
some
really
impressive
stuff.
I
think
everybody's
leaning
into
iteration
really
really
well
and
it
kind
of
shows
in
terms
of
the
okr
for
the
q3
and
the
q2.
B
I'm
currently
working
my
way
through
updating
the
metrics
left
over
the
qr
okrs
left
over
from
roman.
So
I
will
backfill
this
document,
probably
in
the
next
day
or
two,
but
so
far
it
looks
like
we're
on
track
for
the
okrs
from
the
engineering
side.
A
Cool
and
we're
we're
drafting
okay,
ours
a
little
bit
differently
this
for
quarter
three
by
the
way
and
I'll
mention
this
in
the
product
update.
But
hopefully
those
will
be
more
consolidated
and
easier
to
track
in
a
new
tool
that
were
that
we've
been
piloting
and
there
will
be
a
little
bit
a
little
bit
less
manual
tracking
over
time
over.
The
next
couple
quarters
we'll
be
able
to
link
to
those
dashboards
instead
of
asking
you
the
day
before
david,
to
go,
pull
these
numbers
and
update
issues.
B
Yep,
that's
absolutely
no
problem
at
all.
One
of
my
issues,
working
with
darva,
is
to
consolidate
a
single
editor
page
on
sense8,
where
we
will
have
all
these
metrics
available
and
it'll
be
probably
accessible
to
the
team,
so
you'll
be
just
able
to
click
in
and
grab
all
these
at
a
snapshot
so
I'll
be
working
on
that
over
the
next
couple
of
weeks
and
I'll
drop
the
link
as
soon
as
we
have
it.
A
Cool,
I
don't
I
I'll
move
into
the
strategic
product.
I
think
I
don't
have
a
ton
of
specifics
to
discuss,
but
hopefully
it
will
spark
some
some
q
a
now
that
we've
shipped
all
the
work
in
14-0
we've
talked
about
it
a
bit
when
we
kicked
off
14
1
but
as
we
were
drafting
the
okrs
for
q3
like
I
was
just
mentioning,
I'm
starting
to.
A
I'm
starting
to
coalesce
my
thoughts
around
helping
the
merge
requests
by
way
of
the
web
id
and
source
editor,
and
so
that
what
I
mean
by
that
is
the
the
merge
request.
A
Experience
is
one
of
our
most
critical
business,
critical
pages
and
experiences
for
for
almost
everybody
that
uses
git
lab,
but
it's
also
the
one
that
we
get
a
lot
of
usability
feedback
where
there's
a
lot
of
people
interacting
with
many
features
from
the
merge
request
page
and
I
think
the
web
ide
can
do
a
better
job
as
we
improve
the
source
editor
in
making
this
easier.
A
And
so
we
talked
a
little
bit
about
componentizing
the
commit
flow,
and
I
think
it's
partly
making
committing
and
other
types
of
changes
like
commenting
on
code
easier
to
do
from
the
web
ide.
But
it's
also
has
me
thinking
again
about
the
in
context,
editing
and
bringing
merge,
request
discussions
into
the
web
ide
and
what
we
can
do
there.
So
I'm
very,
very
interested
in
the
possibilities
in
this
area.
I
think
it'll
be
a
big
focus
for
us
in
q3.
A
I
think
there's
some
low
hanging
fruit
that
we
could
probably
do
and
there's
some
some
more
exciting
and
maybe
innovative
work
that
we
can
do
now
that
we
have
source
editor
powering
all
the
editing
experiences
where,
as
we
discussed,
having
something
where
we
kind
of
progressively
enhance
the
experience
or-
or
you
know
things
in
that
nature,
so
the
the
tactical
plan
here
is.
I
will
be
scheduling
a
sort
of
think
big
brainstorming
session,
where
I
want
to
get
all
these
ideas
out
again.
A
A
lot
of
them
are
in
our
backlog
in
various
forms,
but
I
want
to
just
talk
through
it
we'll
record
that
for
those
that
can't
attend
and
probably
have
a
corresponding
issue
to
gather
output
from
it
and
then
we'll
turn
around
and
start
doing,
some
problem,
validation
and
solution,
validation
with
design
and
start
prioritizing,
some
work
that
we
know
we
can
get
done
so
I'm
very
excited
to
return
our
focus
there.
I
think
that'll
be
a
big
part
of
the
second
half
of
this
year.
C
Do
you
think
we
should
have
a
separate
session
where
we
talk
about
potential
areas
of
of
work
for
web
id
source
editor
to
to
have
everybody
on
the
same
page
and
to
sort
of
to
to
highlight
the
the
areas
we
are
we
think
are
beneficial
for
the
for
the
product
to
work
on,
or
you
already
have
some
some
plans
and
ideas,
because
technically,
if
we're
talking
about
in
context,
editing
it
in
my
understanding,
it's
quite
different
from
putting
more
time
in
web
id,
those
two
things
are
pretty
much
different
so
like
in
context.
C
Editing
is
one
thing,
but
it's
it
has
nothing
to
do
with
webinar.
Webinar
is
completely
different
workflow,
so
I'm
wondering
whether
we
will
incline
more
towards
web
id
or
towards
the
aim
context.
Editing
work
because-
and
the
reason
I'm
asking
this
as
well-
is
that
source
code
is
working
hard
on
bringing
the
in
context
editing
to
the
repost
review
already
now.
C
So
I
assume
in
a
couple
of
milestones,
we
will
have
pro
prime
context
that,
like
not
proper
but
like
seamless,
switch
between
viewing
files
and
repository
and
editing
the
files
in
the
repository.
So
that's
why?
I'm
I'm
trying
to
to
do
this
and.
A
Yeah,
yes,
that's
a
that's
an
important
distinction
and
I'm
glad
you
asked.
I
think
it
would
be
beneficial
to
have
a
separate
discussion
on
all
the
opportunities
available
in
the
editing
realm.
As
far
as
the
difference
between
in
context,
editing
and
opening
the
web.
A
Ide
I'd
really
like
to
focus
this
think
big
session
on
the
mr
workflow
and
and
how
that
how
you
create
an
mr,
how
you
comment
on
an
mr,
how
you
might
suggest
code
changes
or
review
changes
in
the
web
ide
and
how
we
can
improve
that
if
the
conversa,
the
conversation
could
naturally
evolve
into
something
where
we
say
you
know
this
isn't
actually
part
of
the
web
ide.
This
is
more
part
of
in
context,
editing
and
we
should
bring
the
editing
experience
into
the
mr,
rather
than
bringing
the
mr
experience
into
the
web
ide.
A
I'll
start
by
scheduling
this
one
and
I'd
like
to
get,
I
mean
my
original
vision
for
this
before
we
just
got
completely
bogged
down
with
execution.
Work
was
to
have
these
think
big
sessions
at
least
once
a
month
for
those
that
can't
attend.
So
I
I
would
like
to
david
and
I
and
michael,
and
I
will
talk
about
how
feasible
that
is,
and
if
we
have,
if
we
can
support
that,
but
I
I
think
it'd
be
valuable
to
at
least
pull
different
topics
once
a.
A
A
Shifting
gears
to
the
content
editor
we're
seeing
a
lot
of
excitement
and
momentum
behind
the
mvc.
So
I'm
really
excited
that.
It's
used,
you
know
it's
in
production
and
it's
being
used
by
people
and
they're
leaving
great
feedback
in
the
issue.
There's
a
very
clear
path
to
immediate
next
steps.
A
But
I'd
really
like
to
schedule
a
similar
think
big
session
to
talk
again
and
realign
on
the
longer
term
vision
for
it
in
the
wiki,
but
also
as
it
as
we
plan
to
expand
it
to
issue
description,
editing
to
you
know
being
something
that
could
be
loaded
from
any
markdown
file
in
the
repository
view
or
something
like
that.
So
I'll
get
that
on
the
books
as
well.
That
might
be
a
little
longer
because
I
don't
want
to
overwhelm
you
with
think
big
sessions.
But
I
think
the
immediate
plan
is
pretty
clear.
A
We
have
content
support
that
we
need
to
get
full
support
for
gitlab,
flavored
markdown
and
we
have
some
initial
ideas
and
where
we
want
to
improve
the
ui
and
ux
on
the
editing
view
of
the
wiki,
to
give
it
a
little
more
space
and
move
towards
sort
of.
Like
a
block,
editing
experience
and
things
like
that,
so
we'll
be
refining
those
issues
over
the
coming
weeks
and
making
sure
that
plan
is
very
clear,
but
that's
going
to
be
a
big
focus
as
well
for
quarter
three.
A
I
would
like
for
for
transparency
the
draft
of
our
our
product
okr.
One
of
the
key
results
is
getting
100
support
for
gitlab
flavored
markdown,
and
so
I
would
really
like
to
come
together
soon
to
spec
out
what
that
really
means,
and
what
that,
what
effort
that
is
really
going
to
take
how
many
engineers
we
need
to
put
on
that
to
make
it
happen
in
quarter
three.
I
think
that
would
be
an
important
goal.
A
B
Super
excited
to
see
more
on
the
content
editor
by
the
way
so
for
everything,
I've
seen,
looks
really
really
cool,
just
not
really
a
question
just
to
give
everybody
a
sort
of
an
async
update
or
a
sync
update,
because
everybody's
here,
I'm
in
the
process
of
building
out
a
new
issue,
triage
process
for
our
backlog
to
try
and
make
it
so
that
when
an
engineer
or
anybody
arrives
at
one
of
our
backlog,
issues
that
it's
pre-weighted
it's
pre-labeled-
it's
essentially
ready
for
development.
B
It's
a
it's
a
strategy,
I've
done
in
other
teams,
so
once
I
have
it
fleshed
out
an
issue,
I'll
open
it
up
to
the
team
for
feedback,
and
we
can
sort
of
do
like
maybe
a
quarterly
or
a
bi-quarterly
review,
and
the
goal
will
just
be
to
reduce
noise
or
complexity
within
those
issues,
so
that
people
can
just
pick
them
up
and
run
with
them
if
they
need
but
yeah.
Just
to
give
you
a
status
update
on
that.
D
C
C
C
Resourceful
for
somebody
from
the
editor
team
to
to
name
this,
but
we're
here
to
help
so
in
context,
editing
is
mainly
involving
from
what
I
understand
for
now
involving
source
editor.
C
It's
not
for
content,
not
not
the
content
editor,
but
I
assume
it's
not
going
to
be
a
problem
for
content
editor
to
to
follow
the
same
thing
so
technically,
whenever
like,
whenever
you
see
a
content
that
needs
to
be
that
that
is
potentially
editable
on
gitlab,
like
blob
snippet,
whatever,
whatever
thing
that
you
can
click
button
called
edit
and
go
edit.
This
piece
of
content,
the
in-context
editing
effort,
is
about
making
this
as
seamless
as
possible
so
that
you
do
not
need
to
reload
the
page.
C
C
I've
had
the
and
I
I
yeah
I
I've
had
it
for
snippets.
There
is
the
proof
of
concept
somewhere
somewhere
around
and
abandoned
one
that,
because
we
didn't,
we
never
had
time
for
that
and
using
that
approach.
Team
has
created
the
prototype
for
in-context
editing
of
the
blobs
in
the
repository
view
that
the.
C
Source
code
group
is
working
on
at
the
moment
implementing
this
behind
the
feature
flag
for
now,
but
they
put
a
lot
of
effort
there
and
the
result
is
really
nice,
and
this
is
like
for
the
repository
of
for
for
in-context
editing
of
the
repository
files.
This
is
not
really
like.
This
is
the
the
work
that
source
editor
source
code
group
does
for
does
at
the
moment.
It
might
be
not
real
in
context
editing.
C
It
will
just
make
switching
between
editing
viewing
and
editing
faster,
and
the
reason
for
that
is
that
in
that
prototype,
in
that
effort,
we
are
switching
from
generating
the
view
of
the
file
on
the
on
the
back
end.
We
switch
to
generating
the
view
of
the
file
using
the
same
source
editor,
so
it's
gonna
be
source
editor
both
for
viewing
and
for
editing
the
files.
That's
what
makes
it
really
trivial
to
implement
the
in
context
editing,
so
we
just
toggle
the
flag
on
the
editor.
A
Yeah
there
was
maybe
it
was
an
mr.
I
thought
it
was
an
issue
but
the
one
for
editing
snippets
and
that
proof
of
concept
that
you
had
dennis,
and
that
was
where
much
of
the
collaboration
on
on
the
concept
was,
and
I'm
not
sure
if
that
term
was
ever
used
in
a
title
of
an
issue
or
or
in
it's,
certainly
not
on
our
direction
page
but
effectively.
A
It's
what
dennis
said,
which
is
just
making
it.
So
you
don't
have
to
transition
to
a
specific
edit
page
and
you
can
open
it
up.
So.
A
C
The
problem,
why
we
don't
we
don't
have
any
centralized
sort
of
information
on
the
on
the
team
page
and
most
probably,
we
won't
ever
have
this
information
on
the
editor
page,
because
there
are
so
many
places
where,
where
this
might
be
used
and
those
all
of
those
places
are
like
under
responsibility
of
different
groups
like
repose
review
technically,
is
under
the
source
code
groups,
responsibility
right,
so
we
cannot
really
say
like
okay,
we
are
implementing
the
in
context,
editing
as
part
of
our
group's
effort.
C
We
will
just
go
and
implement,
probably
if
they
will
need
this
in
terms
of,
as
I
said,
they
are
in
the
process
of
doing
of
putting
this
as
close
to
in
context
editing
as
possible
already
now.
So
if
there
will
be
needed
some
some
more
effort,
maybe
we
we
might
just
chime
in
and
and
do
do,
help
with
that.
But
the
problem
is
that
we
still
don't
have
any
sort
of
consolidated
idea
and
view
of
how
this
is
gonna,
be,
as
eric
mentioned.
C
It
all
evolves
around
the
the
proof
of
concept
that
I
had
for
snippets
long
long
time
ago.
Last,
like
I
think
it
was
last
year
end
of
summer,
when
I
came
up
with
that,
and
that's
that's
pretty
much
where
it
comes
from,
so
we
have
to
in
order
to
put
at
least
anything
on
our
group's
page
we
have
to.
C
We
have
to
have
some
consolidated
and
grounded
explanation
of
what
is
going,
what
how
it's
gonna
work,
how
it's
gonna
be
and
put
some
some
effort
into
into
providing,
maybe
maybe
providing
more
proof
of
concepts.
I
don't
know.
D
So
I
think
maybe
the
takeaway
from
this
is
because
I
don't
know
I
feel
like
I
should
have
known
this,
but
I
don't
really
feel
that
bad
about
not
knowing
it.
Given
this
discussion,
perhaps
we
should,
and
especially
with
the
the
read-only
thing
said
there
may
be
new
people
in
this
team.
Eventually,
people
change
I've
changed
teams
a
lot.
A
If
we're
going
to
shorthand
something
like
that,
we
should
we
should
have
it
defined,
and
I
think
we
were
taking
a
shortcut
here
by
saying
this.
General
concept
we've
been
talking
about,
which
is
not
defined.
D
A
Yeah
and
and
it
I
think
it
also
touches
on
what
we've,
what
we've
discussed
in
previous
meetings
recently
about
how
we're
in
an
interesting
place
where
we
could
be
asked
to
implement
this
entirely
like
we
could
take
this
further
and
we
could
just
say
say
we
didn't
own
snippets
so
that
we're
not
picking
on
any
particular
group
say
there
was
a
separate
snippets
group
and
but
we
maintained
the
source
editor
if
we
said
we're
interested
in
making
this
feature,
we
could
go
and
build
this
on
top
of
snippets,
but
that's
actually
somebody
else's
implementation
of
source
editor.
A
So
I
think
what
would
be
really
interesting
and
what
would
be
would
be
probably
the
next
best
step
is
to
sit
down
and
define
what
actually
needs
to
change
in
the
source
editor
to
enable
groups
to
implement
it
in
a
way
that
allows
them
to
toggle
quickly
between
read-only
mode
and
edit
mode,
without
opening
up
the
source
editor
in
a
separate
view,
and
if
there's
anything,
we
need
to
do
to
help
them
there.
That
needs
to
get
documented
and
epic
an
issue.
If
there's
anything,
we
want
to
do
for
snippets.
A
C
Trying
to
I'm
trying
to
find
I'm
trying
to
find
the
that
proof
of
concept,
yeah.
C
Now
and
maybe
maybe
it
will
give
some
it's.
A
C
Keep
digging
could
be
I'm
just
trying
to
find
the
merch
requests
created
by
me
and
I'm.
I
just
cannot
find
that.
Well,.
A
There's
seven
thousand
of
them
yeah,
but
that's
a
good
point
thanks
chad
for
for
pointing
out.
We
should
be
more
intentional
about
the
terms
we
use
and
make
it
clear
when
we're
discussing
things
like
that,
but
this
is
all
hopefully
outcomes
from
some
larger
discussions
on
on
opportunities
that
we
can
that
we
have
over
the
next
year
so
that
we
can
then
document
in
that
way.
Yeah,
but
I'll.
Take
that
as
a
as
an
action
david
and
I
can
work
on
it
too.
Yeah.
B
That's
super.
I
I
part
of
my
onboarding
is
to
look
at
updating
the
editor
team
hand
page,
and
so
this
is
a
good
opportunity
for
me
to
learn
some
of
the
more
ubiquitous
language
within
the
team.
Considering
I
am
new
to
the
team
so
I'll
do
that
as
part
of
a
table
on
the
page,
and
then
we
can
open
up
to
the
team
for
feedback
and
extension
thanks
chad.
For
that,
that's
a
great.
A
One
anything
else
on
the
record
before
we
stop
recording.