►
From YouTube: Digital Experience Retro Video
Description
Digital Experience Handbook Page: https://about.gitlab.com/handbook/marketing/digital-experience/
A
B
Yeah,
thank
you
laura
for
adding
the
the
new
like
template
checklist
to
our
mrs.
It
saved
my
bot
already
like
just
the
did
you
test
in
safari
and
chrome
like
there's
something
where
I
went
to
test
it
then
in
safari,
because
I
had
forgot
and
it
didn't
work
in
safari,
so
wow
that
saved
my
skin.
I
hope
it's
helpful
for
everyone
else,
but
I
was
really
stoked
for
that
looks
like
there's
not
anything
else
on
this
list.
So
things
to
improve
on
is
laura.
A
Yeah
so
now
that
we're
kind
of
breaking
off
into
separate
teams
that
each
own
separate
kind
of
sections
or
knowledge
areas
on
the
marketing
site-
I
don't
know
what
happens
when
requests
come
in
that
don't
fall
into
each
of
those
three
buckets.
So
there
have
been.
You
know,
questions
about
the
releases
page.
I
do
a
lot
of
work
with
the
events
page
just
because
I
guess
I'm
the
name
that
they
recognize
and
not
even
page
specific
but
megan,
and
I
met
about
accessibility
issues.
A
I
think
was
last
week
where
you
know
people
are
starting
to
reach
out
from
other
teams
reach
out
specifically
to
megan,
and
we
don't
want
100
of
accessibility
issues
to
fall
on
megan.
You
know.
So
how
do
we
kind
of
bridge
that
that
gap
of,
like
things
that
fall
outside
of
those
those
three
areas
that
we
manage?
As
teams?
You
know,
I
think
phil's
that
has
a
is
typing.
C
Yeah,
I
think,
that's
a
fair
question.
It's
a
process
we're
gonna
have
to
iterate
on,
but
essentially
people
should
not
be
coming
too
directly
with
issues,
because
that
does
disrupt
the
iteration
and
there
are
like.
We
have
a
quarterly
plan.
We
know
what
our
priorities
are
and
fantastic
that
people
have.
You
know,
requests
and
opinions
about
what
things
need
to
get
done,
but
those
items
should
go
to
our
backlog.
C
They
need
to
be
triaged
by
justin,
lauren
and
nathan,
and
I
and
then
we'll
like
assign
them
to
a
group
depending
on
what
we
think
fits.
But
if
your
group,
like
you're,
like
hey,
I
can
support
another
group,
great
fantastic
post
it
in
the
decks
slack
channel
and
we
can
kind
of
like
help
move
things
around.
But
essentially
any
issues
that
are
coming
in
should
be
in
the
backlog
and
triage
before
they
are
ready
to
be
worked
on
anything
to
add
there
lauren
or
justin.
D
Oh
yeah,
the
thing
I'd
say
is
like
communicate
it
out.
If
people
are
submitting
issues
and
they're
automatically
tagging
people
who
have
worked
and
stuff
in
the
past,
let
them
know
you
can
remove
yourself
and
if
it
might
be,
you
know
assigned
to
you
down
the
road
if
you're
part
of
that
group,
but
it'd
be
better
just
to
remove
yourself
and
then
said,
we
will
kind
of
triage
it
and
move
forward.
C
E
For
me,
I
was
tasked
with
removing
cookies
the
sprint
and
one
of
them
was
happening
on
status.gitlab,
and
so
I
had
to
find
the
person
who
was
managing
that
subdomain
and
my
thought
was
okay.
Let
me
look
at
the
handbook
to
see
what
team
it
was
and
then
I
went
to
the
org
chat
to
see
like
who's
on
that
team,
and
then
I
just
picked
a
random
person
and
I
feel,
like
that's,
probably
not
the
best
method
to
find
that
person.
F
E
G
I
added
an
extra
sub
point
in
there
about
being
cautious
about
not
using
it
in
places
where
it
doesn't
make
sense
or
where
it
slows
us
down.
I've
also
seen
projects
where
people
over
type
and
like
the
typing
gets
in
the
way
of
actually
getting
like
simple
changes
out
the
door.
So
I
just
want
to
be
cautious
of
that,
but
I
just
wanted
to
find
like
what
are
good
patterns
for
how
to
do
that
and
I'd
be
happy
to
chat
with
folks
on
the
engineering
team
about
that.