►
From YouTube: Issue Refinement Session: Provide optional title and description before submitting edits
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
Hello,
everybody:
this
is
a
issue
refinement
session
for
the
static
site
editor
in
today's
session,
I'll,
be
refining
the
issue
for
this
request,
title
and
description,
which
is
the
new
feature
we
want
to
bring
in
in
135,
which
allows
the
user
to
specify
the
measures
title
and
description
as
part
of
the
workflow
of
editing,
editing
their
content
using
the
static
site,
editor
and
as
such
is
quite
an
important.
It's
a
it's
a
popular
requested
feature
and
the
especially
since
we
just
use
a
default
title
and
description
right
now.
A
The
user
is
forced
to
go
into
the
merge
request
to
go
and
edit
that,
and
so
we
want
to
bring
that
workflow
closer
to
the
user,
quickly
share
some
mock-ups
that
this
is
actually
part
of
another
issue
which
will
get
you
later.
Hopefully,
today's
session,
but
essentially
you'll
you'll,
see
this
model
come
up
asking
me
to
provide
your
merch
request,
title
and
description.
A
A
Ignore
me
I'm
just
talking
to
myself
for
the
recording
hello,
so
I've
already
identified
a
future
feature
consideration
where
you
could
potentially
specify
that
what
the
default
typing
description
should
be
in
the
config
or
even
simpler,
maybe
just
using
the
the
project's
default
include
a
little
screenshot
of
of
what
that
looks
like
and
that's
currently
under
project
settings.
So
that's
something
we
could
consider
in
the
future
is
to
introduce
or
allow
the
user
to
to
either
use
the
project's
defaults
or
maybe
even
specified
in
the
contract
file.
All
right,
hey,
derek!
A
So
let's,
let's
kind
of
quickly
go
over
this,
so
I
have
covered
the
this
with
you
already
in
broad
stroke,
so
I'm
just
gonna
get
into
it.
So
the
problem
we
want
to
solve
is
that
currently
you.
A
A
So
when
you
we
currently
hit
that
button,
it
creates
the
branch
it
creates
the
commit,
and
then
it
creates
the
the
mr
and
it
can
take
quite
a
bit
of
time,
sometimes
30
seconds
so,
but
apart
from
blanket,
the
thing
we
really
want
to
do
is
allow
the
user
to
specify
the
title
and
the
description
of
the
merge
request
as
part
of
the
workflow
yeah
without
having
to
go
into
the
merge
request,
edit
the
title
edit,
the
description
yeah.
A
It's
part
of
our
our
principle
of
abstracting
the
complexity
of
get
workflows
away
from
from
the
user
right
now.
You
know
we
just
have
this
ugly
title
and
we
don't
actually
have
any
description
text
right
now,
so
we
want
to
make
that
better.
Let
me
just
close
this
because
this
was
just
for
the
test.
A
So
let's
quickly
have
a
look
here,
so
that's
just
kind
of
like
the
preamble
forward.
Why
we
want
to
do
this
feature
all
right?
Indeed,
users,
so
product
managers,
software
developers
pretty
much
everybody
that
uses
aesthetic
side
energy
will
benefit
from
this
user
experience
goal.
So
the
user
should
be
able
to
provide
additional
context
about
the
changes
made
that
carry
over
into
the
resulting
word
request:
yeah
recover.
That
proposal
is
when
submitting
a
change
from
the
static
site.
Editor
prompt,
the
user
to
provide
a
custom,
merge,
request,
titling
description.
A
A
You
make
your
changes
and
then
here
so
as
soon
as
you
click
here,
that's
when
we
want
to
prompt
the
user
to
to
kind
of,
like
you
know,
provide
the
title.
Now,
excuse
me,
two
things
we
need
to
consider
is,
and
I
need
eric
to
still
respond.
Is
that
the
way
they
rate
this
issue
description
of
the
flag
was
that
you
know
the
user
would
open
the
static
site
and
make
the
changes
they
click
submit
changes?
A
A
If
we
look
at
those
that
modal
contract,
so
they
can,
you
know
this
would
be
defaulted
and
they
could
choose
to
change
it
and
save,
or
they
could
close.
A
Now
we
already
know
we
have
a
follow-up
issue
where
we
want
to
decrease
this,
wait
time
that
we
have,
and
so
I'm
this
kind
of
like
the
nice
thing
about
this
is
you
you
can,
I
guess,
cancel
your
your
submit
action
and
return
to
the
editor,
stay
edit
state
without
creating
the
branch
and
committing
the
merge
request.
But
I
don't
think
this
helps
really
with
the
speed
and
the
the
weight
process.
So
an
alternative
flow
that
I
that
I've
thought
of
is
user
opens
the
static
side
here.
A
That
makes
the
changes,
click
submit
changes,
and
at
this
point,
so
when
you
click
here,
it
already
starts
creating
the
the
branch
the
commit
and
the
merge
request,
and
you
know
we
and
we
do
it
in
the
background.
So
we
don't
block
the
ui.
We
open
the
modal
with
the
title
and
the
description
prefill
for
that
we
use
to
create
the
earmarks
for
long,
the
user.
Then
optionally
changes
the
the
title
and
description
if
they
submit
it.
A
We
then
update
the
mr
we
created
with
the
modified
values
only
if
it
was
different.
Obviously,
and
the
user
is
presented,
success
screen
or
if
they
close
the
model.
The
user
is
presented
with
the
success
screen,
because
you
know
there's
no,
the
closing
of
the
model,
isn't
it
canceling
in
terms
of
creating
the
merge
requests?
It's
it's
just
cancelling
changing
the
title
now.
So
the
key
differences
in
the
two
approaches
is
that
in
the
first
one
you
get
to
change
your
mind
and
say
you
know
hold
on.
I
don't
want
to.
A
I
don't
want
to
do
this
anymore
in
the
second
one
you
get,
the
you
don't
get
to
change
your
mind.
You
know
the
branch
you
commit
a
name
and
gets
created
for
you,
and
but
you
do
you
do
get
the
perceived
speed
improvement.
We
prompt
you
for
for
the
for
the
title
and
the
description
while
creating
the
the
thing
in
the
background,
so
I
think
these
are
the
two
kind
of
like
approaches
we
need
to
do
further.
To
that.
A
You
know
that
talks
around
talks
about
you
know
the
the
you
know
creating
the
branch
creating
the
commit,
creating
the
merge
request,
because,
essentially,
even
without
the
progress
bar,
we
if
you
and
if
we
do
option
b
that
I
just
described,
we
need
to
prevent
the
user
from
submitting
the
changes
until
that,
mr
is
created
because
you
know
like
we
need
that
mri
to
be
exist
before
we
can
update
it.
A
B
B
B
Like
we
said
it
could
create
orphaned
things
if
they
abandon
halfway
through
or
also
if
they
rename
it
like
for
people
that
are
likely
to
want
to
rename
every
mr
to
be
something
more
descriptive,
and
perhaps
the
branch
too,
which
may
be
a
lot
of
people,
that's
going
to
create
noise
and
emails,
because
in
gmail
at
least
it
will
thread
differently,
because
the
title
of
the
email
is
different.
B
The
mr
is
going
to
be
created
in
the
back
end
for
you
if
we
offload
that
to
some
background
processing
and
and
furthermore,
like
there's
other
places
like
when
you
create
an
mr
from
an
issue,
there's
a
significant
delay
in
that
currently,
and
it
wouldn't
be
any
worse
than
that
and,
like
I
said,
if
we
did
care
about
it,
we
could
offload
it
to
background
processing
and
let
them
go
ahead
and
close
the
window.
B
C
C
It
would
probably
technically
take
longer,
but
basically
what
I'm
thinking
is,
if
we're
only
allowing
them
to
update
the
mr
title
and
description
right
as
we
really
just
do
the
first
two
steps
that
gets
kicked
off
the
modal
pops
up,
they're
able
to
edit
or
not-
and
basically
it's
not
you've,
already
submitted
your
changes.
Now
it's
just
a
matter
of.
Do
you
want
to?
C
C
You
know
experience
that
might
basically
delay
the
perceived
length
of
time
it
takes
to
actually
do
the
first
two
steps.
So
I
don't
know
that's
just
that's
just
what
comes
to
mind
there.
C
Either
cancels
or
saves
the
basically
yes
just
leave
it
or
yes,
I
want
to
update
it
or
no,
I
don't
and
I'll.
Just
let
you
do
the
defaults
and
again
that's
why
I
said
it
might
technically
take
longer
because
they
could
have
paused
at
that
time
between
the
branch
and
commit
having
completed
and
the
time
they
actually
kick
off.
The
mr
step
again.
C
A
Is
saying,
is
that
this
modal
that
here
will
will
actually,
even
if
you
close
it,
it
still
creates
the
mr
just
with
the
default
values,
but
now
my
my
immediate
reaction
is
that
this
might
create
a
user
expectation
kind
of
like
a
problem,
because
if
I
just
miss
a
modal-
and
I
don't
click
submit
changes,
I
expect
things
not
to
happen
potentially,
and
so
this
is
why
why
I
think
that
might
be
tricky.
I
always
feel
like.
C
At
this
point
that
can
be,
I
think
that
can
be
solved
start
a
button.
I
think
that
can
be
solved
just
in
terms
of
how
we
frame
it
in
the
ui
like
you've
submitted
the
changes,
because
you
clicked
submit
changes
button
all
you're
doing
now
is,
you
know
basically
qualifying
what
your
mr
is
going
to
be.
And,
however,
we
frame
that
as
whether
you
close
this
or
say
that
the
mr
still
happening,
because
you're
submitting
changes
just
a
matter
of
what
metadata
it's
having
because
of
its
title
or
description.
So,
but.
C
Obviously,
it's
something
we
can
consider,
my
gut
would
be.
No,
I
I
just
don't
know
how
people
wanted
that,
like
yeah,
basically
at
a
high
level,
what
I'm
thinking
is
the
way
we
frame
the
actual
ui
and
the
you
know
how
we
communicate
through
the
ui
can
help
us
solve.
Concerns
is
basically
what
I
kind
of
think
we
can
get
to
a
point.
C
B
C
The
change,
and
now
you
have
to
update
that,
mr,
but
again
I
just
I
see
that
being
kind
of
noisy,
but
I
just
don't
know
how
what
that
trade-off
is
how
what
that
trade-off
is.
B
And
I'd
like
to,
I
don't
know,
maybe
get
more
to
the
root
of
what
is
the
user
dissatisfaction
with
the
delay
like
right
now?
They
have
to
click
a
button
and
then
they're
stuck
on
a
screen
that
they
need
to
wait
and
they
they
don't
want
to
close
the
window.
They
don't
know
if
they
can
close
the
window,
but
with
option
a.
B
If
we
get
all
the
information
up
front,
that's
going
to
be
immediately
and
then
when
they
submit
it,
then
we
can
say
if
we
offload
it
to
background
processing,
we
can
say
okay,
this
is
done.
You
can
now
close
this
window
or,
but
is
the
problem
that
we
want
to
redirect
them
to
the
emr
and
that's
what
they
have
to
wait
for.
A
So
so,
right
now,
if
we
look
at
you,
you
open
the
editor,
you
change
something
you
say
submit
changes
see
now
it
waits.
But
now
this
is
a
date
page
know
I
can't
well.
I
guess
I
can
make
changes
here.
I
don't
know
if
it's
gonna
take
it
or
not,
probably
not,
but
right
now
I
don't
know.
If
I'm,
if
I
move
away
what's
gonna
happen
here,
I
would
expect
that
if
I
go
to,
if
I
navigate
away
that
causes
a
page
load
that
will
probably
cancel
the
javascript.
A
That's
that's
kicking
this
off,
and
so
it's
gonna
somewhere
be
stuck
in
the
in
you
know
either
it
might
have
created.
The
branch
might
have
created
the
the
commit
already,
but
maybe
at
the
merge
request
that
was
created,
but
essentially
we
want
to
get
to
the
success
screen
that
tells
them
kind
of
like
you
know.
This
has
now
successfully
been
submitted.
You
know,
go
and
view
your
merge
requests
because
they
need
to.
They
need
to
assign
it
to
somebody
to
to
review
and
merge
it.
B
So
so
with
cited
in,
but
if
I
can
imagine
with
option
a
this
screen
appears
immediately,
but
it
just
doesn't
have
the
link
there
and
it's
got.
You
know
a
client-side
update
polling
for
the
marriage
request
to
be
created,
so
you
can
either
close
this
or
a
link
will
appear
here
in
a
moment
as
soon
as
your
marriage
request
is
created.
C
I
agree:
that's
actually
where
my
brain
was
too
and
what
I
was.
What
would
be
ideal
right
is
if
we
can
at
least
like
this
is
an
optimal
thought
anyway,
like
can
we
get
that
link
to
what
that's
going
to
be
like?
Can
we
somehow
generate
a
a
link
again
that
might
get
complex,
but
they
could
then
know
that
that's
the
link
they
need
to
go
to,
but
they're
at
least
have
confirmation
everything's
in
queue
everything's
good
to
go.
C
You
can
go,
do
your
other
tasks,
but
if
you
need
to
come
back,
that's
possible,
but
I
think
that
does
add
complexity,
but
basically
I
love
that
idea.
Chad,
that's
exactly
what
I
was
thinking
is
like.
We
basically
want
to
say
it's
in
queue:
it's
ready,
it's
going!
It's
just
taking
some
time
and-
and
so
I
think,
that's
a
great
step
personally,
but.
A
That
introduced
a
lot
of
technical
complexity
to
get
that
going
because
right
now,
you
know,
we've
got
three
api.
The
promise
chains
that
that
conflict
causes
us
to
be
in
the
loading
state
before
we
get
to
the
success
state.
Now,
how
do
we?
How
do
we
kind
of
like
kick
those
things
off
because
they're
all
synchronous
right
now,
you
know
you.
B
Simplify
because
you're
moving
all
of
that
to
a
single
atomic
background
job
to
say,
sync
on
the
back
end,
yeah
you're,
essentially.
A
Saying
pause
the
past
instead
of
the
client
now
making
the
the
api
calls
to
make
the
the
the
branch
to
commit
and
the
merger
quiz
you're,
making
a
call
to
the
backend
controller
to
say:
hey,
here's,
the
changes
persisted
for
me.
You
come
to
this
screen,
you
keep
pulling
for
for
status
for
progress,
and
you
you
kind
of
like
show
it
here.
When
it's
all
done,
then
you
show
the
view.
Merge,
request,
button
right.
C
Yeah,
whatever
makes
sense
like
technically
is
fine.
I
just
want
to
communicate,
there's
not
going
to
be
a
problem
for
us
to
obviously
just
change
the
view,
and
let
you
know
that
you
know
you're,
basically
at
this
state
except
there's,
instead
of
being
able
to
view
the
merge
request
button,
it's
loading
or
something
right
like
this
at
least
gets
them
to
the
point
where
things
are
in
queue.
It's
okay,
right
like
it
sounds
like
the
main
concern
is
like
it's:
okay,
you're,
not
gonna,
cancel
it.
B
The
if
we
leave
the
part
of
the
processing
on
the
client
side,
they
can't
cancel
it
because
we
have
to
at
least
wait
for
the
branch
to
be
created
before
we
can
create
the
mr
and
and
like
that,
so
moving
we
could
have.
We
could
eliminate
the
perceived
delay,
but
we
can't
allow
them
to
close
the
window
immediately
unless
we
move
the
api
calls
to
the
back
end.
I
think.
C
Oh,
I
see
you're
saying
sure
yeah,
that's
if
yeah
that's
how
we
have
to
technically
pull
it
off.
That
makes
sense
to
me.
B
C
Yeah,
like
the
simplest
front,
end
thing
would
basically
be.
We
still
know
it's
loading.
We
just
kick
you
to
this
screen
and
the
loading
state
is
no
longer
the
submit
button
at
the
bottom.
It's
your
view.
Merge
request
button,
like
that's,
probably
the
smallest
incremental
step
to
to
at
least
get
past.
Get
you
to
this
page
to
communicate
that
we
probably
have
to
change
the
copy
a
little
bit
right
to
like
communicate
that
it's
like
in
process
as
opposed
to
completed,
but
maybe
not
or.
A
My
question
is:
how
does
this
all
of
this
help
us
with
our
our
objective
here
of
bringing
in
this
the
ability
to
to
edit
the
merge
request,
title
and
description.
B
C
A
C
That
makes
sense
from
an
iteration
standpoint.
Yes,
that
would
be
the
first
step.
I
still
again,
it's
always
the
trap
with
the
complexity
and
obviously
we
won't
have
boring
solutions,
but
I
also
see
at
least
right
now.
C
My
vision
of
like
the
ideal
situation
is
what
you
said,
except
we
still
kick
off
the
mr,
the
first
two
pieces,
because
that
is,
you
know,
there's
parallel
work
that
can
be
done
and
then,
while
you
optionally,
fill
out
the
tyler
description,
only
then
do
we
kick
off
the
mr
again
that
adds
complexity,
but
it
at
least
allows
parallel
work
to
be
done,
but
that
would
be
a
follow-up
of
some
kind.
If
we
went
that
route.
B
So
the
the
reason
I'm
leaning
towards
a
is
because
it
avoids
the
downsides
of
like
if
we
want
to
give
the
control
of
the
branch
name
as
well
as
the
mr
like.
We
need
to
get
all
of
that
information
up
front.
Otherwise,
there's
the
the
possibility
of
an
orphan
branch
if
they
abandon
the
amr
creation
and
also
with
the
gmail
threading.
If
they
change,
if
we
pre-create
it
with
the
default,
then
we
change
it
and
then
there's
the
history
is
going
to
be
spread
across
two
gmail
threads.
B
C
That
might
be
an
assumption
that
I
misread
the
or
didn't
look
close
enough
to
the
mock-up
like.
Are
we
actually
allowing
the
branch
to
be
edited,
or
just
the
mr
title
and
description
so.
A
Right
now,
the
the
idea
is
only
to
do
the
the
mr
title
description.
However,
there
has
been.
I
know
that
some
users
have
mentioned
that
they
would
like
to
name
their
branch
as
well,
so
I
can.
C
Makes
sense
well,
like
I'm
saying
if
I
was
just
solving
for
the
title
and
description
that
I
would
ideally
like
to
kick
off
those
first
two
processes,
because
you
at
least
have
parallel
work,
while
they're
editing
the
mr
title
or
description
but
yeah.
If
we're
going
to
end
up
having
them
edit
the
branch
name
anyway,
then
that's
just
a
you
know
a
bottleneck
before
kicking
up
that
process
to
begin
with.
A
Well,
we
don't
know
if
that
is
coming
down
the
pipe,
because
we,
you
know
that
has
been
one
or
two
people
who've
asked
for
it,
but
it's
not
necessarily
the
majority
of
our
users
like.
If
you
look
at
the
our
target
users,
I
would
we
would
bet
that
the
majority
of
them
would
not
care
about
the
branch
name.
You
know
remember
we're
trying
to
abstract
away
the
git
workflow
complexities.
So
you
know
the
fact
that
you
need
to
create
a
branch
and
choose
a
name
for
it.
C
Yeah,
I
would
imagine
the
title
and
description
is
the
the
piece
that's
important
right
like
do
you
want
to
add
context
to
what
you
just
did
is
essentially
what
you're
saying
yeah
and
they
don't
care
whether
that's
manifests
through
a
branch
or
an
mr.
Those
are
things
again
yeah
going
back
to
your
point,
john
of
the
origins
of
this
is
we're
abstracting
away
get
stuff.
It's
really
about.
I
want
to
add
context
to
this,
or
I
don't
and
just
go.
Do
your
thing.
B
C
B
A
I
do
have
a
question.
It
feels
weird
for
me
to
have
this:
submit
changes,
bring
up
a
model
and
then
submit
changes
again.
I
almost
like
the
call
to
action
here
it
feels
like
it
needs
to
change.
Almost
I
don't
know
what
it
is
finished.
A
Yeah,
so
I
mean
this,
this
could
almost
be
like
finished
editing
or
save
changes.
I
mean
we.
We
also
want
to
think
of
the
you
know
like
down
the
line
we
want
to
have
be
able
to
resume
sessions,
editing
sessions
and
so
on.
So
maybe
something.
A
C
C
A
B
B
A
Oh,
I
also
just
want
to
copy
our
proposed
workflow
in
here
so
proposal.
The
current
default
should
be
agreed.
So
that's
the
proposal.
Let's
do
this
as
the
workflow.
A
One
user
opens
the
static
site
editor
and
makes
changes
to
user
click.
Submit
changes
model
opens
within
our
title
and
description.
Prefold
with
default
values
for
user
option,
changes
the
values
and
then
user
submits
values
if
they
submit
the
branch
commit
and
mergerquest
gets
created
and
the
user
is
presented
with
a
success
screen
now
if
they
close
the
model.
So.
C
A
A
There
are
actually
two
separate
issues
here,
so
I
think
for
for
the
for
this
specific
issue,
we're
not
going
to
deal
with
the
the
perceived
delay,
we'll
just
deal
with
the
work
with
the
actual
logic
flow.
So
one
one
of
the
questions,
though,
that
I
do
have
is
that
if
I
in
this
sequence,
if
I
click
close
here,
my
my
assumption
is
that
I
I
get
returned
to
the
editor
in
my
in
the
edited
state
that
was
so
no
branch
commit
or
mrs
created
that
do
you
all
agree
with
that.
A
C
Don't
I
think
it
should
be
an
optional
like
you're,
basically
you're
submitting
it,
and
it's
now
a
do.
You
want
to
again
from
a
ui
standpoint.
Do
you
want
to
add
context
to
what
you
just
did,
there's
no
backing
out
of
it?
A
Well,
so
that's
an
assumption.
We
can
make
that
you,
so
you
can
either
you
can
either
submit
it
with
it
with
changed
values
you
can
either
submit
it,
as
is
so.
If
we,
if
we
think
about
this,
so
you
click,
save
changes
or
submit
changes
in
the
editor.
Then
this
comes
up.
Then
this
is
already
pre-filled,
so
you
can
then
just
say,
submit
changes.
If
you
you
don't
have
to
change
anything.
A
So
it's
already
ready
for
you
to
submit
the
changes,
ignore
the
fact
that
it's
that
it's
great
out
there
just
look
at
this
last
one
without
the
progress
bar
you'll
you'll
just
say,
submit
changes.
But
if
I
close
this
model,
I
my
assumption
is
that
I'm
not
making
that
final
commitment
to
to
save
yet
and
I'll
return
to
the
editor
state.
So
I'll
return
to
this
state,
and
if
I
click
here
again
it
brings
up
the
modal.
If
I
close
it,
it
goes
back
here.
A
So
it's
basically
just
closing
this
dismissing
the
modal
and
not
triggering
the
creation
of
the
branch
to
commit
in
the
merge
request.
C
B
I
think
we
need
to
consider
this
in
conjunction
with
the
reducing
the
perceived
wait
time
because
they,
in
effect
reducing
the
perceived
weight,
affects
how
this
will
be
implemented.
If
this
model
comes
up-
and
we
don't
kick
off
the
api
calls
until
this
modal
is
completed,
then
it
will
work
the
way
that
you
said
it's
done,
and
we
should
update
the
ui
accordingly,
like
with
a
save
button
which
brings
up
the
modal
and
then
a
create
button
on
the
model.
A
All
right,
I
actually
think
the
discussion
we
had
now
really
shows
that
we
need
a
little
bit
more
thinking
from
a
ux
point
of
view
on
this.
Before
we
commit
to
a
technical
approach,
I
think
we
can
we
can.
A
We
can
definitely
take
what
we
have
right
now,
but
we
definitely
have
to
solve
the
intention
of
the
steps
you
know
like
when
you
know
in
the
sense
of
if
I
click
submit
changes
here.
Whatever
this
is
called
is
my
intention
that
I'm
I'm
committing
to
these
changes
or
with
the
fact
that
I'm
bringing
up
a
model-
you
know,
if
I
close
here
you
know,
do
we
assume
you're
just
canceling
the
fact
of
changing
the
the
opportunity
to
change
the
title
or
you
know.
Does
this
cancel
the
the
your
intention
of
committing
to
the
changes?
A
So
I
think
that's
that's
the
the
thing
that-
and
I
think
we
should
keep
this
back
to
michael
and
eric
tomorrow-
to
watch
this
recording
and
then
give
this
further
consideration.
C
I
think
that
makes
sense
yeah.
I
definitely
understand
the
concern
around
when
you
close
a
modal
with
an
x.
You
kind
of
expect
nothing
to
happen,
whereas
right
now
my
expectation
is
that
you're
just
opting
out
of
making
that
edit
and
it's
still
going
to
happen.
So,
however,
we
communicate
that,
but
obviously
that
does
conflict
with
the
fact.
When
you
hit
an
x
and
a
modal,
you
kind
of
expect
nothing
else
to
happen.
B
C
I
think
I
was
still-
and
I
agree
with
kind
of
I
agree
with
that
like
and,
as
I
mentioned
like,
that,
becomes
a
it
breaks
expectations.
I
was
still,
I
think,
kind
of
mentally
I'm
still
on
the
side
of
we
would
have
like
downstream.
If
we
in
iteration,
we
kick
off
the
two
other
steps
in
your
last
you're,
just
updating
the
fact
that
you're
editing
the
mr
or
not,
but
that's
not
what
we're
solving
right
now.
So
that's,
I
think,
just
kind
of
where
my
head
was.
A
All
right,
well,
gentlemen,
thank
you
for
your
time.
I'm
gonna
stop
the
session
here.
I
think
we
had
some
good
conversation
and
good
consideration
of
different
opinions
and
intentions
and
stuff,
and
I
I
think
we
are
it's
now
it's
at
a
good
point
where
we
can
give
feedback
to
michael
to
say
I
need
you
to
have
a
consideration
of
these
before
we
take
the
technical
planning
further
on
this.