►
From YouTube: Create:Editor - October 2021 Monthly Meeting
Description
In this video, we'll talk about the longer vision for the Editor team's work and what we'll tackle in the next few milestones.
A
C
Yeah-
let's
let's
get
through
it
and
then
we
can
stop,
recording
and
and
continue
the
social
call.
So
yes,
this
is
the
monthly
call
for
the
editor
group
we're
doing
it
a
week
early
and
off
schedule,
which
is
confusing
everybody
but
yeah.
This
is
october
7th,
2021
and
I'll
hand
it
over
to
you,
david
for
the
okr
stuff
and
em
updates.
D
A
A
The
em
updates
for
the
last
little
while
so
our
save
do
ratio
is
in
around
36
percent
67,
not
counting
right
prioritize.
This
is
just
lower
than
usual.
Due
to
the
allocations.
We
just
have
a
lower
amount
of
issues
being
closed
than
we
normally
would
so
it
kind
of
sits
within
the
average
of
the
other
stages
that
are
going
through
an
allocation.
A
The
narrow
mr
rate,
even
though
this
has
been
deallocated
as
a
key
kpi,
we're
still
being
asked
to
track
it
somewhat.
So
we've
I've
put
together
a
throughput
dashboard
where
we
can
track
these
metrics.
If
we
need
them
and
at
the
moment
we're
7.64,
which
is
fine
in
terms
of
our
okr
progress,
we
slammed
the
error
budget.
We
managed
to
get
into
the
range
of
99.98
availability
which
for
the
moment,
puts
us
in
the
green,
so
everybody's
happy
in
terms
of
50
of
the
team.
A
I
would
still,
though,
highly
recommend
it,
as
it
does
really
help
reduce
cycle
times
and
mrs
for
people
who
are
involved
with
our
technical
writing
team,
but
there
is
I
just
want
to
highlight.
There
is
a
chance.
This
might
become
a
requirement
in
the
coming
quarters,
but
I'm
unsure
as
to
whether
or
not
that's
going
to
be
the
case.
A
We've
done
that
that
I'm
just
left
with
the
my
end
of
things,
which
is
to
compile
the
list,
which
is
no
big
deal.
That's
what
that
just
falls
to
me
and
then,
in
terms
of
the
staff
I
st
establishing
mentoring,
relationships
between
staff
engineers
and
team
members
we're
somewhere
between
0
and
50,
due
to
fran
being
on
an
allocation.
He
can't
really
participate
in
that
and
dennis
his
work
with
the
source.
A
C
Awesome,
I
I
think
also
in
particular,
the
the
error
budget
is
a
huge
step
for
us.
That's
a
new
metric.
We
are
on
the
right
side
of
things.
As
with
the
majority
of
groups.
Now
in
the
green,
I
know
there
was
a
discussion,
or
there
was
an
update
on
this,
in
particular
that
that
might
carry
into
next
quarter
and
involve
some
collaboration
among
the
team
and
defining
appropriate
error
budgets
per
endpoint.
C
Second,
I'm
sure
there'll
be
more
discussion
about
this
in
various
issues
and
mrs
and
and
we
can
go
through
our
endpoints
and
determine
what
the
appropriate
threshold
should
be,
which
is
good
because
if,
if
we
just
blanket
set
everything
to
one,
it's
not
actually
reflective
of
both
the
end
user
experience
and
attainability
of
one
second
for
any.
Given
endpoint.
C
C
C
I
don't
know
if
it's
technically
yeah,
I
think
design
manager,
so
they're
staffing
up
they're,
going
to
be
ramping
up,
we'll
do
some
knowledge
sharing
and
some
I
offered
to
support
the
transition,
but
I
don't
think
there'll
be
anything
to
to
directly
impact
any
of
the
engineering
planning
on
that
on
that
side.
As
far
as
moving
the
group
over
so
again,
thank
you
to
everybody
who
did
great
work
on
the
navigation
settings.
C
One
anecdote
I
will
side
track
and
and
say
that
I
had
a
meeting
yesterday
where
we
discussed
the
ongoing
work
from
the
manage
team
working
on
what
is
now
being
called
workspaces.
It's
the
consolidation
of
groups
and
projects
into
a
new
concept
and
in
the
process
of
discussing
it.
I
was
brought
in
the
conversation
because
I
had
been
involved
in
navigation
and
they
wanted
to
know
what
kind
of
impacts
it
might
have
to
navigation
and
the
good
news
was
hey.
C
You
know
some
of
the
patterns
we
introduced
in
the
new
top
nav
actually
aligned
pretty
well
with
changes,
and
so
it
shouldn't
be
that
dramatic
of
an
impact
which
was
great
it
was.
It
was
a
good
feeling
to
know
that
there
wasn't
going
to
be
this
like
big
dependency
on
a
major
refactor
if
all
of
a
sudden,
instead
of
projects
and
groups
in
the
top,
now
there's
just
one
element
called
workspaces
or
something
like
that.
C
We
kind
of
built
a
very
flexible
pattern
and
ux
around
the
navigation
that
should
help
at
least
get
them
through
the
first
few
mvcs,
while
they
ramp
up
and
look
at
more
holistic
navigation
changes.
So
great
news
there,
thanks
for
your
good
work,
we
shouldn't
have
to
do
much
more
and
on
a
related
note,
not
that
this
has
been
a
huge
amount
of
pressure
on
the
engineering
team
in
general,
but
get
lab
docs,
which
we
were
the
technical
dri
for.
C
E
To
voice
what
I
put
in
the
notes,
axel
just
went
on
pto
I
haven't
heard
if
his
partner's
had
their
baby
yet,
but
otherwise
he's
out
for
two
months,
so
we're
just
hoping
that
nothing
breaks
on
the
dog
site
should
probably
warn
the
foundations,
folks
that
all
the
all
the
technical
writers
are
look.
We've
got
some
serious
shifty
eyes.
Hoping
nothing
happens,
looks.
C
Yeah,
I
know
that
there
a
lot
of
the
the
reason
that
the
editor
group
has
not
had
to
support
the
doc
site
is
because
axel
was
on
there
and
helping
out
a
ton.
So
that's
that's
a
good
it's
a
good
thing
to
call
out,
but
on
the
topic
of
focus,
let
me
shift
to
our
our
core
editor
categories
and
talk
a
little
bit
about
the
strategic
monthly
agenda
items
which
I
only
have
two
so
I'll
get
through
them
kind
of
quick.
First
of
all,
thank
you
to
everybody
that
could
join
the.
C
This
we
got
it
all
out.
I
think
everybody's
fairly
aligned
in
in
our
priorities
for
the
code.
Editing
experience
next
steps
here
are
to
here's
what
I
found.
No
siri
next
steps
here
would
be
to
synthesize
that
into
the
direction
page
and
socialize
it
make
sure
that
product
leadership
is
aligned,
although
I
can't
imagine
it
would
argue
for
simplicity
or
argue
against
speed
and
simplicity,
then
create
some
epics
and
issues
to
to
get
some
of
that
work
defined.
C
C
So,
that's
that's
probably
our
next
quarter's
worth
of
work.
Hopefully
we
can
keep
the
ball
rolling.
I
don't
know
when
we'll
have
sufficient
backhand
support
to
to
make
meaningful
changes
in
this
direction,
but
we'll
do
as
much
as
we
can
on
the
front
end
and
get
some
solution.
Validation
done
make
sure
that
our
vision
is
clear.
C
C
I
think
that
aligns
pretty
well
with
plans,
work,
items,
effort
and
redesigning
the
issue
and
epic
description
process,
but
I'm
curious
what
you
all
think
about
that,
specifically,
I
guess
himachu
and
enrique,
who
are
most
familiar
with
the
roadmap
there.
But
how
ambitious
do
you
think
that
is
and
what
what
else
we
might
need
to
consider
in
the
meantime.
D
D
D
D
E
The
editorial
experience
for
our
users
to
be
called
and
then
then
I'll
start
asking
questions
like
and
what
other
things
are
available,
because
right
now,
we've
got
more
than
one
once
I
know
what
it
is,
then
I've
got
to
figure
out.
How
are
we
going
to
talk
about
this
because,
right
now
our
documentation
talks
about
the
content
editor,
the
web
editor,
that's
how
we
see
it
as
employees.
E
E
C
From
yesterday's,
I
think
big
session,
I
I
can't
put
a
timeline
on
this
about
when
we
would
get
here,
but
our
goal.
I
think
that
we're
all
in
agreement
on
would
be
to
remove
any
concept
of
the
difference
between
editing,
a
single
file
and
the
web
id.
They
should
be
the
same
thing.
You
should
edit
a
file
and
then
the
editor
should
be
able
to
be
flexible
enough
and
and
fast
enough,
so
that
there
is
no
reason
why
you
wouldn't
choose
that.
C
C
We
could
say
that
we're
going
to
just
like
hack
together
some
kind
of
file
tree
and
put
it
in
the
single
file
editor
and
do
away
with
all
the
other
niceties
that
the
web
id
has,
but
that's
not
delivering
on
the
power
that
the
web
id
does
have,
which
is
already
maybe
not
enough
to
fulfill
every
promise
that
the
name
web
ide
delivers
so
I'll
upload
that
think
big
session.
We
talked
about
a
lot
of
things,
but
I
think
the
the
to
distill
it.
C
F
E
Okay,
that
will
require
some
moving
around.
I
would
expect
that
the
pages
that
talk
about
the
ide
or
the
content
editor
that
those
would
mostly
go
away
in
favor
of
we
talk
about
issues
and
merge
requests.
We
on
those
pages,
we
would
talk
about
editing,
a
merge
request
or
editing
an
issue
and
moving
moving
the
discussion
of
edits
and
changes
to
the
item
that
we
are
editing
and
that
is
as
far
as
I
want
to
take
you
all
down.
The
technical
writing
rabbit
hole.
E
D
And
some
other
things
that
were
discussed
in
the
think
big
session
and
not
to
put
plans
in
eric's
plan,
but
was
not
only
you
know,
removing
the
distinction
between
single
file
and
multiple
file,
but
also
possibly
removing
the
distinction
between
a
content,
editor
versus
a
source
editor
versus
whatever
the
static
site.
Editor
is
off
to
the
side,
and
just
saying
you
know
you
can
edit
things.
They
may
be
one
or
multiple
things
and
they
may
be
different
file
types.
C
B
B
I
just
wanted
to
highlight
that
we
need
to
to
focus
on
addressing
the
performance
issues
that
we've
found
over
time,
in
particular
reducing
the
bundle
size
of
later
and
and
18
large
documents.
That
may
be
a
problem
when,
in
the
context
of
issues
on
an
ethics,
besides
that,
I
just
wanted
to
highlight
that
the
work
that
himanshu
is
doing
on
preserving
on
change,
markdown
hospital
put
us
ahead
really
like
months
ahead
on
achieving
this
goal.
So
I
think
that
we
are
in
a
very
good
position
to
to
move
forward.
D
And
from
this
may
be
a
little
bit
relevant
to
ducks
like
I'm
hoping
to
to
free
up
some
time
and
get
the
golden
mr
specs
in
review.
Maybe
this
week,
maybe
next
week
there's
some
time
off,
but
that
also
maybe
provides
an
easier
way
to
focus
on
what
is
gfm
and
what
does
it
offer,
because
it's
now
all
in
one
place
and
it's
exactly
what
it
does
and
there's
examples
for
everything.
So
that
might
also
help
you
from
a
doc
perspective
amy
and
we
can
even
do
cool
things
like.
B
D
We
did
that
on
pivotal
tracker,
it's
complex
to
set
up
and
maintain,
but
our
api
ducts
were
driven
by
the
tests
when
you
ran
an
integration
test,
it
captured
the
request
and
the
response,
and
all
of
the
the
dots
for
the
endpoints
were
automatically
generated
off
of
that
with
the
exact
request
and
response.
So
there
was
no
manual
maintenance
of
that
part
of
the
docs.
Only
the
pro
is
part
of
it,
not
the
actual
curl
examples,
which
is
pretty
amazing.
A
Fully
agree
with
you
yeah,
that's
fantastic!
Thank
you
for
highlighting
that
with
the
great
work
manchew
has
done,
enrique,
I'm
very
happy
to
give
that
technical
work
priority
over
the
next
little
while
so
we
can
burn
that
down,
because
I
think
that's
going
to
put
us
in
a
really
advantageous
position
later.
If
we,
if
we
look
at
that
first
before
we
do
any
more
of
the
complex
feature
work,
so
thank
you
very
much
for
spotting
it
and
highlighting
it
whatever
you
need
in
terms
of
support.
Let
us
know.
C
Yeah
you've
got
my
support
too.
On
that
I
I
think
this
milestone,
for
I
guess
it's
we're
playing
fourteen
five,
so
we're
in
fortune
for
now
we're
getting
really
close
to
reaching
that
goal
of
the
rendering
of
all
gfm
content
types.
So
with
that
baseline
in
my
head
has
always
been.
You
know
we're
we're
much
less
likely
to
negatively
impact
the
format
of
a
page,
that's
loaded
into
the
content,
editor
and
kind
of
misinterpret
or
or
reformat
anything.
That's
that
exists.
C
There's
a
there's,
a
bit
of
work
left
to
add
ui
to,
like
you
know,
write,
superscript
or
up.
You
know
manage
mermaid
diagrams,
there's
a
lot
of
work
still
to
do,
but
I
would
be
very
supportive
of
knocking
out
this
technical
debt
before
we
move
too
fast
in
that
direction,
so
that
we
can
have
a
stable
and
performant
architecture
before
adding
all
that
extra
ui.
C
E
E
I
have
wondered
for
a
couple
of
months
now
should,
from
an
engineer's
perspective,
should
all
of
those
files
be
lumped
into
a
single
directory?
No
chad!
You
cannot
have
everything
on
one
page,
no
bad
engineer.
No
cookie
should
all
be
just
piled
under
api,
or
should
we
have
subfolders
in
there
to
help
make
it
a
little
more
navigable
and
if
we
should
have
subfolders?
E
D
No,
I
I
misunderstood
the
the
question
like
it's
not
going
to
be
on
a
single
page,
but
honestly,
I
think
it
doesn't
matter
that
much
going
to
my
previous
point,
I
think
the
ideal
approach,
although
it's
a
lot
of
work,
to
maintain
or
set
up
up
front,
it's
easier
to
maintain,
is
to
have
have
them
data
driven
and
like
we.
We
have
a
pretty
we
use
grape
and
like
it
would
be
possible
to
do
these
things
and
we
have
tests
for
all
of
these
endpoints.
D
It
would
be
possible
to
sort
of
maybe
try
to
automate
this
more
yeah,
not
an
answer
to
your
question,
but
no
from
an
engineer's
perspective.
That's
what
I
like
to
see
that
they're
always
completely
up
to
date
with
the
code,
because
and
it's
you
know
a
technical
writer
as
well,
because
they're
guaranteed
to
write
oh
yeah.
B
A
I
I'm
kind
of
curious
yeah
myself,
I've,
never
to
be
honest,
I've
never
looked
into
it,
but
I'm
I
would
be
curious
as
to
why
we
don't
use
something
like
ramel
or
swagger
to
auto-generate
the
documentation
for
our
api.
It's
something
I
would
have
to
ask
about.
I'm
sure
it's
been
tried
before,
but
there
must
be
a
reason.
We
can't
do
it.
I
cannot
partially.
D
A
Yeah
I
figured
it
must
have
been
down
to
mix
matching
either
had
the
api
works
or
non-standard.
Like
a
non-standardized
approach,
it
would
be
a
really
fantastic
win
if
we
could
standardize
it
because
then
we
could
auto
generate
our
documentation
from
us
it.
You
know
what
it'd
be
something
cool
to
pick
lucas's
brain
about.
I
might
do
that.
The
next
front-end
meeting.
D
One
thing:
that's
really
relevant
is
the
ongoing
discussion
about
the
rest
versus
the
graphql
api,
and
I
think,
where
that
was
leaning
was
really
the
rest.
Api
should
just
be
a
wrapper
around
the
graphql
api
and
point
being,
maybe
that,
because
I
think
I
think
here
we're
mostly
talking
about
the
rest
api,
because
the
graphql
api
is
a
whole
different
set
of
docs,
correcting
and.
D
Right
the
graph
droid
so
as
far
as
the
rest
side,
if
we
go
down
that
route,
if
we
can
ever
allocate
the
time,
I'm
assuming
that
if
we
turn
the
rest
api
into
just
sort
of
a
thin
wrapper
around
graphql
under
the
covers
we're
going
to
end
up
completely
scrapping
it
and
maybe
rape
and
all
of
that
doing
significant
re-architecture.
So
maybe
at
that
time
we
can
step
back
and
think
from
a
doc's
perspective.
A
E
D
A
What
I
will
do,
amy
about
the
documentation
question
for
the
api,
is
we're
doing
a
lot
of
conversations
at
the
moment
about
graphql,
observability
and
scaling
up
our
graphql
api.
So
it's
a
question
I
might
bring
up
just
as
a
as
a
forethought
and
maybe
if
we
can
look
at
getting
some
support
in
front
of
it
at
the
next
graphql
meeting.