►
From YouTube: Create:Editor - Febuary 2022 Monthly Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
D
We
can
save,
maybe
the
the
deep
analysis
for
a
retro,
but
I
would
like
to
just
kind
of
ask
as
we're
starting
to
plan
for
14.9.
If
there
was
anything
in
particular,
we
could
have
done
better
to
plan
for
14.8
if
there
were
blockers
that
came
up
if
we
didn't
have
well
enough
to
find
deliverables
or
what
or
if
things
just
got
away
from
you
like
no
blame.
I
just
wanted
to
know
so
that
we
can
avoid
over
scheduling,
14
9.
B
So
I'll
I'll
jump
in
and
voice
my
points
because
I
think
it'll
be
pretty
closely
related
to
eric's.
So
this
this
is
a
metric.
I
personally
have
not
been
tracking
too
closely
over
the
last
couple
of
months
due
to
all
of
the
shifting
goals.
We've
had
allocations
going
on
security,
burn
downs
and,
to
be
honest,
a
lot
of
what
we've
been
working
on
doesn't
lend
particularly
well
to
small
issues
that
can
be
closed
out
relatively
quickly.
B
They
tend
to
be
long-lived,
big
efforts,
so
I
would
like
to
propose
that
moving
forward
to
start
working
with
this
percentage,
we
start
looking
at
more
granular
issues
that
are
closely
aligned
on
a
one-to-one
basis,
an
issue
for
emerge,
and
if
an
issue
is
going
to
spawn
multiple
merges,
we
actually
consider
breaking
that
into
multiple
issues
housed
by
a
parent,
epic.
I
think
that'll
give
a
little
bit
more
clarity
and
it
should
help
us
effectively
close
out
more
issues
over
a
milestone
and
raise
this
figure.
E
Because
you
know
the
fact
that
you
got
something
wrong
is
part
of
the
calculation.
But
if
you
know
something
is
going
to
be
big,
you
should
definitely
break
it
up
into
small
ones
and
the
mr
issue
and
it's
they're,
rethinking
this
hierarchy
all
the
way
up.
You
know
groups
and
work
items
and
all
of
this
is
being
redone
but
down
the
line
to
just
have
a
more
one-to-one
relationship
between
what's
actually
estimated
and
what's
work
done
and
not
have
them
explode
into
scope
creep,
which
you
know
blows
off.
A
We've
had
really
big
efforts
we're
working
on,
but
we
need
to
capture
the
actual
work
into
small
deliverable
chunks.
Yeah
I
mean
that
sounds
great.
I
think
just
the
thing
that
we
want
to
be
cautious
of
is
letting
the
need
for
small
deliverable
chunks,
not
add,
not
add
friction
or
a
hesitancy
to
doing
big,
ambiguous
work,
which
needs
to
be
done,
and
that's
totally
has
happened
in
in
the
past,
where
we
become
so
metrics
driven
we're
just
thinking
about
what
are
the
low-hanging
fruit
stuff.
A
A
F
Oh
I'm
I'm
I
was,
I
was
preparing
to
just
to
speak,
I'm
sorry
and
it
was
so
yeah.
Let's
consider
it
still
crazed,
but
now
it's
down.
So
what
I
wanted
to
say
is
that
this
milestone
was
a
bit
special
in
terms
of
really
big
efforts
from
all
different
angles
and
it's
natural
that
the
the
ratio
is
not
it's
not
perfect.
F
I
do
agree
with
paul
here
that
we
should
be
very
careful
with
the
being
any
matrix,
driven
and
saying
like
okay,
we
have
the
big
effort,
but
we
still
have
to
like
in
the
context
of
this
big
effort,
we
have
to
make
sure
that
we
push
some
smaller
deliverables,
small
chunks
because
technically,
like
we
have
a
concrete
example,
we're
talking
about,
for
example,
integrating
the
content
editor
for
in
the
product
to
to
edit
the
markdown
files
or
about
the
vs
code.
Those
things
are.
F
It
would
be
very
advanced
sort
of
naive
to
to
consider
that.
Okay,
we
should
start
sending
them
ours
towards
these
goals
right
away,
because
we
are
still
in
the
spike
stage
and
things
might
not
turn
out
to
be
the
way
we
anticipate
them
at
the
moment.
So
if
we
are,
if
we
say
that,
okay,
in
the
context
of
the
big
efforts
we
still
have
to
to
push
some
smaller
changes,
this
might
mean
that
we
will
put
out.
F
We
will
shoot
ourselves
in
the
foot,
meaning
we
will
have
to
push
forward
for
the
f
for
the
effort
that
we
have
contributed
to
in
terms
of
smaller,
mrs,
so
that
that
might
be
a
bit
a
bit
dangerous.
I
still
understand
that
we
are
measured
by
some
some
metrics
and
I
don't
have
any
solution
of
how
we
can
still
show
the
metrics
but
concentrate
on
the
big
efforts.
Nevertheless,
but
just
wanted
to
raise
the
concern
that
we
should
not
catch.
F
E
E
The
way
I
like
to
see
it
captured
as
they're
small
exploratory
issues.
It's
like
okay,
here's
this
thing
that
we
don't
know
about
we're
going
to
make
an
issue.
That's
pointed
to
explore
that,
and
then
we
finish
that
issue
and
maybe
there's
something
else
that
follows
off
of
that,
but
it's
still
captured
in
small
granular
estimated
issues
and
david,
and
I
have
talked
about
starting
nmr
for
our
team
page
on
in
the
handbook
that
writes
all
this
stuff
down.
D
We
can
talk
about
this
more
in
the
retro,
I'm
just
from
from
a
product
perspective,
I'm
concerned,
if
I'm
over
scheduling
you
right
if
we
commit
to
issues
that
are,
in
my
mind,
look
small
and
fairly
well
defined,
but
then
we
pair
them
up
in
your
on
your
plate
with
these
big
technical
discussions,
if
you're,
if
you're
unable
to
context
switch
or
if
something
that's
less
knit
less
well-defined
ends
up
taking
longer
and
then
those
other
deliverable
slip
milestone
milestone,
I
just
need
to
know
right.
That's
all
so
I
I
don't.
D
D
I
just
want
to
make
sure
that
what
we
say,
we're
going
to
deliver
is
at
least
closely
reflective
of
what
we
can
deliver
and
obviously
that
comes
with
more
predictability,
more
upfront,
time,
planning
and
stuff,
so
we'll
keep
working
on.
I
just
want
to
make
sure
there
if
there
were
any
major
red
flags
that
came
up
in
this
milestone.
We
could
talk
about
it
I'll
get
to
the
other
hands,
but
we
don't
need
to
belabor
this
point
until
the
retro.
B
Next
enjoyed
taking
notes
and
speaking
at
the
same
time,
yeah.
I
think
this
is
going
to
be
a
really
fantastic
discussion
for
our
retro.
We
can
get
into
this
in
depth.
This
is
this
is
something
like
on
our
team.
We
do
this
particularly
well
we're
really
good.
We
have
big
lofty
goals
and
big
aspirations
in
our
team
and
we're
really
good
at
setting
our
priorities
and
moving
towards
it,
and
all
I
would
like
us
to
do
is
look
at.
B
Can
we
refine
our
process
a
little
bit
without
gamifying
it,
because
I
don't
also
don't
want
to
gamify
this
metric?
I
have
no
interest
in
that.
It
means
nothing.
It
just
creates
overhead.
So
if
we
can
refine
this
process
a
little
bit
and
make
life
easier
on
people
fantastic,
if
we
can't
that's
still,
okay,
we
still
work
towards
great
stuff
when
we
deliver
it,
but
we
can
get
into
it
in
the
retro.
B
B
All
right
super
stuff,
my
last
two
points
I'll
keep
them
super
quick.
So,
as
usual,
we
are
in
the
higher
end
for
our
teams
and
our
race.
The
editor
team
is
consistently
one
of
the
higher
teams
in
terms
of
narrow,
mr
rate,
so
there's
nothing
that
we
really
have
to
do
different
there
we're
killing
it.
So
thank
you,
everybody
for
continuing
to
work
in
a
iteration-based
approach.
It
is.
It
reflects
well
on
the
team.
B
B
What
I
am
going
to
do
is
I
am
going
to
be
creating
a
per
quarter
issue
that
will
live
for
the
entirety
and
I
will
be
updating
the
progress
of
the
ocares
and
that
will
be
linked
in
the
weekly
team
announcements
to
ensure
that
everybody
has
a
good
idea
of
how
we're
progressing
in
our
okrs
and
it'll
also
invite
you
to
leave
feedback
or
ask
questions
in
an
asynchronous
setting,
so
moving
forward.
Okrs
will
be
hopefully
much
more
highly
visible
and
they'll
be
done
completely
asynchronously,
and
hopefully
that
is
a
little
better
for
people.
D
D
So
this
is
what
I
have
it's
open
for
discussion,
I'm
not
just
trying
to
monologue,
but
the
next
two
to
three
milestones.
At
least
I
want
to
continue
pushing
forward
with
vs
code,
even
though
we
don't
have
a
formal
decision
stamp
of
approval
from
product
leadership,
or
anything
like
that.
There
have
been
no
major
red
flags
for
me
right
now.
We're
continuing
to
do
validation
on
the
the
solution
itself,
as
well
as
legal
and
appsec
and
other
concerns.
D
D
I
will
say
that
there
are
some
in
very
high
levels
of
product
leadership
that
are
extremely
excited
about
this
approach,
so
there
there
would
have
to
be
some
pretty
big
red
flags
in
the
data
coming
back
from
research.
That
users
would
reject
this
change,
which
I
don't
think
will
happen
or
a
major
security
or
legal
challenge
to
overcome
to
to
derail
this.
This
appears
to
be
the
direction
we'll
head
in.
D
So
that's
that's
that
and
amy.
Yes,
we
we've
been
talking
with
tomas.
I
he's
been
fantastic
to
pair
with,
although
I'm
putting
words
in
paul's
mouth,
but
they've
been
pairing
together
on
it.
We
hope
to
use
some
of
the
great
work
he's
done
to
bolster
our
offering
and
make
it
consistent,
and
things
like
that.
D
Cool
yeah
and
I
actually
have
a
regular
sync
with
him
just
because
I
used
to
work
with
him
on
gitter,
and
we
just
keep
in
touch
so
he's
he's
closely
he's
very
much
aware
of
what
we're
working
on
cool.
Thank
you
now.
The
content.
Editor
is
our
other
major
opportunity
here
we
have,
or
I
have
realized,
that
the
preservation
of
unchanged
markdown
is
the
biggest
blocker
to
a
lot
of
what
we
want
to
do
here.
D
I
feel
david
and
I
both
feel
like
swarming
on
this
challenge
will
unblock
a
lot
of
potential
later
in
the
year.
So
I
think
over
the
next
two
to
three
milestones:
getting
as
much
front-end
support
to
enrique's,
to
to
implement
enrique's
architecture
that
he's
working
on
will
be
our
primary
focus
and
that
will
lead
into
I
see
enrique.
You've
left
a
question
down
in
the
open
q.
A
we'll
talk
about
it
more
but
I'll
just
say
this
is
this:
is
our
one
of
our
top
priorities
for
the
front
end
team
right
now?
D
H
Sure
so
you
also
you
put
a
note
there
about
start
working
start
breaking
the
work
into
issues,
that's
something
that
we
should
probably
start
collaborating
on
next
week.
I
finished
working
on
the
technical
design
document.
I
just
just
wanted
to
spend
two
or
more
or
three
days
investigating
the
problem
a
bit
more
because
I
think
that
we
should
answer
some
important
questions
upfront
about
the
architecture.
H
D
That's
fantastic,
the
timing
sounds
great.
Just
so.
Everybody's
aware,
like
the
14.9
milestone
board,
might
be
a
little
light
until
we
flesh
out
those
issues,
because
those
will
be
ones
that
we
roll
right
into,
if,
if
possible,
so
that
I'll
leave
room
in
149
to
just
continue
working
on.
This
is
what
I'm
getting
at
and
now
welcome
back
for.
Unofficially.
Well,
almost
officially,
I
don't
know
exactly
when
we
can
say
that
you're
back,
but
it's
great
to
have
you
back
on
the
call,
no.
I
I
D
I'll
be
sure
to
tag
them
in
this
recording
and
make
sure
that,
but
you
did
great
work,
I'm
glad
you're
back.
It
was
very,
very
important
work
that
you
did,
but
now
that
you
are
back
there's
a
couple:
backhand
tasks
that
we've
had
lingering
improving
performance
of
wikis
and
stuff
like
that,
but
the
bigger
effort
over
the
next
two
three
milestones,
as
you
called
out
in
the
planning
issue,
is
moving
away
from
gollum
and
working
on
those
giddily
rpc's.
I
D
The
code
base
as
a
whole,
we
have
big
picture
long-term
vision,
for
you
know
wiki
pages
stuff,
but
we
can
make
improvements
now
that
will
help
the
half
a
million
people
that
are
using
wiki
already
so
that'll,
be
your
primary
focus
over
the
next
couple,
two
three
milestones
and
moving
on
to
pages,
which
is
not
officially
our
category
yet
in
the
handbook,
but
welcome
again
to
vishal
and
casio.
We're
very
excited
to
have
you
and
very
excited
to
take
on
pages.
D
There
are
lots
of
onboarding
tasks
and
you
got
to
get
up
to
speed,
we're
not
going
to
put
too
much
pressure
on
you
in
the
in
the
next
couple
milestones.
But
as
you
do
get
your
feet
under
you
and
you
start
picking
up
issues,
we'll
focus
on
the
the
work
related
to
rate
limiting
and
just
stability
of
pages,
and
then
there's
a
couple
really
long
standing
features
that
I'd
like
to
just
dig
in
and
understand.
D
D
D
So
that's
our
strategy,
you'll
notice
that
there's
a
couple
things
missing
snippets.
I
don't
expect
a
lot
of
investment
over
really
this
year
unless
something
changes.
So,
let's
not-
let's
not
worry
too
much
about
that
right
now
and
source
editor,
while
there
are
probably
going
to
be
some
issues
and
especially
if
they
start
investigating
using
it
for
comments
and
notables,
and
things
like
that,
we'll
want
to
support
them.
D
But
I
think
right
now
we
need
to
swarm
on
the
content,
editor,
preservation
of
unchanged
market
and
then
return
to
things
like
the
multi-file
experience
and
things
like
that
afterwards.
So
we'll
continue
doing
validation
over
the
next
two
three
milestones
on
that,
but
we
probably
won't
kick
off
a
big
effort
for
source
editor
until
you
know
14
10,
15,
0.,.
B
All
right
super
stuff,
thank
you.
So
much
eric
sounds
really
really
good.
Sounds
like
a
really
really
fantastic
long
term.
Clear
plan
really
really
appreciate
it.
It's
going
to
be
good
stuff
and
again
welcome.
Cassio,
welcome
to
xiao
excited
to
have
yous
yep.
Take
your
time,
get
ramped
up,
looking
forward
to
some
really
cool
stuff
for
pages,
it's
one
of
the
more
loved
categories
by
our
users
and
I
think
we're
going
to
be
able
to
do
some
really
cool
stuff
with
it
in
terms
of
the
q.
B
A
I
have
the
first
question:
I've
been
bugging
everybody
about
this
question,
but
now
that
our
team
is
finally
back
together
in
a
holistic
sense,
I
would
like
to
look
at
how
I've
been
planning
milestones
with
eric
and
if
there
are
things
that
I
can
do
better
to
either
make
things
more
clear
for
y'all
or
to
make
life
a
little
more
straightforward
and
it
kind
of
feeds
into
the
conversation
above,
but
any
and
all
feedback
you
can
provide
it
asynchronously
or
synchronously
and
yeah.
If
you've
got
any
suggestions,
please
let
me
know.
A
So
this
is
related
to
the
sedu
stuff,
so
I
was
gonna.
I
realized
we're
gonna
talk
about
that
in
the
retro,
but
I
had
some
questions
that
maybe
just
wanted
to
plant
some
seeds,
so
we
can
be
pondering
this
and
maybe
discuss
more
in
detail
as
we
think
more
about
it
before
I
do
that.
I
do
want
to
give
so
much
love
to
our
pages
feature
like
that
is
definitely
one
of
my
favorite
features
of
git
lab.
A
We
do
it
so
much
better
than
github
and
I
think
users
that
use
it
and,
if
use
both
github
and
gitlab.
This
is
a
clear,
huge
win
that
gitlab
has
over.
I
think
any
of
competing
offer
pages
with
the
baked
in
ci
and
stuff
is
really
nice,
so
that
is
exciting,
that
we
get
to
own
it
and
it's
an
exciting
feature
to
work
on.
So
thanks,
kaziel
and
vishal,
please
don't
break
it.
I'm
joking.
A
The
question
I
want
to
ask
talking
specifically
about
the
seidu,
which
kind
of
goes
into
kind
of
goes
into
the
milestone
planning
question.
When
we
have
these
big
issues
that
are
ambiguous
and
we're
just
there's
something.
We
know
we
gotta
wrestle
with.
We
gotta
talk
about
it,
it's
not
clear
like
what
the
artifact
of
it
is
like,
and
maybe
that
just
needs
to
be
a
requirement
for
every
issue
we
have
of
like.
A
This
is
the
expected
artifact,
and
this
is
you
know
how
we
can
close
it,
and
once
we
have
this
artifact,
then
we
know
this
is
this
is
closable?
If
we've
had
some
sort
of
discussion,
maybe
the
artifact
is
okay.
We've
put
that,
maybe
even
just
that
discussion,
we've
added
it
to
some
sort
of
document,
architecture
document
or
something
like
that-
and
I
don't
know
if
I
think
sometimes
issues
themselves
are
the
artifacts
and
I'm
just
thinking
making
it
really
clear
when
there's
a
large
topic
at
hand.
A
B
And
again
it's
be
careful
not
to
game
of
fires,
but
I
think
in
this
way,
ultimately,
it
would
be
useful
if
we
could
maybe
look
at
translating
spikes
as
we've
been
doing
into
really
well
fleshed
out
epics.
I
think,
with
small,
very
granular
very
well
understood
issues
that
live
underneath
it
and
I
think
that
that's,
like
our
mr
rate,
is
already
very
very
high.
So
we
do
a
lot
of
really
good
work
with
iteration.
So
maybe
it's
getting
more
and
more
into
this
habit
of
using
epics
and
then
smaller
issues
more.
A
I
think
yeah,
I
think
that's
almost
an
artifact
of
a
discussion
is
like
sometimes
you
don't
even
know
what
is
the
and
what's
the
implementation
plan
gonna
look
like
so
it's
hard
to
break
it
out,
and
so
maybe
maybe
one
flavor
of
spike
has
here's
just
an
architecture
plan,
but
we
still
have
to
maybe
wrestle
with
here's
how
we're
actually
going
to
implement
it,
and
so
maybe
maybe
defining
architecture
plan
is
a
legit
artifact.
This
is
what
we
expect
out
of
this
and
then
implementation
plan
is.
We
actually
have
epics
and
issues
created.
A
A
I
I
see
as
I've
done
a
couple
of
spikes
here
and
as
I've
seen
participate
in
others.
I
see
I
see
these
two
flavors
coming
up.
One
is
just
we
just
need
to
really
wrestle
with
this
at
a
high
level.
I
don't
even
know
what
issues
are
gonna
come
from
this,
but
what's
the
architecture
we
could
do
and
then
the
other
flavor
is
okay.
We
can
actually
create
issues
from
this
and
that's,
I
think
I
think
that'll
probably
help
help
scope.
These
a
lot.
E
An
intention
to
focus
on
small
iterations
small
deliverables
like
it,
helps
in
that,
because
you
don't
want
to
get
stuck
in
scope
creep.
You
always
want
to
have
something
that
you're
delivering
as
as
part
of
looking
into
this.
Even
if
this
document
saying
okay,
here's
what
we
know-
and
it
was
completely
wrong
from
what
we
thought
before
you
know-
that's
that's
an
issue,
and
then
you
go
into
the
next
step
to
figure
out
more.
G
Just
to
voice
the
top
that
I
put
in
there,
I
think
the
handbook
mentions
to
have
a
threshold
of
five
the
weight.
Five
on
an
issue
to
split
in
smaller
issues.
On
my
former
group,
we
used
to
do
that
as
well,
so
issues
that
were
eight
five
weight.
Five,
we
usually
break
it
in
smaller
ones,
but
beyond
that,
I
think
spiking
on
those
issues
before
breaking
smaller
issues
should
be
a
good
practice.
It
could
be
a
good
practicing,
and
I
agree
with
having
a
well-defined
out
expected.
E
Over
yeah
and
we've
got
to
get
into
the
wheeze,
but
as
far
as
estimation
like
I've
discussed
this
in
the
past,
I'm
a
fan
of
fibonacci
like
the
one
three
one,
two
three
zero
one,
two
three
five,
eight
and
like
an
age
is
never
prioritized.
It
always
has
to
be
broken
out,
but
five
is
like
it
really
should
be
broken
up.
But
if
it's
like
just
a
bunch
of
rent
work,
really
straightforward
low
risk,
maybe
you
probably
are
interested
five
other
than
that
everything
should
be
a
one
or
two
or
three.
E
H
H
H
D
And
I
think
that's
exactly
right
and
also
once
you
start
building
out
issues
from
the
preserve
unchanged
markdown
we're
going
to
have
a
lot
of
really
small
scoped
issues
to
tackle.
So,
if
you're
looking
for
predictability
and
deliverables,
I
think
we're
on
the
horizon.
Seeing
that
change
so
you're
right
we've
been
planning
a
lot
of
big
things.
B
Yeah,
it's
a
very,
very
good
point.
Enrique
contextually
is
great
and
again
whenever
I
bring
up
anything
like
this,
this
is
never
in
any
aspect
of
blame
or
we're
not
doing
things
right.
This
is
always
just
a
check
in
with
us
to
make
sure
that
people
are
happy
with
the
process.
It
makes
sense
for
them
because
we
deliver
a
lot
of
kick-ass
work.
So
I'm
not
worried
about
that.
A
Well,
I
think
I
think
it's
you
know
I
I
think
the
process
can
can
be
improved
and
yeah.
It's
not
in
a
matter
of
blame
but,
like
I
know
it's
going
to
affect
the
quality
attributes
of
our
organization,
so
much
to
where
different
people
can
hop
in
and
out
of
the
issues.
The
plan
is
clear,
like
I
would
like
to
propose
that
we
start
seriously
considering
adopting
the
terminology
of.
A
That's
one
huge
step
and
that's
a
spike
of.
Is
this
architecture
gonna
work
and
then
what
could
be
another
spike?
And
maybe
it's
not
even
a
spike?
And
it's
just
okay.
Now
we
gotta
do
this
now
we
gotta
plan
it
and
let's
do
the
iteration
plan
and
like
so.
I
would
really
like
for
us
to
maybe
adopt
that
terminology
of.
A
We
need
to
do
this
architecture,
validation.
We
have
an
architecture
plan
and
the
iteration
plan,
and
if
we
don't
have
like,
if
we
don't
right
now,
we
don't
have
a
solid
artifact,
for
this
is
the
architecture
plan
for
the
vs
code
spy.
So
that's
something
on
me
that
needs
to
be
an
artifact
that
we
need
to
create
we're
doing
a
lot
of
requirements,
validation
there
and
I
kind
of
have
steps
I
need
to
do.
A
I
could
probably
create
smaller
issues
to
help
me
complete
that
final
artifact,
so
that
it's
just
not
all
in
my
head
of
like
oh,
I
know
I
need
to
do
these
things
like
and
it's
it's
a
tough
problem
because
it's
very
ambiguous
and
but
I
do
feel
like
there's
a
lot
to
gain
when
we
can't
break
it
out
and
just-
and
I
think
we
can-
and
so
I
wanna
I'm
encouraged
to
do
that.
I
want
to.
D
I
like
that,
a
lot.
I
also
think
that
it
helps
spread
the
workload
so
if,
for
example,
we're
coming
up
on
vs
code
and
I've
asked
you
and
david
to
prepare
for
appsec,
review
and
stuff
like
that,
if
there's
an
artifact
there
that
needs
to
be
created,
that
david
can
help
you
with
he
can
assign
himself
to
that
issue
or
some
or
someone
else
on
the
team
could
pick
up
for
you.
D
E
I
think
that's
a
really
good
point
like
there's
the
things
like
yagni,
you,
ain't
gonna,
need
it
and
you
don't
optimize
for
performance
upfront,
but
the
nuance
to
that
is
like.
If
you
know
you
are
going
to
have
to
reach
a
certain
scale
like
you,
don't
do
things
that
are
obviously
stupid
or
that
they're
obviously
going
to
break,
or
that
are
one-way
doors
that
are
going
to
be
really
hard
to
change
later.
So
it's
you,
don't
do
a
big
design
up
front,
but
you
also
don't
do
dumb
things.
A
Yeah,
and
on
that
quote,
don't
you
don't
do
big
design
up
front?
I
think
this
is
where
design
and
architecture
separate,
because
it's
like
architecture
is
you
want
to
do
the
big
architecture
up
front
like?
Is
this
going
to
work
at
scale
and
there's
ways
to
to
do
that,
but
not
not
at
a
more
granular
design
level
and.
A
A
A
B
B
B
So
I'm
trying
to
set
us
up
for
success
as
we
move
into
creating
our
iteration
plans
and
see
if
there's
anything
anybody
would
like
or
if
there
are
approaches
to
it,
that
people
feel
are
better
than
others,
but
that's
a
good
point
to
keep
in
mind
and
that's
something
that
I
do
communicate.
We
do
a
lot
of
research
in
the
last
couple
of
months
is.
A
A
B
B
That's
an
interesting
one
to
watch.
I
currently
don't
I'll
link
the
link
card,
metrics
dashboard,
which
is
where
I
take
most
of
our
metrics
from
I
currently
don't
have
anything
like
that,
but
I
could
definitely
create
a
panel
for
long-lived
issues
that
relate
to
being
architecture,
plans
or
spikes.
It
shouldn't
be
hard
to
add
in
something.
A
A
H
D
Yeah,
so
just
to
summarize,
the
the
investigation
was
prompted
by
just
a
hope
that
there
would
be
a
lightweight
solution
to
get
this
in
the
web
editors
and
offer
an
alternative
solution
for
people
who
might
be
looking
for
a
visual
markdown
editor
and
no
can
no
longer
find
one
in
the
product.
It's
become
clear
that
it's
more
complex
than
that,
so
it's
not
a
blocker
to
remove
the
static
site
editor.
D
We
got
approval
and,
frankly,
it's
not
impacting
enough
people
to
hold
up
our
other
work
and
the
way
I
see
it,
swarming
on
the
preservation
of
unchanged
markdown
is
the
first
step
towards
getting
to
the
point
where
we
can
offer
this
experience,
which
will
benefit
far
more
people
than
the
static
site
ever
static
site.
Editor
ever
did,
but
we
need
to
do
it
right.
I
don't
want
to
hack
something
together
and
have
a
bunch
of
like
lost
data,
because
we
we
aren't
preserving
cram
down
syntax
or
something
like
that
right.
D
H
E
D
Well,
get
off
this
call
and
start
I'm
just
kidding.
This
is
yeah.
So
again,
it's
not
a
blocker.
It's
a
nice
to
have.
We
will
we
will
push
in
this
direction
as
soon
as
we're
ready,
I
can
see
by
the
end
of
the
year.
I
would
love
to
have
content
editor
loading
in
the
web,
ide
web
editor
and
in
issues
and
to
get
there
first
thing
we
need
to
do
is
figure
out
how
to
preserve
the
unchanged
markdown.
So
we
don't
end
up
with
those
noise
emrs
and
a
bunch
of
deleted
content.
H
A
No
eric
eric,
already
kind
of
answered
it
I
was
just
wondering
like.
Is
it
worth
creating
a
feature,
flagged
version
just
for
these
100-ish
users
to
opt
into,
but
it
sounds
like
we
wouldn't
even
it
sounds
like
there's
blocking
issues
even
supporting
what
what
they
would
currently
use.
So
it's
not
a
big
deal.
H
H
However,
I
want
I'd
like
to
know
like
we
are
getting
these
two,
how
those
vs
codes
align
with
our
vision
in
terms
of
delivering
a
source,
editing
experience
in
the
product.
What
do
we
want?
What
new
right?
I
think
this
is
very
important,
like
mainly
what
new
user
experiences
do
we
want
to
enable
once
we
have
like
vs
code
integrating
into
a
product.
I
know
this
is
like
question
probably
for
for
another
meeting
a
home
meeting,
but
if
we
have
a
rough
idea,
it
would
be
amazing.
D
It's
a
great
idea,
david,
and
I
have
been
talking
about
this
a
lot.
This
is
probably
the
thing.
That's
been
the
top
of
mind
for
me
as
I've
evaluated
the
opportunity
and
what
it
means
for
a
long
term
strategy.
I
wish
I
had
a
better
answer.
I
think
we
need
to
learn
a
little
more
before
I
can
say
for
sure.
There's
clarity,
but
there
in
my
mind,
will
always
be
a
need
for
source
editing
inside
gitlab.
D
We
should
consider
the
vs
code
ide,
the
web
ide
running
vs
code
as
a
separate
editing
experience.
It
is
a
more
fully
featured
end-to-end
integrated
development
environment
that
doesn't
mean
that
we
won't
need
the
source
editor
or
something
similar
to
work
consistently
across
gitlab
and
it.
What
it
will
probably
do
is
shift
our
focus
for
that
over
the
next
year
or
two
to
offer
more
tailored
solutions
like
lightweight
multi-file,
editing
like
the
in-context
editing.
We
talk
about
in
snippets,
where
you
kind
of
just
toggle
between
without
switching
views.
D
Those
all
need
to
be
validated,
though
those
are
just
my
assumptions
and
anecdotal
experiences
that
I've
heard
from
people
there's
another
option
that
we
can
go
down
and
whether
or
not
we
can
strip
away
the
core
of
vs
code
and
use
it
like.
We
use
the
source
editor
elsewhere
in
the
gitlab
experience
for
consistency.
I
just
don't
know.
If
that's
going
to
be
possible,
we
can
talk
about
that
more
in
a
longer
meeting
and
when
paul
is.
D
Had
time
to
research,
that,
and
generally
though,
the
other
thing
we
want
to
look
at
is
once
we
have
vs
code
in
an
extensible
web
ide.
What
experiences
should
we
inject
into
that
web
id
outside
of
our
vs
code
extension
that
our
workflow
extension
that
already
exists?
Do
we
invest
in,
for
example,
I
was
spitballing
with
david.
Should
we
encourage
the
pipeline
editor
team
to
build
an
extension
that
runs
both
in
desktop
and
web
and
moves
out
of
the
gitlab
ui
and
does
even
more
validation?
D
Should
we
try
and
build
more
partnerships
and
alliances
with
things
that
would
offer
like
more
code
completion
or
ai
and
ml
like
it?
It
offers
us
the
opportunity
to
enhance
those
user
experiences
down
the
road,
especially
when,
and
if
we
have
some
kind
of
server
runtime
available
and
we
can
actually
compile
code
until
then,
it
might
be
more
like
you
know,
looking
at
the
output
of
a
security
scan
or
something
like
that
in
the
ide,
even
though
it
becomes
stale
as
soon
as
you
edit,
it
could
be
valuable.
D
A
A
D
B
E
E
E
It's
a
lot
cleaner.
It's
set
up
to
plug
in
new
capture
implementations
as
well,
which
is
one
of
the
big
things
they
have
going
forward,
and
I
thought
I
was
done
and
I
went
to
write
the
dots
and
I'm
like
wait.
There's
the
whole
rest
api
thing.
It
is
like
this
odd
person
out:
that's
not
matching
the
others
and
still
has
technical
debt.
It
makes
sense
for
me
to
to
finish
that,
which
I'm
hoping
isn't
that
hard.
All
of
the
dots
are
written
basically
except
the
rest
api.
E
The
developer
dots
and
I
realized
I
was
like
oh
like
this
thing-
is
completely
different
than
the
other
stuff
and
doesn't
make
sense
to
even
document
that
way.
It
needs
to
be
like
everything
else,
so
that's
the
plan
and
then,
at
that
point,
there's
out
of
the
last
security
allocation.
Like
a
year
and
a
half
ago
I
got
assigned
to
like
add
capture
to
notes
randomly
because
I
was
the
capture
person
at
that
time.
Luckily,
now
it's
the
access
team.
E
E
I
I
I
E
A
B
E
A
Okay,
I
paint
you
on
this
apollo
3
upgrade
mr
chad
to
because
I
think
this
may
be
a
feature
we
haven't
quite
verified
because
we
were
doing
we're
upgrading
all
of
apollo
and
this
was
implemented
using
like
apollo
middleware
stuff.
So
we
just
want
to
confirm.
This
is
all
still
works,
so
if
you
think
you
could
test
it,
that'd
be
great
or
if
there's
instructions
on
how
someone
else
can
test
it.
I
can.
D
We
made
it
through
that
was
quite
an
agenda
thanks
everyone
for
your
thoughts,
it's
good
to
have
pretty
much
the
whole
team.
Well,
I
guess
this
is
the
whole
team,
because
simon
she's,
unfortunately
leaving
us
next
week,
so
yeah,
it's
great
to
have
everybody
back
and
two
new
members.
So
we'll
see
you
next
week,
hopefully
just.