►
From YouTube: Digital Experience Retro Video - Feb 10, 2022
Description
Digital Experience Handbook Page: https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/
A
Hi,
everyone
welcome
to
digital
experience,
teams
retro
from
january
31st
to
february
10th
we're
going
to
go
over
what
went
well
and
what
we
can
improve
on
and
just
to
start
out.
It
was
our
first
iteration
using
boards
and
tracking
kind
of
our
issues
through
these
boards,
and
I
just
want
to
start
off
a
conversation
of.
I
guess
what
went
well
and
what
didn't
go
well
with
the
boards
themselves.
A
Is
there
anything
we
want
to
change?
Do
we
like
the
labeling?
Do
you
want
to
add
more
columns,
remove
more
columns
to
try
and
make
it
more
efficient
and
easier
for
us
going
forward.
A
A
Okay,
so
yeah
add
anything
about
the
the
boards
and
I'll
just
go
ahead
and
say
what
went
well
so
the
first
one
is
actually
on
me
and
I
just
want
to
say
I
did
enjoy
using
the
boards.
I
thought
it
went
really
well.
I
like
that
we're
using
gitlab
the
product
itself
in
our
day
to
day.
That's
all.
I
really
wanted
to
say
jess.
I
don't
know
if
you
want
to
vocalize
that,
but.
B
Yeah,
I
feel
like
we
can
all
agree.
The
one
thing
that
was
like
a
little
messy
was,
we
didn't
know
who
was
going
next,
so
I
just
threw
a
website
in
here.
Random.Org
list
you
throw
in
you
know
everybody's
name
and
it'll
randomize
the
list,
and
we
can
just
do
that
each
time.
So
it's
not
the
same
person
going
first,
every
time
or
last,
every
time.
C
I
was
just
gonna
say
I
think
it's
great
one,
fewer
google
doc
to
juggle
obviously
we're
working
out
of
one
right
now
on
this
agenda,
but
google
docs
are
good
for
agendas
right
and
like
less
good
for
work
management.
So
I
liked
that
there
was
one
fewer
link
link
to
track
with
everything.
I
still
you
know.
C
I
don't
know
with
anything
you
like
you
forget
to
to
move
the
thing
move
the
label
like
go
dude,
so
you
know
it's
one
other
thing
to
do
outside
of
like
doing
the
work
which
can
be
frustrating
when
you're
like
in
a
rush
but
but
yeah.
I
I
think
this
was.
I
think
this
is
the
right
direction
and
I
honestly
don't
have
any
pain
points
around
more
or
l
or
fewer
labels,
but
I
would
be
amenable
to
like
one
or
two
more
of
a
label
or
column,
but
probably
not
more.
D
C
A
A
F
G
Yeah,
this
is
in
regards
to
a
slack
thread
from
I
don't
know
last
week
or
something
like
that,
where
designers
were
wondering
what
to
do
with
issues.
If,
when
a
design
is
done,
do
we
create
new
issues
for
engineering
or
not?
There
was
like
a
26
response,
slack
starting.
I
believe
that
we
ended
on
new
issue,
one
issue
for
engineering
when
issue
for
design.
I
did
do
that
for
one
of
my
issues
for
this
iteration
and
it
seems
to
look
better
on
our
boards.
G
F
Yeah
mine,
mine
piggy,
backs
off
of
that.
If
you
want
your
work
to
show
and
it
won't,
you
want
us
to
get
counted
in
our
metrics,
make
sure
there's
a
freaking
issue
for
it,
I'm
a
little
salty
about
that.
But
that's
just
the
way.
We're
gonna
do
it
and
that's
great
so.
C
Yeah,
I
think
this
feels
onerous
sometimes,
but
I
think
that
the
value
is
like
the
metrics
we
get
out
of
it,
but
I
still
feel
I
still
feel
like
we
sh.
I
don't
know
I'm
worried
about
the
mat.
I'm
worried
about
the
metrics
when
the
when
the
processes
are
not
consistent,
like
how
you
know
how
many
issues
you.
C
How
many
issues
we
create
is
something
that
feels
like
it
varies
widely
by
person
and
so,
like
percentages
of
issues
open
seems
like
we
have
a
high
degree
of
variance-
and
I
agree
with
michael
that
it'll
normalize
over
time
and
that's
what
like
not
to
say
that
we
should
like
we
shouldn't
use
it.
Just
that,
like
we
should
use
those
metrics
to
try
and
get
us
all
to
corral
around
like
up
like
a
standard
like
we
should
try
and
get
like.
We
should
try
and
reduce
the
variance
over
time.
C
I'm
just
like
I'm
worried
about
whether
or
not
we
will,
but
we
will
try-
and
I
think
you
know
if
we
open
up
an
issue
for
every
like
discrete
piece
of
work,
we're
doing
that'll,
probably
help
or
get
closer.
A
A
C
Look
at
the
the
one
in
the
gitlab
product
code
base,
it's
like
they
have
one,
but
it's
like
it's.
I
think
it's
actually
way
shorter
and
like
a
lot
of
stuff,
you
can
like
delete
really
easily.
I
think
just
I
think,
streamline
it.
I
I
think
that,
like,
if
there's
a
bunch
of
stuff
to
do
like
one
of
the,
I
think
we've
used,
I
think
we
have
in
the
past,
used
these
templates
as
like
safeguards
that
a
human
reviewer
should
be
the
safeguard
for
so
like
there's
templates,
where
it's
like.
C
If
I
changed
like
ux
did
I
like
show
a
designer
or
whatever
and
like
a
human,
should
look
at
this
and
be
like
hey,
so
you
wrote
100
lines
of
css
like
did
tina,
see
it
like
like.
Have
we
shown
this
to
someone
else?
I
think
that's
a
human
thing
and
I
think
you
can
cut
down
on
the
boiler
plate
by
like
we
can
just
streamline.
I
think
it's
like
I.
C
I
think
that
maybe
we
should
just
copy
what's
in
the
gitlab
product
code
base,
because
it's
like
what
does
this
do
and
why
screenshots
and
screen
recordings?
C
If
you
want
to
it's
optional
but
encouraged
steps
to
validate
locally,
which
again
is
like
optional
but
encouraged
and
then
like
a
link
to
their
mr
guidelines
right-
and
I
think
we
could
do
something
like
that-
that's
basically
the
same
deal
and
it
would
be
shorter
and,
like
you
can
delete
you
can
take
what
you
want
and
leave
what
you
don't
and
like
we
just
need
to
have
human
people
do
better
at
catching
the
stuff
that
we've
tried
to
catch
via
markdown
that
everyone
just
skims
and
deletes.
C
F
A
H
Okay,
so
I
think
I'm
next
so
I
saw
this
iteration
that
a
lot
of
merge
requests
range,
so
lauren
we're
merging
a
lot
of
measure
requests
and
some
conflicts
appear.
So
I
saw
that
some
conflicts
are
not
being
done
correctly
and
some
code
is
being
lost.
So
I
think
that
we
need
to
take
care
more
of
the
conflicts
and
check
both
both
code
blocks
and
see
what
needs
to
be
combined
between
the
both
the
two
code
blocks,
because
sometimes
we
only
do
take
this
one.
H
So
I
think
this
point
is
to
take
very
caring
of
the
conflicts,
because
we
are
losing
some
code
in
the
in
the
merging
and
right
now
we
have
like
three
measure
requests
per
day,
so
it's
a
lot
of
code
that
maybe
can
be
missed,
and
regarding
that
other
thing
that
I
saw
is
that
some
conflicts
are
only
indentation,
so
I
think
that
maybe
is
better
to
have
indentation
rules
for
everyone
and
not
what
the
ide
has
as
in
the
settings.
H
H
And
that
goes
to
my
next
point.
That
is
also
check.
Where
are
the
regressions,
because
lauren
found
two
regressions
today
that
were
linked
to
some
changes
that
were
made
to
generic
components,
and
if
we
do
changes
to
generic
components,
we
need
to
be
sure
that
we
are
not
breaking
anything,
because
there
are
some
components
that
are
being
used
in
more
than
10
pages.
So
I
think
is
also
take
very
care
enough
regression,
and
that
would
be
for
me.
C
C
A
bunch
of
this
is
to
like
spin
up
cyprus
and
do
visual
regression
like
differing
on
all
the
merge
requests
and
that's
something
we
can
absolutely
do,
but
it
will
be
like
wasted
effort
until
we
have
like
a
baseline,
that
we
don't
want
to
regress
backwards
from
right
and
there
we're
going
to
get
all
this
like
new
brand
updates
and
like
a
bunch
of
this
work,
that's
coming
like
this
quarter
so
like.
I
think
I
think
we
should
do
regression
testing.
C
We
said,
but
we've
said
this
for
as
long
as
I've
been
here
and
probably
longer,
we
absolutely
need
to
do
visual
regression
testing,
but
I
don't
think
we
can
put
that
we
can
do
that
until
we
are
like
at
a
point
where
we
can
say
that
we
know
what
the
right
answer
is
right
like
we
need
to
know
what
all
of
the
components
must
look
like,
or
you
know
some
meaningful
percentage
like
80
percent
of
them
must
look
like
before
it's
worth
the
time
to
invest
in
regression
testing,
but
when
we
go
to
plan
this
and
like
when
we're
communicating
outwards
on
these
projects,
like
the
regression
testing
needs
to
be
a
part
of
the
plan,
we
also
can't
say
like
oh
well,
we'll
do
it
when
we're
done
like.
C
I
think
that
should
be
part
of
the
definition
of
done.
We
just
I
like
like
this
is
a
thing
that,
like
I,
don't
think
test
driven
development
works
well
for
for
visual
regression,
testing
for
something
like
this,
like
we
don't
want
to
write
these
tests.
First,
we
want
to
like
iterate
get
happy
with
it
and
once
like
designers,
stakeholders,
everyone
is
like
happy
with
how
it
looks.
Then
we
say
cool
like
we
grab
cyprus.
C
You
know
we
like
fuzz
some
difference
on
it
and
if
it
goes
beyond
the
threshold
we
say
hey,
we
have
a
regression,
but
we
can't
do
regressions
without
without
a
standard
first,
so,
although
I'd
say
super
high
dude
like
a
hundred
percent,
let's
do
regression
testing
and
let's
make
sure
that
it's
part
of
the
plan
and
if
it
isn't
part
of
the
plan,
because
we
don't
have
time,
we
should
communicate
that
if
we
don't
make
regression
testing
part
of
the
plan,
we
will
have
regressions
and
we
will
spend
time
like
infinitely
battling
regressions
afterwards.
F
Nine
comment:
piggybacks
off
that
yeah
there's
like
12
mr
shipping
at
least
a
week,
and
when
they're
all
touching
global
components,
extensively
like
I'll
spot
check
some
pages
from
each
content
type.
We
have
like
over
60
pages.
I
can't
check
all
of
them
if
most
of
them
look
good
cool,
we're
moving
fast.
F
There
are
going
to
be
regressions,
but
we
have
a
great
team.
We
have
the
entire
company
they'll,
let
us
know-
and
sometimes
it's
a
really
quick
fix,
like
those
two
that
john
patched
up
this
morning,
super
small
real,
real
quick.
So
it's
not.
I
don't
think
it's
like
the
death
to
our
team.
If
we
we
have
a
couple
regressions
because
we're
moving
so
fast,
and
maybe
we
have
like
a
thorough
weekly
regression
like
the
end
of
a
sprint
or
the
start
of
a
sprint
to
make
sure
we're
catching
stuff.
I
I
just
wanted
to
call
out
a
point
that
I
thought
was
really
useful
that
I
had
seen
with
netlify
the
product
itself,
where
it'll,
when
you're
like
generating
like
you're
building
out
a
static
site
generator
it'll
tell
you
like
what,
like
a
number
of
pages,
that
have
changed.
So
it's
like
if
you're
changing
something
like
card.view
it'll.
Tell
it'll
tell
you
like:
hey,
like
you,
know,
company
and
solutions,
and
all
of
these
child
pages
changed
like
we
don't
know
where
it's
changed,
but
something
in
here
changed.
I
So
I
don't
know
if
that
would
be
helpful
for
us
without,
I
feel
like
we're
still
like
in
you
know
that
kind
of
very
early
land
where
that
stuff
might
not
be
as
beneficial
but
something
we
could
certainly
look
into
as
we're
starting
to
get
more
stuff
rolled
out,
and
I
just
wanted
to
call
that
out,
because
that's
something
that
I
always
thought
was
super
cool.
C
Yeah
we
get,
I
mean,
that's
the
those
are
the
regret
like
we
can
do
the
same
thing
I
just
like.
I
don't
think
we
should
until
it's
like,
because
if
you,
if
we
set
it
up
right
now,
everything
will
change
every
time.
You
do
a
thing
like
it'll
be
noise
that
we'll
ignore
every
single
time.
Like
that's,
that's
good
like
if
we
do
regret
visual
regression
testing
too
early.
It's
just
going
to
get
so
noisy
that
we'll
never
pay
attention
to
it.
C
If
we
never
do
it,
then
we'll
never
have
it
so
like
we
absolutely
like
it
needs
to
be
part
of
the
plan,
but,
like
I
just
I
fear,
setting
up
regression
tests
that
everyone
learns
to
ignore
because
they're
like
every
time.
I
make
an
mr.
The
entire
website
changes
because,
like
we're
still
in
such
an
early
phase
that
like
that,
is
an
expected
behavior
right.
D
Has
been
considered
to
have
an
staging
environment
with
all
of
iteration
changes,
all
the
all
the
mrs
deployed
and
make
the
regression
on
that
the
staging
staging
environment
before
merge
to
production,
I
mean
it
will
be
a
bigger
task,
bigger
for
make
a
regression
for
everything,
and
we
will
need
someone
to
to
do
that
anyway,
but
we
we
will
avoid
to
have
that
kind
of
issues
in
production.
I
mean
it's
just
an
idea.
I
don't
know
I
I
use
one
to
share
that
idea.
F
C
I
think
it's
a
good
I
like
started
like,
I
feel
like
I'm
repeating
myself
too
much,
and
I
like
I,
don't
I
don't
want
it
to
be
dismissive.
It's
like
yes,
that
is
absolutely
what
we
should
do
just
like
not
now
like.
C
We
should
not
spend
the
time
putting
that
together
when
we're
about
to
when
we're
about,
to
cause
regressions
on
every
single
visual
element
of
the
site
right
like
because
it's
all
gonna
change
with
the
new
brand.
So,
like
we'll
just
fail
the
regression
test
every
single
day,
and
that
will
be
an
expected
behavior
and
I
don't
think
we'll
be
adding
value
like
until
until
we
get
to
a
stable
point
where
we
say
like
the
work
is
basically
done.
C
It
should
not
regress
from
this
point,
but
I
would
expect
visual
regressions
every
single
day
from
now
until
the
end
of
the
quarter
and
like,
I
think
we
just
have
to
move
forward
with
them
right,
but
like
again
like
that
is
exactly
the
right
idea,
like
100
staging
environment
run
the
regression
test
on
them.
Let's
do
it.
I
just
think
like
now
is
not
the
time
to
do
it.
A
Do
we
want
to
move
on
I'm
already
kind
of
eight
minutes
over?
So
I
don't
keep
everybody
here,
but
just
did
you
want
to
go
over
that
last
point.
B
Yeah
so,
while
y'all
were
talking
about
number
one
of
the,
how
are
we
going
to
deal
with
the
mr
issue
issue?
I
found
this
link
to
an
issue
that
already
exists,
and
there
are
a
couple
before
that.
There's
one
that's
like
four
years
old,
one,
that's
five
years
old,
all
asking
for
the
same
request
of.
B
Can
we
add,
mrs
to
issue
boards
and
tyler
actually
had
commented
on
this
one
in
particular
like
a
year
ago
and
becky
was
on
board,
but
I
don't
think
she's
here
anymore,
but
I
was
just
curious
like
can
we
push
forward
to
get
this
feature
into
gitlab
so
that
we
don't
have
to
keep
using
workarounds
tyler?
You
have
to
comment
there.
You
wanna
go
talk.
C
Yeah,
I
don't
know
you
know,
I
mean
we
gotta
swim
upstream
against
whatever
process
like
you
know,
the
business
has
to
decide
that
they
want
to
do
it
right,
but
I
think,
like
the
thing
that,
like
I
commented
on
this,
because
I
was
hoping
that
by
commenting
on
it,
it
would
like
be
another
like
tick
mark
in
the
should
we
do
it
or
not.
So
I
think
you
know
anyone
on
this
call
or
watching
this
video
who,
like
wants
this
thing,
there's
a
link
in
our
agenda
to
the
specific
feature
request.
C
I
think
just
go
and
just
like
type
a
comment
and,
like
I
think,
there's
like
six
six
reactions
on
mine.
I
think
it's
more
powerful
to
like
type
three
sentences
and
be
like
I
want
this
too,
because
xyz
like
I
like,
I
pull,
I
like
linked
it
to
our
communications
handbook
and
I
was
like
in
the
handbook
we
say
we're.
Mr
first,
but
like
mrs,
are
not
like
the
easiest
thing
to
work
with
to
track
work,
so
I
think
go
write
three
sentences
on
it
and
see
what
I
like.