►
From YouTube: GMT20211202 194814 Recording gallery 1280x720
Description
Digital Experience Handbook Page:
https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/
A
Hi
everyone
welcome
to
the
digital
experience
team
retro
video
today
is
thursday
december
2nd
we're
going
to
talk
about
what
went
well
things
to
improve
on
and
some
action
items
and
up.
First,
I
have
the
first
thing
that
went
well,
so
I
feel,
like
the
data
attribute
work
for
google
analytics,
has
kind
of
been
going
well,
we've
been
flying
through
a
lot
of
issues
on
that
at
the
beginning
of
this
week
we
didn't
have
like
any
of
those
issues
done.
A
B
Yeah
things
that
went
well,
I'm
enjoying
the
collaboration
between
design
and
the
nursery
team,
specifically
on
the
work
on
transitioning
the
solutions
pages,
I'm
looking
at
you,
john
and
miguel,
and
I
just
added
a
little
reminder
to
those
who
haven't
just
to
tag
me
in
those
mr
reviews,
I'm
pretty
reasonable.
With
my
feedback.
C
Yep,
I
think
that
we
have
made
great
progress,
although
we
have
that
problem
with
the
simultaneous
work
we
are
doing
with
slippers,
but
I
think
that
collaboration
will
will
enable
us
to
to
do
that
job
of
documenting
and
getting
on
the
same
on
the
same
track
and
yeah
and
things
to
improve
on.
I
have
that.
I
think
that
I
that
I
can
improve
the
guidance
on
on
the
migration
and
the
the
collaboration
that
I
was
talking
about.
I
think
it
will
greatly
benefit
that
thing.
B
Yeah
things
to
improve
on,
I
had
a
question
about
who
triages
are
issues
javi
here
wrote
that
it's
a
mix
of
lauren
and
nathan.
I
don't
know
if
you
want
to
vocalize
what
you
have
here,
no
okay,
and
so
you
know
I
was
wondering
when
creating
issues
you
know,
there's
the
triage
label.
Should
we
assign
an
engineer
or
not
sometimes
we're
kind
of
unsure.
If
it
doesn't
get
assigned
to
an
engineer,
will
it
get
lost?
So
maybe
something
to
improve
on
is
to
just
understand
that
process.
Teamwide.
D
D
I
don't
know
if
there
is
a
right
person
for
us
to
be
doing
this
right
now,
so
I
would
just
say
that,
like
in
the
sprint
planning
like
because
there's
the
we
have
like
the
board
set
up
is
just
like
keep
an
eye
on
that
like
triage
section
of
it
and
see
if
like,
if
there's
anything
that
makes
sense
for
us
to
bring
up.
I
know
that
we
have
like
the
within
the
sprint
planning.
There's
the
unassigned
section
so
maybe
like
pulling
things
in,
there
would
probably
make
sense
from
the
triage.
A
I
think
I've
got
the
next
point,
which
is
actually
a
stolen
point.
Barker
mentioned
earlier
today.
You
know,
with
troubles
of
we've
all
had
troubles,
kind
of
setting
up,
repos
lately
and
we're
using
and
collaborating
with
more
and
more
teams
like
docs
and
customers
and
setting
up
their
repositories.
So
yeah
is
there.
A
Is
there
a
way
that
we
can
start
thinking
about,
containerizing
or
or
you
know,
set
up
virtual
machines
or
something
that
will
help
it
so
that
we
have
different
dependencies
for
different
projects
and
those
aren't
conflicting
with
each
other
but
yeah
very
rhetorical?
But
it
was
a
good
point
that
barker
brought
up.
So
I
added
it
into
things
to
improve
on.
Let's
start
thinking
about
and
javi
is
the
next
one.
D
D
I
inserted
the
handbook
page
for
the
values,
specifically
the
short
short
toes
sub
value,
just
because
we
have
a
lot
of
fresh
eyes
on
the
team,
and
people
see
things
that
other
people
don't,
and
so
I
would
encourage
team
members
to
just
make
an
mr
for
things
that
they
think
could
just
be
improved,
especially
if
it
makes
sense
and
it
works
with
everything
else.
I
would
also
encourage
people
to
straight
up
also
just
make
empty,
mrs
with
a
new
branch
that
has
the
same
things
as
your
main
branch,
but
it's
just
like.
D
A
And
just
to
add
on
to
that,
because
when
you
mentioned
storybook
I
was
like
wait,
I
thought
we
weren't
using
storybook
anymore
and
maybe
we
are
and
I'm
just
confused,
but
have
we
decided
on
a
single
sort
of
source
of
truth
yet
for
like
design,
development
and
documentation,
kind
of
the
way
that,
like
pajamas,
has
a
public
facing
site
with
all
that
like
n1?
Is
there
have
we
decided
on
that?
A
B
E
A
D
Yeah,
I
just
last
point
I
don't
think,
there's
anything
inherently
wrong
with
like
rebuilding,
because
I
think,
like
it's
actually
kind
of
a
good
thing,
because
it's
the
exercise
of
like
doing
things,
learning
from
it
and
then
like
rebuilding.
It
makes
like
the
thing
that
we
make
afterwards
better,
because
we
have
all
of
this
context
of
like
past
experience,
to
base
our
stuff
on.
So
I
don't
think
it's
necessarily
a
bad
thing.
It's
just
like
we
should
stabilize
at
some
point.
E
And
in
the
case
of
the
buyer's
experience
repository,
I
think
it's
necessary
anyway,
because
I
don't
think
we
can
import
directly
the
components
that
we
are
using
in
the
www
and
use
them
on
the
view
code.
So
either
way
we
have
to
create
the
new
component,
so
better
document
them
on
the
starbuck
from
the
beginning.
A
So
I'll
add
an
action
item
for
myself
to
see
I'm
going
to
wait
and
see
how
sprint
planning
looks
if
we
have
another
kind
of
wild
spring,
we
don't
have
time
for
a
retro,
but
hopefully
next
sprint.
I
can
put
something
on
the
calendar
for
everyone
to
do:
slippers,
retro,
yeah
and
I
think
daniel's
got
the
next
point.
F
G
I'm
going
to
follow
up
there
on
that
one
there's
a
mr!
We
deployed
in
the
new
buyer
experience
repo
and
there's
a
what
tyler's
saying
nasty
silent
bug
in
the
review
app
where
even
if
the
build
fails,
it'll
still
show
what
like
the
past
cache
was
and
therefore,
when
it
actually
got
deployed,
then
we
noticed
all
the
stuff
was
broken.
So
we
found
a
bug
and
we're
gonna
fix
it.