►
From YouTube: Create:Editor - March 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
A
Hello,
hello
and
welcome,
so
we
have
our
editor
monthly
meeting.
We
start
off
right
away
and
I'll
hand
over
the
first
parts
all
to
eric
and
I'm
quite.
B
I'm
listening
in
thanks
yeah,
so
I
have
to
drop
a
little
bit
early,
so
I
asked
roman
to
flip
it
around
and
let
me
have
my
time
up
front
but
I'll
try
and
be
brief
and
then
I'll,
try
and
dial
in
on
the
way
to
pick
up
my
kid
so
editor
naming
thanks
for
your
feedback
and
consideration
in
the
issue,
and
I
I
clarified
that
we
are
indeed
the
dri
for
this
and
I
think
it's
just
necessary
to
pick
a
direction
and
go
so
after
great
consideration
and
all
of
your
wonderful
feedback.
B
B
I
know
there's
still
a
little
bit
of
ambiguity
there,
but
I,
I
think,
they're,
complementary
enough
and
distinct
enough
that
we
can
move
forward
with
those
if
you
have
severe
reservations
or
if,
like
that,
translates
to
something
inappropriate
in
your
language
or
something
like
that,
then
please,
let
me
know
and
we
can
revisit,
but
for
now
I
think
we
should
sit
with
that
decision
and
and
move
forward.
B
B
Cool,
so
I'll
try
and
catch
myself
also
try
and
lead
by
example,
and
call
them
the
proper
names
in
chatting
with
roman,
I
believe
in
one
of
our
one-on-ones.
I
was
encouraged
to
hear
some
feedback
coming
from
you
all
the
engineers.
B
That
is,
that
you
were
enjoying
a
level
of
autonomy
and
like
the
ability
to
propose
solutions
and
come
up
with
technical
approaches
without
feeling
like
they
were
being
dictated
to
you
or
handed
to
you
for
implementation,
and
so
on
that
in
that
discussion
I
kind
of
outlined
a
few
of
my
thoughts
and
thought.
B
Maybe
it'd
be
good
to
share
with
you,
but
I
think
that
I'm
encouraged
to
hear
that
and
I
would
have
been
very
upset
to
hear
anything
else
other
than
that
because,
as
far
as
I'm
concerned
as
a
pm,
I'm
only
responsible
and
only
interested
in
delivering
value
to
our
customers.
So,
as
I
think
about
planning
and
iteration,
that's
the
mindset,
I'm
or
the
the
that's
how
I
frame
these
decisions
and
how
I
frame
the
the
issue,
writing
and
everything.
B
It's
always
derived
from
the
value
that
we're
going
to
deliver
and
I
think
about
an
easy
mechanism
might
be.
How
am
I
going
to
write
about
this,
or
how
would
I
talk
about
this
in
a
release
post,
so
I
am
not
as
interested
and
have
no
preconceived
notions
about
how
we
implement
any
of
these
things,
and
I
don't
think
I
should
so.
B
B
We
have
some
very
big
problems
to
solve
and
I
want
to
let
you
have
the
room,
you
need
to
solve
them,
and
that
said,
I'm
also
very
much
in
favor
of
making
the
time
necessary
to
plan
out
our
technical
approaches
or
do
the
investigation
that
you
need
to
to
build
it.
The
right
way,
the
first
time,
but
I
would
say
I
also
don't
really
love
hand,
wringing
and
like
so
like
just
trying
to
kind
of
being
paralyzed
by
multiple
options
and
and
not
picking
one.
B
B
B
It's
also
how
I
think
about
some
cost
fallacy
in
in
the
work
we
do,
and
I
don't
think
that
there's
any
shame
in
in
bias
towards
action
in
this
regard,
and
that's
just
how
I
feel
so
again,
if
that
gives
you
some
level
of
comfort
in
your
planning
or
or
autonomy
or
independence
in
your
decision
making,
then
then
that
is
probably
the
that's
the
desired
outcome
this
I
put
in
here,
because
I
don't
think
this
really
came
across
in
any
of
my
previous,
like
rants,
about
product
management,
but
we
all
succeed
together
right.
B
B
We
should
celebrate
those
accomplishments
and
we
have
our
team
day
coming
up
soon.
Hopefully
we
will
be
able
to
do
that
in
a
more
formal
way.
I
take
I'm
not
here
to
take
any
credit
for
any
of
your
work
or
accomplishments,
but
I
am
here
to
take
responsibility
for
anything
that
may
go
wrong
or
our
actions
or
a
decision-making
process.
So
think
of
me
as
the
one
who's
gonna,
hopefully
deflect
the
blame.
B
If
something
goes
wrong,
but
certainly
lift
you
up
as
things
go
right
and
and
give
you
the
credit,
you
deserve
a
lot
of
pms
find
that
part
of
the
job
difficult,
but
I
actually
don't
love
the
spotlight,
so
it
fits
really
well
for
me
and
last
I
really
like
data.
B
We
talked
about
this
a
bit
in
another
in
our
our
last
backlog,
refinement
session,
I'm
always
going
to
advocate
for
getting
instrumentation
into
features
and
learning
actual
data
about
how
people
are
using
our
features,
but
I'm
struggling
to
figure
out
how
it
works
here
at
gitlab
still
and
I'm
over
a
year
in.
B
I
still
can't
wrap
my
head
around
size,
sense
and
usage
ping,
sometimes
so,
if
I'm
ever
vague
in
my
requirements
for
tracking
it's
just
because
I
don't
know
and-
and
you
can
feel
free
to
to
ask
me
to
elaborate
or
give
me
suggestions
of
how
to
do
it
better.
B
Please
do
so
there's
just
some
high
level.
You
know
check
in
on
my
product
management
style
and
I'm
glad
to
hear
that
at
least
some
of
you,
I
don't
know
who
gave
this
feedback.
I
don't
want
to
know,
but
I'm
glad
to
hear
at
least
some
of
you
know
that
you
have
this
autonomy
and
and
are
appreciating
it.
D
I
was
gonna,
say,
roman
when,
when
I'm
late
on
status
updates,
I'm
gonna
blame
eric.
Now
you
should
I'm
joking,
you
absolutely
should
no
thanks
eric
and
we.
I
really
appreciate
your
your
approach
to
pm.
Pm-Ing
has
been
really
encouraging
so
and
and
and
inspiring.
So
I
appreciate
it
all
right.
What
were
you
gonna
say?
Chad,
sorry
interrupted.
C
I
was
gonna
say
as
far
as
metrics
and
again
continuing
the
discussion
yesterday.
I
I've
done
seis,
it
can
be
complicated,
but
it
doesn't
have
to
be
I'd
like
to
step
back
and
especially
work
with
with
eric
and
michael
and
catherine,
to
get
a
bigger
picture
of
like
what
do
we
want
to
do
around
experimentation
and
metrics
and
data
gathering
what's
important
to
you.
E
B
A
more
concise
ask
for
like
what
data
is
important
to
me
and
and
put
these
into
epics
and
issues
for
each
of
our
categories,
so
that
we
can
chip
away
at
our
our
data
backlog
and
instrument
where
we
need
to
and
build
dashboards
where
we
can.
I
want
to
be
able
to
help
out
there.
My
sequel
is
very
rusty,
but
I'm
willing
to
learn.
D
My
my
gut
tells
me
it's
possible.
We
just
don't
have
the
the
hypotheses
that
we
want
to
test
like.
I
know
that
in
the
webide
world,
we're
not
in
hypothesis
land
we're
in
you
know
technical
debt,
fixed
things,
land
and
there's
not
a
lot
of.
We
need
to
try
to
disprove
some
hypothesis.
We
have-
and
I
think
once
we
find
ourselves
asking
those
questions,
then
I
think
it's
gonna
be
really
obvious
what
data
we
want,
but
until
then
I
would
say:
let's
avoid
trying
to
push
a
square
peg
through
a
circle
hole.
C
Don't
even
worry
about
sql,
like
I'm
glad
to
help
you
figure
out
how
to
do
its
license,
but
I'd
love
to
hear
from
you
and
the
designers
like
what
problems
are
you
trying
to
solve?
What
hypotheses
are
you
testing?
What
data
do
you
want
to
help
you
with
that,
and
then
I
would
love
to
help
you
figure
that
out
appreciate
it.
I
will
hold
you.
B
Certainly
hold
you
to
that,
and
also
that
is
definitely
on
my
list
to
to
make
that
more
clear,
build
up
a
nice
little
a
little
backlog
of
data
requests,
starting
to
do
that
a
little
bit
on
some
of
the
the
wiki
some
of
the
wiki
data
that
I've
been
looking
into,
but
we'll
have
more
to
come.
B
So
shifting
gears
away
from
sort
of
meta
team
discussions
strategically,
we
have
not
a
shift
in
our
strategy
update,
but
it's
starting
to
sort
of
solidify
around
a
few
different
tracks,
and
so
I
wanted
to
just
check
in
on
what
the
next
you
know.
Maybe
six
months
looks
like
so
it's
probably
no
surprise
to
some
of
you,
but
we've
got
over
the
next
two
and
a
half
release
we're
almost
done
with
13
10,
so
two
releases
in
a
few
days.
B
We've
got
really
three
main
tracks
that
are
forming,
so
we
are
probably
putting
60
of
our
time
into
settings
and
navigation
to
bring
some
really
meaningful
work
over
the
finish
line
and
realized
some
of
the
great
research
that
michael
and
catherine
have
been
doing
to
consolidate
the
top
navigation
menus
and
reorganize
and
give
a
facelift
to
the
left
navigation.
B
B
It
still
to
me
feels
realistic
to
to
aim
for
14-0
to
wrap
up
this
work,
but
yeah
per
the
next
bullet
point.
It's
an
ambitious
goal.
So
just
keep
that
in
mind
and
then
also
the
third
track
is
getting
an
mvc
of
our
content
editor
in
the
wiki,
and
that
again
is
ambitious.
But
it's
it's
very
meaningful
work
and
it's
very
exciting
work.
I
think
the
the
impact
it
could
make
is
is
one
of
the
larger
themes
in
general
over
the
next
year.
B
So
I'd
really
really
love
to
see
the
mvc
land
strong
and
the
wiki
is
a
great
place
to
do
it.
So
those
are
the
three
main
themes.
B
Anything
else
like
bug,
fixes
and
ux
fixes
and
and
security
bugs
will
slot
in
as
needed,
but
for
the
for
the
foreseeable
future
in
the
next
couple
releases
would
really
like
to
stay
focused
on
those
three
things
I
do
just
again
per
the
top
half
of
my
conversation
and
my
pm
style
want
to
say,
like
I'm,
not
drawing
a
line
in
the
sand,
saying
you
have
to
work
nights
and
weekends
to
ship
this
work
by
14-0.
B
B
B
It
can
be
yeah,
we
want
to
make
reasonable
steps
towards
it,
and
we
were
actually
just
talking
with
fran
about
this
yesterday
in
the
backlog
refinement
session.
I
think
we
want
to
be
smart
about
which
things
we
move
around
for
both
the
technical
complexity
of
like
how
things
are
wired
up
with
you
know,
permissions
and
and
visibility,
and
things
like
that,
but
also
just
the
overall
impact,
so
I
think,
to
to
people's
workflows.
There
are
other
groups
working
on
breaking
up
their
categories.
B
Like
operations
is
working
on
making
their
menu
into
two
menus.
I
believe
there's
a
few
concrete
proposals
for
moving
things
around
and
then
there's
a
just
generally
facelift
and
sort
of
ux
ui
improvements
that
we
can
make,
regardless
of
where
the
items
are
and
what
the
information
architecture
is.
So
I
think
we're
going
to
try
and
tie
together
mostly
skewed
towards
the
front
end
and
information.
B
I
mean
sorry,
the
ux
ui,
but
tackling
a
few
of
the
low-hanging
fruit
for
the
information
architecture,
with
an
eye
towards
something
else
coming
up,
which
is
like
a
more
holistic
framework
to
redo
the
left
nav
and
make
it
more
scalable.
D
Is
how
disruptive
is
it
to
to
the
to
the
end
user?
Do
you
think.
B
We
don't
want
to
do
it
every
milestone.
I
think
we
don't
want
to
like
shift
things
around
and
because
you're
going
to
build
spatial
recognition
and
not
ever
settle
in,
but
there
are
items
that
are
clearly
in
the
wrong
place,
so
I
think,
as
long
as
it
makes
sense,
the
people
will
adjust
and
if
we
let
the
dust
settle
for
at
least
a
few
milestones
before
we
make
any
other
massive
changes.
I
think
we'll
be
okay.
D
Okay,
cool!
No!
That's
that's.
That
sounds
that
sounds
really.
Neat
sounds
ambitious,
but
that's
good.
B
And
continuing
on
with
our
ambitions,
the
14-0
release
will
be
a
big
one,
but
obviously
we
won't
stop
there.
14-1
will
come
up
very
quickly
after
we
celebrate
the
wins
of
14-0,
and
so
the
the
next
quarter
really
the
next
three
releases
there.
I
starting
to
think
about
what
we
might
pay
attention
to
and
I
think
for
me
it
would
be
continuing
to
iterate
on
the
content
editor
to
fully
support
all
the
different
gitlab
flavored
markdown
extensions
and
really
build
a
fully
featured
editor.
B
I
think
it
would
be
fantastic
if,
in
the
process
we
found
another
location
to
put
the
content
editor,
whether
that's
in
the
repo
view
in
the
single
file
editor
like.
If
you
open
a
markdown
file,
we
we
show
it
there
or
maybe
it's
in
snippets
in
the
same
scenario
or
it
could
be
that
we're
ready
to
put
it
in
issues,
issue,
description
and
our
descriptions.
B
B
We
don't
want
the
source
editor
formerly
known,
as
editor
light
to
languish,
so
we
would
start
giving
some
attention
back
to
that
and
push
that
maturity
forward.
I
think
there's
a
a
lot
of
opportunities
to
extend
that
in
and
I
listed
something
here,
but
I
think
we
can
plan
this
together
and
figure
out
what
the
most
meaningful
ones
are:
most
impactful
ones,
whether
that's
a
you
know
the
toolbar
or
in
context
editing
or
what.
So,
let's.
Let's
keep
that
in
mind?
B
There's
something
post
140
that
we'll
want
to
pick
back
up
and
then,
as
I
mentioned,
the
left
nav,
the
fran
had
a
comment
that
was
very
encouraging
during
editor
refinement
that
aligned
pretty
well
with
how
we
were
thinking
about
settings,
which
was
what,
if
the
settings
were
represented
by
data
files,
and
we
could
take
those
data
files
and
build
the
settings
views
out
of
that
it'd
be
a
lot
more
flexible,
well
and
similar
to
similarly
to
how
a
framework
has
been
built
for
for
geo.
B
That
allows
people
to
self-serve,
which
fran
also
just
did
for
our
group
wikis,
and
did
it
very
quickly
so
we've
seen
that
it
works
internally,
given
that
we
or
whoever
ultimately
owns
settings
in
nav
will
not
want
to
be
the
gatekeeper
for
changes
to
the
left
nav.
It
would
be
great
if
we
could
build
a
framework
that
was
a
little
less
fragile
and
a
little
more
consistent,
and
we
could
potentially
learn
from
an
effort
focused
on
the
left
now
and
apply
that
to
the
settings
work
further
into
the
14.x
milestones.
B
And
yeah
dennis
thanks
for
adding
the
the
epic
for
editor-like
maturity,
I
think
we
could,
probably
in
the
next
month
or
so
sit
down
in
a
sync
meeting
and
just
really
talk
through
editor-like
maturity
plans.
I
think
it's
long
overdue
to
just
like
sync
up
on
all
that.
B
And
yeah
after
that,
it's
a
little
nebulous
like
plans
change
it's
kind
of
pointless
to
make
too
many
specific
changes
plans
for
for
what
we're
doing
after
that.
But
I
think
we
have
an
opportunity,
starting
at
14-4,
to
to
shift
our
focus
to
that
concept.
That
we've
been
talking
about
with
the
wiki
and
rebuilding
as
a
static
site,
and
what
are
the
conversions
of
the
static
site?
Editor
and
wiki
might
look
like
whether
there's
an
opportunity
to
take
a
more
mature
content
editor
and
put
that
into
some
kind
of.
B
Static
site
driven
wikilike
experience
and
build
that
into
the
product
to
address
a
lot
of
the
shortcomings
of
our
wiki,
while
also
delivering
like
a
more
flexible
knowledge
base
platform
within
gitlab.
This
is
going
to
take
probably
the
better
part
of
a
quarter
for
me
to
wrap
my
head
around.
Get
alignment
probably
do
some
validation.
B
You
know
opportunity.
Canvas
needs
to
be
presented.
We
need
to
do
competitive
analysis
and
all
that
so
probably
wouldn't
kick
off
until
I
don't
know,
what's
14
for
map2
month
wise,
that's
like
end
of
the
year
right,
maybe
six
yeah,
it's
like
fall
into
fall,
but
I
think
we
can.
We
can
look
forward
to
that.
I'm
very
very
excited
about
that
and
then
yeah
settings.
B
Been
march
for
a
year,
yeah
some,
what
is
something
I
said
march,
375th
or
whatever.
B
And
then
yeah,
I
I
think
we
can
take
the
lessons
learned
on
the
data
driven
left,
nav
and
really
work
on
that
componentization
of
settings.
I
think
that's
a
really
impactful
bit
of
work,
but
it's
going
to
take
a
lot
of
planning
and
validation.
If
we
do
decide
to
go
in
that
direction,
I
think
it
would
be
great
to
kick
off
those
streams
in
parallel.
You
know
have
part
of
the
team
working
on
the
new
handbook,
wiki
knowledge
base
product
and
then
the
other
part
working
on
cleaning
up
our
settings.
C
B
B
Okay,
that's
my
rant.
It's
always
far
too
long.
Any
questions
on
the
strategy
stuff
did.
I
is
there
like
a
a
feature
or
category
that
you
feel
is
not
getting
its
due
attention
in
this
plan
or
should
we
are
you.
E
Open
question:
are
we
gonna
meet
to
define
what
the
mvc
of
the
content
editor
looks
like.
E
B
Yeah
yeah:
let's
do
that.
Let's
sync
up
soon,
I
know
michael,
was
doing
some
planning
for
solution,
validation
on
the
editing
experience
itself
and
whether
or
not
we
should
do
a
block
type
editor
or
a
toolbar
based
editor
in
the
wiki
and
the
the
like,
the
user.
Experience
would
probably
be
defined
by
the
outcomes
of
that,
and
then
we
can
certainly
talk
about
like
what
features
make
the
cut
and
like
what
we.
What
our
success
criteria
for
the
mvc
is.
B
B
I
wouldn't
say
we
don't
have
to
do
anything,
but
it's
something
where
we're
just
going
to
have
to
find
the
time
we
can't
dedicate
major
streams
of
work
to
it.
It's
like
a
in
our
matrix
of
percentage
of
time
spent
it's
in
the
zero
to
five
percent
range,
every
milestone.
So,
as
things
come
up,
we'll
try
and
slot
it
in
it
is
important.
Obviously,
we
wanna
keep
that
category
moving
forward,
but
yeah
it's
not
our
our
primary.
C
D
In
so
many
ways
to
piggyback
on
that,
the
web
id
is
is
is
suffering,
but
it's
it's
suffering
valiantly,
but
it
is
suffering
and
we
have
an
epic
that's
been
around
for
a
while
to
address
the
root
of
this
issue
and
I
think,
with
hamachio
and
a
lot
of
the
other
people
that
have
been
a
dentist
that
have
been
aware
of
this.
D
We've
made
small
payments
on
this
debt
to
where
I
think
we
can
address
some
of
the
root
problem
of
redoing,
how
we
do
our
staged
changes
to,
so
that
it's
actually
reliable
and
it's
doesn't
have
weird
user
quirks.
So
I
would
say
the
web
id
is
not
in
a
lovable
state,
and
I
think
I.
E
D
I
think
that
there
is
a,
I
think
in
a
couple
of
milestones.
It
could
be,
though
we
could.
We
could
have
it
where
the
user
experience
is
quite
reliable
and
so
having
attention
on
that
would
be
really
nice.
I'm
I'm
have
a
a
priority.
Three
bug,
I'm
working
on
this
milestone
with
a
weight
too,
but
just
to
deal
with
that.
D
It's
requiring
taking
spaghetti
balls
out
and
just
peeling
out
the
noodles.
We
really
need,
and
so
it's
we
really
need
to
have
a
flag
on
web
ide,
just
the
state
it's
in,
because
it's
not
a
lovable
state
for
developers
or
a
lovable
state
for
users,
and
I
think
it's
really
possible
to
get
there
and
I'm
hoping
this
milestone.
D
This
is
this
is
a
common
theme
I'm
addressing
one
problem,
but
rather
than
doing
the
quick
fix,
I'm
trying
to
do
the
real
fix
and
it
fixes
five
other
ones
that
were
more
severe
than
we
realized.
So
that's
no-
and
I
appreciate
where
you
come
from
as
a
pm,
because
this
gives
me
the
liberty
to
do
that.
So
that's
I
think
the
web
id
would
be
cool
if
it
was
one
to
be
more
lovable,
but
that's
just
bringing
awareness
there.
B
Yeah
absolutely-
and
I
appreciate
that
approach
like
fixing
five
things
by
addressing
one-
is
always
something
I
like
to
see
and
negative
lines
of
code,
and
mr
is
always
great.
I
think
the
visual
of
you
pulling
a
noodle
out
of
a
giant
ball
of
spaghetti
is
something
that
will
get
me
through
the
day.
B
So
thank
you
for
that,
and
I
think
you
bring
up
a
good
point
and
I
think
web
id
maturity
plan
that
that
builds
on
our
strategy
for
maturing
the
source
editor
with
an
eye
towards
addressing
technical
debt
in
the
state
management
in
the
just
left,
sidebar
in
general,
and
making
it
more
resilient
and
polishing
up
the
ux
around
like
the
commit
flow,
and
you
know
the
diff
view
and
stuff
like
that-
would
definitely
be
a
candidate
for
for,
like
the
the
next
six
months.
F
I
have
a
question
I
I
totally
second,
what
what
paul
just
said-
and
I
I
saw
that
magic-
was
that
here
references
it's
just.
It's
not
really
like
taking
the
bowl
of
spaghetti.
It's
like
picking
out
spaghetti
out
of
the
italian
telly
dish.
It's
like
it's
kind
of
challenging,
but
in
general
I
would
like
to.
F
I
see
web
id
now
in
the
in
our
plan
for
14
143,
but
what
what
I'm
missing
personally
is
the
clear
understanding
of
where
a
web
id
goes
like
with
the
kai
being
the
pm
we
have.
We've
got
some
shaking
like
some
unstable
message.
At
least
I
I've
got
where
it
wasn't
clear
whether
web
id
is
here
to
stay,
or
it's
going
to
be
like
with
all
this
code,
sound
bar.
Well,
I
not
called
sandbags
but
like
what?
F
What
do
we
use
like
yeah,
I
get
pod
with
all
that
thing
like
I
would.
I
would
like
us
to
have
the
clear
picture
on
on
the
web
ids
web
id
as
a
product
and
its
place
in
the
overall
product
like
where
does
it
go?
Where
do
we
want
to
be
with
webid
in
a
year
like?
What's
what
what
are
we
building,
whether
we
build
it,
whether
we
just
maintain
it
whether
we
gradually
kill
it
like
what?
What
is
the
plan?
That's
that
would
be.
F
That
would
be
very
important
to
know
for
the
whole
team.
I
think,
and
that
that
that
plan
would
would
directly
affect
our
plans
on
the
estate
cleanup
and
all
these
things
and
select
priorities.
B
Wise
great
question-
and
I
would
say,
like
I,
don't-
have
a
concise
vision
established
yet,
and
I
know
I
need
to
work
on
that.
I
need
to
do
a
little
more
research.
I
need
to
revisit
the
discussion
on
these.
You
know
server-based
runtime,
evaluation,
kind
of
products
and
whether
or
not
we
should
be
revisiting
that
that
is
an
open
question,
but
I
will
say
right
now:
my
intent
is
not
to
shut
down
web
id
or
even
let
it
languish
even
de-prioritize
it.
B
I
think
it's
a
it's
a
core
aspect
of
the
platform
and
it
should
get
the
attention
it
deserves.
I
think
we
can.
We
can
make
it
better,
even
if
it
doesn't
serve
100
of
our
users.
We
can
work
towards
answering
and
coming
up
with
a
stronger
opinion
about
whether
or
not
we
want
like
server-based
evaluation
and
like
a
container
and
piping
data
from
the
web,
ide
back
and
forth,
or
something
like
that.
We
need
to
do
more
research
and
validation
from
the
business
side.
B
I
mean
I
know
that
we've
done
like
a
year's
worth
of
research
in
the
past
before
I
joined,
but
learning
from
the
getpod
integration
is
the
strategy
not
using
gitpod
to
replace
the
web
id?
If
that's
probably
the
most
concise
way
I
can
put
it
I
do
have
to
drop,
but
I
I
will
be
back
in
like
five
minutes
to
listen
on
my
car.
F
Thanks
just
I
just
think
that
we
we
will
have
to
like
take
our
group's
web
id
page
and
just
like
put
all
our
vision
into
this
page,
so
that
everybody
is
on
the
same
page
and
we
could
reference
other
team
members
to
to
that
page.
But
yeah
thanks
for
agreeing
for
explaining
this.
Thank
you.
C
C
I
wanted
to
say
on
technical
debt
and
eric
left
by
that.
I
personally
feel
it's
important
to
address
technical
debt
organically
to
not
try
to
set
aside
releases
for
it,
because
then
you
tend
to
focus
on
things
that
aren't
necessarily
as
important
than
driving
it
like.
I
like
them
to
be
driven
by
something
you're
trying
to
do
with
some
feature.
C
F
You
really
need
to
try
and
levitate
all
that
technical
depth
that
that
really
like
technical
depth
in
general
stands
in
a
way
right,
but
in
case
of
wear
body
it
just
like
stands
in
your
way
and
just
slam
slaps
you
in
the
face-
and
it's
just
like
you
know.
If
we
try
to
like,
for
example,
the
the
polis
is
switched
off
now,
but
in
case
of
paul's
magic
where's.
Now,
like
the
merchant
blast
itself,
is
more
or
less
like
straightforward.
F
But
in
order
to
get
to
this
straightforward
decision
like
he
had
to
push
the
mr
with
like
just
like.
Let
me
just
take
a
look
with
plus
178
minus
390
lines
of
code
of
cleanup.
You
know
to
get
to
the
straightforward
decision,
so
it's
like
the
the
the
problem
is
that
not
tackling
tech
like
technical
tackling
technical
debt
in
web
id
organically
is
very
challenging
because
it
really
affects
the
planning
and
proper.
F
Weighing
of
the
issues
like,
as
paul
said,
the
the
the
issue
itself
is
weighed
at
two
but
like
in
order
to
deliver
those
two.
We
need
to
deliver
like
five
weights
of
technical
debt
and
that's
that's
the
main
issue
and
it
makes
things
really
complicated
when
one
tries
to
deliver
any
tech,
any
any
new
feature
or
maintaining
an
existing
feature
in
webinary
and
it
just.
It
just
puts
pressure
on
the
ics.
C
A
And
I
I
think,
like
there's
like
different
kind
of
technique
with
that
right
and
in
this
case,
or
so
I
always
like,
bind
it
very
much
like
to
use
a
value
the
want
to
create-
and
in
this
case,
there's
on
a
web
ide
like
there's
like
really
currently
the
issue
that,
like
our
state
management,
for
example,
is
like
really
not
working.
So
there's
a
lot
of
value
that
we
could
create
for
users
that
we
just
don't
because,
like
the
technical
that
is
actually
preventing
us
creating
this
value.
A
So
by
paying
off
this
debt,
we
actually
start
creating
this
value.
So
it's
like
super
worthwhile
investment,
but
fixing
the
state
suddenly
like
50
things
that
were
not
working
before
are
working.
Now,
because
we
paid
off
the
debt
and
fix
these
things
kind
of
unavoidably
in
the
process,
then
it
is
like
super
worthwhile
investment,
and
I
think,
like
eric
and
myself
were
totally
on
the
same
page
here
and
like
super
supportive
of
this.
A
A
A
small
team
with
kind
of
a
lot
of
goals
and
a
lot
of
kind
of
like
responsibilities
right
now,
like
just
finding
the
right
time
in
in
doing
so,
but
I
think
it's
also
I'm.
F
I'm
sorry
to
interrupt
you,
roman,
but
I
just
think
that
it's
very
important
to
mention
that
actually,
all
those
like
thoughts
about
abandoning
web
id
or
like
getting
rid
of
it
like
they
partially
came
from
the
idea
that
velocity
of
developing
new
features
for
webb
is
very
low
and
the
velocity
is
very
low
exactly
because
of
technical
depth.
It's
like
I
in
general.
F
I
do
agree
that
tackling
technical
depth
organically
is,
is
a
good
approach,
but
when
it
comes
to
web
ide,
it's
sometimes
it's
questionable
whether
it's
more
of
a
features
or
technical
depth
project.
So
in
this
particular
case,
technical
depth
for
webide
has
to
be
dealt
with
exactly
as
any
other
feature
would
be.
Absolutely
I
see
something.
F
That
robin
and
eric
are
on
the
same
page
with
regarding
this,
and
hopefully
we
can.
We
can
fix
this,
especially
if
we
plan
to
keep
web
id
and
go
on
with
it
and
make
it
a
better
product.
Yeah.
A
100
agree:
I
need
to
fully
confirm
this
with
eric,
of
course,
but
like
I
don't
see
that
the
the
web
ide
is
going
anywhere.
It's
like
just,
I
think,
like
the
division,
diverges
from
kind
of
what
like
was
previous
division
and
now
the
visualizer
for
web
ide,
and
I
think,
like
just
where
we
want
to
bring
the
web
id
as
like
an
integral
part
of
your
gitlab
workflow
and
how
you
operate.
Everything
like
this
makes
so
much
sense
right.
We
just
need
to
focus
on
the
right
things.
A
We
cannot
hunt
for
the
wrong
things
by
saying.
Okay,
we
want
to
create,
like
your
next
git
pod
integration
or
git
pod.
Product
like
this
is
clearly
cannot
be
our
goal
because,
like
our
team
is
like
way
too
small
for
this
or
something
what
we
want
to
do,
but
there's
like
so
much
potential
for
web
ide.
F
Also,
with
with
the
with
the
source,
editor
driving
webid,
now
it's
it
opens
the
door
to
so
much
so
many
opportunities
to
like
live
previews
and,
like
all
sorts
of
cool
things
that
that
were
really
complex
to
to
implement
in
web
ide.
Previously.
C
E
So
we
want
to
do
something
more
similar
to
cold
sandbox
thing
right,
but
we
still
want
to
do
something
where
we
can
like
build
an
architect
from
the
source
that
we
are
eating.
F
Yeah,
I
I
think
I
think
that
that
that's
a
good
comparison
like
I,
we
don't
want
to
build
the
new
vs
code.
We
want
to
build
the
new
code
sandbox,
apparently
that's
that
would
be
more
like
a
line
and
it's
like
it
makes
sense,
because
we
have
to
to
to
appreciate
the
what
what
web
platform
gives
to
us
and
use
it
for
our
benefits.
Instead
of
like
trying
to
replicate
the
desktop
application
on
the
web.
E
A
Thanks
for
this
good
discussion
or
so
and
seems
like
we're,
all
visually
kind
of
like
aligned,
which
is
nice
just
now,
need
to
wait
for
eric
to
kind
of
whip
it
into
proper
words
and
sell
it
to
the
upper
mantra.
That
should
be
good
cool.
A
Second
time
I
want
to
use
like
quickly
the
time
to
jump
on
some
of
em
updates.
One
thing
in
general
I,
as
kind
of
mentioned
previously,
I
want
to
give
everybody
like
a
more
general
like
stat
update
as
well
as
part
of
this
one.
So,
first
of
all
our
say:
do
ratio
for
the
last
milestone
for
39
was.
This
is
like
82
and
that's
like
amazing.
A
It's
amazing
there's
another
number
in
there
like
with
70,
which
kind
of
takes
away
like
work,
that
kind
of
slipped
in
and
was
kind
of
repurposed
or
so,
which
is
like
totally
fine.
So
I
don't
really
care
for
this
number,
because
sometimes
we
just
plan
differently
for
the
work
that
we
do.
82
percent
is
like
amazing,
so
good
job.
Everyone
very
much
appreciate
it.
A
I
would
say
like
the
baseline
or
so
teams
are
aiming
for
is
between
like
70
75
percent,
okay,
I'm
about
kind
of
reaching
at
82
percent,
we're
above,
like
the
the
expectancy
or
so
by
a
good
number,
which
is
nice
cool,
never
mind
rate
we're
at
10,
mrs
per
engineer
for
the
last
month.
This
is
also
super
good
unchanged
from
the
previous
months
or
so
so
good,
making
good
progress.
F
A
Yeah,
thank
you.
Whole
team
very
nicely
said
denise
and
then
quick
check
in
on
the
okrs,
where
we
stand
right
now,
we're
at
like
17
percent
of
progress
so
far
when
it
took
like
the
the
last
calculation
at
the
beginning
of
march,
just
like
some
other
good
things
and
updates
coming
in
there.
So,
as
I
pro
expect,
will
make
kind
of
a
good
update
over
the
course
of
march
and
there's
like
something
else,
kind
of
changing
the
number
or
will
be
added.
But
overall,
I
think
we're
on
a
on
a
good
good
track.
A
We're
gonna
go
here.
So
thanks
everybody
for
chipping
in
on
this
cool,
and
then
I
just
want
to
kind
of
talk
a
little
bit
about
our
kind
of
a
work
approach
and
so
very
much
based
on
like
what
eric
said
right,
we're
going
to
topics
of
autonomy
and
everything
we
talked
about
it,
and
it
seems
so
far
that,
like
the
collaboration
aspect
of
our
work,
that
we're
doing
is
like
having
really
positive
impact
on
the
outcomes
of
the
thing
of
our
results
and
what
we
deliver.
A
So
this
is
like
amazing,
and
I
think
we
just
like
deliver
really
good
things,
but
like
one
news
feedback
or
so
I
would
totally
left
off
in
the
retro.
A
The
retro
is
already
like,
open
and
prepared
for
everybody
to
drop
in
their
feedback
about
this,
but
on
that
base,
or
so
we'll
probably
go
forward,
especially
for
the
next
two
milestones
to
kind
of
think
about,
like
this
more
buckets
of
work,
or
so
that
would
kind
of
like
to
to
box
in
some
ways
or
so
and
make
it
like
as
a
team
effort
where
say
like
I'm,
either
assigned
like
multiple
people
or
kind
of
just
give
people
an
epic
where
hey
there's
a
bunch
of
stories
I'll,
let
you
come
up
with
like
the
the
proper
plan
of
doing
this,
maybe
also
even
like
saying:
okay,
there's,
maybe
a
bigger
issue
that
needs
to
be
split
up
in
multiple
issues
or
so,
but
like
just
giving
the
people
the
autonomy
or
so,
and
everybody
here
to
say.
A
Okay.
I
think
this
is
how
we
need
to
do
it
and
kind
of
diverging
even
like
from
the
plans
every
now
and
then
this
is
like
totally
fine
and
acceptable,
and
it's
cool,
because
I
really
do-
and
I
want
to
emphasize
this-
I
really
do
trust
each
and
every
one
of
you
in
this
team,
like
very,
very
highly,
on
kind
of
making
the
right
calls
and
kind
of
knowing
what
to
focus
on
there's
nothing.
Why
I
wouldn't
trust
you
you'll
deliver
like
amazing
results
again
and
again
over
the
last
milestones
here.
A
So
this
is
like
just
very
much
amazing
and
it
can
just
like
second
what
eric
stated
above.
Basically,
if
we
can,
I,
as
a
and
a
new
manager,
can
enable
you
and
support
you.
I
think,
then,
I'm
very
happy
cool
and,
regarding,
like
the
next
two
milestones
like
in
general,
there's
like
two
access.
A
First,
like
to
you
to
plan
work
right
on
the
one
side
either
like
you
have
a
you
know
the
work
that
you're
going
to
work
on,
and
then
you
just
figure
out
how
much
time
does
it
need,
like
we
say:
okay,
one!
Do
this,
let's
see
how
long
this
takes.
The
other
approach
is,
of
course
it's
like
okay.
I
have
a
time
box.
How
much
work
can
I
fit
into
this
time
box?
A
That
makes
sense
so
in
this
case
now
we're
in
the
process
of
saying
okay,
we
have
like
a
time
box
with
like
14
0,
of
like
two
milestones,
and
I
really
want
to
use
this
like
as
a
as
a
bigger
picture
in
this
case,
and
let's
say,
okay
like
something
needs
to
be
done
by
milestone.
1311.
A
If
you
say
okay,
this
does
not
make
any
sense,
or
this
is
like
absolutely
not
doable.
That
is
totally
fine
and
acceptable
right,
just
like
focus
on
the
ambitious
goal
or
more
so
that's
the
thing.
So
what
yeah?
A
Overall,
I
think
there
will
be
fewer
deliverables
than
usually
but
they're,
just
like
a
little
higher
expectancy
or
more
very
descriptive
or
what
we
expect,
or
so
what
is
like
planned
to
give
everybody
like
this,
the
scene
or
so
where
we
want
to
move,
and
then
I
trust
everyone
or
so
to
think
what
is
the
right
thing:
cool
denise!
You
want
to
verbalize
yeah.
F
No
yeah-
I
I
just
like
this
idea-
it's
like
it's
very,
very
it's
very
anarchy,
but
I
I
think
like
this.
This
actually
might
work
out
for
our
particular
group,
because
we
are
all
highly
professional
individuals
who,
surprisingly,
can
work
in
the
teams.
F
So
I
think
I
think
this
this
actually
might
work
out
and
might
bring
really
good
results.
So
I
really
appreciate
this
approach.
Thank
you.
Cool.
A
Thank
you
for
your
feedback
and
then,
like
the
final
thing,
is
create
edited
team
day.
Just
want
to
highlight
it
again.
It's
coming
up
like
on
the
22nd,
which
is
like
the
monday,
so
we
all
should
be
quite
refreshed.
A
After
a
long
weekend,
which
is
nice,
the
issue
is
open,
so
I
didn't
see
too
much
activity
on
it
or
so,
but
I
would
totally
love
to
have
like
some
more
ideas,
maybe
or
so
till
the
end
of
this
week,
to
kind
of
formulate
our
plans
ideally
beginning
of
next
week
as
a
team
and
yeah
anything
that
you
kind
of
think
would
be
cool.
A
Just
let
us
know
one
thing
I
just
want
to
highlight,
or
so
and
that's
why
I'm
curious
what
people
think
the
hackathon
kind
of
is
something
that's
interesting.
Paul
brings
up
like
maybe
something
like
a
game
jam
which
yeah
might
be
hard
to
kind
of
yeah.
I
don't
know
if
anybody
has
like
the
time
and
resource
to
kind
of
jump
in
this,
or
so
like
paul
is
definitely
way
above
us
with,
like
his
game
jam
experience.
I
have
no
clue
about
this.
A
To
be
honest,
but
like
a
hackathon
in
the
way
of
saying
like
okay,
what
if
you
want
to
do
something
on
gitlab
or
so
that
is
like
not
really
related
to
the
work
that
you
do
on
a
daily
day
basis?
Is
there
something
in
the
product
or
so
or
like
any
idea?
You
want
to
spin
off
and
try
out,
and
so
if
this
is
something
that's
interesting
and
we
could
like
structure
the
team
day
around
kind
of
this
functionality.
A
E
So
good
we
weren't
going
to
meet
preparing
sessions,
so
we
can
use
the
same
the
same
problem:
okay,.