►
From YouTube: 2020-12-09 Code Review 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
B
Yeah
yeah,
I
don't
know
fyi
about
my
my
holiday
pto.
Just
for
you
to
be
aware.
Yeah
I
have.
I
have
the
only
point
in
the
agenda
feel
free
to
add
more.
B
If
you
want-
and
it's
just
about,
I
actually
had
it
wasn't
meant
to
be,
but
I
had
the
last
two
calls
so
in
back
to
back
fashion-
and
we
were
just
talking
about
this
with
other
designers
as
well
about
how
we
can
have
more
predictability
about
what
we're
going
to
do
and
work
on
and
yeah
and
just
just
the
disclaimer
here
is
that
I
don't
think.
That's
that!
That's
I
don't
think
that's
a
burden
that
should
only
be
on
on
the
pm's
shoulder.
B
It
should
be
on
the
whole
team
to
accomplish
that,
but
just
in
general
how
we
can
do
that
more
because,
from
my
side,
I'll
tell
you
that
there's
yeah
designers
are
always
too
thin
across
many
different
things,
and
in
case
you
haven't
noticed
but
yeah.
It's
just
there's
a
big
burden
and
and
since
sensitive
expectation
from
from
everyone
that
the
issues
that
go
into
the
build
track
so
like,
for
example,
for
13
aids.
B
That,
in
theory,
all
of
them
should
be
as
scoped
out
and
as
detailed
as
possible
for
for
engineering
to
get
started
on
them
and
then
create
mrs,
and
do
all
of
that.
And
I
mean
this
is
a
generalization.
And
of
course,
some
issues
are
not
ready
when
the
milestone
starts,
and
we
end
up
discussing
some
things
and
change
between
the
milestone.
B
But
it
would
be,
but
but
that
again,
that
that
puts
a
lot
of
pressure
on
design
to
get
everything
right
and-
and
I
I
mean
at
the
end
also-
I
think
product
management's
to
make
sure
that
we're
focusing
the
efforts
on
the
right
things
and
that
we
have
everything
ready
for
engineering
yeah
and
I'm
just
wondering
how
we
can
work
more
ahead
and
yeah.
B
It
at
that,
and
just
for
your
comments
in
general.
What
what
do
you
think
are
some
tactics
that
we
can
apply
to
have
more
predictability.
A
Yeah,
I
think
the
big
one
is
focus
and
I
think
this
group
lacks,
I
don't
want
to
say
a
tremendous
amount,
but
a
tremendous
amount
of
focus.
I
think
there
are
yeah
competing
ideas
and.
A
A
Thirteen
7
has
what
else
did
I
just
go?
Write
release
post
for.
A
Let
me
just
look
13
7
has
custom,
commit
messages
for
suggested
changes,
and
it
has
reviewers
all
in
13,
7
there's
like
five
different
things
that
are
of
all
of
those,
I
would
say,
custom
messages
or
depth
like
they're,
the
one
probably
the
only
thing
in
there
that
is
depth
on
an
existing
feature.
Everything
else.
A
Like
a
first
iteration
on
a
on
a
new
thing-
and
I
would
I
would
argue
that,
like
from
an
outsider
looking
in
and
and
this
is,
this
is
new
perspective
under
the
group,
but
none
of
them
are
related
like
none
of
these
things
are
related
to
each
other.
A
Yet
we
can
probably
build
and
get
there,
but
like
the
theme
of
them
is
not
is
not
tied
together
enough
to
know
that,
like
we're,
building
reviewers
and
we
built
this
file
change
thing
or
the
mark
is
viewed,
and
you
know
I
could
make
some
logical
leaps
that
say
well.
What
we
could
now
do
is
show
a
list
of
reviewers
and
actually
which
files
they've
reviewed,
because
we
have
the
data
that
they
were
a
reviewer
and
we
have
the
data
of
the
file.
They
were
there,
but,
like
I,
I
I'm
willing
to
bet.
A
Thought
was
actually
about
like
finding
a
reviewer
who's,
the
right
reviewer
who
can
approve
it,
and
how
do
we
select
that
right
person
versus
what
do
we
do
with
a
reviewer
in
terms
of
communicating
status
to
other
things,
and
so
there's
a
long-winded
way
of
saying
that
what
we
need
to
do
is
focus
what
we're
gonna
go,
do
and
go,
and
and
to
me
it
is
much
more
efficient
to
build
deep
down
into
something
because
you,
you
can
start
thinking
through
those
next
things.
A
How
do
we
communicate
status
better
of
where
the
review
is
right
like
how
do
we?
How
do
we
deal
with
that
problem?
Space
versus
like
how
do
we
deal
with
the
problem
space
of
reviewers
and
which
things
they
can
approve
and
sort
of
all
of
that?
Or
how
do
we
deal
with
tracking
files?
And
all
of
that
like
if
you've
got
a
very
good
connected
theme,
then
you
can
you
can
focus
your
research
and
focus
the
designs
and
focus
everything
that
we're
thinking
about,
to
go
and
and
lay
those
issues
out.
A
So
to
me,
it's
focus
what
I
linked
you
to
was
the
mr,
where
I'm
rewriting
the
direction
right
now,
I'm
framing
reframing
the
way
we
think
about
what
we
want
to
accomplish
in
code
review,
so
that
we
can
use
that
to
go
and
form
the
things
that
we
do,
and
so
I
would
say
that
is.
That
is
my
answers
to
that
question
it
has
been.
A
It
was
my
experience,
an
editor
that,
when
we
had
ethics
that
were
were
better
scoped
and
the
work
the
legwork
from
product
and
design
have
been
put
into
them
to
like
build
out
where
we
wanted
to
go
multiple
iterations
ahead,
that
you
could
get
sort
of
more
efficiently
moved
and
there
weren't
questions
there.
A
Weren't
like
day
of
implementation,
questions
there's
an
added
thing
that
I'm
hoping
happens
is
that
one
of
the
things
I
have
noticed
with
this
group
so
far
is
that
it
doesn't
appear
that
engineers
feel
a
sense
of
ownership
over
the
things
we're
shipping
and
so
the
more
that
we
can
get
epics
built
out
that
dictate
a
vision
with
good
design
and
well
articulated
problems
and
other
things
the
easier
it
is
to.
Let
engineers
pick
up
those
epics
and
sort
of
start
figuring
out.
A
What
the
implementation
path
is
to
do
that
and
owning
the
completion
and
seeing
through
something
versus
adding
things
at
the
last
minute
or
sort
of
changing
scope
or
discussions
happening
too
late
in
the
process,
and
so
that
is
sort
of
the
other
thing
that
I
want
to
drive
with
that,
and
I
think
all
of
that
gets
us
ahead.
But
that's
two
or
three
months
of
us
trying
to
get
to
a
state
where
we
can
talk
like
that.
B
Yeah
yeah,
of
course,
yeah
yeah.
It's
not
going
to
be
just
changing
the
light
bulb
and
it's
working
yeah.
So
I
think
taking
this
last
part
what
you
were
saying
about:
epics
yeah,
that's
really
what
I
would
love
is
to
have
engineering
more
involved
early
on,
and
I
mean
we
have
andrei
and
michelle
and
they
they
do
a
great
job.
B
But,
as
you
said,
then
the
engineers
themselves,
the
people
that
are
building
things,
aren't
don't
feel
ownership
and
don't
have
the
visibility
and
and
we've
so
many
times.
We've
we've
heard
that,
like
I
don't
feel
the
ownership
and
and
if
I
knew
that,
maybe
we
would
be
doing
it
this
way.
Perhaps
I
would
have
implemented
it
differently
or
I
would
have
talked
with
that
person
or
whatever
it
is,
and
I
I
really
don't
like
our
model
of
assigning
things
to
people
when
the
milestone
is
about
to
start
and
then
okay
either
here
it
is.
B
This
is
what
you
have
to
do.
Go
do
it
yeah.
I
would
prefer
if
they
were
more
involved
before
and
felt
not.
I
don't
think
I
think
people
are
interested
but
just
say
that.
Okay,
it's
okay
for
you
to
be
curious
and
interested
and
involved
in
the
these
issues,
we're
not
going
to
measure
your
output
in
that
regard
like
we're
not
because
right
now,
it's
just
about
mrs
that
are
merged,
and
so,
if
you
take
your
eyes
out
of
the
merger
requests
you're,
not
shipping!
B
That's,
I
think,
is
what
engineers
are
thinking
about,
so
every
single
minute
that
they
spend
in
an
epic
looking
at
something
that
we're
still
in
pasta
mode
and
discussing
the
spaghetti.
If
it's
going
to
have
chili
sauce
or
it's
going
to
be
carbonara,
it's
there
they're
wasting
time
in
emerge,
requests
right.
B
I
love
pasta
by
the
way
and
yeah.
I
would
love
to
see
engineers
more
involved
that,
and
so
I
think
perhaps
what
you
were
saying
about
the
epics
is
maybe
having
the
planning,
breakdown
and
breaking
things
down
at
the
epic
level
like
we
have
the
epic
and
then
we
have
the
direction,
and
then
engineering,
together
with
everyone,
but
mostly
engineering,
would
then
decide
how
we're
going
to
break
this
down
in
a
way
that
fits
what
we
want
to
build
on
on
the
other
side.
B
What
I
would
love
to
do
more
is
work
less
for
the
milestones
themselves
and
in
those
small
issues
and
giving
those
detailed
specs
about
we're
going
to
build
this
with
that
button,
and
it
has
this
spacing
and
that
size
and
it
goes
there
and
it
goes
there
and
with
all
of
those
high
fidelity
mockups,
which
I
already
try
to
do
very
less,
but
most
of
the
times
it's
needed.
I
feel
that
engineers
think
they
need
it
think
they
need
those
mock-ups,
but
I
I
don't
think
the
engineers
actually
need
them.
I
think
they
they
are.
B
They
don't
give
themselves
enough
credit
for
the
sensibility
and
for
design
and
for
user
experience
that
they
have,
and
I
think
we
actually
have
like
when
I
see
engineers
later
on
in
the
merge
requests
when
they're
building
things
and
and
then
putting
things
together,
they
start
questioning
hey.
Does
this
make
sense?
B
Maybe
we
should
have
like
this
button
should
link
to
that
other
page
or
we
should
have,
and
that's
amazing-
and
I
would
love
to
see
that
involvement
earlier,
so
that
I
don't
need
to
be
so
handholding
during
the
mr
process,
because
I
think
if
I,
what
I
would
love
to
do
is
just
give
a
sketch
that
we
can
all
agree
on
is
like
a
good
broad
way
of
doing
something,
and
then
they
figure
it
out,
because
we've
laid
out
the
goal
post
and
we
said
hey.
This
is
the
outcome
that
we
want.
B
A
I
don't
recall
having
to
be
so
opinionated
prior
to
engineers,
picking
things
up
an
editor
or
providing
like
as
I
forgot
and
it's
you
know.
Engineers
are
all
different
and
some
have
different
levels
of
confidence
of
like
that,
but
like
we
would
often
have
like
terrible
sketches
or
things
that
I
would
go
like
you
know,
chrome
console,
like
dev
tools,
move
around
and
change
and
be
like
yeah
yeah.
A
This
is
like
the
thing,
and
then
you
know
it
would
get
you
know
engineers
would
tweak
it
as
they
needed
to
go
and
do
it,
and
so
it
is
interesting
that
there
seems
to
be
somewhat
of
a
heavier
reliance
on
that
in
this
group,
and
I
don't
know
that
I
have
an
answer
for
that
other
than
we
did
an
editor,
often
things
that
we
knew
needed
needed
that
more
comprehensive
design
pieces.
There
are
certain
interactions
that
do
just
want
to
be
more
thoughtful
of.
A
We
would
never
schedule
implementation
and
design
and
the
same
milestone
for
those
things,
and
I
don't
know
that
that
that
luxury
has
been
afforded
to
to
you
or
did
the
code
review
group
before.
But
I
think,
like
one
of
the
things
that
I'm
I
don't
want
to
say,
passionate
about
but
like
a
stickler
for,
is
being
very
reasonable
about
what
we
can
actually
do,
and
it's
historically
proven
very
unreasonable
to
expect
good
design
and
engineering
delivery
to
happen
inside
of
a
milestone.
And
so
I'm
often
very
willing
to
just
say.
A
B
I
think,
for
the
whole
time
that
I've
been
at
gitlab,
that's
there
were
it
rarely
we
had
occasions
of
design
and
development
happening
in
the
same
milestone
only
when
there
was
very
high
confidence
and
very
low
risk
of
something
not
going
forward,
and
it
was
a
very
small
issue.
B
Usually
what
happens
is
design
work
and
when
I
see
design
is,
is
is
broad
design,
so
understanding
what
we're
going
to
build
and
how
we're
going
to
build
it,
and
it
can
be
a
very,
as
you
were
saying,
like
some
issues-
require
more
user
interface
work.
Others
require
less
user
interface
work,
but
they
all
need
to
be
designed.
They
all
need
to
be
skipped
spec
out,
they
all
need
to
have
the
scope
defined
and
even
if
it's
a
very
technical
issue
and
only
engineers
are
involved,
I'm
only
seeing
people
discuss
issues,
one
milestone
before.
B
And
I
think
that's
generally
okay,
in
the
sense
that,
like
as
you
move
and
you
get
closer
to
the
actual
moment,
you
start
building
things.
That's
the
moment.
B
You
need
to
have
as
much
as
possible
more
certainty,
but
I
mean
things
could
still
be
up
in
the
air
and
you
can
experiment
in
the
merge
requests
on
a
few
things,
but
I
want
to
see
people
caring
more
and
start
being
interested
more
about
the
issues
like
two
or
three
milestones
before,
because
what
I've
noticed
is
if
we're
only
caring
about
like
I
spent
a
very
big
proportion
of
my
time,
is
reviewing
merge,
requests
that
are
happening
in
the
current
milestone.
So
I
don't
have
enough.
C
B
To
think
and
be
interested
about
other
things
as
much
as
I
would
want
to
and
and
going
back
to
what
I
was
saying.
Also
engineers
don't
do
that.
So
what
happens
is
that
we
only
notice
like
a
problem
is
a
problem
or
an
issue
is
a
issue
worth
implementing
one
milestone
before,
and
that
is
usually
not
enough
time
for
us
to
think
about
it.
Discuss
it
break
it
into
other
parts,
get
everything
together
for
it
to
be
implemented.
B
So
usually
what
happens
is
what
you
were
describing
for
this
milestone
where
in
37
we
have
the
toggle
file
by
file,
merge
requests.
We
have
the
marking
files
as
reviewed.
We
have
the
custom
suggestions.
We
have
reviewers
so
like
some
of
the
issue,
issues
that
slipped
and
all
of
that
was,
I
could
say
that,
except
for
reviewers.
C
B
A
big
part
of
reviewers,
except
that
part
about
the
filter
which
we
were
expecting
for
it
to
work
other
than
that
everything
else
was
thought
about,
one
milestone
before
or
even
less
just
a
few
weeks
before
it
was
scheduled
and
it
was
in
the
current
milestone
and
I
think
a
lot
of
it
has
to
do
with
focus.
As
you
said,
like
focusing
on
less
things
and
to
be
honest,
it's
just
trying
to
do
less,
because
we
try
to
do
too
much
for
the
number
of
resources
that
we
have
and
there's
just.
B
It
could
be
just
one
product,
we
could
be
a
startup
right
and
the
same
for
every
other
group,
but
and
when
we're
competing
with
companies
that
have
more
than
one
designer
and
more
than
one
pm.
And
you
know
what
I'm
saying
it's:
it's
crazy
that
we're
shipping
at
this
velocity
sometimes
faster
than
our
competitors,
that
have
more
people,
and
that
is
not
necessarily
bad.
B
The
the
bad
thing
is
that
we're
sacrificing
all
of
this
because
we're
trying
to
ship
more
in
this
and
yeah,
and
I
think,
if
we
had
more
focus,
as
you
said
and
then
and
and
intentionally
said,
to
engineers
and
to
everyone
like
slow
down,
it's
okay,
to
take
time
from
delivery,
work
to
discuss
what
we're
going
to
do
and
how
we're
going
to
do
it.
If
we're
solving
the
right
problems
and.
A
Yeah,
I
would
agree,
I
think,
yeah.
I
think
all
of
this
just
boils
back
down
to
the
focus
piece,
and
I
think
that's
the
one
that
I'm
hopeful,
that
we
we
get
a
handle
on
sooner
figure
out.
What
we're
gonna
go,
do
and
make
sure
that
we
we
sort
of
stick
on
that
track
and
instead
of
filling
in
with
other
insert
random
feature
work
that
we
could
do.
A
Yeah
in
engineering
an
editor,
I
often
only
had
two
direction
and
issues
ever
like
playing
in
a
milestone.
Two
or
three-
and
I
was
sort
of
like
these-
are
the
these
are
the
big
things
I
care
about.
Here's
some
other,
like
not
user
facing
but
stuff
that,
like
I
need
done
because
it's
analytics
or
it's
whatever
and
then,
let's
figure
out,
like
the
other
work
that
we
need
to
be
doing.
A
That
like
helps,
keep
the
day-to-day
moving,
because
we
just
the
fact
that,
like
I'm,
trying
to
draft
like
five
release,
post
items
makes
me
feel
uncomfortable
right
now
because
like
we
would
never
have
tried
to
release
five
things
in
editor
and
they're
different
groups
and
like
whatever,
but
like
that's
just.
B
I
would
actually
yeah,
I
think
I
think
I
think,
you're
right
in
in
the
balance
of
what
you
were
describing
for
editor,
but
at
the
same
time
me
not
knowing
so
well
the
what
was
happening
inside
of
editor.
I
would
actually,
if
you
told
me,
oh,
we
were
actually
doing
five
direction
items
and
then
the
rest
is
just
very
few
performance
and
bug
bugs
I
I
would
accept.
B
I
wouldn't
be
surprised
if
you
told
me
that,
because
I
would
think
oh
maybe
they
have
less
legacy,
they
have
less
things
to
refactor.
They
have
yeah
less
things
to
attend
to
because
they're
a
new
group.
B
To
code
code
review
and
or
source
code
before,
but
we
have
so
much
legacy
and
I
think
that's
also.
Another
thing
is:
if,
if
we
dedicated
more
and
more
and
more
time
to
all
of
those
backstage
performance,
polish
bugs,
I
think
not
attaining
them-
is
what
is
also
making
us
creating
a
lot
of
problem
for
us
when
we're
creating
when
we're
trying
to
do
direction
issues.
B
Basically,
so
by
having
all
of
that
depth
we're
moving
we're
trying
to
move
faster
on
the
direction
issues,
we're
actually
always
finding
things
that
are
broken
and
that
we
can
do
right
now
or
we
have
to
do
differently.
So
we
need
to
change
the
ux
or
we
need
to
change
the
scope,
and
we
only
find
that
whenever
we're
d
knee
deep
in
the
in
the
mrs
and
that
has
happened
with
reviewers,
that
has
happened
with
the
toggle
for
file
by
file
that
you
described.
A
Yeah
yeah,
I
mean
I
I'm
hopeful
that
that
focusing
the
group
fixes
it.
It's
gonna,
take
me
time
to
get
figured
out
what
that
focus
is
and
codify
it
in
a
direction
page,
but
hopefully
that
helps.
B
So
yeah
I
mean
I'm
here
to
help
of
course,
so
whatever
I
I'll
review
the
the
merge
request
that
you
have
there
and
see
if
there's
anything
that
I
can
contribute.
B
Yeah,
I
think
it's
not
difficult
for
us
to
have
a
milestone
with
just
one
direction
issue.
There
are
just
so
many
issues
to
pick
from
it's
it's
not
hard.
So
if
you
were
saying
like,
we
will
need
time
to
like
two
three
milestones:
to
get
into
the
right
pace
and
into
the
right.
I
think
mental
state
of
how
we're
going
to
maintain
this
focus
and
maintain
this
predictability
and
maintain
this
at
the
end
quality
of
what
we're
shipping
and
the
problems
that
we're
addressing.
B
I
think
we
can
start
that
today
by
just
well,
I'm
gonna,
it's
of
course
it's
not
that
way,
but
but
just
if
we
only
scheduled
100
of
bugs,
we
would
still
have
a
lot
of
work
and
we
will
fix
so
many
things
that
maybe
some
people
will
think.
Oh,
this
is
actually
a
new
feature.
It's
not
it's
just
that
we
fixed
the
bug.
B
Yeah
catherine,
you
gonna
say
something.
C
I
was
just
gonna
say
I.
I
really
agreed
with
everything
I
said
about
focus,
and
then
I
was
wondering
since
I
know,
for
example,
james
when
he
was
pm
there
was
so
many
epic
studies
created
to
house
things
like
about.
Basically
all
the
problems
that
we've
heard
about.
You
know
tracking
files
that
have
been
already
reviewed
navigation.
C
A
I
have
been
having
I
think
every
week
in
this
call.
I
asked
pager
like
what's
the
one
thing
that
you
want
me
to
think
about
or
focus
on
sort
of
this,
maybe
where
that
starts.
I
I
also
talked
right
after
I
joined
the
team.
I
talked
to
every
engineer
just
to
sort
of
get
their
sense
of
things,
and
I've
talked
to
michelle
and
andre,
and
obviously
I
talked
to
james
every
engineer
really
yeah.
I
had
a
one-on-one
with
every
engineer
on
the
team.
Wow,
that's
amazing,
but
my.
A
A
Overarching
sort
of
the
philosophy
that
gitlab
has
is
that
code
reach
view
should
be
fast
and
we
should
be
supportive
of
getting
code
merged
before
sort
of,
like
anything
else
like
that,
those
are
sort
of
like
the
the
top
of
the
list,
and
so
with
that
in
mind,
I'm
trying
to
look
at
the
things
that
are
like
what
makes
where
do
we?
A
Where
do
we
end
up
in
bottlenecks
or
slowdowns
or
like
what
are
the
things
that
cause
that
I
think
reviewers
is
a
great
step
in
terms
of
helping
that,
and
I
think
one
of
the
things
about
reviewers
is
like
if
you
pick
the
wrong
person
to
review
your
mr,
like
you've.
Now
you
put
that
thing
on
a
grinding
halt
until
you
find
the
right
person
right,
so
I
think
that's
an
area
that
I
want
to
go
explore
more.
A
In
terms
of
how
do
we
make
sure
that,
like
I,
as
an
author,
know
the
status
of
my
merch
request,
I
as
a
reviewer
know
that
I
have
reviewed
this
and
the
ball
is
back
in
the
author's
court
and
sort
of
eliminating
a
lot
of
those
manual
manual,
things
that
we
have,
and
if
you
look
we've
talked
about,
I
think
you
know
a
few
weeks
ago
when
we
spoke
it's
the
tracking
of
unread
files
and
disks
is
sort
of
like
the
one
big
thing
that
pedro
says,
and
I
think
that
ties
very
well
into
reviewers.
A
I
think
the
thing
about
reviewers
that
the
path
that
it
was
on
or
it
was
potentially
on,
was
so
much
about
like
how
do
reviewers
fit
into
approval
rules
and
sort
of
all
these
other
things,
and
I
think
I
think
that's
a
byproduct,
maybe
or
something
we
figure
out
later
versus
like
how
do
we
communicate
status
because
status
tends
to
show
up
in
lots
of
these
epics
of
of
that
piece,
and
I
think
that's
the
thing
that
I
would
say
we
go
focus
on
I've
also
closed
some
of
james's
epics
and
things
that
we're
not
gonna
go
do,
and
I
I
think
that's
another
thing
that
this
group
has
not
done.
A
Is
I
love
james,
but
there's
a
lot
of
stuff
out
there,
and-
and
I
think
we
just
need
to
be
more
realistic
about
what
we're
gonna
do
and
not
not
have
some
of
these
like
longer
longer
fine
sky,
things
that
maybe
we're
not
gonna
get
to.
B
Yeah
yeah,
I
I
apologize
if
this
whole
point
sounded
more
like
rant.
C
You're
really
not
because
kai
made
a
great
point
about
even
with
the
research,
it's
kind
of
a
thing
where
you
could
spend
a
bunch
of
time
researching
or
doing
the
solution,
validation
for
a
very
specific
feature-
that's
going
out,
but
then
you
didn't
dedicate
that
time
to
the
depth
and
kind
of
something
that
would
contribute.
Maybe
more
significantly.
So
I
I
totally
agree
with
that.
A
Oh,
it's
a.
It
is
a
two-sided
coin
for
sure,
because
it
doesn't
matter
what
we
do
in
product
and
design
to
sort
of
like
get
ahead.
If
one
of
the
things
that
I'm
I'm
still
going
to
work
with
andre
and
sheldon
is
getting.
C
A
That
editor
did,
that
was
a
that
was
something
that
darva
initiated
that
like
on
monday
mornings,
the
backend
engineers
actually
got
a
set
of
issues
based
on
epics,
that
they
knew
were
upcoming
and
had
to
go
and
like
provide
breakdowns
and
give
their
thoughts
and
opinions,
and
those
conversations
would
start
well
in
advance
of
us.
You
know
being
able
to
schedule
or
do
something,
but
they
were
always
looking.
A
Engineers
were
always
in
the
issues
looking
at
them,
because
we
just
accounted
for
that
as
part
of
capacity,
and
so
that's
another
piece
that
we're
gonna
have
to
keep
working
on
and
trying
to
leverage
in.
But
it's
gotta
happen
as
a
group.
It
can't
it
can't
just
be
us
and
it
can't
just
be
engineering,
so
we'll
have
to
figure
out
how
we
work
all
that
out,
but
that
that'll
also
help
move
move
the
needle
the
right
way.
A
B
Yeah,
that's
that's.
What
I
was
saying
before
is
that
I
yeah
I
want
engineering
to
be
more
involved
before
and
I
don't
think
yeah,
I
just
don't
think
andre
and
michelle
can
can
do
all
of
that
and
and
while
everything
else
that
they
have
to
do,
I
don't
think
that's
fair.
So
and
again
it
will
have
a
good
another.
B
So
the
product
of
that
is
that
engineers
will
feel
the
ownership
of
what
they're,
building
more
and
more
so
and
and
we
will
be
able
to
have
better
technical
decisions,
because
we
have
predictability
and
that
will
probably
allow
us
to
move
faster
as
well
and
create
less
technical
debt.
So
there's
a
lot
of
positive
effects
to
that
yeah
about.
B
Final
thing,
I
wanted
to
say
about
the
bugs
and
issues.
Sorry
bugs
and
usability
issues
and
ui
polish,
like
katherine,
did
a
great
job
of
creating
those
issues
for
from
the
sus.
Some
of
them
are
things
that
we
can
do.
Some
of
them
are
not.
Some
of
those
are
things
that
we
already
did,
but
maybe
people
didn't
know
and
other
than
that
we
also
have
this
quarter,
we're
pushing
really
hard
on
those.
I
think
I
don't
know
how.
B
It
is,
I
think,
100
issues,
or
maybe
I
don't
know
if
there's
so
many,
but
that
we're
pushing
in
terms
of
getting
the
wax
right
so
that
we
can
improve
the
sus
and
another
thing
I
wanted
to
share
with
you
guys-
which
I
don't
know
if
you're
also
aware,
is
that
I've
been
trying
to
take
some
time
every
week
to
create
issues
just
from
the
we
did
a
prioritization
session
in
another
prioritization
center.
We
did
a
async
critique
exercise
in
figma
on
the
merge
requests
page.
B
B
In
the
finishing
up
creating
issues
from
the
ux
department
critique,
I
haven't
even
looked
at
the
product
critique
yet
so
I
you
have
to
look
into
that,
but
just
the
sheer
amount
of
issues
that
I've
been
creating
or
that
I
can
create,
because
creating
issues
takes
time
and
especially
these
ones
that
already
have
something
actionable
and
a
proposal
of
things
to
fix.
B
So
even
like
this
monday,
I
created,
I
think,
16
issues
and
I
still
have,
I
think,
16
or
15
more
to
create
and
then
I'll
be
done,
and
those
are
just
ui
polish
ui
texts
or
plain
front-end,
bugs
that
that's
it
that
it's
not
like
something
big.
It's
just
things
that
are
plainly
wrong
and
maybe
tyrion
really
well
with
the
nitpicks
that
you
had
so
yeah.
We
have
a
lot
of
issues
that
we
can
focus
on.
B
A
Yeah
I've
seen
new
merch
request:
ux
improvements,
epic
and
base
user
get
at
it
so
yeah.
I
think
we
just
need
to
figure
out.
A
Mrs
had
a
lot
of
we
could
do
debt
and
bugs
and
ui
polish
forever
and
probably
never
dig
ourselves
out
of
the
list.
So
at
some
point
we'll
need
to
get
smart
about
what
we
do
but
yeah.
I
appreciate
you,
you
you're
doing
those
as
well
us.
I
know
by
the
time
I
got
to
the
product
side
of
that
figma
review.
It
was
already
well
inundated,
and
so
I
can't
imagine
what
you
ended
up
with
out
of
all
of
that.
B
Yeah
yeah.
A
Cool
well
enjoy
the
rest
of
your
wednesday
catherine
u2,
and
then
I'm
going
to
go
back
planning
at
some
point
and
hope
that
we
can
get
13
8
at
least
semi-planned
yeah.
B
A
A
B
You
so
much
for
this
conversation.
This
was
great
and
yeah
have
a
great
rest
of
your
week.
Thank
you.
Thanks.