►
From YouTube: Digital Experience Sprint Retro - Sept 8, 2022
Description
Digital Experience Handbook Page: https://about.gitlab.com/handbook/marketing/digital-experience/
A
Hi
everyone
welcome
to
digital
experience.
This
is
our
iteration
retro
meeting
it's
thursday
september
8th.
We
will
go
over
things
that
went
well.
This
iteration
and
some
things
to
improve
on
so
first
up
for
things
that
went
well
is
justin.
B
Yeah,
I
just
wanted
to
say,
like
our
ability
to
jump
on
things,
some
crazy
updates
and
changes
to
the
commit
landing
page
thanks
to
megan
for
being
on
the
spot.
B
I
have
a
follow-up
on
this
later
down
things
to
improve,
but
like
megan,
you
were
there
making
the
changes
as
they
came
in
right
on
the
spot.
So
thanks.
C
Oh
just
plus
one
thank
you
megan
for
your
patience.
I
really
appreciate
it
and
it's
been
really
chaotic,
so
just
a
lot
of
acknowledgement
and
thank
you
for
being
on
top
of
it.
D
Yeah
one
more
things
went
well.
I
just
wanted
to
do
a
shout
out
for
the
nav
team,
thanks
for
being
flexible
and
pushing
through
to
getting
that
that
nav
release
out
it's
a
big
one.
B
All
right
things
to
improve
on
kind
of
to
my
point
above
is
that
we
need
to
work
with
our
content,
owners
and
requesters,
not
always
bending
backwards
to
accommodate
their
massive
list
of
changes
all
the
time.
We
should
ask
them
for
consolidated
issues
of
all
the
changes
and
we
make
the
changes
and
then
move
on
to
our
next
issue.
Next
iteration
and
not
constantly
be
making
like
iterative
updates
for
these
pages
that
one
they
should
be
doing
and
if
they
can't
we
need
a
request.
They
consolidate
everything.
A
C
A
Well,
I
thought
it
was
more
of
like
a
stretch,
goal
kind
of
like
oh
I
see
but
but
yeah.
I
think
we
had
always
talked
about
kind
of
starting
this
work
for
localization,
but
now
this
needs
to
be
like
built
and
we're
having
meetings
with
smartlink
but
yeah
yeah.
Now
I
feel,
like
we've
got
like
a
due
date.
You
know,
like
it's
gotta
happen.
C
D
I
have
the
next
one
about
sprint
boards
and,
let's
kind
of
just
want
to
pose
a
question
out
to
the
team
is:
how
can
we
reduce
issue
carryover
from
iteration
to
iteration.
E
I
think
this
is
a
a
much
bigger
issue
and
I
added
some
points
underneath
as
well,
but
I
think
we
should
be
updating
the
boards.
I
think
there's.
I
think
the
issue
for
carryover
is
a
like
they're,
just
too
big,
so
maybe
we're
taking
on
work.
That's
like
months.
I
see
some
that
just
sit,
sometimes
we're
waiting
for
content,
we're
waiting
for
another
team
to
approve
like
we're
waiting
on
things,
and
so
what?
E
If
we
make
these
mars
or
these
issues
smaller,
so
they
fit
within
iteration,
because,
right
now
our
tracking
is
a
bit
off
like.
If
you
look
at
our
current
board,
I
think
we're
at
like
30
to
maybe
40
completion,
and
I
know
to
us
like
that-
doesn't
mean
much,
but
there
are
some
people
that
may
look
at
that
and
be
like.
E
Okay,
like
I
guess,
what's
happening
with
the
other
60,
so
I
think
we
need
to
stay
on
top
of
it
and
make
sure
we're
not
over
committing
like
sometimes
it's
better
to
under
commit
and
pull
stuff
in
than
it
is
to
overcome
it,
and
so
that
that's
just
my
thoughts
on
it
tyler.
I
know
you
have
the
next
point.
F
Yeah
you
sort
of
answered
that
a
little
bit
nathan,
I'm
just
curious
about,
like
the
numbers
like.
What's
the
actual
like.
What's
the
actual
problem
here
right
like
are,
we
is
the
problem
that
we're
carrying
over
60
every
single
week
and
like
like.
Is
that
an
average
right
like?
Is
that
true
like
like
what
are
the
actual
numbers
like?
F
What's
the
problem
we're
trying
to
solve
because,
like
I
don't
want
to
make
changes
or
like,
I,
don't
want
to
solution
something
without
like
a
clear
problem
statement
statement
and
if
it
just
like
feels
like
we're
carrying
stuff
over
like?
Is
that
really
an
issue
like
how
many
points
are
actually
getting
carried
over
every
iteration?
But
I
I
think
you
know,
I
would
guess
anecdotally
that
there's
probably
like
50
percent
kind
of
sounds
right,
but
nathan.
F
I
think
you
identified
things
that,
like
we
end
up
waiting
on
with
requirements
like
those
should
get
dropped
from
the
iteration
like.
If
I
get
tasked
with
a
thing-
and
I
end
up
in
waiting
like
out
of
my
iteration
right
like
that's
not,
I
can't
work
on
it
like.
If
I
can't
work
on
it,
then
it
shouldn't
be
on
my
list,
but
I
guess
my
question
like
like
lauren:
do
you
have
numbers
that
you're
thinking
of
that
are
the
problem.
D
F
I
think
the
first
like,
like
first
step,
is
like
get
the
numbers
like
get
the
historic
data
right
and
then,
like
second
step
is
like
like
set
a
goal
or
like
percentage
completion
or,
like
you
know,
percentage
carried
over
like
either
a
higher
completion
percentage
or
a
lower
carryover
percentage
like,
and
then
we
can
track
short
and
and
then
we
can
make
a
change
and
see
if
it
helps.
But,
like
I,
you
know
just
like
with
anything
we
do
with
our
okr's
like.
G
E
I
guess
this
is
another
point
where
we
can
step
back
and
see
like.
Why
are
we
doing
boards
and
I
think
the
decision
to
do
the
boards
was
to
just
get
a
a
fairly
accurate,
but
like
somewhat
like
not
super
granular,
but
to
understand
what's
going
on
iteration
iteration
on
our
team,
and
so
we
can
go
up
to
whoever
and
say
like
this
is
what
we
completed.
This
is
what
we
committed
to
and
if
that's
still
the
plan,
then
I
think
we
need
to
to
figure
out
this
carryover
thing.
E
C
I
know
like
for
a
fact
rey
does
so
that
this
is
like
data
and
information
that
he
generally
wants
to
see.
So
he
is,
he
has
requested,
like
burn
down
information
around
like
how
much
work
is
being
completed,
so
it
is
important
and
like
nathan,
to
your
point.
There
are
people
looking
at
it.
It's
like
we're
not
doing
this
for
nothing.
Yeah.
F
F
D
I
think
we're
in
that
process,
where
we
get
to
help
guide,
that
discussion
now
and
I
think
it'd
be
great
to
get
ahead
of
it
and
guide
it.
The
way
that
we
we
see
fit,
that's
going
to
help
our
team
work
efficiently,
yeah.
C
I
think
the
response
from
our
team
so
far
has
been
like
we're
not
at
that
stage
yet
to
for
this
data
to
be
accurate,
so
we
basically
want
to
set
our
team
up
for
success
by
getting
ahead
of,
like
lauren
said
getting
ahead
of
it
and
like
our
new
org
structure,
it
hasn't
even
been
a
quarter
that
we've
gone
through
this.
So
this
is
like
preliminary
and
like
just
area
of
opportunity
for
us
to
improve
on.
A
Tina
has
a
point
ahead
of
me
about
design
issues
carrying
over,
and
I
have
a
similar
point
that,
like
there
are
some
issues
that
I
think
by
nature,
are
just
going
to
be
longer
issues
you
know
maybe
like
with
design
I'm
talking
out
of
my
butt,
but
maybe
design
goes
a
lot
back
and
forth
with
yeah.
You
know
I
can
let
you
talk
if
you
want,
but
yeah
there's
a
lot
of
kind
of
back
and
forth.
Smartling
is
going
to
be
another
one
where
we
need
infrastructure.
A
I
don't
know
when
we're
going
to
get
that
resource,
we're
still
meeting
with
smartlink
to
figure
out
a
path
forward
like
I
expect
this
to
go
on
for
another
two
or
three
sprints,
not
that
it's
a
lot
of
work,
but
just
the
back
and
forth.
So
I
don't
know
the
best
way
to
handle
those
they're,
probably
going
to
kind
of
tank.
Our
numbers
a
little
bit.
D
Yeah,
the
I'll
just
go
out
and
turn
that
pia
smarling
poc
was
like
a
perfect
example,
one
that
I
could
see
going
to
the
end
of
the
quarter
and
so
me
and
laura
connected
on
that
and
yeah
we're
going
to
elevate
it
to
an
epic.
I
C
Something
yeah
absolutely-
and
I
don't
want
this
process
to
be
disruptive
to
your
to
anyone's
workflow.
To
be
honest
with
you,
it
shouldn't,
like
tracking,
shouldn't,
disrupt
y'all's
workflow,
but
the
the
point
is
not
that
we're
expecting
a
hundred
percent
all
I
issues
are
closed.
Every
single
iteration,
like
that's,
not
the
expectation
so
say
we
have
75
to
80,
completed
every
iteration
and
we
have
like
very
valid
reasons
of
like
why
there's
20
that
are
ongoing,
there's
a
sprintling
one,
design
issues,
etc,
etc.
That's
fair!
The
other
part
of
measuring
this
work.
C
A
I
would
tina
said
a
good
word
consequences.
I'm.
H
A
A
Something
like
you
know,
because
my
smartling
issue
stays
open
forever,
but
the
other
thing
I
kind
of
like
we
had
a
similar
kind
of
process
at
my
old
job,
and
it
got
to
the
point
where
they
placed
a
lot
of
importance
on
burndown
charts
and
so
at
the
end
of
every
sprint,
all
of
the
employees
were
kind
of
fudging.
Their
numbers
they'd
start
closing
things,
even
if
they
weren't
fully
done
yet,
but
they
didn't
want
that
issue
to
carry
over
and
they'd
address
it
next,
like
quietly,
create
a
fix
for
it.
A
Next
iteration
or
they'd
ping,
their
buddy.
Oh,
can
you
review
this
real,
quick
and
merge
it
in
and
whatever
you
know
like
it
starts
to
get
a
little
bit
like
you.
You
worry
less
about
the
good
work
that
you're
doing
and
more
about
like
how
it
looks
like
the
work
that
you're
doing
is
getting
done.
So
I
worry
about
the
importance
that
we
place
on
the
numbers.
I
love
it
as
like
insight
into
what
our
team
is
doing,
but
as
long
as
like
there
are
huge
consequences,
you
know
what
I
mean.
C
Yeah,
that's
that's
very
fair
feedback.
I
think
it's
like
you
said
it's
it's
insight
into
the
work
and
it's
a
lot
more
about
planning
the
work
like
we
know
we
can
expect
x
number
of
issues
to
be
completed
so
then
it
helps
like
myself
and
lauren
and
justin.
Like
report
back
to
the
leaders
to
say,
like
we
can't
work
on
xyz,
because
we
know
how
many
issues
we
can
complete
within
a
given
iteration
and
we're
already
at
that
limit.
C
Therefore,
like
we
can't
accept
new
work,
so
a
lot
of
it
is
capacity
planning
to
be
honest,
but
again
like
at
least
from
my
perspective,
and
I
think
lauren
and
justin
share
the
same
thing
like
we
don't
want
this
to
be
like
a
burden
on
anyone
and
like
we
want
good
work
and
that's
way
more
important
and
the
metrics
that
we're
improving
on
the
business.
Like
that's
key,
it's
not
about
how
much
work
we
do
it's
about
the
quality
of
the
work
and
like
we're
moving
the
right
metrics
in
that
way.
C
A
Yeah,
I
think,
ideally,
if
fills
lauren
and
justin,
if
you
keep
us
updated,
if
leadership
starts
to
look
for
specific
things
and
we're
not
hitting
targets
or
whatever
there's
problems,
let
us
know
yeah.
B
I
think
I
also
think,
like
their
leadership
is
just
looking
for
data
like
a
lot.
You
know
the
change
of
the
past
couple
months
in
our
leadership
in
the
organization,
not
just
in
marketing
but
across
the
board,
like
they
come
from
other
companies
that
have
used
data
differently
and
they
are
trying
to
see
like
if
that
works
well
and
get
lab
is
in
their
teams
now.
So
I
think
a
lot
of
it
is
like
they
knew
what
they
used
before.
Can
it
work
here?
B
They
want
to
look
at
the
data,
they
see
the
data
and
it's
not
what
they
expect
to
see
because
they're
used
to
something
different.
So
I
also
think
there's
a
some
level
of
like
education
across
the
board,
and
this
is
just
an
initial
like
you
know,
like
we
said,
like
keep
an
eye
on
it,
keep
it
on
your
boards.
B
E
D
F
F
You
know
this
is
the
first
time
I'm
really
thinking
of
it,
like
I
haven't,
looked
at
those
charts
in
a
long
time,
so
it's
like
it'd
be
great
to
think
about
like
it
looks
like
you
know,
looking
at
the
the
two
that
you
linked
here,
it's
you
know,
there's
like
51
percent
44
right
and
it's
like
what,
if
like
so
now,
I
have
a
benchmark.
I'm
like
okay,
that's
that's
right!
We're
at
roughly
half
so
maybe
30
is
a
goal
for
the
rest
of
the
quarter
like.
F
Can
we
get
it
down
by
20
percentage
points
right
or
up
or
whatever
the
direction
is
like
like
get
it
gooder
by
20
by
20
points,
20
20
points
gooder,
something
like
that.
It
would
just
be
nice.
I
E
Sure
I'll
jump
ahead.
I
know
I
brought
this
up
earlier
in
the
year.
I
want
to
add
an
in
review
column
tyler's,
saying
that
I
took
it
away.
You.
H
E
F
I
think
it
would
also
be
a
good
number
to
commute.
They
would
identify
bottlenecks
too
because
like
what,
if,
if
we're
looking
at
the
burn
down,
charts
and
we've
got
three
or
four
iterations
that
are
at
50,
but
then
we
hone
in
we
say
how
many
of
those
open
items
were
in
review.
We
can
say,
like
we
can
say
a
little
bit
more
with
nuance,
that
it's
not
just
like
items
not
completing
getting
pulled
forward,
but,
like
our
review
step,
is
a
bottleneck
right.
I
don't
know
that.
C
F
I
think
it's
like,
I
think
it
communicates
like
if
you
are
the
person
assigned
an
issue
and
you
put
a
review
label
on
it.
What
you're
saying
is,
I
did
my
work,
I'm
waiting
for
an
approval
like
and
that
might
be
design
review.
It
might
be
code
review.
It
might
be
some
other
stakeholder
like.
I
think
it's
just
a
like.
I
So
with
that
in
mind,
tyler
and
this
idea
of
in
review
that
might
help
our
design
issues
carrying
over
forever
and
now.
I
Just
since
I
have
all
your
brains
here,
I
don't
know
how
you
do
it
carrie,
but
I
keep
my
design
issue
open
for
maybe
too
long
like
usually
until
things
are
deployed,
because
that's
where
often
stakeholders
are
communicating
with
me,
I'm
wondering
if
in
review
would
help
or
if
we
just
close
that
issue
and
as
soon
as
I
ship
a
design
and
there's
an
engineering
issue,
I
open
a
feedback
issue
and
maybe
we
can
standardize
that
type
of
process.
So
the
design
issue
is
done.
C
Sorry,
I
just
can't
say
learner:
justin,
do
you
know
other
engineering
teams
operate
similarly.
B
I
think
we're
in
like
a
weird
spot,
just
because
of
like
what
we
do
and
like
we
have
so
many
outside
people
requesting
things
and
and
whatnot
that,
like
the
product,
probably
has
more
say
on
their
stuff.
But
we
get
a
lot
more
noise
coming
in.
B
I
wouldn't
say,
like
my
point,
and
I
think
that's
kind
of
somewhere
like
tina's
is
like
even
the
analytics
like
dennis
when
you
have
to
have
an
issue
open
to
like
collect
data
for
a
long
period
of
time,
like
that's
one,
that
figure
out
like
how
that
works
and
how
that
looks
on
their
boards
because,
like
our
burn
down,
charts
are
specifically
the
project.
H
Sorry,
am
I
next
or
milestones
do
we
use
that
or.
E
H
H
D
I
can
take
that
on.
That
is
an
action
item
to
just
start
that
conversation
and
research.
H
Okay,
I
wasn't
going
to
vocalize
this,
but
then
there
is
good
discussion.
So
I
think
I
should
I
guess
in
relation
to
the
sprint
boarding,
I
was
going
to
say
that
capacity
planning
as
an
individual
computer
can
feel
unfair
when
things
get
brought
up
mid-sprint.
So
what
I'm
meaning
is
like
if
we're
having
issues
with
like
burn
down,
chart
completion
rates,
but
things
get
brought
out
in
mid-sprint
or
it's
like
say
like.
H
We
need
to
release
an
events
page
because
someone
like
needs
that,
by
an
end
of
a
certain
point,
it
does
feel
like
we're
being
held
to
a
higher
standard.
That,
I
think,
is
fair
to
us,
because
it's
like
we're
being
asked
to
be
flexible,
while
also
being
judged
against
that,
like
sometimes
moving
target.
D
Yeah,
I'm
I'm
guilty
of
that
placing
issues
on
the
open
column.
I
know
I
asked
the
team
like
hey.
I
put
some
on
there
grab
him
if
you
feel
free,
so
I
will
stop
doing
that
and
I'll
put
all
the
issues
on
a
board
at
the
beginning
of
iteration
and
that's
that's.
The
iteration.
E
I
think
what
we
should
be
doing
too,
with
the
ones
that
come
in
is
making
sure
that
the
equivalent
weight
is
getting
dropped.
It's
like,
if
you
want
something
you're
going
to
lose
something,
and
so
I
think
we
need
to
figure
that
out
too.
Is
we
want
eight
points
so
four
days
worth,
we
need
to
remove
four
days
per
word
and
that'll
keep
our
numbers
the
same
and
it'll
also
be
like
hey.
C
I
agree,
I
think
the
only
other
thing
I
added
was
that
there
is
a
dex,
unplanned
label.
I
don't
always
remember
to
add
it,
but
if
you
are
being
asked
to
do,
work,
that's
being
brought
in
mid-spin
sprint
like
please
add
that
label.
So
at
the
end
of
the
iteration,
I
can
just
account
for
how
much
unplanned
work
was
brought
in
it's
just
like
a
visibility.
Transparency
thing
it's
like
the
like
just
so,
we
can
also
communicate
outwards
how
much
extra
work
the
team
was
doing
in
that
quarter
in
that
iteration.
B
I
think
we
also
take
into
account
that,
like
not
every
other
group
team
works
in
our
iteration
cycle,
so
like
this
kubecon
pigeon
javi's
working
on
like
it's
going
to
roll
over
to
next
sprint,
because
it's
not
due
to
next
print.
But
you
had
to
start
at
this
print.
So
there
are
certain
pages
that
certain
things
that
do
roll
over
and
that's
just
the
nature
of
like
the
work
and
then
kind
of
how
we're
doing.
Because
we
are,
we
don't
get
to
dictate
some
of
those
like
hard
due
dates.
D
D
E
G
E
I
E
G
I
I
G
I
E
I
guess
one
thing
just
to
add
about
the
whole
thing
is
like
no
stress
like.
I
know
it
seems
like
extra
process
and,
like
I
don't
know,
you
have
stuff
and
get
it
done
by
thursday,
but
it's
not
like
that
like
keep
working
and
and
doing
things
as
you
were
before,
but
I
think
we
should
be
a
little
more
cognizant
on
like
what
the
board
looks
like
at
the
end
of
the
the
two
weeks,
and
so
I
think
it's
just
a
little
more
housekeeping
and
I
just
yeah.
E
G
I
think
I
have
the
next
one.
My
point
is
just
that.
Is
there
a
better
way
to
communicate
when
a
component
is
already
being
used?
That
is
not
in
slippers
ui,
especially
the
new
ones
that
are
being
created.
It
happened
to
me
this
iteration
that
there
are
some
cards
that
are
going
to
be
used
in
the
features
they.
I
mean
the
solutions
page
that
I
started
to
work
on
and
then
I
realized
that
margaret
had
already
created
those,
but
it
was
not
merged.
It
was
not.
G
It
is
not
very
still
so
it's
not
live.
It
is
not
on
slippers,
so
I
was
just
wondering
if
it's
there's
any
good
way
to
communicate
that
a
component
that
is
in
multiple
designs
is
already
being
created
by
someone.
It
also
happened
to
john
with
a
component
that
I
created
and
that
one
is
harder
because
we
are
in
different
groups,
so
we
are
not
necessarily
looking
at
what
other
groups
are
creating,
so
he
had
not.
K
Yeah
so
in
that
case
it
happened,
since
we
did
the
full
migration
and
the
release
of
the
new
brand
of
gitlab.
K
We
did
a
lot
of
components
that
are
repeated
even
three
or
four
times,
and
there
is
no
easy
way
to
detect
that
there
are
replicated
components
all
across
the
project
and
we
have,
let's
say
more
than
100
components
in
the
project.
So
I
was
talking
with
with
mateo
about
some
solutions
that
we
can
think
about,
maybe
implementing
storybook
for
the
common
components,
and
in
that
way
we
can
see
what
what
components
we
have,
but
there
are
some
other
components
that
are
on
their
solutions
on
their
support
that
are
the
same.
K
But
as
we
are
different
groups,
we
do
not
have
a
way
to
know
if
another
group
did
that
component.
So
I
don't
know
if,
if
we
can
create
a
single
source
of
truth
for
our
components
and
check
this
component
is
here
in
this
in
this
folder
inside
the
project.
It
can
be
reused,
so
I
don't
know
it
would
be.
K
G
Or
maybe
at
the
figma
level,
when
when
a
component
is
placed
in
a
page
design,
maybe
just
to
mention
that
it
is
already
it
is
also
placed
in
another
page,
and
then
we
when
we
are
going
to
develop
it,
we
can
check
if
that
page
is
already
being
built.
So
if
someone
is
already
creating
that
component
or
is
already
created.
J
Yeah,
that
was
the
line
I
I
had
just
checking
in
figma
or
checking
with
a
designer,
I
feel
like
I
I
don't
know
could
be
making
this
up,
but
I
feel
like
our
designers
talk
to
each
other
and
that's
where
we're
getting
like
similar
components
from
so
it's
just
a
matter
of
ask
you're
designing
like
hey.
Was
this
component
used
anywhere
or
not
to
put
extra
work
on
designers
but,
like
you
could
also
just
label
hey?
This
is
used
elsewhere,
but
also
that
I
think
that's
a
mess.
J
Then,
if
you're
labeling,
every
single
thing
in
figma
like
this
is
used
on
this
page.
Like
that's
gonna
get
messy,
I
do
see
like
some
outliers,
and
this
is
a
bad
example,
but
the
only
one
I
can
think
of
is
like
the
frequently
asked
questions
component.
I
think
we
have
like
we
use
them
in
three
or
four
different
pages,
but,
like
some
of
them
are
used
differently
or
like
accordion
components
like
there's.
J
One
frequently
asked
questions
component
that
it
like
has
groups
that
can
expand
like
groups
of
questions
and
the
questions
themselves
expand,
and
it's
like
they're
so
similar,
but
like
the
functionality
and
kind
of
javascript
behind
it
is
like
more
messy.
If
you
keep
like,
if
you
have
to
specify
what
kind
of
frequently
asked
questions
component
you
want
to
use,
it's
like,
where
do
we
draw
the
line
of
like
hey,
just
make
a
different
one?
The
faq
is
probably
a
bad
example,
but
I
like
maybe
like
cards.
J
I
know
we're
having
like
trouble
with
like
cards,
because
we
have
so
many
different
types
right.
You
just
have
one
card
component,
that's
like
super
dynamic
and
messy
code
wise
to
handle
all
these
page
like
different
types
of
cards
across
our
site,
or
do
you
just
make
like
so
many
different
card
components?
F
Yeah
I
mean,
I
think,
like
one
of
the
things
I
think
nathan
did
a
really
good
job
job
on
on
this
most
recent
slippers,
iteration
that
we
should
like
extend
forward
is
like
oh,
like
the
core
set
of
things
that
live
in
the
slippers
like
node
package
became
like
a
much
slimmed
down
version
of
them
right,
they
became
like
sort
of
like
the
primitives
of
like
here
are
like,
like
the
containers
and
the
rows
and
like
some
typography
stuff
right
and
so
like.
I
think,
there's
a
little
bit
of.
F
If,
if
it
is
true-
and
I
don't
know
if
it's
true
but
like
if
it
is
true
that,
like
every
card
on
the
website,
looks
basically
the
same,
should
look
the
same
then
like
there
ought
to
be
like
a
slippers
component,
that
the
only
thing
the
component
does
is
look
a
certain
way
should
have
no
javascript
in
it.
Just
look
like
it,
they
should
basically
be
like
a
css
and
html
bundle
right.
F
It
should
do
zero
things
and
the
cool
thing
about
like
the
way
that
view
works,
is
you
can
like
pass
those
like
js
handlers
like
onto
them?
The
the
challenge
becomes
sometimes
when
the
semantics
are
different
right
because,
like
sometimes
we
treat
cards
like
buttons
and
sometimes
we
treat
them
like
links
and
like
that's
kind
of
weird-
and
I
would
argue
like
wrong
right
like
there's
like
some
weirdness
with
the
semantics,
so
you
can.
It
can't
always
work
like
that.
F
The
other
thing
you
know
think
about
like
custom
slots
too
right
so
there's
a
lot
of
cards.
I
think
that,
like
sometimes
we
put
like
icons
in
cards
and
like
top
right
or
sometimes
they
go
on
the
title,
and
it's
like
we
could
do
a
little
more
javascripty
viewey
stuff.
F
If
we
say
like
okay,
like
here's
the
card
component
and
it's
blank-
and
it
doesn't
know
anything
about
anything,
but
it
does
have
four
custom
slots
and
these
custom
slots
are
the
things
that
like
they
will
accept
content.
They
will
accept
other
components
and
we
can
style
them.
So
if
we
like,
like,
I
think
you
know-
maybe
the
thing
to
do,
and
we
should
do
this
across
like
like
this
is
why
we
do
slippers,
and
this
is
how
you
make
design
systems
work
right.
F
And
we
say
this
is
the
card
and
like
it's
in
zero
places,
and
we
put
in
like
one
two
three
places
and
we
do
it
kind
of
slowly
and
like
catch
anything
that
kind
of
breaks
or
changes
because,
like
oops,
we
forgot
an
abstraction
but
like
and
same
thing
for
all
the
other
components
but
like
we
do
on
a
smaller
set
of
components.
I've
gone
on,
but
that's
that's
sort
of
like
that's
the
work
we
just
got.
We
got
to
do
it.
F
I
think
this
is
the
thing
I
think
like
we
have
the
autonomy
to
do
it.
Michael's,
like
we've,
talked
about
this
like
this
is
like
that
20
time
like
this
is
the
friday
thing
so,
like
you
know,
maybe
tomorrow
or
next
week
or
whatever,
like
maybe
next
week,
because
we
we
just
are
talking
about
today,
but
like
next
friday.
Like
let's,
I
know
you
know
it's
no
meetings
but
like
this
isn't
a
meeting.
It's
a
working
session.
Let's
grab
like
four
people.
F
Every
every
squad
sends
a
person
to
go,
be
the
card
person
and
then
like,
let's
hack,
out
a
card
and
then
try
it.
If
it
doesn't
work,
then
we
just
don't
use
the
compo
like
we
don't
need
to
like,
swap
we
don't
just
find
and
replace
all
the
cards.
Let's
make
the
card
see
if
it
works
on
a
couple
pages.
H
E
I
completely
agree,
I
think,
there's
one
part,
though:
it's
that
we
can
create
a
basic
card
like
a
design
system
card
that
is,
like
you
said,
just
a
couple
slots
could
be
header,
footer
content
body,
whatever
you
want
to
call
it,
and
then
let's
say
we,
we
have
a
design
for
a
certain
variation
of
a
card
and
then
two
separate
people
go
and
make
that
variation.
E
So
now
we
have
two
variations
that
are
the
same
thing
but
coded
independently,
and
so
I
think
we
need
a
place
and-
and
maybe
this
is
what
I
was
subconsciously
thinking
when
I
made
that
compositions
folder
in
slippers-
and
that
is
maybe
for
those
unique
elements
like
every
unique
element-
is
just
displayed
in
storybook
somewhere.
So
all
those
50
variations
of
cards
are
there
and
so,
when
you're,
starting
something
you
can
go
there
and
see
like.
E
F
F
E
F
Different
cards
and
find
out,
if
that's
the
one
right
like
I'd
rather
so,
and
that's
kind
of
why
I
feel
like
like
we
should
we
really
should
be
like
no.
This
is
the
card
like
this
is
th.
You
get
one
card
from
slippers
and
if
you
got
to
do
something
else
like
you
do
it,
but
like
we
open
every
time,
anyone
ever
mod
augments
a
card.
They
augment
that
card
component.
I
Can
I
ask
a
question
so
I
think,
because
designers
are
kind
of
the
front
line
and
we
kind
of
see
what's
going
on
a
card
is
a
great
example.
If
I
see
something
or
I'm
using
something
that
I
know
exists
somewhere
and
then
I'm
like
hey,
I
know
this
is
on
this
page.
I
How
do
I
know
if
that's
the
right
version,
or
if
it's
like
with
without
having
that
source
of
truth
like
how
do
carrie
and
I
figure
out
and
jess
which,
which
page
or
which
component
to
point
to
if
it's
outside
of
storybook
the
card
is
a
great
example,
because
we
all
were
working
on
it
simultaneously.
I
Jess
carrie
and
I
and
then
whomever
picked
up
that
issue,
and
I
believe
it
was
margaret
started
working
on
the
card
and
then
the
issue
that
mateo
picked
up
was
two
months
later,
so
it
was.
I
think
she
was
doing
it
for
the
release
post
and
I
didn't
even
know
margaret
was
working
on
that.
So
we
had
no
real
way
to
know
that
mateo
was
going
to
duplicate
that
card.
If
that
makes
sense,.
I
Yeah
that
makes
sense
in
in
the
card
in
the
case
of
the
cards
the
design
that
yeah
it
was
just
like
a
flip
in
time.
Basically,
we
thought
one
thing
would
be
built
before
the
other
and
didn't
know
the
other
one
which
came
way
later
months
later
was
going
to
be
the
first
one
out
and
it
was
in
a
different
team.
So
we
didn't
know
it
existed.
I
didn't
know
it
existed.
J
In
the
figma
slippers,
I
don't
know
what
to
call
it
slippers
project
where
there's
elements
like
the
border,
colors
grid,
there's
components
for
them.
There's
blocks
so
cards.
Ctas
headers
quotes,
I'm
looking
at
quotes,
and
I
know
we
have
many
different
quote
components
or
looking
quotes
throughout
our
website
now.
Can
we
try
keeping
this
more
up
to
date
with
like?
Okay,
if
you
created
a
new
like
quote
design,
you
just
stick
it
in
here
and
then
we
can
like
probably
use
this
as
a
source
of
truth,
and
it's
like
all
right.
J
K
Yeah
we
were
thinking
the
same
with
mateo,
something
like
a
library
of
components
in
figma
or
in
the
project
in
the
project
would
be
a
lot
of
work
and
also
in
figma,
but
we
can
incrementally
add
some
things,
for
example
a
carousel
component,
so
we
create
our
figma
library
or
our
by
experience
component
library.
K
We
add
that
component
and,
for
example,
if
it's
in
figma,
we
can
put
the
url
to
the
project
where
that
component
is
located,
so
that
will
make
the
engineers
to
find
components
easily
and
also
for
designers.
The
designers
can
go
to
this
figma
library
with
components
that
we
keep
adding
and
they
can
know
also
that
this
component
exists
in
another
page.
K
We
don't
know
in
which
page,
but
we
have
the
url
for
the
component
in
the
project.
I
don't
we
can
elaborate
more
that,
but
I
think
it
would
be
a
good
start
point.
G
I
also
have
a
suggestion
there.
It's
related
to
something
that
came
up
in
our
product
marketing
meeting
earlier.
G
We
were
discussing
about
having
multiple
different
in-page
navigations,
and
I
created
this
issue
that
I'm
going
to
share
here
in
the
chat
just
to
track
the
navigations
that
we
already
have
in
case.
We
are
going
to
reuse
them
and
we
could
do
something
similar
for
components
that
we
realize
that
are
being
duplicated
and
we
could
have
an
epic
with
a
bunch
of
issues
inside
for
tracking
this
kind
of
components,
and
I
think
it's
easier
to
create
than
what
a
storybook
and
player's
experience
would
be,
or
maybe
a
figma
file.
D
G
Issue
this
issue
was
just
a
result
of
a
discussion
that
we
were
having
earlier.
It's
not
really
related
to
this
conversation,
but
it's
similar
it's.
This
one
was
because
we
have
multiple
in-page
navigation,
so
I
we
decided
to
create
an
issue
to
show
those
in-page
navigations
and
where
they
are
being
used
just
to
have
a
guide
as
to
which.
G
D
I
Yeah,
I
think
that's
a
good
point.
I
think
once
that,
because
I
think
that
issue
more
is
to
do
like
an
analysis
of
which
navigation
we're,
keeping
and
we're
going
to
reuse
and
which
ones
are
snowflakes
and
then
kind
of
once
that's
sorted,
is
it
handbook
or
is
it
do
we
need
our
own
pajamas
or
like
a
fully?
I
D
Very
good
point:
it
seems
like
an
action
and
we
can
do.
D
Discovering
a
way
to
document
the
best
way
for
this
were
quite
a
bit
over
so
I'll
put
that
action
in
there,
but,
let's
close
it
out
any
last
words.