►
From YouTube: Digital Experience Retro Video April 22, 2021
Description
Sprint Retro Doc: https://docs.google.com/document/d/1kMNiUF2UDuSrMDuzLyRi8OEhVxry_MJoYi38RmmWafY/edit?usp=sharing
Digital Experience handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/
Inbound Marketing handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/
A
B
Yeah,
just
briefly,
we
had
our.
We
had
an
awesome
like
block
of
okr
planning
for
q2.
I
thought
that
it
just
went
phenomenally,
I'm
feeling
so
optimistic
about
the
next
quarter.
I
feel
like
we
did
a
lot
of
really
good
team
building.
It
was
so
it
was
worth
the
time
it
was
awesome.
It
was
great.
So
that's
all
thanks
for
everyone
for
doing
that.
C
I'm
next,
what
well
well
for
me
was
assigning
weight
to
mr
reviews,
which
I
wasn't
doing
before,
because
they
weren't
associated
to
issues
that
are
assigned
to
me
necessarily
or
epics.
I
felt
that
I
was
just
able
to
be
quicker
to
respond
to
mrs.
Instead
of
you
know,
24
hours
going
by,
I
could
actually
respond
within
the
hour
and
then
set
time
aside
to
be
thoughtful
about
my
my
my
reviewing
and
my
answers
and
the
feedback
that
I'm
giving.
C
A
A
D
Same
as
yourself
cross
functional
stuff,
it's
going
of
cropped
up
a
little
bit
through
my
okr
that
it's
touching
on
content
and
then
technology,
just
like
different
departments.
So
content
team
are
very
easy
to
talk
and
very
easy
to
just
get
in
touch
with
them.
They
have
all
the
information
that
you
need
and
they're
always
open
to
suggestions
and
help
and
all
the
things
that
we
can
talk
about
so
yeah,
that's
that's
the
main.
The
main
thing
that
went
well
for.
B
Yeah
see
that's
a
good
discussion
in
here.
I
think
this
is
a
small
change
and
I
don't-
and
I
might
even
like
this
might
even
actually
still
be
true,
and
I
just
need
someone
to
tell
me
like
I,
so
we
like
do
our
iteration
planning
on
like
a
monday
right
and
then
there's
a
week
and
then
there's
another
week
and
we
do
our
release
stuff.
So
I'm
like
wednesdays.
We
have
a
reminder
of
like
okay
release
async
like
tell
us
about
your
releases.
B
Thursdays
we'll
have
like
we
have
show-and-tell
in
the
morning
and
then
we
like
do
a
release
post
and
then
we
do
this
and
then
that
friday,
I'm
like
like
on
fridays.
I've
been
like,
like
I'm
like
okay,
I
brainstormed
for
planning
on
the
next
on
the
upcoming
monday,
but
it's
like
a
focus
day.
Yeah
like
gitlab
broadly
and
like
I
love
that
I
love
that
I
never
have
meetings
on
fridays.
B
I
get
a
lot
of
work
done,
but
I
feel
like
I'm
just
missing
that,
like
I
feel
like
I
have
to,
I
end
up
feeling
rushed
on
wednesdays
because
I'm
like
I
gotta,
get
this
in
today,
because
I'm
all
I'm
gonna
do
on
thursday
is
talk
about
it.
I
can't
really
work
on
it
thursday
and
then
there's
this
like
block
of
time.
That
feels
like
sacred
to
me
that
I
just
don't
get
to
like
it
doesn't
happen
in
this
iteration.
B
It's
not
a
part
of
the
next
iteration
and
it's
like
kind
of
like
these
agency
days,
but
like
we're
getting
like.
I
just
like
I
get
weirdly
stressed
out
on
wednesdays.
I
just
feel
super
flustered,
and
I
also
find
that,
like
you
know,
we
have
the
family
and
friends
days
which
are
usually
on
fridays
and
then
so
it's
like
like.
I
want
my
no
meeting
fridays.
I
just
I
just
want
it.
B
I
just
want
those
I
want
them
in
the
iteration
and
I
think
the
only
change
that
I
personally
need
like
if
you
look
at
the
dates
on
the
top,
like
retro
012
the
heading
here.
If
this
22
was
a
23
or
like
a
25,
because
the
milestones
the
marketing
milestones
are
pinned
to
the
sunday,
I
could
just
be
like
yeah
yeah.
I'm
gonna
finish
this
like
on
time,
because
I
have
that
friday.
So
you
know
that's
just
a
me
thing
like.
B
I
also
know
that,
like
I
need
to
have
more
chill
about
like
due
dates
and
like
working
things,
so
I
don't
want
to
pitch
like
a
whole.
I
don't
know
if
this
needs
to
be
a
huge
like.
I
don't
think
it
has
to
be
a
change
and
again
maybe
this
is
already
the
case,
and
I
have
a
misunderstanding
about
things.
I
just
really
love
to
have
like
two
potential
work
block
fridays
within
an
iteration.
Even
if
I
take
one
off
for
family
and
friends
or
time
off,
I
just
want
the.
B
E
E
B
That
may
and
that's
that
makes
a
lot
of
sense
like
I
could
just
like
scope
back
a
little
bit
more
and
and,
like
I
said
before,
like
I'm,
I'm
still
feeling
like
I'm
not
nailing
it
on
my
scoping.
So
I
think
I
just
need
to
continue
to
like
work
on
myself
to
like
commit
to
a
little
less
each
time.
But
I
do
you
know,
like
I
really
really
like.
B
I
love
a
day
where,
like
no
one
can
book
a
meeting,
and
I
can
just
work
like
like,
even
even
if
I
like
scope
back
like,
I
still
want
the
option
to
do
that
and
it
feels
like
you
know,
like
you
said
like
on
tuesdays
or
like
any
or
like
yesterday.
Like
I,
the
meeting
with
cloudinary
like
I
was
like.
Oh
like
this
is
like
totally
cool
like
I
just
feel
like.
Oh,
like
monday,
through
thursday,
people
are
welcome
to
drop
stuff
on
my
calendar
and
I'm
like
cool.
B
That's
fine,
it's
not
friday,
and
I
just
kind
of
want
to
like
keep
friday
as
like,
really
focused
work
time
and
it's
great
to
like.
Take
it
off
have
family
and
friends
day,
but
if,
like
it's
always
off
for
me,
then
I
never
have
a
focus
time
day
and
then
I
have
to
like,
maybe
like
artificially
say,
like.
Oh
tuesdays
are
my
focus
time
day,
but
now
I'm
like
impacting
other
people's
requirements
of
the
sync
time
they
need
from
me
so
again
and
again
milestones
set
to
the
sunday.
B
C
You
know
thursdays
are
right
off
most
of
the
time
and
I
think
that
the
reason
it
was
set
that
way
and
I'm
making
an
assumption
here
is
because
agency
day
was
something
different,
at
least
for
me
when
I
first
started
now,
they're
integrated
into
our
sprints
and
they're
no
longer
like
okay
come
to
me
with
what
you
got.
You
know.
E
To
rebuttal,
with
the
releasing
on
friday,
I
would
like
us
to
not
get
in
the
habit
of
showing
stuff
on
our
release:
videos
that
isn't
deployed
onto
the
live
website,
because
there's
lots
of
things
that
can
happen
in
that
that
time
frame
of
actually
getting
it
up
on
the
website.
It's
okay!
If
it
happens
a
little
bit
here
there,
but
I
wouldn't
want
us
to
get
into
that
habit.
E
F
Just
a
real,
quick
heads
up,
I
I
totally
am
on
board
with
like
we
can.
We
can
change
how
we
plan
to
do
things
because
it
is
stressful
to
release
or
to
rush
at
the
end
of
the
week
and
try
to
get
things
done
on
friday,
but
friday's
not
really
part
of
things.
However,
just
be
aware,
we
don't
want
to
release
on
fridays
because
weekend
and
if
something
goes
wrong,
then
we
got
to
fix
it
and
we
don't
want
to
mess
with
our
weekends.
F
I
would
be
inclined
to
say:
hey
monday
is
our
release
day,
and
that
way
we
can
have
friday
to
work
on
things
and
then,
if
we
need
to
release
on
monday,
that's
totally
fine.
That's
expected,
however,
that
also
encourages.
I
don't
want
people
working
on
the
weekends,
so
food
for
thought.
Whenever
we
do
it,
we
just
need
to
be
careful
about
not
encouraging
bad
habits.
Like
you
know,
friday
releases
and
working
over
the
weekend
and
stuff
like
that,.
B
Yeah
and
that's,
I
think,
like
also
to
keep
it
as
a
really
small
iteration,
like
I
I'm
not
proposing.
We
change
our
release,
videos
or
even
our
like
release
date.
I
just
want
to
like
count
friday.
I
just
want
it
to
count
right
like
right
now
I
feel
like
it
doesn't
count,
and
so
I
I
think
maybe
my
proposal
here
is
on
our
retro
docks
our
release
docs
and
our
planning
docs
that
we
just
use
like
monday
to
friday
and
like
let's,
let's
not
even
do
the
sunday.
B
I
think
your
point
about
working
on
the
weekends
is
good.
I
think
that
like
if
we
put
the
sunday
date
in
there,
there's
like
an
implicit
like
hey,
you
could
do
this
on
saturday,
but
like
don't
but
like
so,
the
change
would
be
as
simple
as
this.
This
retro
012
would
be
from
0409
to
04,
23
and
like
now
I
can
sleep
like
that,
but
I
think
that's
all
I
need,
if
that's
cool.
F
Makes
sense
also
something
I
did
recently
is
on
the
sprint
planning
dock
for
the
next
upcoming
sprint,
you'll
notice
that
I
changed
it.
So
it
used
to
say
you
know
for
the
sprint
between
x
and
y,
and
then
I
just
change
it
to
for
the
sprint
starting
from
so
like
it
doesn't
matter
when
the
sprint
finishes,
it
could
finish
early,
it
could
finish
late,
it
could
do
whatever
it's
just.
This
is
the
starting
date
and
that's
what
we
work
from.
So
that's
another.
B
A
So
that
that's
helpful
for
like
changing
the
kind
of
mental
model
of
what,
when
due
dates,
are
when
it
comes
to
keeping
our
release.
Videos
like
the
one
we
just
had
half
an
hour
ago.
Do
we
still
not
count
stuff
like
if
we
do
stuff
on
friday
that
gets
released
on
monday
or
whatever
do
we
still
show
that
in
the
following
sprint
release
video
being
like?
Oh,
we
did
this
last
iteration,
it
just
didn't,
make
the
cut
or
whatever
we
could
do.
Something
like
that.
A
B
I
think
that's
actually
what
I
did
today
for
the
video
thing,
because
I
think
I
actually
released
the
video
on
that
friday
before,
but
I
said
it
was
but
like
it
was
this
iteration
because,
like
that's
basically
what
it
was
like,
I
don't
I
don't.
I
don't
know
if
it
has
to
be
super
strict.
I
just
like.
I
just
need
someone
to
tell
me
that,
like
the
work
I
do
on
fridays
is
part
of
something
yeah.
G
F
The
last
thought
I
have
here
is
that
iterations
are
a
planning
tool,
we're
not
supposed
to
be
like
stressing,
or
you
know,
having
the
iteration
and
form
the
work
to
a
large
degree.
It's
basically
like
this
is
when
we
think
it'll
get
done
it
may
or
may
not.
You
know
to
tyler's
point
about
having
friday's
count
totally
on
board
with
that,
but
yeah
like
we,
it's
it's
good
to
be
flexible
about
iterations,
so
yeah.
We
spent
a
lot
of
time
on
this
one.
E
F
Yeah
I
I
agree
that
it's
maybe
we
should
take
into
account
basically,
whatever
day
the
release
team's
doing
their
thing,
and
just
you
know
so
that's
one
example
to
lauren's
point:
it's
only
one
example
and
there
could
be
others,
but
just
thinking
out
loud
here
like
maybe
we
just
don't
release
on
the
product
days,
because
we
know
that's
when
products
going
to
be
releasing
and
we
don't
want
to
be
impacting
each
other
or
stuff
like
that,
but
yeah.
It
would
be
great
to
have
a
deployment
strategy
overall.
B
B
B
So
if
we
add
the
calendar
event
to
the
digital
experience,
calendar-
and
it
just
says
like
release
post
day,
don't
push
big
about
changes
like
that,
communicates
that
and
then,
if
someone
does
like
request
something,
we
can
like
look
at
the
calendar
and
like
point
them
to
the
calendar
or
the
handbook
page
and
say
like
hey,
just
a
heads
up
like
it
won't
go
out
today.
Here's
why
we
wrote
it
down.
F
F
If
you
need
us
to
not
release
on
a
day,
please
let
us
know,
and
then
we
can
add
that
to
our
calendar,
so
where
kind
of
along
those
lines
is
for
internally
right,
like
we
all
to
some
degree,
know
what
we're
working
on
so,
for
example,
I
know
that
the
plan
is
to
release
monday
for
the
ruby
3
or
whatever
we're
working
on.
My
plan
was
also
to
release
the
pricing
test
on
monday.
F
I
can
coordinate
that
because
I
know
the
two
are
happening
because
I'm
an
internal
team
member,
someone
external,
wouldn't
necessarily
know
that
so
maybe
adding
something
to
our.
You
know
requesting
help
section
that
says
hey.
If
you
need
us
to
not
release,
let
us
know,
or
or
at
least
for
the
big
breaking
changes
we
can
still
release
small
things
in
content
or
whatever
it's
not
going
to
hurt
anyone,
but
like
something
like.
G
This,
I
think,
I'm
next,
if
no
one
has
anything
else
to
add
all
right.
I
just
wanted
to
add
a
note
to
account
for
taking
time
off
and
planning.
I
think
this
was
like
just
exaggerated,
because
I
had
taken
time
off
and
then
we
had
the
off-site,
so
it
was
just
like.
I
had
a
lot
of
time
that
was
just
like
blocked
out
of
my
schedule,
some
of
which
I
like
knew
at
the
beginning
of
the
iteration
and
other
things
that
like
just
happened,
and
so
that's
just
something
to
keep
in
mind.
G
I
think
like.
I
don't
think
there
needs
to
be
any
action
item.
I
think
it's
just
like
that
experience
of
like
take
that
into
account
things
will
always
come
up
as
things
do
and
so
like
be
conservative
with
your
estimates,
because
there's
things
that
you
know
sometimes
there
just
is
a
four-hour
meeting
on
your
calendar
when
you
didn't
expect
one
so
and
I
think
that's
okay,
I
had
a
point
for
encouraging
people
to
write
smaller.
Mrs
rebasing,
like
really
big
mrs,
have
been,
have
been
nasty.
G
B
Yeah,
if
it's
like
a
guideline,
I
feel
fine
with
that.
I
would
be
concerned
about
like
a
linting
rule
or
something
because
like
because
something
like
laura
had
a
really
good.
Mr
today,
that's
like
it's
like
45
files
changed.
It
is
very
easy
to
understand.
It's
like
very
easy
to
reason
about,
because
it's
the
same
change
across
four.
It's
like
this
isn't
www,
it's
not
in
slippers,
but
like.
B
I
consider
that
a
very
small,
mr
because
it's
like
the
same
thing
over
and
over
again,
it
just
has
to
be
each
one,
but
I
think
like
as
a
yellow
flag,
if
you
see
like
double
digits
files
changed
or
like
huge
changes
like
I
think,
maybe
I
I
think
this
is
like.
I
think
this
is
a
practice
thing.
I
think
this
is
just
we
all
need
to
like
think
about
it
and
try.
You
know-
and
I
don't
know
if
there's
like
a-
I
don't
know
if
there's
a
process
other
than
like
really
restricted,
linting
rules.
B
That
would
like
make
this
happen
automatically.
I
think
we
just
need
to
you
know
self-improve
that
iteration,
maybe
we
make
we
all
make
a
commitment
to
go
to
the
next
iteration
office
hours
with
sid.
Right
like
I
haven't
yet
actually
gone
to
one
of
those
things,
and
I
imagine
that
that's
extremely
useful.
So
maybe
something
like
that.
A
Yeah
we
had
a
like
checklist
at
my
former
company
that
was
like
when
you
every
time
you
were
making
an
mr,
the
mr
checklist
included
a
line
that
was
like.
Is
this
change
over
400
lines?
Difference?
If
so,
please
explain
why
kind
of
thing
like
just
to
stop
and
make
you
think
that,
like
it
was
kind
of
a
barrier
that
was,
you
could
break
through
it
if
you
wanted
to,
but
I
know
that
we
do
have
a
mr
checklist
that
we
sometimes
use.
F
F
You
know
my
experience
at
other
companies
has
been
like
you
need
to
make
this
change.
It's
gonna
happen
across
hundreds
of
files.
There's
no
way
to
mitigate
that.
Then
what
you
can
do
is
you
can
kind
of
have
this
feature
flag
or
or
branch
strategy,
whatever
you
do
like.
Basically,
if
you
know
that's
going
to
happen,
try
and
come
up
with
a
strategy.
G
Okay,
sim
on
a
similar
point
process
for
updating
tail
and
config.
It
affects
css
everywhere.
That's
honestly,
like
the
big
rebase,
usually
comes
with
conflicts
with,
like
tillwin
configuration,
not
so
much
in
like
the
configuration
file
itself,
but
like
the
css.
That's
like
output,
because
if
you
change
the
configuration
that
means
you're
changing
the
name
of
the
classes,
which
means
you're
changing
like
vast
amounts
of
like
class
names,
which
is
usually
where
conflicts
lie.
I
would
love
for
us
to
iterate
on
that.
F
Point
kind
of
along
those
lines.
I
don't.
I
don't
have
an
answer
for
the
tailwind
tailwind
config
specific
example,
but
as
we're
building
out
blocks
in
tailwind,
you
know
like
a
video
card
or
whatever
we
could
within
each
particular
block,
say
one
example
of
a
testing
location.
So
you
can
say:
hey.
You
know
if
you're
changing
this,
please
at
least
go
check
this
one
other
spot
when
you're
changing
for
what
you're
changing
and
why?
B
I'm
going
to
grab
a
link
to
a
code
snippet
in
in
storybook
there's
a
way,
in
your
view,
components
to
use
inline
comments
to
generate
to
auto
generate
documentation
in
the
stories.
I've
done
it
for
like
a
handful
of
things,
and
it
is
as
it
is
as
straightforward,
as
underneath
the
first
script
tag.
You
start
a
comment
with
like
two
stars:
you
do
the
long
form
javascript
comment
and
then
you
just
write
into
it
and
it
just
auto
populates
and
I
think,
marked
out-
and
I
think
it's
technically
marked
down
in
there.
B
B
Like
it
is
really
hard
to
parse
out
from
that
documentation,
I
had
to
the
storybook
docs
were
not
clear.
I
had
to
go
to
the
storybook
repo
look
at
how
they
made
it
happen
and
then
go
like
trial
and
error
a
couple
a
couple
times
to
get
it
so.
Moreover,
I
suppose
I
should
probably
document
it
for
ourselves
and
maybe
contribute
back
to
them.
G
I
would
love
for
us
to
spend
like
a
half
day
at
some
point
to
just
like
push
that
back
out
into
the
world
so
that,
like
other
people
in
the
future,
don't
have
to
like
do
what
we
have
to
do
to
figure
these
things
out
so,
and
that
being
said,
storybook
is
an
awesome
tool
like
I
don't
think
we
would
have
gotten
to
where
we
are
without
it,
but
the
docs,
for
it
are
not
great
and
there's
no
real
direct
competitor.
That
does
what
storybook
does
that's
open
source,
so
food
for
thought.
F
A
Yeah,
so
I
think
the
first
one
for
me
is
just
a
lesson
learned.
I,
when
we
had
this
pricing
page
update,
originally
just
supposed
to
be
like
a
copy
change,
and
so
I
was
like.
Oh,
we
don't
even
need
a
design
issue.
This
is
going
to
be
like
literally
just
copy
and
paste,
and
then
we
did
need
a
design
and
then
we
needed
another
one
and
another
one,
and
I
never
made
a
design
issue.
A
So
I
haven't
been
able
to
like
track
my
progress
or
my
work
and,
like
I
said,
I
think
that's
just
a
lesson
learned
that,
like
as
soon
as
you
realize
there
is
going
to
be
work
or
maybe
even
preempt
it
and
close
the
issue.
If
you
don't
need
it,
but
definitely
learned
that
I
should
make
an
issue
and
then
the
second
thing
is
kind
of.
In
the
same
vein
of
this
pricing
update,
like
it
changed
so
much
just
over
the
course
of
the
week
that
I
had
a
really
hard
time.
A
It's
like
it's,
not
a
normal
project
like
normally
there's
like
some
sort
of
pretty
good
feedback
loop
happening
and
you
kind
of
know
the
cadence
that's
going
to
be,
but
in
this
one
in
particular
like
it
was
like
give
something
out,
you
know
get
it
back
for
like
another
day
or
something
or
normally
it
might
be
like
an
hour.
So
I
don't
know
if
anyone
has
any
ideas
on
how
to
judge
those
kind
of
projects
and
just
like
how
much
time
they
would
take,
but
I
was
like
yeah
I
went
from
being
like.
F
Yeah,
so
this
technique,
I'm
about
to
recommend,
isn't
necessarily
applicable
in
all
situations
like
if
you
know
we're
working
on
a
pricing
page
and
it
is
highly
cross-functional
it's
going
to
have
a
lot
of
iteration,
then
it
is
going
to
be
hard
to
judge,
but
sometimes
it's
okay
to
say,
hey
for
this
particular
iteration.
I've
time
boxed
myself
at
you
know
one
day's
worth
of
work.
We're
about
to
exceed
that.
Can
I
you
know
file
away
any
of
this
for
suggestions
for
next
time
and
can
we
kind
of
wind
down?
F
You
know,
or
you
might
say
I
was
time
boxed
for
you
know.
One
day
it
looks
like
it's
gonna
take
two.
I'm
gonna
have
to
close
out
this
other
project
instead
and
delay
that
till
next
time-
and
you
know
just
be
aware
that
all
this
iteration
is
gonna,
be
you
know,
causing
other
projects
potential
issues
and
that
that
may
be
fine,
because
you
know
this
is
a
highly
important
project.
F
D
So
the
issue
that
had
the
okr
in
it
then
last
week
we
discovered
that
there
was
another
pretty
much
like
a
sister
issue
that
was
almost
identical
to
that,
and
not
only
did
was
there
another
issue,
but
there
was
a
lot
of
work
done
in
that
issue,
and
so
we
linked
the
two
and
then
the
person
from
the
other
issue
kind
of
chimed
in
on
ours,
and
they
were
pulled
apart.
Basically,
they
were
just
there's
a
difference
of
opinion.
D
It
was
a
different
idea
of
how
we
go
about
this
work
and
at
the
time
I
thought
well
that's
going
to
derail
us.
It's
going
to
put
the
brakes
on
we're
going
to
have
to
stop
we're
going
to
have
to
rejig
things,
and
that's
ultimately
not
the
case.
However,
having
some
sort
of
prior
knowledge
that
something
like
that
was
in
existence
would
have
helped
that
half
a
day
lost
of
thinking.
D
Well
everything
that
I've
stuck
on
my
wall
here
is
not
it's
not
worth
doing,
but
there
are
also
some
other
snippets
of
some
of
the
pages
that
I'm
working
on.
You
know
if
we
want
to
make
changes
to
those
with
call.
There
are
actually
people
who
own
those
pages
and
own
the
code,
and
they
never
knew
that.
D
So
it's
fair
enough.
You
could,
I
think,
just
says
it
it's
better
to
ask
for
ask
for
forgiveness.
So
just
do
it
and
then,
if
someone's
like
what
happens
like.
Oh
I'm
sorry
about
that,
as
opposed
to
asking
for
permission
and
not
saying
that
that's
what
we
should
do,
but
it
is
a
strategy
that
may
or
may
not
work,
and
but
I
guess
that
discovery
kind
of
opened
up
a
few
things
for
me
of.
D
Or
at
all,
in
this
other
one,
it's
all
engineers,
it's
all
developers
and
they're
kind
of
come
up
with
you
know:
taxonomy
decisions
and
navigation
decisions
and
categorizing
things
in
different
ways,
and
you
know
I
don't
think,
there's
anything
that
we
can
necessarily
do
about
that,
but
definitely
open
my
eyes
up
a
little
bit
to
the
possibility
of
discrepancies
across
different
things.
So
I
know
slight
rant
there,
but
you
get
the
idea.
E
F
A
Yeah,
I
added
one
of
the
comments
there
that
I
just
made
some
changes
to
slippers
blog
confetti
stuff
that
I'll
need
to
bring
into
www,
which
it'll
be
kind
of
my
first
time
doing
that
I
know
that
we
have
like
a
html
or
yeah
html,
the
hamlet
converter.
That
will
do
things,
but
a
lot
of
the
blog
stuff
is
like
ruby.
A
B
There's
a
there's
a
doc
somewhere
in
slippers
about
that
a
little
bit,
or
maybe
it's
an
mr
and
needs
to
get
put
into
doc.
I
I'm
of
the
opinion
that
when
you
do
the
migration
work,
you
will
have
a
better
time
if
you
write
in
erb
instead
of
haml,
because
what
you
get
out
of
storybook
looks
like
is
html
and
erb
is
a
superset
of
html
rather
than
an
entirely
different
syntax.
So
I
think
you'll
just
like
have
a
nicer
time,
but
the
answer
like
there
isn't
a.
F
B
Way
right
now
and
that's
like
we've,
it's
come
up
a
couple
times.
Brandon
made
another
issue
for
it.
Barker
and
I
talked
about
it
this
morning,
like
we
just
have
to
get
to.
We
have
to
get
to
a
place
where,
like
we
have
view
static
tooling
in
the
thing
until
then,
it's
just
duplicate
work
and
like
there
isn't
a
better
way
like-
and
this
is
just
like
the
you
know-
iterative
nature
of
it
all
so
yeah.
But
I
think
that
the
suggestion
is
the
right
one.