►
From YouTube: UX Showcase: Redesigning merge request widgets
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
A
Well,
good
day,
I'm
jeremy
elder
senior
product
designer
on
the
ux
foundations
team.
Today,
I'm
going
slideless,
so
I
feel
a
bit
exposed.
So
I
can't
hide
behind
any
any
slides,
but
I
do
have
notes
so
I
will
try
to
stick
to
those
and,
as
story
mentioned,
I'm
going
to
discuss
redesigning
merge,
request,
widgets.
This
is
work
that
is
in
progress,
and
so
I
I
felt
it
more
appropriate
to
just
show
kind
of
my
desktop,
my
landscape
of
of
how
I'm
navigating
this
and
and
how
I'm
working
through
it.
A
So,
if
you're
not
familiar
with
this
kr,
it's
about
focusing
on
merge
requests
and
there's
consistently
like
a
negative
theme
around
it
in
both
sus
and
nps
related
to
merge
requests
widgets
and
what
we're
trying
to
solve
here
and
why
it's
important
is
from
a
from
a
ux
standpoint
is
that
merger
quest
widgets
are
they're
different
from
each
other.
There's
many
of
them
and
they're
often
overwhelming
with
the
information
they
display
and
it
leads
to
a
lot
of
confusion.
A
So
it's
important,
because
if
we
can
streamline
the
design
and
the
patterns,
then
it
should
be
ideally
make
the
information
more
clear,
consumable
and
actionable,
and
that's
really.
The
goal
is
to
synchronize
create
more
of
a
framework
around
how
these
widgets
display
their
information,
how
they
behave
and
go
from
there.
So
the
scope
of
this
from
a
polish
ui
and
text
is
to
address
nine
merge
request.
A
Widgets,
you
can
see
them
listed
in
this
table
out
of
scope,
would
be
approvers,
branches,
merge
and
pipelines,
because
the
the
type
of
content
that
is
in
those
are
completely
it's
different
enough
that
it
didn't
work
being
part
of
this
effort,
and
so
the
scope
will
be
to
create
a
framework
that
aligns
all
of
these
and
and
accounts
for
all
of
these,
as
well
as
their
various
states.
A
Some
of
the
constraints
that
we're
working
with
it's
just
the
fact
that
it's
a
large
number
of
widgets
and
each
of
them
having
their
own
states
they're
on
reporting
their
own
type
of
status,
there's
just
a
lot
there
from
a
scope
standpoint
and
also
the
the
fact
that
there
are
these
other
widgets
kind
of
waiting
in
the
wings
to
be
done.
Keeping
those
in
mind
peripherally
as
we
create
a
framework
just
for
these.
We
don't.
We
don't
want
to
have
like
two
well.
A
We
do
want
to
have
blinders
on,
but
not
too
much
so
that
we
that
we
make
a
pattern
or
introduce
something
that
that
these
won't
be
able
to
fall
in
line
with
later
or
or
work
with.
A
Another
constraint
is
it's
just
ensuring
that
the
framework
is
applicable
to
everything,
and
you
can
see
there's
a
lot
here
and
last
constraint
that
I'll
mention
is
just
consideration
for
other
issues
that
that
we
know
exist
in
the
product,
but
that
happen
to
be
surfaced
in
the
context
of
widget.
So
it
might
not
be
specific
to
a
widget,
but
it's
something
that
we
could
possibly
address
and
and
help
alleviate.
A
few
examples
would
be
using
the
x.
A
A
Another
item
kind
of
related
would
be
pipeline
status,
icons,
they're,
being
used
for
status
of
other
elements,
and
when
we
talk
about
that
in
the
context
of
of
merge
requests
and
widgets,
that
status
can
start
to
get
confusing
when
you're
trying
to
look
at
pipeline
and
then
there's
icons
that
relate
to
that
and
you're
familiar
with
it
and
there
are
different
places
and
then
another
one
from
a
ui
polish
standpoint
would
just
be
how
we
use
borders
and
how
we
group
items
how
we
contextualize
information.
A
A
So,
like
I
mentioned,
the
status
is
in
progress
and
I'll
just
talk
a
little
bit
about
my
process.
I'm
sorry
that
there's
not!
I
don't
have
like
monster
trucks
on
here
or
anything,
that's
gonna
pop
out.
I
wish
I
did
because
that
was
awesome,
so
good
stuff,
and
so
my
process
initially
was
to
review
the
research
that
that
katherine
put
together
there's
a
great
deck
it's
linked
to
in
the
agenda
and
it
walks
through
all
of
this.
I
won't.
I
won't
walk
through
it
again.
A
I
know
she
has
at
some
point
in
the
past,
but
please
take
a
look
at
that.
There's
a
lot
of
synthesis
in
there
a
lot
of
documentation
on
the
purpose
of
each
widget.
That's
very
helpful.
So
my
my
first
kind
of
foray
into
this
was
to
go
through
and
review
the
research,
the
kr's,
the
epic
pedro
created
a
a
fantastic
epic,
and
so
the
process
here
was
to
contribute
to
that.
I
created
my
own
issue
to
track
my
my
work
from
a
ux
foundation
standpoint
on
the
visual
design
aspect
of
it.
A
We
had
a
sync
kickoff
meeting
to
discuss
the
scope
and
address
questions.
I
I
found
that
the
the
sync
that
that
ian
helped
organize
was
was
really
helpful,
allowed
us
just
to
kind
of
air
a
few
things
really
quickly
and
and
handle
it
just
in
a
sync
fashion,
with
just
you
know
more
of
a
conversational
tone
as
part
of
the
process.
We
have
a
dedicated
slack
channel,
mr
widgets,
which
I
always
read
as
mr
widgets,
which
is
just
kind
of
fun
too.
A
I
guess-
and
we
have
plenty
of
async
discussion
in
there,
so
join
mr
widgets,
if
you,
if
you
want
to
participate
there-
and
I
want
to
call
out
ian
here
because
as
part
of
the
process
he's
done
a
great
job
kind
of
assembling
a
lot
of
data
and
doing
an
audit
of
existing
widgets,
all
their
states
pulling
in
the
designers
who
work
on
those
and
having
everybody
contribute.
A
And
one
of
the
reasons
that
we
wanted
to
highlight
this
in
in
foundations
is
because
it's
not
a
one-to-many
type
of
work,
it's
more
of
a
many-to-one
to
many
type
of
work
where
it
affects
multiple
teams,
multiple
stages
and
then
there's
also
krs
for
other
teams
that
are
dealing
with
performance
of
merger,
quests
and
other
things
around
this
to
help
with
the
sus
and
the
nps.
A
So
it's
a
really
good
example
of
the
team,
collaborating
on
a
single
problem
and
coming
together
on
it
and
then
being
able
to
to
propagate
those
decisions
and
have
that
funnel
out
and
or
filter
out
into
the
rest
of
the
product.
So
I
wanted
to
highlight
that,
let's
see
here
all
right,
I'm
gonna
put
pull
up
the
figma
inventory,
real,
quick.
A
Let
me
just
go
this
mode
here
and
widgets
that
are,
and
so
for
each
of
these
categories
we
have
all
the
states
captured
if
there's
any
notes,
conversation
updates
that
are
happening,
we're
capturing
these
and
then
as
part
of
that
effort
and
summarized
all
of
the
the
learnings
excuse
me
into
let's
see
here
the
synthesis
where
basically
calling
out
all
the
items
where
they're
the
same,
where
they're
different
it
dealt
with
headers
iconography,
all
the
text
and
the
structure
iconography,
if
I
didn't
say
that
one
already
color
status.
A
So
all
of
these
different
things
is
synthesized
into
action
items,
and
from
that
I
was
able
to
to
start
my
own
effort
and
and
clarify
my
let's
see
here
my
work
from
a
foundation
standpoint
and
have
a
scope
for
myself,
and
so
it's
part
of
my
process.
This
is
how
I've
kind
of
categorized
all
the
different
items
that
I
need
to
take
into
consideration.
A
So
what
I
focused
on
initially
here
is
jump
back
over
into
figma
some
design
exploration,
and
when
I
do
do
that
exploration,
I
like
to
start
kind
of
big
and
boil
everything
down
and
see.
What's
left
and
distill
it
and
then
try
to
work
back
out
so
very
much
a
divergent
convergent
type
of
a
a
workflow
specifically
when
it
comes
to
like
ui
design,
and
so
what
I
focused
initially
on
was
layout
and
determining
structure,
responsive
behavior,
where
these
widgets
live
kind
of,
what's
their
environment.
How
are
they
behaving
with
other
content?
A
I
focused
on
hierarchy
and
content,
relationships
iconography
and
then
a
big
focus
on
communicating
what
my
ideas
behind
it
and
inviting
feedback.
So
let's
jump
in
here
just
to
show
that
a
little
bit
so
you
can
see.
A
I
brought
in
my
list
from
my
my
issue
that
lists
out
the
items
I'm
focused
on
and
started
to
break
out
some
of
these
items.
Some
of
them,
like
I
mentioned
they're
in
progress,
so
you're
not
going
to
see
anything
there
yet,
but
understanding
that
we
want
to
have
more
of
a
responsive
behavior
for
these,
so
laying
out
the
structure
with
frames
to
address
that
we
have
both
fixed
and
fluid
preferences
for
layout,
and
these
widgets
respond
to
that.
A
So
I
want
to
make
sure
that
we're
counting
for
that
and
how
content
reflows
and
how
far
apart
actions
can
be
from
their
parent
and
our
status.
Things
like
that
wanted
to
take
into
account
spacing
utilities
create
a
like
a
universal
action
bar
that
I
can
pull
into
some
of
these
items
so
really
just
starting
with
some
initial
testing
and
hierarchy
and
flow.
A
I
took
that
into
some
more
exploration
where
I
looked
at
indentation,
specifically
so:
com,
compact,
optimized
or
just
purely
cascading
nesting,
and
and
putting
these
things
through
their
paces
and
seeing
you
know
what
works
best.
What's
going
to
flow,
what's
going
to
be
more
readable,
getting
feedback
along
the
way
and
then
iconography
so
exploring
using
the
the
smaller
status
icons.
A
And
how
might
we,
you
know,
take
those
and
maybe
add
a
highlight
to
emphasize
the
the
parent
item
while
continuing
the
nested
in
the
sub
items,
comparing
that
with
current
icons
and-
and
I
haven't
really
explored
this
direction
quite
as
much
just
yet,
primarily
because
I
don't
like
mixing
two
icon
sets.
So
some
of
this
I'm
kind
of
treeing
off
and
and
pruning
along
as
I
go,
you
can
see.
There's
some
exploration
here
for
status.
A
So
with
this,
I
found
that
I
had
a
lot
of
thinking
behind
this
and
just
throwing
a
barrage
of
comments
on
here
wasn't
really
what
I
wanted
to
do.
I
wanted
it
to
feel
a
little
more
fluid,
so
I
gave
fig
jam
a
little
trial
and
started
just
sketching
some
notes
on
top
where
it
pulls.
You
know
the
design
straight
from
my
working
file,
but
then
I'm
able
to
kind
of
call
out
a
few
things
and
you
know,
pose
some
questions,
get
some
additional
feedback
and
work
through
it
in
that
fashion.
A
So
what
I
plan
on
doing
is
continuing
exploration
here
and
with
the
sad
departure
of
ian
that's
gonna,
be
you're
gonna,
be
missed
on
this
project,
we're
going
to
be
trying
to
to
assimilate
some
of
these
ideas
and
present
them
to
the
designers
that
we
can
get
some
feedback
with,
hopefully
next
week,
at
the
soonest
and
and
start
to
to
assimilate
these
and
and
gets
more
conversation
through
figma
on
that
verify
an
idea
or
concept
of
a
framework
with
those
different
teams
hoping
to
do
some
validation
testing
before
before
the
end
of
the
milestone
and
then
another
item
I
wanted
to
call
out,
you
won't
see
it
presented
here
but
part
of
handoff
how
we
get
this
work
to
other
teams,
because
the
challenge
next
becomes.
A
So
I
want
to
show
the
content
relationships
both
from
an
individual
widget,
but
also
as
a
set.
So
if
we
we
say,
okay,
a
group
of
widgets
is
an
unordered
list
and
each
one's
a
list
item
and
there's
these
items
that
are
interactive
and
these
that
aren't
what
would
we
call
it
from
a
region
standpoint
or
you
know,
semantically?
A
A
So
I
want
to
make
a
a
really
clear
and
concerted
effort
to
do
that,
so
that
all
teams
have
the
same
kind
of
mindset
behind
how
we
implement
these,
because
it
will
be
different
teams
that
go
ahead
and
code,
these
up
and
update
them,
and
another
idea
that
that
someone
mentioned
apologies
for
not
remembering
who
specifically
was
to
roll
out
these
updates
behind
the
feature
flags,
so
that
we
can
do
one
at
a
time
but
behind
the
feature
flag,
so
that
when
we
release
it
all
the
updates
come
in
at
the
same
time
and
and
that'll
effectively
allow
us
to
to
see
the
changes
in
line
and
and
work
through
that,
let's
see
here,
another
next
step
would
be
to
create
epics
and
issues
for
those
teams
to
work
on
that.
A
I
also
plan
on
with
the
framework
and
the
work
in
figma,
creating
a
figma
assets
that
are
pretty
robust,
where
you
might
be
able
to
configure
a
widget
very
quickly,
whether
it's
new
or
for
state,
so
that
any
any
designer
can
either
create
a
new
type
of
widget
or
represent
their
current
widget
in
any
state.
Any
kind
of
layout
in
any
screen
moving
forward.
So
hopefully
we'll
have
those
assets
in
there
as
well.
That'll,
be
really
robust
and
then
pajamas
documentation
around
just
merge,
request,
framework
and
widgets
so
a
lot
there.
A
B
Yeah
I
I
echo
your
last
thanks
and
also
I
wanted
to
shout
out
to
amy
for
her
leadership
in
the
ux
writing
front,
which
will
be
a
very
important
part
of
this
work,
because
text
is,
is
what
users
appreciate
hands
more
than
anything
else,
and
also
from
the
accessibility
front,
it
will
be
very
important
yeah.
So
I
don't
have
any
specific
questions.
Let's
see
what
other
questions
people
have,
but
thank
you
so
much
also
to
you,
jeremy,
for
the
presentation,
the
work
you've
done
ian
and
all
the
designers
that
contributed
to
the
audit.
C
A
Yeah,
I
think
that
that's
pbd,
but
that
would
be
my
plan.
I
know
we've
had
some
discussion
on
regions
and
layouts
and
different
and
then
objects,
so
we
have
a
few
things
working
in
pajamas
that
are,
I
I
think
that
we're
going
to
have
to
clarify
so
where
this
lives,
I
think,
is
to
be
determined.
But
yes
that
concept,
I
think,
is
what
will
move
towards
having
exist.
A
D
Yeah
hey:
this
is
such
a
huge
initiative.
Thank
you
for
for
tackling
it.
There's
there's
a
lot
of
parallel
efforts
going
on
at
least
I
know
within
secure
and
protect
I've
been
collaborating
with
with
pedro
and
then,
of
course,
as
part
of
that
that
figma
I've
been
adding
in
a
lot
of
screenshots.
There's
there's
a
lot
of
ongoing
efforts
as
well.
So
I
will,
you
know,
continue
to
update
those
as
as
things
progress,
but
one
thing
I
did
want
to
call
out
which
I
mentioned
in
the
agenda.
D
D
They'll
sometimes
interpret
that,
as
all
is
good
here,
no
security
findings
were
found,
no
vulnerabilities
were
found,
and
so
that's
something
that
we've
tried
to
tackle.
I
know
camellia
has
done
a
lot
of
work
with
exploring
different
iconography
to
try
to
communicate
like
yes,
hooray
good,
like
job
past,
which
means
that
you
know
that
it
that
in
it
of
itself,
is
a
success,
because
you
can
configure
scanners
in
a
lot
of
different
ways
and
sometimes,
if
they're
configured
in
a
way
that
causes
the
the
job
to
fail.
D
That
you
know,
that's
obviously
something
we
need
to
communicate
like
it
needs
to
be
configured
properly
and
play
well
with
with
ci
cd.
But
how
do
we
show?
Yes,
you
know
it
ran
successfully,
and
yet
there
were
vulnerabilities
detected.
That's
something
that
I
think
keeps
popping
up
here
and
there.
So
I
know
I
just
wrapped
up
the
sas
to
complete
cms
and
application
security
analysts
engineers
who
are
familiar
with
ci
cd
and
familiar
with
apsack.
D
They
understand
these
concepts,
but
there
was
somebody
new
on
a
team
and
she's
a
developer
who
just
got
out
of
the
boot
camp,
and
so
I
saw
her.
I
asked
her,
you
know:
are
there
any
security
vulnerabilities
in
this?
Mr
and
she
said,
nope
green
check
mark
looks
good
and
it's
like.
Oh
yeah,
that's
not
what
that
means.
D
A
No,
I
think,
that's
that's
helpful
and
that's
one
of
the
next
steps
just
going
back
to
this
and
that
I've
with
the
owl
scout
for
is
to
help
identify
what
the
statuses
are
and
how
they
bubble
up
so
is.
Is
this
at
the
parent
level?
Does
this
mean
that
this
is
the
highest
warning
or
alert
of
anything
within
or
can
we
have?
A
You
know
severe
things,
but
it's
only
a
warning
because
it
doesn't
stop
the
pipeline
and
what's
the
relationship
to
the
pipeline,
so
as
part
of
the
framework,
I
want
to
help
create
general
rules.
That
would
hopefully
address
something
like
that,
as
far
as
when
does
something
trigger
a
failure
or
a
block
in
the
in
the
merge
request
versus
when
is
something
a
warning
that
can
be
continued
versus.
A
When
is
something
successful,
but
there's
still
things
that
are
failures
within,
and
so
I
think
that's
that's
part
of
this
and
hoping
to
get
some
more
feedback
on
that
and
work
through
that.
I'm
going
to
try
with
the
rest
of
this
week
and
early
next
to
kind
of
assimilate.
A
What
I
have
in
my
mind
and
then
we'll
put
that
out
for
some
feedback
and
reaction
that
we
can
work
through
and-
and
it
might
be
nuanced
where
you
know
some
widgets
they're-
never
going
to
trigger
a
failure
and
they're
never
going
to
see
this
blocking
status
of
the
mr,
but
they're
still
going
to
experience
other
failures
within,
and
so
how
do
we
adjust
those
rules
and
have
kind
of
a
decision
tree
of
that?
So
I
appreciate
you
calling
that
out
and
that's
something
that
I'll
be
sure
to
to
involve
you
in
next.
D
Week,
actually,
I
just
I
just
realized
that
this
is
something
that
I
haven't
put
into
the
figma
yet
but
security
approvals
and
vulnerability
checks.
I
mean
there's,
there's
a
lot
of
different
configurations
that
somebody
can
set
up,
so
you
can
configure
your
project
so
that
if
a
particular
type
of
job
fails,
then
the
pipeline
fails.
D
So
that's
something
else
that
needs
to
be
communicated
in
addition
to
certain
policies,
and
I
know
that
the
the
protect
team
is
working
on
more
policy
management
stuff
that
will
be
released
soon
and
so
right
now
that
we
have,
you
know
security
approval
so
that
if
a
security,
vulnerability
of
critical
high
or
unknown
status
is
detected,
you
can
enable
it
to
block
the
mr
from
being
merged
until
a
approver
comes
along
and
says
you
know
it's
okay
to
merge
so
I'll
just
go
into
the
figma
and
make
sure
that
that
is
also
captured,
that
approval
section.
A
That's
helpful,
that's
helpful
and
yeah
and
part
of
this
effort
not
to
dumb
it
down
for
lack
of
better
term
but
will
be
to
just
to
say:
hey
we're
just
gonna
use
these.
These
are
our
statuses,
and
this
is
what
it
looks
like
and
really
place
some
some
extra
emphasis
or
weight
on
the
content
that
that
I
know
amy's
working
on,
so
that
we
can
make
sure
that
the
language
around
it
is
clear
and
and
hopefully
communicate
those
types
of
scenarios
because
yeah
it
gets
complex,
pretty
quick.
B
Yeah
one
one
little
bit
of
context
that
I
wanted
to
add
as
well
in
in
the
periphery
of
the
work
that
jeremy,
ian
and
amy
are
doing
here
is
the
also
understanding
what
is
beyond
this
work.
So
right
now
we're
doing
this
mostly
polishing
of
the
current
experience,
not
only
visually,
but
also
in
terms
of
writing,
so
that
it's
as
low
effort
as
possible
with
the
biggest
gain
possible.
B
But
at
the
same
time
we
have
research
that
catherine
did
and
jeremy
showed
a
little
bit
of
that
initial
synthesis,
and
she
also
did
some
interviews
about
how
engineers
use
the
widgets
and
which
points
and
how
valuable
they
are,
and
in
turn
that
will
allow
us
to
redesign
the
widgets
in
a
more
innovative
way,
with
more
data
to
back
it
up
and,
at
the
same
time,
we're
tracking
more
and
more
the
actual
interactions
that
people
have
with
the
widgets
themselves,
because
we
don't.
B
B
So
what
I
want
to
get
at
is
that
we
have
this
work
that
will
be
for
the
mid
long
term,
vision
of
merge,
request,
widgets
and
and
jeremy's
doing
all
of
this,
and
I
was
talking
with
ian
about
it
and
he
actually
asked
me
so
why,
like?
Why
are
we
doing
this
now
and
investing
this
effort
in
in
doing
this
polishing,
where
maybe
we
end
up
knowing
through
research
that
we
actually
need
to
redesign
all
of
the
widgets
or
put
them
all
behind
the
tab
or
put
them
in
another
location
in
the
sidebar?
B
Or
I
don't
know
and-
and
I
think
that's
a
very
good
question,
because
it
it's
just
about
the
efforts
that
it
takes
us
to
create
value
and
the
time
that
we
rob
users
from
that
value
right.
So
we
could
say
we're
not
going
to
do
any
of
this,
but
we
would
spend
months
researching
and
redesigning
all
the
widgets
to
then
release
them
and
have
a
big
impact.
But
what
we've
decided
to
do
is
we
acknowledge
that
there
are
things
we
can
do
now
that
are
small
and
that
will
have
a
big
impact.
B
So
let's
not
rob
users
of
that
value.
While
we
work
on
the
other
things,
and
maybe
it
will
invalidate
all
of
jeremy's
work,
I
don't
think
it
will
and
nor
the
the
work
that
amy
is
doing.
I
think
we
will
learn
a
lot
from
this
to
apply
in
the
future,
but
nonetheless
I
think
that's
a
really
important
lesson
about
iteration
and
yeah
and
not
robbing
users
from
value
in
that
iteration
process.
So
I
just
wanted
to
share
that
context
about
why
we're
doing
this.
This
way.
A
Yeah,
I
that's
super
helpful
and,
to
that
point
yeah
it
would
be
awesome
to
have
so
much
more
like
input
now
before
we
do
this
and
how
I
view
like
system
thinking
and
approaching.
This
is
that
right
now
there
is
no
system,
and
once
we
get
all
of
the
the
widgets
on
the
bus
tracking
down
the
highway
in
the
same
direction,
we
can
then
say
well.
We
need
to
divert
we
need
to
go
off
this
ramp
or
go
off
this,
but
everything
is
there
together
doing
it
the
same
now,
so
we
can.
A
We
can
have
everything
pivot
together
and
and
continue
to
move
forward
in
a
synchronized
way
rather
than
everybody's
in
their
own
lane
doing
things
you
know,
trying
to
get
to
the
same
destination
and
trying
to
navigate
once
we're
able
to
have
a
system
approach
to
this
we'll
be
able
to
be
a
lot
more
flexible
and
iterative
in
the
future.
B
Yeah
and
one
last
thing
I
want
to
hijack
this
a
lot,
but
one
last
thing
I
just
wanted
to
do
to
mention
is
also
thank
you
to
tori
for
creating
space
for
jeremy
to
work
on
this,
and
I
hope
that.
B
Well,
you
don't
have
a
lot
of
people
in
the
ux
foundations
team,
but
I
hope
that
over
time
either
with
the
people
that
we
have
today
or
with
more
people
that
we
can
invest
in
more
of
these
initiatives,
where
we
ask
for
help
from
the
ux
foundation
team
and
from
people
that
are
outside
of
the
usual
stage
group
work
and
can
lend
their
expertise
into
these
very
important
areas.
D
Yeah,
I
was
just
wondering
if,
if
we're
planning
on
doing
any
solution,
validation
from
any
of
the
work
that
will
come
out
of
this,
whether
it's
a
complete
you
know,
re-architecting
or
you
know,
iconography-
is
that
going
to
be
part
of
this
initiative?.
A
I
I
hope
so
I
don't
know
if
ian
or
pedro
you'd
probably
be
better
suited
to
jump
in
in
relation
to
the
entire
epic.
If
you're
able
to.
A
Okay,
I
that's
that's
my
hope,
as
as
the
next
step
would
be
able
to
validate.
This
is
as
leanly
as
as
possible
to
keep
it
moving,
but
yeah.
I
won't
ramble
on
that,
but
yes
short
answer.
Yes,
I
hope
so.