►
From YouTube: Digital Experience Retro - Nov 17, 2022
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone
welcome
to
digital
experience.
This
is
our
iteration
retro
meeting
today
is
Thursday
November
17th
we'll
go
over
some
of
the
things
that
went
well.
This
friend
and
some
things
to
improve
on
first
thing
to
bring
up
is
John.
B
B
It
is
needed
because
the
library
that
we
are
using
that
is
called
semantic
release
reads
these
commits
and
it
detects
what
kind
of
change
it
is
is
if
it's
a
major
change,
a
minor
change,
a
path
change,
and
it's
really
important
for
this
library
to
know
to
read
these
commits
using
conventional
commits.
So
please
have
it
in
mind.
I
will
have
some
more
documentation
for
you
to
know
how
the
process
works,
but
we
will
start
doing
new
releases
and
new
versions
from
now
on.
So
please
please.
B
It
is
very
important
to
do
this
to
add
these
commit
messages.
I
will
pass
it
over
to
Laura.
C
So
I'd
like
to
get
this
merged
like
this
iteration
merged
in
end
of
day,
and
then
next
iteration
will
will
start
practicing
in
using
some
of
these
conventional
commits.
You
know,
it'll
be
a
test
run
and
by
the
end
of
next
iteration,
we'll
create
our
first
change
log
using
this
process.
C
It
probably
won't
be
perfect
and
there
will
be
some
learning
experiences
as
we
as
we
go
through
it.
But
I
think
this
is
one
of
those
things
that
we
just
have
to
try
it
and
then
iterate
on
it
as
we
as
we
get
it
in
there.
What
does
the
team
think?
C
It's
kind
of
a
big
change?
We
got
to
put
formatic,
commit
messages
and
now.
C
B
So
it
is
really
important
to
do
a
squash,
because,
if
not
someone
has
a
20
commits
in
one
message
request.
All
those
20
commits
will
be
on
the
change
lock,
and
that
is
not
the
idea.
The
idea
is
only
to
put
in
the
change
lock
the
the
commit
or
the
issue
or
the
topic
of
the
issue.
For
example,
we
have
a
new
navigation
button,
so
it
will
say
a
new
book
that
is
added
and
not
all
the
commits
that
were
added
doing
or
adding
that
button.
B
B
D
D
F
I'm
Pro
conventional
commits
and
also
Pro
squashing,
and
do
you
feel
like
it's
a
good
change?
A
lot
of
overhead,
however,
like
I'm,
hoping
to
try
it
and
see
how
it
goes
for
us
and
if
it
doesn't
work,
then
we
can
try
something
else,
but
I'm
open
to
like
going
for
it
the
code's
already
written.
Let's
try
it.
If
it's
a
chaos,
then
we
can
always
go
back.
B
F
B
I
think
the
same
and
right
now
we
are
going
to
to
use
some
manual
job,
but
if
things
go
well,
the
idea
will
be
to
create
a
create
a
schedule
and
and
do
a
release
every
two
weeks
at
the
end
of
each
iteration.
But
we
are
going
to
test
it
these
days.
A
So
the
current
implementation
it
every
time
you
know
you
merge
a
change
in
you,
make
your
special
message
and
you
merge
it
in
and
it
increments
the
version
for
us
or
we're
just
doing
one
version
in
increment
per.
B
Iteration,
yes,
one
version
per
iteration,
so
it
is
a
manual,
so
the
manager
I
believe
Lauren
will
do,
will
run
this
this
this
job
and
it
will
add
all
the
things
that
were
that
we
did
from
the
iteration.
So
all
the
mesh
requests
will
be
on
this
new
version
and
that's
it.
There
is
nothing
to
add
sorry.
C
B
Yeah
so,
for
example,
we
did
10
fixes,
but
someone
with
one
feature:
the
fixes
increase
the
patch
version,
but
the
feature
will
increase
the
minor
version
so
for
dietary
relation.
The
version
will
increase
in
a
minor
way
and
all
the
fixes
will
be
added
in
the
changelog
as
part
of
the
release
or
or
that
new
version.
G
The
other
question
I
was
going
to
have
is
like
pretty
much
all
of
our
page
on
our
side.
The
code
earners
are
us,
so
we
need
to
merge,
but
if
we
open
this
up
to
let
other
teams
edit
content
and
they
don't
follow
the
conventional
commit
message.
Is
that
going
to
cause
an
issue
down
the
road.
B
Well,
we
have
a
common
analyzer,
so
if
there
is
no
conventional
commit
they
commit,
analyzer
will
try
to
detect
reading
the
commit
if
it's
a
fix
or
a
feature
or
something.
So
if
we
sometimes
miss
a
conventional
message,
the
the
library
will
try
to
detect
which
type
of
change
it
is.
C
D
Okay,
I'm
going
okay
cool.
A
Thank
you,
John
mine
is
less
less
cool
and
exciting
we're
talking
about
removing
slippers
from
the
navigation
repo
or
like
dealing
with
that
package
size.
So
there's
a
kind
of
simple
solution
of
adding
slippers
as
a
peer
dependency.
A
We
still
also
need
it
in
order
to
run
the
server
locally,
so
it
also
has
to
be
a
Dev
dependency,
and
so
those
are
two
separate
kind
of
imports
of
that
package,
and
that
is
fine.
It
is
a
fine
solution.
We
can
absolutely
move
forward
with
that.
The
only
I
guess
con
is
that
we
rarely
go
and
update
the
slippers
version
in
navigation
like
it's
sitting
at
I.
A
Couldn't
tell
you
what
version
two
dot
something
whatever,
but
if
we
make
changes
to
slippers,
we
have
to
manually
go
in
and
make
changes
to
our
local
navigation
and
those
changes
will
be
different,
then
what
it
pulls
in
when
we
bring
it
into
a
fire
experience
because
it'll
be
using
the
buyer
experience
version
version
of
slippers,
so
you
can
see
some
like
discrepancies
there,
which
is
a
bit
of
a
pain
but
not
the
end
of
the
world.
The
other
option
is
that
our
team
has
kind
of
discussed
a
little
bit
is.
A
Do
we
need
slippers
in
our
navigation?
It's
very
lightweight.
You
know
there
are
some
textiles
and
a
few
icons,
and
so
I
made
a
proof
of
concept
Mr
to
remove
slippers
from
navigation,
and
it
did
need
about
150
lines
of
CSS,
but
that
is
also
an
option.
But
again
the
con
is
that
if
we
make
changes
in
slippers
and
try
to
bring
them
into
our
navigation
like
we
need
to
make
those
changes
manually,
so
you
know
pros
and
cons
of
either
path.
A
I
have
I
linked
a
note
here,
where
I
kind
of
go
over
that,
and
my
recommendation
would
be
to
start
with
having
it
as
a
peer
dependency
and
see
how
that
works,
but
maybe
there's
a
future
one.
We
don't
use
slippers
in
the
navigation
at
all,
because
it
it's
pretty
self-contained,
but
thoughts
or
feelings
feel
free
to
comment
on
that
Mr
or
any
of
those
Mrs
or
issues
I'll
be
watching
foreign.
A
And
I
have
one
more
thing
that
I
didn't
add
in
there.
This
is
a
another
addition
to
buyer
experience
that
has
not
been
merged
yet
but
I'm
going
to
share
my
screen
for
a
quick
sec.
Okay.
So
this
is
my
like
repo
I've
added
this
HTML
validator
to
the
buyer
experience
site.
A
It
starts
showing
errors
on
your
local
server
when
you
run
up
your
server.
So
this
is
like
the
home
page.
It's
showing
me
like
buttons
can't
have
divs
in
them,
which
is
really
helpful
to
know
for
hydration
errors.
My
server
is
still
running.
This
doesn't
like
bail
out
my
server,
but
it
is
kind
of
a
pain
because
it
doesn't
show
the
actual
line
right.
It
shows
the
compiled
line,
but
not
the
actual
like
where
to
find
this
problem
in
your
code
is
very
difficult.
A
I've
been
going
to
the
like
browser,
Dev
tools
and
searching
for
a
button
finding
the
button
that
has
a
div
in
it
and
changing
it
in
the
code.
But
yes,
this
is
something
I
was
thinking
of,
adding
to
buyer
experience
to
kind
of
help
with
some
of
those
issues.
So
my
thinking
was
that
I
would
go
through
and
fix
all
the
major
errors
on
like
the
top
couple
of
pages.
A
But
how
does
the
team
feel
about
having
that
implemented?
Is
that,
like
super
distracting
during
your
your
local
development,
I'll
link
the
issue
where
I'm
doing
it,
and
you
can,
let
me
know
your
thoughts
and
feelings
there
too.
D
F
A
This
is
create
files.
This
one
is
just
in
development,
it's
just
a
Dev
dependency,
so
it
would
just
be
for
local
development.
Just
to
show
you
where
you
have
issues
I,
we
could
probably
look
into
running
it
on
the
build
step.
I
I,
don't
know.
If
that's
what
we
want,
the
errors
are
kind
of
useless
because
they
don't
show
the
the
actual
line
or
where
the
error
is
occurring,
but
yeah
I
can
look
into
improving
it.
A
There
are
also
like
in
the
next
config,
where
I
imported
that
module
there's
also
a
section
of
like
rules
that
you
can
turn
off
and
turn
on
like
if
people
are
seeing
rules
that
they
don't
care
for
that,
like
are
kind
of
irrelevant,
for
whatever
reason,
then
we
can
kind
of
tweak
it
as
we
go
along,
but
it
is
like
I
understand
that
everyone
all
the
engineers,
are
working
on
this
repo
all
day
every
day,
and
you
know
if
you're
constantly
getting
errors,
even
if
they
are
pink
and
cute
on.
A
On
my
with
my
theme,
it's
still
kind
of
a
pain
so
yeah,
but
yeah
we
could
look
into
I.
Just
don't
want
to
fail
the
pipeline
for
these
types
of
things,
but
you
know
we
could.
C
Chime
in
like
an
advantage,
I
agree:
we
don't
want
to
fail
the
pipeline
and
we
don't
want
to
create
a
messy
error
warning
pipeline,
but
it's
also
really
hard
to
find
an
issue
if
the
pipeline
does
fail,
and
then
you
have
to
go
search
through
those
jobs,
and
it's
just
like
line
after
line
of
like
thousands
of
Errors
makes
it
hard
to
find
out
what
actually
broke
it.
So
it's
like
good
would
be
good
hygiene
just
to
start
fixing
all
this.
A
I
guess
it's
similar
to
I,
guess
the
recent
the
link
Checker,
the
404
link,
Checker,
similar
I,
guess
issue
where
it
can
spit
out
problems,
but
it's
up
to
us
how
we
want
to
fix
those
problems
and
who
wants
to
take
on
those
those
problems.
So
maybe
there's
a
it
spins
up
an
issue
or
whatever
each
iteration
I
can
look
into
kind
of
how
how
to
handle
these
errors.
A
A
Okay,
things
that
went
well
Justin,
you
have
the
burst.
G
Thank
everyone.
Everything
kept
moving.
Well,
half
everyone
was
out
at
the
off
site,
and
communication
was
key.
I
know
that
some
people
like
who
are
gone
like
they
were
slow
to
respond,
but
communication
was
still
good
things
kept
happening.
So
I
just
want
to
thank
everyone
for
all
the
hard
work
they.
You
know
that
you
did
to
get
all
the
pages
out.
A
Yeah
I
wanted
to
thank
I,
guess
whoever
was
involved
in
the
spreadsheet
that
I
linked
there.
It
has
all
of
the
Q4
due
dates
for
all
the
work,
upcomings
split
up
by
team
and
expectations.
A
So
that's
really
cool
and
neat
I
know
it's
not
a
gitlab
issue,
but
we
have
all
that
in
an
epic.
Also,
it's
just
nice
to
see
it
all
laid
out.
Thank
you,
philsa
and
I
assume,
Lauren
and
Justin,
and.
D
C
I
I
put
one
in
there.
Thank
you,
Miguel,
Carrie
and
John
for
pushing
a
quick
iteration
to
our
nav
that
we
got
out
on
Monday
and
then
we
pushed
another
one
on
Wednesday,
so
good
job.
C
A
D
C
Yeah,
let's,
when
you
have
that
handbook,
Mr
tag
me
and
Miguel
on
that,
so
we
can.
D
C
C
One
things
improve
on
this
is
like
I
I
got
lost
in
a
review
because
there's
conversations
happening,
multiple
places,
issue
and
Mr.
There's
an
example
for
that
Partners
page.
So
I
don't
know
if
the
action
is
there
I
think
that's
just
sometimes
the
reality
we
live
in,
but
if
I'm
feeling
it
I'm
sure
our
stakeholders
are
going
to
have
a
hard
time.
C
C
Yep,
the
second
one
in
our
Mr
descriptions,
make
sure
you're
writing
out.
What's
changed,
why
it's
changed
all
the
things
you
need
to
know
about
that
Mr.
C
Just
looking
back
to
the
issue,
isn't
enough,
when
I'm
looking
at
an
MR
I,
don't
want
to
have
to
click
on
something
and
have
two
windows
open
I,
ideally
I
want
it
all
right
there
and,
for
example,
if
you're
doing
an
MR
for
the
product,
do
you
need
to
say
what's
changed?
Why
have
screenshots
and
then
steps
to
reproduce
how
to
verify
this
locally?