►
From YouTube: 2021-02-10 Code Review Weekly 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).
B
Thanks,
I
was
waiting
for
the
document
to
load,
so
this
pedro
asked
me
to
provide
an
update
on
verify
stages,
efforts
to
refactor
the
mergibility
check,
and
this
started
as
an
intention
to
simplify
or
make
the
code
that
handles
the
error
messages
and
the
states
and
all
that
live
on
the
back
end.
B
Instead
of
doing
a
bunch
of
checks
on
the
front
end,
they
started
putting
forward
a
proposal
of
setting
a
working
group
in
place
for
this
effort
and
then
eventually
an
option
of
putting
a
architecture,
evolution,
blueprint,
kind
of
thing
in
place,
which
is
some
process
more
formally
more
formal
to
do
architectural
changes.
B
They
checked
and
both
scenarios
were
kind
of
discarded,
because
the
scope
of
this
effort
is
far
smaller
and
more
restricted,
as
it
is
right
now.
What
I
saw
there
and
sam
beckham,
the
frontend
manager,
reached
out
to
me
to
just
to
get
involved
in
this,
and
what
I
saw
there
is
an
opportunity
to
line
up
the
work
that
peter
is
doing
with
the
lovable
merge
button
in
case
it
requires
any
sort
of
changes
on
the
way
we
handle
error
messages
or
states,
or
anything
like
that.
B
The
good
review
from
the
top
of
my
head
is
dependent,
cmrs
and
unresolved
discussions
and
probably
a
couple
of
others.
So
there
is
some
sort
of
alignment
required
between
our
stages
in
our
groups.
But
what
I
see
here
is
like
there's
two
efforts
working
on
this
thing.
One
is
pedro's
exploration,
ux,
the
other
is
their
part
of
the
code,
so
I
don't
know
about
whether
we
should
get
ourselves
involved
from
the
ux
perspective
and
engineering.
B
C
Yeah
cheryl-
and
I
have
been
talking
about
this
for
weeks
now
and
I'm
so
glad
that
there's
finally
an
issue,
but
to
be
honest,
I
have
not
dove
into
the
issue
yet
I
did
read
some
of
it
and
I
think
it
solves
a
really
huge
problem,
which
is
the
widget
itself
and
all
of
the
different
components
that
exist
in
there.
C
But
I
don't
think
that
that's
the
reason
that
we
have
all
of
these
bugs,
I
don't
think,
that's
the
only
reason,
and
I
don't
think
it's
the
only
thing
that's
going
to
solve,
like
even
when
you
just
said
verify
checks
in
my
head.
I
was
like.
What's
that
mean?
I
don't
know
what
that
means
like
merging
pipeline
succeeds.
Is
us,
and
also
that,
like
I
don't
know-
and
I
think
that's
a
problem
and
that
this
issue
doesn't
solve
that,
so
I
do
think
that
we
should
all
be
involved.
C
I
think
that
this
I
I'm
really
eager
to
hear
kyle's
opinion,
but
I
think
I
should
be
involved.
Tal
should
be
involved
pedro
everyone,
because
this
is
turning
into
a
very
technical
discussion
and,
from
my
perspective
and
talking
with
cheryl,
I'd
like
to
back
a
little
bit
out
of
that
and
make
this
one
part
of
solving
this
problem.
A
Yeah,
I
think
I
have
seen
the
issue.
I
agree.
It
feels
very
engineering
focused.
It
feels
like
engineers
are
solving
like
a
problem
for
engineers
and
that's
fine,
sometimes,
but
I'm
a
little
bit
concerned
that,
like
it's,
not
the
right
way
to
solve
it,
and
I
say
that
because
I
don't
think
any
of
our
engineers
have
weighed
in
right
and
as
as
code
review,
we
ultimately
own
sort
of
what
that
merge.
Button.
Experience
should
be
and
what
that
the
direction
and
features
that
we
want
to
add
there
and
the
work
that
pedro
is
doing.
C
A
So,
in
my
mind,
this
should
come
from
us
with
pedro
stuff
to
engineers
and
say
here's
all
the
things
that
we
found
engineers.
What
do
you
think
the
best
way
to
solve
this
is
and
scary.
We
have
three
front
end
engineers
on
here
who
have
probably
seen
the
front,
and
you
know
phil
probably
knows
a
lot
about
the
merge
button
and
I
I'd
love
to
know
like
if
you
read
that
like
do
you
look
at
that
and
go
yeah,
this
makes
a
ton
of
sense
or
like
no.
A
B
Just
as
a
note
this-
and
I
agree
with
you
with
everything
you
just
said-
we
should
be
owning
this.
We
should
be
steering
the
solution.
The
solution
is
very
engineering
heavy
because
it
started
as
such.
B
It
started
as
an
engineering
problem
and
they
involve
this
and
that's
where
we're
waving
the
flag
of
wait,
a
minute,
there's
more
work
here
that
can
be
done
before
we
even
get
to
move
the
rocks
out
of
place,
so
I
think
we're
all
aligned
in
that
sense
that
we
should
definitely
do
a
deeper
analysis
and
come
up
with
sort
of
a
direction
for
it
for
everyone
to
be
on
board
and
right
now,
the
solution
proposed
is
to
solve
their
problem.
That's
it
so
yeah.
D
B
Yeah,
I
think,
we're
all
in
agreement,
so
we
already
started
setting
a
bit
of
that
with
the
merge
request,
widget
extensions.
B
B
A
I
don't-
want
to
have
another
conversation
until
pedro's
ready
to
have
that
conversation
about
what
we
need
the
merge
button
to
do,
because
it
doesn't
how
we
architect.
It
is
very
dependent
on,
like
all
of
the
experience
that
we
want
to
design
to
it
and
until
we're
ready
to
have
that
conversation
like
these
other
ones.
Don't
don't
matter
to
me
right!
That's
why
I
was
sort
of
surprised
to
see
this
come
up
when
when
we
started
our
own
like
conversation
from
another
direction,
but
like
I'm
not
ready
to
have
those
conversations.
A
Yet
I
don't
think
this
group
is
ready
to
have
conversations
yet
like
we
don't
have
opinions
because
we
haven't.
We
haven't
seen
everything
that
pedro
has
come
back
with.
We
haven't
had
that
conversation
as
a
group
to
even
have
opinions
to
like
talk
to
another
group
about
what
we
want.
What
we
would
want
them
to
do.
B
Yeah,
I
I
can
see
that
and-
and
I
think
part
of
the
conversation
will
be
revolving
around-
that
we
need
to
wait
a
little
bit
before
we
can
even
get
our
hands
down
to
the
code,
so
the
immediate
thing
would
be
to
just
convey
to
them
that
we
have
an
ongoing
ux
exploration.
B
Peter,
do
you
have
any
expectation-
and
I
don't
want
to
put
pressure-
is
that
something
to
take
the
whole
quarter?
Is
that
something?
What's
your
sort
of
timeline
there
yeah.
E
So
so
the
like
reinventing
and
having
a
more
innovative
approach
to
the
mr
widgets,
we're
not
close
to
that
right.
Now,
we're
focusing
on
the
merge
widget
only
in
the
merge
button
and
making
that
a
little
bit
better
and
it
would
not
involve
a
significant
rework
so
two
thoughts.
One
of
them
is.
I
agree
that
we
should
own
this
as
much
as
possible
and
two.
E
I
think
that
this
is
something
worth
doing
if
the
scope
of
what
we're
thinking
in
terms
of
engineering
is
just
rewiring
things
in
a
different
way,
and
it
would
not
be
a
lot
of
effort
if,
because,
as
kai
said,
maybe
in
the
future,
we
will
change
things
more
dramatically
or
not,
and
that
is
still
in
the
open.
So
if
we
just
want
to
clean
the
house-
and
that's
not
a
lot
of
work-
I'm
okay
with
that
anything
other.
E
B
Okay,
I
I
do
think
that,
even
though
we
were
focused
on
the
merge
button,
the
way
we
present
error
messages,
what
kind
of
error
messages
what
kind
of
states
I
want
to,
let
that
on
your
plate,
you,
you
should
comment
how
that's
how
that
lands
on
the
next
proposal,
the
next
iteration,
and
I
do
think
that
will
affect
the
way
we
work
out
the
code.
B
So
I
think
I'll
relay
that
to
the
team
right
now,
so
I'm
not
so
sure
if
we're
ready
right
away
to
have
that
conversation
as
a
big
group,
but
I'll
relay
the
feedback
from
from
our
conversation
here,
and
we
might
still
continue
to
have
like
loose
conversations
from
the
engineering
perspective,
but
they're
all
pending
on
your
outcome
on
this
thing
and
I'll
see
what
what
what
they
come
back
with
michelle.
Do
you
have
any
thoughts
on
that.
C
Yeah,
I
do
I'm
still
concerned
again.
I
just
want
to
underscore
that
it
needs
to
be
reworked.
I
saw
some
of
the
example
code
in
the
issue
and
they
were
like
this
is
a
pipeline
error
message.
That
means
this.
I
love
that
we
definitely
need
to
do
that,
but
still
I
think
that
the
bigger
problem
is,
for
example.
I
closed
two
duplicate
issues
this
morning,
for
I
you
remember
this
issue
because
it's
come
up
before.
C
If
you
try,
if
you
have
require
that
pipelines
succeed
and
you
submit
an
mr
that
does
not
have
a
pipeline,
then
it
just
sits
there,
spinning
that
that
and
I'm
not
blaming
it
on
verify,
I'm
just
saying:
there's
a
conflict
in
product
on
what
these
features
should
and
should
not
do,
and
we
have
not
looked
at
them
holistically
in
terms
of
what,
if
you
have,
this
merge
option,
enabled
plus
this
verify
option
enabled
and
so
to.
C
In
my
mind,
that's
still
like
just
number
one
to
me
is
this
direction,
that
we
have
conflict,
conflicts
and
features,
and
but
I
do
think
that
the
widget
is
like
it's
super
important,
that
we
can
separate
that,
and
I
think
that
it
will
help
too
like.
If
we
have
clearer
error
messages,
then
at
least
we
can
quickly
pinpoint
and
say
this
is
their
issue.
This
is
our
issue.
C
B
B
But
if
you
have
problems
like
the
one
you
mentioned,
definitely
we
definitely
should
address
them.
But
I'm
just
wondering
about
that's
kind.
C
C
B
Okay,
right
yeah,
I
think
it
does,
but
I
think
it
at
least
we
have
some
understanding
what
the
group
thinks
it's
early
to
have
deep,
deep
changes.
We
have
ux
leading,
but
we
still
have
to
look
at
the
cases
in
between
and
I
think
we'll
just
have
to
address
them
on
a
case-by-case
basis.
A
Yeah,
I
think
michelle's
point
is
more
that
like-
and
this
is
true
product
does
not
agree
on.
What's
a
feature
and
what's
a
bug
of
the
merge
button
right
now
and
like
to
the
to
the
question
about
like
if
you
have
don't
allow
empty
pipelines,
but
you
have
a
mr
that
can
run
without
pipelines,
not
being
mergeable.
A
Verify
considers
that
a
feature
and
code
review
considers
that,
above
because
we
have
like
differences
of
opinion
on
terms
of
like
what
gets
you
to
mergiable
right
now
and
largely.
That
is
because
that
is.
A
And
this
is
the
work
that
that
pedro
is
doing
that.
I
want
to
use
to
say
these
are
our
expectations
of
mergiability,
and
these
are
like
sort
of
not
up
for
discussion
like
we.
I
want
to
be
able
to
go
back
and
sort
of
define
what
the
answer
is
to
all
of
these
questions
and
give
other
groups.
The
hope
is
that
we
can
give
other
groups
like
a
way
to
say
okay,
I
need
to
add,
like
this
thing
we
say
great.
A
Sort
of
in
isolation,
which
is
what
has
happened
up
to
this
point,
I
think
that's
why
you
see
like,
like
the
one
thing,
I'm
most
happy
about
pedro's
work,
and
I
I
hope
we
come
out
of
this
with
is
like
that
button
can
only
ever
say,
merge
and
it
can
never
say,
like
anything
other
than
merge,
like
you
know,
it
can't
say,
merge
when
pipeline
exceeds,
it
can't
say,
add
to
merge
train
when
pipeline
succeeds.
It
can't
say
all
of
these
other
things.
They
can
just
say,
merge
right
and
that's
it.
A
That's
all
that
button
should
ever
say
because
that's
to
a
user,
that's
what
it
is
and
that's
that
is
something
that
we
have
not
ever
like
defined
or
been
good
about
about
like
trying
to
control
that
experience
more,
and
we
need
to
be
better
about
about
that
and
then
I
think
that
would
inform
groups
sort
of
our
expectations
and
how
they
might
be
able
to
integrate
an
architect
with
that.
But
I
don't
think
that's
why
I
say
we're
not
ready
to
have
that
conversation
with
verify
about
how
to
do
that.
B
A
We
have
to
solve
bugs,
and
I
think
like
there
are
bugs
that
come
up
and
like
that'll
continue
to
be
a
thing.
What
I
think
we
don't
want
is
we
don't?
I
think
in
pedro,
said
this
too.
It
would
be
a
not
a
waste
it
would.
It
would
not
be
probably
a
potentially
valuable
use
of
time
to
go
and
start
a
massive
refactor
project
today
without
knowing
what
that
might
need
to
look
like,
but
if
there
are
severe
bugs
today,
we
should
be
looking
at
solving
those
severe
bugs
today.
C
B
Okay,
I'll
relay
that
to
the
team
and
we'll
keep
bringing
this
up
as
we
have
more
touch
points,
but
thanks
everyone
for
the
thoughts
we're
really
looking
forward
to
your
outcome
better
than
we
look
great.
What
I
love
thanks,
andre
for
taking
this
on
as
well.
Thanks
for
keeping
us
posted.
C
Okay,
we
got
10
minutes,
so
the
kanban
workflow.
Hopefully
you
all
have
seen
this
issue
that
the
team
has
brought
forth,
and
this
is
an
open
proposal
to
support
at
least
the
back
end
team
working
in
a
more
kanban
approach,
based
on
a
list
of
priority
issues
that
are
not
always
assigned
to
someone,
and
we
pick
from
the
top
of
the
list.
So
my
questions
are
what
concerns
do
you
have
and
what
are
some
requirements
that
you
would
need
from
us
if
it
did
end
up
being
just
backend
who
works
this.
B
Way
so
my
initial
concern
right
away
is:
if
it's
just
the
back
end,
then
we,
how
do
we
address
the
issues
that
are
both
back
in
front
end?
That's
my
biggest
one.
In
that
scenario,.
C
So
there
are
still
assignments
in
this.
I
think
that
discussions
kind
of
already
unfolded
in
the
issue,
but
if
there
needs
to
be
like
a
dri
for
the
issue-
and
I
think
you're
the
one
who
actually
proposed
this-
which
was
a
great
idea-
I
thought,
but
if
there
does
need
to
be
two
counterparts
or
a
dri
for
the
issue,
they
can
still
be.
A
I
don't
have
any
concerns
like
we
already
set
a
board.
We
set
a
list
if
they
want
to
pick
which
issues
they
want
to
work
on
from
the
list.
I
don't
I
don't
have
any
concerns.
I
just
don't
think
it
does
what
they
want
it
to
do,
and
so
I
I'm
concerned
that,
like
it's
not
going
to
be
the
right,
the
right
iteration,
but
I'm
happy
to
let
them
like.
C
So
this
has
actually
come
up
for
many
many
months
individually
and
one-on-ones
and
then
finally,
it
came
to
a
head
like
a
week
or
two
ago,
as
a
team
on
a
sync
call.
So
there's
a
lot
of
different
reasons.
C
It
started
out
because
our
team
in
particular-
and
it
started
with
the
source
code
team
they're
more
distributed-
does
not
feel
like
a
team,
because
we
are
super
managers
of
one
and
we
work
on
our
own
stuff
and
we
only
ever
really
interact
with
you
pedro
or
I
as
product,
but
not
each
other.
I'm
just
gonna,
it's
recorded,
so
I'm
gonna
keep
talking
because
we're
short
on
time.
So
that's
how
it
started
off
as
it
kind
of
bled
into
like.
C
We
just
have
no
idea
what
each
other
is
working
on
and
we
don't
help
each
other
and
we
wanted
to
be
better
about
helping
each
other
when
they
were
blocked
or
like
we
identify
when
someone
needs
help
quicker
than
they
may
identify
that
they
need
help.
And
so
all
of
that
we're
kind
of
hoping
in
terms
of
like
a
measurement
that
will
feel
better
as
a
team,
more
collaborative
and
more
efficient
and
hopefully
reduce
slippage.
But
I'm
not
sure
that
that
one
is
really
a
measurement.
B
F
I've
two
notes
now
that
you
said
that
I've
I've
brought
this
up
a
couple
of
times
with
andre,
specifically
for
the
reduced
slippage
thing,
just
it
just
sort
of
flips
the
flips,
the
script
of
like
you
have
all
of
these
things
assigned
and
if
you
miss
any
of
them,
they
slip
versus
here's
all
the
things
we
could
do,
pull
on
I'll
pull
them
off.
F
As
you
have
time,
and
maybe
the
last
one
you
work
on
is
going
to
slip
or
something,
but
the
only
thing
that
that
I
have
a
concern
was
andre
mentioned
this
one.
When
I
brought
it
up,
there's
I
have
a
preference
for
like
backup,
front-end
stuff,
like
not
you
know,
not
not
ui.
F
I
like
doing
more
like
logic,
work,
type,
stuff
and
andre
tries
to
assign
those
types
of
things
to
me
and
with
this
sort
of
like
kanban
style,
that
sort
of
like
manager,
input
on
on
where
work
goes,
could
be
lost.
I've
had
a
lot
of
ui
work
this
milestone,
so
I'm
not
sure
that
there's
enough
backup
front-end
work
for
that
to
be
a
real
loss
for
me.
So
I'm
not
sure
if
that's
a
real
big
complaint
but.
C
That
actually
did
get
brought
up
by
the
team,
and
so
hopefully
they're
comfortable
with
that
kind
of
caveat,
because
I
do
tend
to
assign
issues
that
number
one.
I
know
that
you
really
like
to
work
on
and
number
two
issues
that
I
know
that
are
going
to
be
a
challenge
for
you
and
you
need
to
get
better
at
working
on
so
their
solution
to
that
was
like.
Well,
if
you
still,
if
you
really
want
an
issue,
you
can
still
assign
yourself
to
the
issue.
C
I'm
not
sure
how
I
personally
feel
about
that,
but
that's
an
option,
but
the
slippage
thing
you've
actually
reminded
me
of
a
really
good
point.
There
has
been
a
handful
of
times,
like
probably
a
lot
of
times
where
most
people
have
already
delivered
all
of
their
work,
and
now
it's
one
person
who's
slipping,
half
of
their
work
and
that's
kind
of
where
they're
coming
from
where
they're
like
yeah.
We
could
pick
that
up
and
it
right
now,
that's
really
up
to
me
to
realize
everyone's
finished,
but
you.
C
B
For
that
particular
thing,
I
think
we
could
have
other
solutions,
but
regardless
of
that,
I
think
my
biggest
concern
goes
to
something
that
phil
mentioned
on
his
experience
on
working
this
way,
which
is
the
the
psychological
pressure
that
you
have
if
you're
expected
to
deliver
four
things,
and
you
know
that
you're
expected
to
deliver
those
four
things
and
you're
working
on
one
and
for
some
reason
that
blows
out
of
proportion
in
terms
of
complexity
and
it's
harder
for
you
to
get
that
notion
that,
even
though
it's
a
weight
too
weight,
two
do
not
equate
to
time.
B
So
that's
why
I
feel
like
it's
a
it's,
a
harder
task
for
the
ic
to
keep
track
of
their
own
time,
and
it
pushes
to
me
it
pushes
so
we're
trying
to
make
delivery,
deliverables
more
predictable,
improve
the
say:
do
ratio
that's
in
our
okrs
and
I'm
not
so
sure
this
brings
us
in
the
right
direction.
I
think
it
makes
kai's
work
less,
not
guys
work.
It's
it's
less
clear.
B
What's
actually
going
to
get
delivered
at
the
whole
span
of
the
milestone,
so
I
think
it
pushes
in
the
wrong
direction
there
rather
than
make
us
more
predictable
as
a
team,
but
yeah
that's
my
kind
of
biggest
concern,
but
I'm
okay
in
you
trying
it
out
the
back
end,
because
I
feel
like
the
push
came
from
you
and
we
see
if
we
can,
the
result
of
that
so
yeah.
C
My
biggest
concern
as
a
manager
is
the
predictability
and
so
just
to
be
super
clear.
If
it
is
in
that
board,
we
expect
them
all
to
be
delivered.
There's
always
really
good
reasons
why
we
have
slippage,
which
is
like
we
didn't
estimate
it
correctly,
and
so
so
there
still
will
be
slippage.
The
problem
I
want
to
solve
is
it
didn't
slip
because
we
didn't
get
to
it
it
slipped,
because
something
else
was
a
higher
priority
than
that.
You
know
it
took
longer
more
complex.
B
Okay,
as
a
word
of
caution,
michelle
the
order
of
the
issue
boards
is
going
to
be
a
struggle,
so
try
to
come
up
with
a
solution
preemptively
because
there's
so
the
problem
with
the
order
is
that
when
you're
dragging
things
from
column
to
column
and
you're,
placing
them
somewhere,
there
you're
changing
the
order
manually
and
you
don't
notice.
C
B
Me
and
peter
worked
on
planned
team
and
we
know
that
that
one
was
a
bit
of
a
mess
to
solve
and
wrap
our
heads
around.
So
that's
just
a
heads
of
caution.
A
word
of
caution:
try
to
find
a
way
to
solve
that
reliant
reliably.
E
Minutes,
pedro
yeah:
we
can
yeah
this
one.
I
don't
know
which
one
is
more
important,
with
only
two
minutes
left
yeah
we
can.
We
can
talk
about
this
okr.
Maybe
if
we
have
time
during
the
prioritization
session,
I
prefer
to
jump
to
number
four,
that's
okay,
so
we
we
were
implementing
the
skeleton
loaders
in
the
changes.
E
Tab
replacing
the
spinners
thomas
discovered
that
this
is
a
much
larger
undertaking
and
I'm
looking
at
this
as
a
successful
spike
and
learning
experience,
because
iteration
is
mostly
about
learning
and
given
his
feedback
and
the
amount
of
work
I'm
assuming
that
it
would
be
a
lot
of
work
to
get
this
done
properly
and
compared
to
my
initial
expectation
of
effort.
I'm
now
thinking
that
this
might
not
be
worth
doing.
At
least
now
that
we
have
probably
much
more
important
things
to
do.
B
Yeah
thanks
for
that,
I
we
did
pair
up
yesterday,
thanks
thomas
for
for
documenting
everything
in
the
epic.
It
made
everything
a
lot
clearer.
We
still
so
thomas.
If
you
have
an
update,
please
interrupt
me,
but
we
we
paired
up
yesterday.
We
have
still
some
potential
way
forward,
we're
just
not
sure
if
the
compromise
will
be
acceptable
from
the
ux
perspective.
B
F
Basically,
the
basic
kind
of
losses
here
are:
we
probably
won't
have
something
that
looks
good
on
mobile.
F
We
probably
we
don't,
have
the
logic
available
to
really
have
the
skeleton
loaders
really
load
in
the
right
sections,
like
the
header
bar,
for
example,
there's
just
no
state
for
that,
so
it
just
kind
of
has
to
pop
in
when
other
things
pop
in
and
the
svgs
aren't
gonna
look
right,
because
it's
just
it's
just
kind
of
hard
that
we
need
to
do
so.
We
can
get
like
something
out
and
then
maybe
iterate
on
it
later.
We
just
don't
have
like
the
capability
to
do
everything
almost.
B
If
I
can,
I
think,
the
one
that
you
mentioned
on
the
top.
I
think
we
can
add
a
third
state
easily.
I
think
the
biggest
challenge
that
we
found
yesterday
on
the
pairing
is
that
there's
an
initial
spinner
at
the
beginning
that
we
want
to
make
we
want
to.
We
want
to
show
it
as
quickly
as
possible
to
take
care
of
perceived
performance
and
everything,
but
if
we
have
to
have
an
alignment
on
the
file
tree
being
open,
the
file
tree
being
closed.
B
All
of
that
it
takes
another
step,
so
that
will
be
delayed
by
a
couple
of
seconds
and
that's
what
I
think
the
impact
is
the
bigger,
because
we
don't
want
to
have
like
a
skeleton
show
up
and
then,
after
a
couple
seconds,
another
set
of
skeletons
show
up.
So
the
inconsistency
there
is
a
problem,
but
to
have
that
we
have
to
delay
the
time
that
we
have
to
show
the
skeletons
properly
in
place,
regardless
of
all
the
other
problems
that
I
think
we
can
iterate
on,
and
we
can
have
the
third
state
easily
added.
E
I
think
if
it's
much
more
work,
ux
wise,
I
don't
think
it's
worth
doing
worth.
Okay,
we
have.
We
have.
B
B
And
would
they
make
a
decision
whether
we
pursue
it
or
not
over
time
thanks
everyone
thanks
for
joining.