►
From YouTube: 2021-06-22 Create:Code Review Weekly UX Sync
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
Yeah,
let's
go
all
right
so
today
I
was
actually
tangently
discussing
this
with
kai
and
I
thought
it
would
be
good
to
get
this
conversation.
I
think
it's
not
get.
A
This
conversation
started
but
check
in
on
this
topic,
because
we
need
to
keep
talking
about
this
and
now
especially
so
I
don't
know
if
this
was
already
announced
in
you
know
not
in
the
code
review
channel,
but
it
was
just
announced
in
the
ulx
call
so
annabelle
she
will
be
moving
as
a
product
designer
from
I
don't
remember
it
from
the
secure
stage
to
the
code
review
group
permanently,
so
we're
going
to
have
two
designers
permanently
in
the
code
review
group
me
and
annabelle.
A
Yes,
but
but
if,
if
it,
if
it
helps,
I
will
be
less
involved
in
the
detailed
work,
so
yeah
more
giving
feedback,
but
I
don't
think
it
will
be
more
issue.
Work
or
merge,
requests
work
for
for
you
necessarily
anyway.
This
is
going
to
be
good.
She
will.
I
should
have
actually
written
that
in
the
agenda.
Let
me
write
that
so
annabelle
will
join
us
permanently
as
product
designer
from
14
3
onwards.
A
A
A
But
of
course
it's
just
an
input.
There
are
other
inputs,
and
but
nonetheless,
this
has
allowed
us
to
focus
the
group
in
the
short
term
for
the
performance
work
and
everyone's
really
focused
on
that
not
only
from
an
engineering
perspective
but
also
the
ux
perspective.
I'm
working
with
anne
our
ux
researcher
to
help
us
measure
the
mr's
perceived
performance
and
just
get
more
information
about
performance
in
general,
from
a
user
experience
standpoint
and
get
that
organized
so
that
we
can
make
better
decisions
so,
but
performance
right
now
is
a
big
topic,
but
going
forward.
A
We
have
to
think
about
the
other
priorities
and
how
we're
going
to
line
them
all
up
but
yeah
before
I
proceeded
for
forward
about
the
first
thing
that
I
talked
about
and
adult
joining
us
permanently.
Any
questions
at
the
moment.
A
I'll
hold
my
comments
till
the
end,
because
they're
they're
they're
on
a
tangent,
okay,
okay,
feel
free
to
write
them
down
and
yeah
kai
any
questions
or
thoughts.
B
I'm
excited,
I
think
we
had
reasonably
good
success
with
two
for
the
last
few
months,
and
so
I'm
excited
that
we're
I'm
gonna
get
to
continue
that
in
the
group.
I
think
this
is
a
group
that
demands
more
focus,
and
so
I'm
glad
that's
being
recognized
and
we're
getting
it.
So
I'm
happy
yeah
we're
also
getting
annabelle,
which
is
like
pretty
crazy,
because
she
is
also
one
of
like
the
original
gitlab
designer
who
has
been
here
for
approaching
five
years
and
so
yeah.
A
A
She
was
originally
a
front-end
engineer
at
gitlab
and
she
transitioned
to
a
designer
and
when
she
did
that
we
so
I
I
when
we
were
first
assigned
to
stages
at
gitlab
designers
in
the
beginning
it
was
when
god
created
earth.
A
Everything
was
crazy
and
designers
ran
everywhere,
chaotically,
but
then
we
were
assigned
to
stages,
and
when
that
happened,
I
was
assigned
to
the
planned
stage
and
annabelle
when
she
transitioned
from
front-end
to
design.
She
came
to
work
with
me,
so
me
and
annabelle
were
actually
the
first
two
designers
for
plan,
and
then
we
went
our
ways
knee
to
code
review
and
then
eventually
she
went
to
secure
and
now
we're
back
together.
A
And
so
she
has
this
amazing
quality
that
she
is
able
to
empathize
with
from
the
engineering
side
very
well,
because
she
used
to
be
an
engineer
at
gitlab
and
use
code
review
for
that.
So
that's
it's
amazing
and
she's
very,
very
excited
about
that,
and
we
were
all
jumping
up
and
down
in
the
ux
colleges.
Now.
A
With
the
work
that
we're
doing
now
for
performance
during
this
quarter,
which
I
assume
that
it
will
not
end
in
this
quarter
and
we
will
keep
pushing
for
it
nonetheless,
but
it
I
don't
it's
a
very
ambitious
goal
that
we
have
for
this
quarter
with
the
okr.
A
B
I
have
phrased
in
this
way.
The
way
I
have
typically
tried
to
run
product
groups
at
gitlab
is,
I
think,
it's
important.
I
think
it's
important
for
the
product.
I
think
it's
important
for
the
people
that
work
in
the
group.
I
think
it's
important
for
product
managers
and
designers
that
there
is
always.
B
Some
feature
work
happening
because
I
think
it's
and
it's
a
balancing
act
and
what
I've
tried
to
do,
and
I
think,
if
you
look
at
like
our
planning
over
the
last
several
milestones,
it's
been
close,
but
we
try
and
keep
like
one
to
two
like
direction
driving
feature
issues
in
because
I
think
it
it
signals
sort
of
like
where
we're
going
and
what
we're
doing.
B
B
We
have
so
many
tech
and
ux
debt
and
we
have
bugs
and
we
have
performance-
and
we
have
polish
and
there's
a
lot
of
that,
and
we
only
have
you
know
a
finite
amount
of
capacity,
and
so
I'd
like
to
keep
doing
things
that
way.
But
I
recognize
that,
like.
I
think
this
milestone,
there's
not
a
single
feature.
I
don't
even
think
the
last
milestone
had
like
a
single
feature
issue
in
it.
B
Outside
of
like
some
design,
things
that
we
were
talking
about,
and
so
I
think
there's
times
where
we
can't
do
that,
but
I
would
like
to
keep
moving
on
some
of
it,
but
recognizing
that
these
other
things
are
more
important.
I
guess
is
maybe
how
I
think
about
that.
A
Yeah
yeah,
I
understand,
do
we
have
an
idea
yeah
and
that-
and
I
think
it
also
helps
keep
the
team's
morale
and
that
people
are
not
just
working
and
polishing
things
that
were
already
there,
that
they're
also
making
shiny
new
things
that
maybe
in
the
beginning,
they're
not
that
shiny,
but
they
look
shiny
because
they're
new
yeah.
I
understand
that.
A
Do
we
have
an
idea
of
how
to
best
prioritize
those
new
features
and
the
reason
I
ask
this
is
when
we
look
at
the
results
from
those
internal
and
external
surveys
that
again
they're
just
their
inputs
from
what
we
would
like
to
think
a
representative
audience
of
users
but
they're,
not
necessarily
the
people
that
will
buy
gitlab
or
upgrade
because
of
certain
features,
and
one
thing
that
we
thought
was
very
important
for
our
users
was
to
build
more
features
around
reviewers
and,
for
example,
at
the
bottom
bottom.
Three
problems.
A
We
have
finding
appropriate
reviewers
for
an
mr
and
there
are
a
couple
of
other
problems
that
we
thought
were
ranked
higher
and
they
don't
and
again.
This
is
just
an
input.
So
what
I'm?
Thinking
here
here
is,
would
it
be
possible
for
us
to.
A
A
So
let
me
rephrase
that
we
also
have
the
most
popular
issues
like
there
are.
A
lot
of
new
feature
work
that
people
are
upvoting
and
we
want
this,
and
this
is
annoying,
and
this
is
breaking
our
workflows
and
we
would
like
to
have
this,
so
we
can
transition
to
gitlab
and
so
on
and
so
on,
and
then
we
also
have
customer
requests
or
prospective
customer
requests.
A
B
So
that's
that's
why
you
and
I
exist,
is
to
like
use
our
guts
and
make
some
decisions.
That's
why
I
have
a
job.
I
suppose
I
think
the
other
piece
is
like.
Sometimes
people
don't
maybe
like
we
could
call
this
like
the
steve
jobs
effect
or
the
apple
effect
right,
like
sometimes
people
don't
know
what
they
they
need
or
what
they
don't
have,
and
we
we're
trying
to
think
ahead
or
we're
thinking
through
problems
differently
than
like
what
people
explicitly
state,
and
we
do
that.
B
A
lot
right
like
people
say
that,
like
it's
interesting
that,
like
I
mean
we
could
debate
this
forever
but
like
finding
appropriate
reviewers
for
an
mr,
was
really
low
like
across
the
board
internally
and
externally,
and
yet
we
get
into
these
conversations
or
I
hear
from
customers
all
the
time
like.
B
Well,
how
do
I
know
who's
like
supposed
to
approve
this
right
like
and
they
they
don't
say
like
who's
supposed
to
review
it?
They
say
like
who's,
going
to
approve
this
or
like
who
can
merge
this
or
like
you
hear
these
like
phrased
differently,
and
so
I
think
people
maybe
don't
relate
concepts.
The
same
way
that
we
sort
of
think
about
them-
and
so
I
think
I
I
hesitate
to
say
this
like
this-
is
like
a
terrible
term
but
like
taste
maker
sort
of
right
is
what
that
is.
B
We
need
to
make
sure
that
we're
putting
enough
new
things
into
their
product
in
sort
of
like
different
areas,
to
get
the
feedback
that
we
think
we're
missing
like
adding
the
checkbox
we
talked
about
this
this
morning,
like
adding
the
view
checkbox
like
opened
up
all
these
sort
of,
like
other
things,
that
people
wanted
and
needed,
and
it
was
sort
of
like
a
can
of
worms
but
like
we
wouldn't
have
known
like
those
sort
of
next
things.
B
Unless
we
did
the
first
one
and
we
can
now
look
at
that
and
go
yeah,
I
mean
that's
nice,
but
maybe
we
don't
need
to
go.
Do
all
those
things
they're
like
we
can
be
tolerant
to
sort
of
the
state
of
where
it
is
because
it's
not
broken
it.
Just
maybe
there's
some
other
things,
and
so
part
of
this,
and
what
I
like
about
gitlab
is
sort
of
doing
those
little
things,
because
we
do
get
that
feedback
right.
That
is
the
important
pieces
of
iteration.
B
I
don't
know
if
that
answers
like
how
do
we
best
prioritize
this,
but
I
think
to
me
it's
making
sure
that
we're
exploring
enough
areas
that
we're
giving
we're
enabling
ourselves
to
get
feedback
and
then
in
areas
where
we
have,
I
think,
a
good,
a
good
gut
feel
or
a
good
understanding
like.
We
need
to
make
sure
that
we're
pushing
sort
of
like
our
entire
vision
through
on
those-
and
I
think
like
reviewers,
is
a
good
example.
B
I
think
we
there
was
a
strong
opinion.
You
know
prior
to
me
getting
here
that,
like
reviewers
needed
to
be
like
a
separate
thing
on
the
sidebar-
and
I
think
that's
I
agree
with
that
and
I
think
that's
good.
The
the
next
step
was
like
finding
appropriate
reviewers
and
we
were
going
to
spend
more
time
on
sort
of
making
making
that
list
smarter
right.
We
we
talked
about
adding
like
information
about
free
busy
when
that
got
added
by
manage.
B
We
talked
about
adding,
subject,
matter,
expertise
and
like
how
could
we
bring
more
data
in
to
to
make
that
list
better,
but
we
didn't
do
that.
We
sort
of
like
got
it
to
a
point
where
we
could
wait
and
get
feedback
and
it
seems
like
people,
don't
necessarily
want
that
yet,
and
so
I
think,
there's
I
don't
know,
I
think
we've
got
a.
B
This
is
also
like-
I
don't
want
to
say
this
either
but
like
put
a
bunch
of
like
paint
on
the
canvas
or
like
throw
things
at
the
wall
and
see
what
sticks
and
what
doesn't
stick
in
an
area
that
is,
is
so
big
and
has
so
much
opportunity
right
like
there's
so
many
things
we
could
do.
B
I
don't
know
that
we'll
ever
have
like
a
great
signal
on
the
most
important
thing
to
do,
given
the
way
that
we
deal
with
telemetry
and
other
other
usage
data
like
we're,
we're
so
reliant
on
qualitative
feedback
from
users
because
of
our
telemetry
situation.
That,
like
I
think
it
gives
it's
a
blessing
and
a
curse.
It
gives
us
a
lot
more
freedom
to
dig
into
things
that
we
think
are
interesting
or
important
and
also
means
we'll
we'll
miss.
Sometimes
when
we
won't
solve
the
right
problems,
and
I
think
that's
okay,
too,.
A
A
I
think
we've
we,
I
think,
we've
been
doing
that
for
too
long,
so
the
throwing
at
the
wall
and
seeing
what
sticks
and
the.
A
I,
what
I've
seen
is
we
in,
for
example,
in
one
milestone.
Let's
imagine
throw
like
three
things
at
the
wall
and
now
what
if
the
three
of
them
stick
right
and
that's
what
I've
seen
is
that
sometimes
you
actually
deliver
things
that
different
people
want,
and
now
you
have
self-assigned
yourself,
more
maintenance
and
more
enhancement
work
on
those
things,
but
yet
you
were
only
trying
to
see
if
it
stuck
and
it
did.
But
now
you
you're,
it's
like
you
signed
a
contract,
and
now
you
have
to
follow
through
with
it
talking
about.
A
Yeah,
that's
that's
a
great
example.
Actually,
that's
that's
a
great
example
like
we
just
saw
if
it
worked
and
it
it
kind
of
did
and
that's
what
people
wanted,
but
we
keep
doing
that
multiple
times
and
I
think
we
talked
about
that
being
iteration
and
in
a
way
it
is,
but
I
think
we
end
up
iterating
in
too
many
directions
at
the
same
time,
while
also
not
foreseeing
what
the
next
iterations
could
be.
A
So
when
we
release
an
iteration
we're
like
well,
let's,
let's
wait
for
feedback,
let's
not
do
anything,
and
then
we
get
feedback,
but
we're
already
planning
these
other
things.
And
now
we
have
to
scramble
to
change
our
prioritization
and
scramble
to
find
a
design
and
scramble
to
find
a
technical
solution
for
something
that
we
didn't
foresee
and
now
we're
stuck
in
this
iteration
loop.
A
Would
it
be
crazy
if
the
wafers
iterate
in
this
very
large
group
that
has
a
very
large
scope
and
can
do
so?
Many
amazing
things
would
be
just
to
pick
one
or
two
problem
spaces
and
research
them
figure
out
what
would
be
some
reasonable
iterations
and
go
after
those
iterations
and
learn
in
the
middle
of
those
iterations,
but
always
within
that
problem
space.
Everything
outside
of
that
problem
space
we
would
not
pursue
until
we
have
had
some
confidence
that
this
problem
space
is.
A
A
We
have
that
problem
that
people
keep
talking
about
with
the
squatch
commits,
and
we
created
that
you
or
you
created
that
issue
kind
of
configuring,
the
default
behavior
the
squash
commit
message,
and
now
we
have
a
merge
request
from
the
community
contributor
to
create
templates
for
the
merge,
commit
message,
and
then
we
also
have
the
default
target
branch,
and
some
milestones
ago,
we
shipped
a
setting
that
allows
you
to
deny
encourage
or
require
squashing
on
every
on
every
merge
request
and
all
of
these
things
to
me,
they
all
belong
to
the
same
problem
space
we,
but
we
didn't
do
any
exploration.
A
We
didn't
do
any
research
on
the
problem
space
and
we
didn't
define
a
vision
for
that.
That
would
also
allow
engineers
to
feel
excited
and
to
plan
how
technically
we
would
do
it.
B
You
know
that's
one
of
the
things
I
guess
like
I
don't
know,
I'm
going
to
keep
talking
about
reviewers,
because
it's
really
the
only
thing.
We've
I've
even
remotely
sort
of
shipped
as
a
feature
here
but
like
joined
a
group
and
picked
up
someone
else's
teacher
and
then
like
did
other
work
but
we'll
just
we'll
use
it
anyway.
So
like,
if
you
think
about
reviewers
like
one
of
the
things
that
like
I
did
was.
B
I
took
the
epic
and
the
epic
had
like
all
these
other
epics
inside
of
it
and
somethings,
and
I
was
sort
of
like
well,
let's
like
figure
out
where
we're
drawing
the
line
and
like
closing
the
epic
and
to
me
like
I
prefer,
to
keep
those
epic
epics
sort
of
finite
and
scope
and
much
more
problem
focused
to
like
get
get
to
the
closing
of
the
epic
like
we
still
haven't
closed.
Actually,
I
don't
think
I've
closed
the
reviewers
epic.
I
need
to
go
look
and
it
might
be.
B
I
haven't
closed,
like
the
top
level
one.
I
think
I
closed
like
the
sub
one
after
I
moved
everything
around
but
like
to
me.
That's
really
important,
and
I
think
this
group
has
historically
not
done
a
good
job
of
that,
which
is
why
I
think
we
potentially
feel
that,
like
we
put
things
that
stick
but
like
I
don't
I
have,
I
guess
I
think
about
this
in
terms
of
like
multiple
simultaneous
work
streams
and
I'm
ok,
I
am
more
tolerant
of
that
in
terms
of
like
features
like
I
prefer
us
to
have.
B
What
I
don't
like
about
sort
of
what
you
were
saying
is
like
let's
go
deep
into
a
couple
areas,
because
I
think
just
going
deep,
based
on
the
way
that
I
have
seen
this
group
operate
and
what
I
know
about
sort
of
like
how
development
works
inside
of
gitlab.
B
It
scares
me
to
go
incredibly
deep
into
things
only
because
we
end
up
in
these
states
where
people
are
like
well,
let's
refactor
sort
of
all
of
this
first
and
like
not
do
anything
that
helps
us
like
move
the
ball
forward
on
on
the
vision
that
we
want
to
accomplish
right,
like
one
of
the
fears
of
like
the
merge
button
when
you
started
working
on
that
was
sort
of
like
well.
B
So
I
don't
know
I
guess
like
yeah,
throwing
things
at
the
wall
and
seeing
what
sticks
is
not
the
right
like
one
or
two
issues
worth
of
work
is
not
the
right
answer
like
there's
a
we
need
to
have
a
good
like
in
state
we
want
to
get
to
when
we
are,
I
think,
investing
more
time,
but
I
think
it's
also
okay
to
throw
like
an
occasional
thing
out,
and
otherwise
we
just
don't
get.
We
just
don't
get
any
feedback
on
it
right
like
the
way.
B
Our
and
our
telemetry,
as
a
not
data
driven
ever
product
manager,
it's
sort
of
frustrating
to
be
in
a
situation
where,
like
we
have
some
data,
but
we
don't
have
the
right
kinds
of
data
or
the
right
way
to
think
about
our
data
to
like
actually
make
a
ton
of
use
out
of
it.
It
sort
of
is
just
like
a
point
in
time,
amount
of
data
and
so
like
to
me.
B
It
just
makes
me
much
more
reliant
on
like
engaging
in
issues
and
seeing
what
people
are
saying
and
talking
to
customers
versus
like
trying
to,
and
the
only
way
you
get.
That
is,
if
there's
something
for
them
to
talk
about.
No
one
talks
about
the
things
that
don't
exist
and
so
you've
gotta
you've
gotta
at
least
have
something
for
them
to
like
get
their
head
going
in
the
in
the
space
of
the
thing
that
doesn't
even
exist.
Sometimes.
A
A
I
think
I
tend
to
agree,
but
when
you
know
the
ideal
and
states
and
ideals
is
a
balance
here,
I
think
it
would
be
easier
for
us
to
break
that
ideal
state
into
smaller
iterations
that
drive
us
toward
that
ideal,
and
maybe
the
refactor
is
needed
for
us
to
get
to
that
ideal.
Maybe
it
doesn't,
and
maybe
that's
something
that
we
can
push
back
on
engineering
to
do
and
related
to
your
second
point
about
learning,
and
maybe
we
just
want
to
throw
something
so
that
we
can
learn
if
people
actually
want
this.
A
I
think
that's
that
goes
back
to
knowing
the
ideal.
So
I
think
we
can
do
some
research.
We
can
do
some
design.
We
can
do
some
validation
that
we
can
then
say
hey.
This
is
what
we
think
if
we
wanted
to
go
all
in
on
the
problem.
This
is
what
would
adequately
solve
all
of
these
different
facets
of
the
problem,
but
we're
we
don't
want
to
go
all
in
on
it.
A
So
what
we're
going
to
do
is
we're
going
to
plan
how
we're
going
to
do
it
so,
for
example,
first
we're
just
going
to
throw
an
iteration
that
is
very
minimal
and
would
only
serve
for
us
to
get
data
on
usage
or
to
get
qualitative
feedback
from
users,
but
we've
planned
that
right
and
we
have
all
of
the
other
things
that
we
think
we
will
do
after
that.
But
we're
only
doing
this
very
first
step.
A
And
so
we're
only
doing
this
very
first
step,
but
we're
actually
planning
so
we're
going
to
pause.
This
feature
work
for,
let's
imagine
two
milestones.
Three
milestones
until
we
get
enough
feedback
and
what
we're
already
doing
is
we're
planning
for
two
scenarios:
either
one
we'll
have
to
rethink
the
next
iterations,
so
we're
already
blocking
some
time
three
milestones
from
now
to
rethink
that
work
or
if
nothing
new
or
surprising
happens,
we're
just
going
to
continue
what
we
have
already
planned.
A
But
this
is
plans
right
and-
and
this
is
I
think,
more
intentional
iteration
than
and
we're
more
intentional
about
what
we're
willing
to
learn
from
shipping,
something
and
trying
to
see
if
it
sticks
on
the
wall,
because
what
I
think
is
that
often
we
do
that.
Okay,
let's
see
if
it
sticks
and
and
then,
if
it
does,
we
don't
know
necessarily
what
to
do,
because
it's
so
half
baked
and
we
didn't
have
any
plan
for
what
to
do
next.
But
now
we
have
to
figure
out
how
to
shove
that
into
our
milestones.
B
I
think
we're
both
saying
the
same
thing
differently.
I
think
we
both
agree
that,
like
there
needs
to
be
a
start
and
a
stop
point
and
the
the
question
is
like
how
far
down
the
start
and
the
stop
point
are
I
don't.
I
think,
especially
in
this
group,
one
of
the
things
that
I
have
learned
and
that
you've
been
great
at
teaching.
B
Is
that,
like
it's
significantly
harder
to
get
away
with,
like
one
milestone's
worth
of
work
in
this
group
in
a
feature,
it
is
significantly
less
tolerated,
and
so
I
think
I
think
that's
good
and
I
think
like
we
need
to
know
yeah
like
we
need
to
know
the
next
several
milestones
worth
of
work
when
we
dive
into
an
area-
and
I
think,
like
with
the
waiting
for
stuff
or
whatever
we're
calling
it
now
request
attention.
B
We
should
like
we,
I
think
we
would
know
right
like
if
we
started
down
that
path.
B
If,
even
if
we
go
down
this
path-
and
I
think
like
that
to
me-
is
fine,
like
I'm,
okay
with
like
that,
I
think
the
the
struggle
in
this
group
is
one
being
willing
to
say
this
is
what
we
agree
to.
This
is
what
we're
shipping
and
we're
okay,
stopping
like
we
don't
need
to
keep
going
the
counter
to
that
is.
B
We
also
need
to
be
much
better
about
getting
back
to
things
than
we
are
like.
We
do
not
ever
get
back
to
things,
which
is
why,
like
when
you
look
at
the
code
review,
like
top
level
epic,
you
lose
your
mind
because
you're
like
there's,
400,
open
epics
in
like
this
group
alone,
one
of
them
is
epic,
one
which
I
get
tagged
on
frequently
where
people
are
like
did
you
know?
This
is
the
first
ever
epic
on
gitlab
like
what
are
you
doing.
B
But
so,
like,
I
think,
like
that's,
we
need
to
figure
out
how
we
get
back
to
those
things
or
be
better
about
saying,
like
we're.
Never
getting
back
to
those
things
or-
and
I
think
maybe
that's
the
other
piece
of
what
you
you
are
struggling
with
and
that
we
need
to
figure
out
how
to
address
is
like
how
do
we?
B
A
Yeah,
so
that's
what
you
were
just
saying
and
taking
the
example
of
the
waiting
for
or
request
attention.
We
are
already
aware
that
people
can
make
some
requests
of
certain
nature
after
we
ship
this
with
that
knowledge
and
knowing
that
people
can
possibly
ask
about
other
cases
or
even
say
that.
A
A
A
Quick
reaction
to
the
change
or
what
is
a
mature
response
over
time,
so
let's
say
we
wait,
two
milestones
but
we're
already
putting
in
the
third
milestone
after
we
ship
this
we're
already
thinking
about
allocating
some
time
to
working
on
designing
improvements
to
the
working
to
the
waiting
for
or
request
attention,
but
we're
not
sold
on
that.
Like
we're.
A
We
need
that
time
or
we
don't
need
it
and
we're
not
going
to
do
anything
so
we're
going
to
replace
that
time
block
with
something
else
that
we
want
to
do.
So
I
just
think
we
need
to
it's
a
little
bit
like
you
know,
I
I
have
a
task
in
my
personal
task
manager
that
happens
every
six
months
to
clean
my
dishwasher
and
put
like
a
special
product
in
there
to
clean
it,
and
but
I
know
that
once
I
complete
that
task,
it
will
repeat
again
after
six
months
after
I
complete
it.
A
So
it's
also
always
a
reminder.
I
need
to
do
things,
but
maybe
I
don't
know
six
months
from
now.
I
will
say
I
don't
need
to
do
it,
so
I
won't
do
it
anymore,
but
I
just
think
we
need
to
be
more
intentional
about
those
reminders
as
setting
time
aside
to
work
on
things,
because
we
have
given
enough
learning
room
for
us
to
learn
about
that
either
from
quantitative
or
qualitative
feedback.
A
But
to
do
this
properly
and
to
be
organized,
and
also
because
we're
not
a
very
big
group,
and
it's
only
it's
only
you
you're
you're
one
product
manager,
and
you
can
only
think
about
so
many
things
at
the
same
time,
and
also
all
of
us,
that's
why
I
don't
think
the
multiple
like
throwing
multiple
things
at
the
wall
works,
because
it
just
creates
a
mess
out
of
the
planning
and
then
trying
to
forecast
the
iterations
and
what
he
will
learn
and
that's
why
I'm
thinking
I'm
not
sold
on
the
idea.
A
But
it's
what?
If
we
just
focus
on
a
couple
of
things
per
milestone,
I
mean
it
will
depend,
of
course,
maybe
one
month
and
we
won't
do
feature
work.
Maybe
another
muscle.
We
will
do
two
initiatives
or
one
it
doesn't
matter,
but
just
work
on
very,
like
the
smallest
number
possible
and
be
very
conservative,
but
at
the
same
time
we're
actually
being
very
ambitious
on
what
problems
we're
solving.
B
B
So
we
have
to
figure
figure
that
piece
out,
and
I
say
that
because
like
when,
I
think
about
like
the
planning
issues
and
like
what
ends
up
on
the
board.
B
There's
usually
like
one
work
stream
happening
like
engineering
workstream,
but
there's
likely
two
or
three
work
streams
happening
for
like
you
and
I,
and
maybe
that's
like
the
distinction
that,
like
or
like
between
product
and
design
or
like
in
exploration
or
other
things
like
that,
like
maybe
that
is
sort
of
the
difference
like
I
don't
think
we
jump
around
a
ton
and
if
it
feels
like
we
are,
then
then
maybe
that's
like
the
difference
that
we
need
to
figure
out.
A
B
A
B
Yeah,
I
think
maybe
we
should
just
figure
that
out
like
and
maybe
like
it
would
help
maybe
to
get
clarity
on
that
like
if
you
go
through,
and
I
don't
know
if
you
really
want
to
do
this.
But
if
you
were
to
go
through
like
the
last
several
milestones
and
sort
of
like
like
highlight
those
cases
of
where
it
looks
like
we're
slipping
around
or
like
if
it
feels
like
we're,
jumping.
B
B
B
Yeah
from
like
an
engineering
perspective,
and
maybe
that's
yeah
from
an
engineering
perspective,
there's
no
feature
work
underway
and
I
think
the
last
feature
work
we
well.
This
is
complicated.
The
last
feature
work
we
or
the
areas
we've
been
in
for
future
work.
Most
recently
were
the
viewed
checkbox.
A
B
B
We
tried
to
continue
iterating
on
tracking
for
persisting
viewed
state,
we
sort
of
got
some
like
immediate
feedback,
but
we
did
not.
We
actually
haven't
done
anything
there.
Also.
All
we
did
was
like
the
mark
is
viewed,
and
then
we
didn't
do
anything
else
which
maybe
that's
like
one
of
those
where
we
should
have
kept
going.
B
A
A
Because
suddenly
we
were
faced
with
other
things
or
are
we
stopping
because
we
are
not
going
to
do
anything
or
are
we
stopping
because
we're
giving
this
breathing
time
to
figure
out
what
we
need
to
do
next
or
here's
some
breathing
time,
and
we
will
use
that
breathing
time
to
design
and
validate
future
iterations,
because
we
already
kind
of
know
where
this
is
headed.
So
I
think
that's
that's
what's
missing
and
I'm
actually,
I
I
think
it's.
This
is
a
great
time
to
have
this
conversation.
Because
of
what
you
said.
A
We
don't
have
any
featuring
work
in
engineering
right
now,
but
we're
this
is
rare
in
this
group.
So
this
is
a
rare
time
and
we
should
take
advantage
of
it
to
understand
what
we
want
to
work
on.
How
long
and
be
intentional
about
the
starting
and
stopping
moments
and
the
confidence
levels.
And
of
course
we
will
never
know
exactly
from
the
start,
and
we
will
learn
as
we
go
and
we
will
build
our
confidence
over
time
about
these
things.
But.
A
Yeah,
for
example
like
the
and
we
do,
I
don't
think
we
need
to
continue
and
end
this
discussion
and
to
get
to
a
a
decision.
I
think
this
discussion
is
good
in
of
itself
as
food
for
thought,
and
maybe
next
week
or
we'll
talk
about
this
more
but,
for
example
like
would
we
do
we
want
to,
for
example,
research,
the
single
file
mode
and
learn
more
about
that,
and
maybe
plan
for
and
understand,
if
like,
for
example,
auto
switching
automatically
to
single
file
mode
when
it's
a
large
merge
request.
A
Does
that
make
sense,
or
maybe
even
highlighting
the
single
file
mode
more
so
that
we
can
improve
people's
perception
of
performance
because
they're
only
loading
one
file.
The
first
file
includes
much
faster,
or
maybe
that's
not
the
feature
that
we
want
to
dedicate.
A
Maybe
we
want
to
dedicate
ourselves
more
to
the
require
my
attention,
or
maybe
we
want
to
look
at
the
merch
options.
What
I
was
saying
in
the
beginning,
like
the
squash,
commit
messages,
the
default
target
branch
setting
the
faults
for
that.
Like
there's
a
another
issue
that
I
saw
somewhere,
I
didn't
link
here
that
was
to
control
whether
users
could
delete
the
source
branch
at
all
like
right.
Now
we
have
enforcing
mechanisms
for
the
squash,
but
not
for
the
delete.
A
You
can
only
set
the
default,
but
someone
can
change
that
or
they
can
decide
not
to
delete
it
or
to
delete
it
and
I've
seen
an
issue
where
project
owners
want
to
decide
and
enforce
a
specific
setting.
So
maybe
we
need
to
look
at
that
problem,
space
of
enforcing
certain
practices
of
emerging,
so
yeah,
whatever
we
decide-
and
that
goes
back
to
my
first
point
about
how
do
we
balance
all
these
things?
And
where
do
we
get
these
signals?
A
Do
we
lean
more
towards
the
feedback
that
we
have
from
customers
and-
and
I
agree
with
what
he
said
in
the
beginning
of
like
the
customers
like
when
you
know,
I'm
always
using
this
method,
this
story,
but
when
ford
came
out
with
the
car,
people
wanted
faster
horses,
so
customers,
sometimes
they
will
not
know
what
they
want,
or
maybe
they
would
say.
A
I
want
this
feature,
but
they
want
something
else,
but
regardless
of
how
we
interpret
those
signals
and
that
feedback
are
we
leaning
more
towards
customers
or
towards
prospective
customers
that
want
to
migrate
to
the
github
or
want
to
upgrade
licenses,
and
so
we're
going
to
favor
those
or
maybe
we're
going
to
favor
our
own
practices
internally
and
and
the
features
that
gitlab
the
company
needs,
or
maybe
we're
just
going
all
in
on
the
popularity.
A
B
I
think
that's
fair
and
I
don't
have
an
answer
for
you,
so
I
think
that's
fair.
I
think
we
have
to
figure
out
how
to.
B
A
A
B
A
A
That
it
came
to
mind
as
requiring
more
ux
exploration,
but
anyway,
I
think
if
we
get
started
with
that
google
sheet
and
I
think
we
could
make
some
progress
yeah,
I
think
the
first
step
is
just
putting
everything
on
the
table.
Look
at
it
and
try
to
make
sense
of
it
or
just
recognize
that
we
can't
make
sense
of
it
yeah.
But
I
think
I
think
we
we
agree
on
these
things
that
we
were
talking
about
so
cool.
B
Okay
yeah:
well,
let's
I
will.
I
will
create
a
google
sheet
and
I
will
not
put
anything
into
it
and
then
we'll
I'll
just
do
it
now
at
least
we'll
have
one,
and
then
we
can
start
figuring
out
how
to
fill
that
out
and
go
from
there.
A
A
No,
I
was
just
looking
at
amy's
comment,
but
in
this
case
she's
not
here,
it
will
be
more
of
read
only.
B
A
Thanks
kai
have
a
good
day,
and
if
I
don't
see
you
before
that,
maybe
are
you
off
tomorrow
or
only
thursday.