►
From YouTube: Retrospective (Public Stream)
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
Skit
lab
team
retrospective,
my
name
is
jarva
satcher
and
I'm
your
host
for
today's
meeting.
We
have
a
retrospective
that
is
both
synchronous
and
asynchronous.
So
if
you
are
following
us
asynchronously
we
have
a
retrospective
summary
video.
We
have
a
slide
deck
and
today's
meeting
will
also
be
async.
If
you're
going
to
review
the
video
later
and
if
you're
joining
us
right
now,
it
will
be
synchronous.
A
Today
we
will
be
discussing
our
previous
retrospective
improvements
for
around
five
minutes.
The
discussion
topics
two
topics
at
seven
minutes:
each
improvements
to
track
for
next
release
for
five
minutes
and
then
we'll
wrap
it
up.
Alright,
so
I
will
get
started.
We
will
get
started
with
the
previous
retrospective
improvement
task.
Cz.
Are
you
on
the
call.
B
Yes,
I
can
talk
first
yeah
last
time
we
said
we
wanted
to
keep
working
on
some
performance
improvements
and
in
the
last
release
we
did
two
things.
First,
with
our
research,
we
increased
the
number
of
our
elastic
such
cluster
sharps.
I
think
which
results
in
a
good
performance
improvements,
and
the
second
thing
is
that
we
are
splitting
our
elasticsearch
index
into
multiple
ones,
based
on
the
data
type.
We
hope
a2
pass
the
performance
improvements
as
well
yeah.
A
C
Yeah
sure
thing
we
were
just
having
a
little
bit
of
issues
with
forgetting
documentation
up
into
the
merger
quest
going
into
review.
So
we
kind
of
just
resolved
to
reinforce
the
the
current
process
and
ensure
that
the
documentation
section
of
issues
is
well
filled
out
and
engineers
are
taking
a
look
at
that
prior
to
moving
the
issue
into
the
workflow
in
review
status.
Columns.
So
we're
getting
better
at
our
document,
remembering
documentation.
A
All
right,
thank
you
and
I
just
added
two
items
on
the
list.
I
experimented
with
the
poly
pole
feature
to
gather
votes
for
the
discussion,
topics
that
we're
going
to
have
later
on
I'll,
be
interested
to
see
how
people
like
that
edition-
and
you
all
can
mention
that
in
a
retrospective
on
the
retrospective.
A
The
next
item
is,
I
created
a
playlist.
I
was
going
through
looking
at
previous
retrospectives
and
they
weren't
in
a
playlist.
So
I
just
created
a
playlist,
so
maybe
moving
forward
as
we
create
retrospective
videos,
we
can
store
them
in
that
playlist
all
right.
A
A
I
went
with
the
first,
the
first,
which
was
div
values
that
had
the
highest
votes,
so
I
will
be
talking
about
community
contributions,
so
there
will
be
a
quarterly
hackathon
for
get
lab
community
team
members
to
come
together
to
work
on,
merge,
requests,
anticipate
and
to
participate
in
tutorial
sessions
and
support
each
other
on
the
get
loud
contributors
channel,
and
there
is
one
coming
up
very
soon.
So
I
thought
this
was
a
very
timely
discussion.
A
One
thing
that
I've
noticed
is
that
we
don't
always
have
good
label
hygiene,
so
I
would
recommend
that
we
have
labels
such
as
first
good
for
first
time,
contributors
weights
of
one
and
different
any
labels
that
we
already
have,
or,
if
we'd
like,
to
create
new
labels
to
make
it
easier
for
them
to
find
and
be
more
transparent.
D
Okay,
which,
which
label
would
you
recommend
since
folks
may
be
watching
this
or
watching
asynchronously?
I
think
I
know
which
one,
but
I
figured
I'd
ask
and
we
can
just
get
it
in
the
stock
here.
A
Honestly,
I
would
need
to
go
through
all
of
the
lists.
I
know.
There's
a
first-time
contributor
label,
there
might
be
a
community
contribution
label,
but
I
think
that's
used
once
someone's
already
contributed.
D
A
F
A
I
was
also
curious
if
anyone
has
ever
intentionally
like
grouped
them
into
an
epic,
maybe
like
by
some
type
of
categories
like
handbook,
community
contributions
or
just
various
web
ide,
and
then
maybe
centralize
them
on
a
handbook
page
and
possibly
advertise
them
through
the
various
social
media
options.
We
have.
F
I
can
say
that
in
the
front
end
I
can
remember
any.
I
don't
have
the
link
right
on
top
of
my
head,
but
we
have
a
couple
of
like
clean
up
issues
clean
up,
epics
of
rewrites
and
refactors,
where
we've
had
we're
going
to
create
a
bunch
of
issues
on
those
epics
and
that
potentiates
the
participation.
F
So
I
feel
like
that's
a
great
idea.
It
does
require
a
bit
of
a
an
effort
on
a
specific
topic.
If
it's
like
a
too
broad
of
an
epic,
it
might
be
too
spread.
But
it's
something
like
rewrite
this
into
that
or
clean
up
the
jest
or
something
like
that
and
clean
up
the
tests
from
karma
to
jess,
like
the
ones
we
had
might
might
better
attract
other
people.
G
Yeah
there
is
some
just
while
you
were
speaking,
I
find
the
guidance
in
the
handbook
so
I'll
link.
It
there's
some
guidance
around
specifically
for
first-time
contributors
that
they
might
want
to
look
through
issue
lists
of
issues
weighted
one.
So
I
think,
since
we're
linking
to
that
issue
list,
it
might
make
sense
to
have
a
number
of
those
in
your
group's
backlog.
E
One
one
question
I
have
is
is:
has
anybody
seen
more
likelihood
of
a
community
contribution
if
they
have
a
good
description
or
a
graphic
of
some
sort
like
some
way
to
demonstrate
it
like?
I
don't
know
if
I
would
call
that
a
best
practices
more
question
from
that
perspective
of
if
we've
got
any
feedback
of
that
nature,.
A
E
Yeah,
so
one
of
the
things
that
we've
been
looking
at
is
this
mr
arr
mar,
which
is
basically
looking
at
the
mrs,
are
contributed
by
customers
who
have
a
greater
size,
arr
associated
with
their
investment
in
gitlab,
and
one
of
the
things
we
might
want
to
look
at
the
mec,
mecca's,
primarily
driving
that
so
one
of
the
things
we
may
want
to
do
is
go
back
to
mac
and
ask
them.
If
we
can
do
some
analysis
on.
E
C
Sure
yeah,
one
thing
I
was
wondering
about
was
just
if
there's
a
relationship
between
the
availability
and
thoroughness
of
contributor
documentation
in
the
in
the
docs
section
and
how
many
community
contributions
those
sections
receive,
just
in
so
far
as
like
technical
documentation,
architecture
diagrams
how
these
features
work
under
the
hood.
E
A
All
right,
so
this
sounds
like
a
wonderful
area
for
opportunities.
So
if
you
all
just
keep
these
in
mind-
and
maybe
we'll
come
up
with
some
improvements
for
the
next
release
to
track
as
well
all
right
on
to
the
next
one,
the
reason
why
I
make
I
chose
the
div
values
is
because
this
particular
retrospective
there
was
no
dib
comments,
and
so
I
wanted
to
take
a
step
back
to
look
at
if
we
wanted
to
share
best
practices
for
how
to
strengthen
dib
values
on
our
team.
H
Yeah,
I
think
I
think
it's
a
good
one
diversity.
Inclusion
belonging
is
pretty
one
of
our
values
at
gearlab
and
I
think
oftentimes.
What
we
need
to
remember
is
we
all
need
to
live
these
values
and
represent
them
ourselves.
We
do
have
competencies
in
the
handbook.
H
H
So
I
think,
taking
a
look
at
those
things
fairly
regularly
and
reminding
our
team
members
to
be
supportive
thinking
about
of
each
other
thinking
about
the
language
that
we
use,
how
inclusive
we
are
in
meetings,
and
that
starts
with
everyone
individually,
myself
included.
So
I
think
that
we
could
be
using
the
we
could
be
using
those
competencies
as
a
place
to
start,
if
we
weren't
sure
exactly
how
to
build
that
out,
and
then
you
know
engaging
in
tmrgs
as
a
for
example
managers.
H
But
anyone
could
be
reminding
team
members
that
there
are
tmrgs
team
member
resource
groups,
that
is,
that
are
available
to
them
as
well.
So
I
think
that's
a
I'll
leave
the
death.
A
I
would
I
have
a
few
one
would
just
be
to
simplify
some
of
this
into
just
learning
something
new
about
people
who
are
different
from
you,
and
you
can
do
that
through
coffee,
chats
or
book
clubs
or
like
there's
a
dead
book
club
that
I'm
in
right
now
with
generational
diversity,
I'm
not
in
the
tmrg,
but
I'm
reading
the
book
with
the
book
club
and
also
social
events.
A
The
create
team
day
had
a
wonderful
social,
social
event
create
team
day
event
a
few
months
ago,
where
we
did
virtual
tours
of
our
communities
of
our
cities
of
our
neighborhoods,
and
it
was
really
great
to
kind
of
get
to
know
the
team
and
learn
more
about
where
people
came
from.
So
those
are
really
good
examples
that
I
had
does
anyone
have
any
other
examples
they'd
like
to
share.
F
Never
if
I
may
add
one
thing
on
that
particular
example:
you
gave
create
team
day.
One
of
the
things
we
got
really
good
feedback
on
was
the
fact
that
we
created
six
calls
throughout
the
day,
starting
in
the
australian
time
zone
very
early
for
them,
so
they
would
be
allowed
to
participate
comfortably
so
much
so
that
they
weren't
even
expecting
for
us
to
make
that
plan,
and
they
thought
that
we
were
planning
the
days
and
that
would
be
their
saturdays.
F
So
their
assumption
was
that
we
didn't
count
with
them
and
I
felt
like
that
was
a
particular
good
feedback
that,
by
just
thinking
about
them
from
the
first
moment,
gave
a
really
good
inclusion
feeling.
So
you
can
take
a
look
at
the
issue.
There's
an
issue
template.
If
you
want
a
copy,
please
go
ahead.
It's
been
copied
by
a
bunch
of
groups
already
they
started
off
with
plan.
Another
example
of
iteration
and
we
just
keep
improving
the
model.
C
Sure
yeah,
this
is
just
another
simple
thing
that
we
recently
did
is
we
went
back
and
reevaluated
all
of
our
synchronous
meetings
and
and
just
took
a
real
hard
look
at
whether
they
all
needed
to
be
synchronous
or
not.
So
we
ended
up
removing
a
synchronous,
refinement
meeting
and
instead
moved
all
of
our
refinement
to
be
asynchronous
and
that
actually
worked
out
a
lot
better
than
the
synchronous,
meaning.
F
I
have
one
more
darva,
sorry,
I
don't
have
any
entry
yet,
but
recently
I
participated
on
the
minorities
in
tech,
mentoring
program
and
one
of
the
projects
we
did
was
to
take
a
look
at
inclusive
behavior
on
the
day-to-day,
and
we
created
a
report
that
I'm
going
to
be
linking
in
two
seconds
after
I
stopped
speaking
where
it
has
a
bunch
of
examples
like
this.
F
One
of
the
big
examples
that
speaks
to
mine
is
when
somebody's
talking
about
a
topic,
and
you
know
the
answers
to,
but
there's
an
owner
on
the
call
if,
if,
if
you're
asked
that
question-
and
you
know
that
that
person
is
better
equipped
to
answer
that
question,
redirecting
that
to
that
person
is
a
way
of
recognizing
their
their
responsibility
and
their
their
contributions
and
some
other
times.
We
know
the
answers,
and
we
just
answer
those.
But
by
doing
that,
we
still
that
the
owner
of
that
topic
to
participate
and
to
be
highlighted
there.
F
A
All
right,
thank
you,
andre.
Would
anybody
else
like
to
add
comment:
verbalize
yeah,
all
right,
so
there
were
two
other
discussion
topics
that
were
really
great
ideas
too,
but
I
just
could
only
do
two,
so
maybe
if
you
all
would
like
you
could
roll
those
over
to
another
week,
another
retrospective,
all
right
next,
we'll
discuss
the
improvements
for
the
next
release
to
track
christopher.
You
are
up.
E
Yes,
I
think
we're
gonna
try
this
in
january,
we'll
do
it
the
well.
Actually,
I
forget
the
exact
date,
because
I
don't
have
the
calendar
up,
but
oh
yeah,
I
think
either
january
11th
or
12th.
I
think
we'll
move
the
actual
retro
for
next
month
and
we'll
actually
probably
try
an
afternoon
u.s
afternoon
time,
so
we'll
try
to
be
apac
friendly,
just
as
an
experiment
as
well
and
see
if
we
can
get
participation
that
way.
So
that's
my
action
item
for
next
month.
G
Yeah,
this
one's
pretty
straightforward.
We
had
a
bit
of
feedback
that
we
thought
we
were
closing
more
issues.
The
team
thought
as
a
result
of
moving
to
two-week
iterations,
and
that
was
part
of
dog
food
and
good
labs.
Iterations
feature
that
we've
just
finished
in
the
plan
team,
so
we're
going
to
do
a
straight
up
count
and
see
if
13
7
correlates
with
13
6
and
if
we
really
close
more
issues
or
if
it
was
just
an
anomaly.
G
G
This
is
a
bit
trickier,
yeah,
it's
a
common
problem
and
I
think
it
comes
up
in
our
retrospectives
a
lot
like
how
do
we
get
engineers
involved
in
the
design
of
features
earlier
in
the
process-
and
I
mentioned
elsewhere
in
the
document,
but
jan
spent
48
hours
shadowing
a
product
manager
in
the
team-
and
you
know,
got
a
real
feeling
for
how
important
this
is
that
we
don't
just
wait
until
features
get
into
the
planning
breakdown
phase,
but
that
we
for
some
features
get
engineers
involved
earlier.
So
there's
a
follow-up
issue
there.
G
A
D
Here
so
just
this
month
the
I
created
a
retro,
async
retro
issue
for
the
database
maintainers
I
was
hearing.
They
were
spending
a
lot
of
time
on
reviews
and
maintainership
so
put
together.
An
ac
grant
trail
got
some
really
good
feedback
and
got
some
some
good
iteration,
some
good
small
steps
that
we
can
do
to
improve
the
overall
process,
either
through
documentation
or
updating,
templates,
etc,
and
we
have
some
longer
term
improvements
that
we
can
implement
like
some
kind
of
automation.
D
It
went
well
enough
that
I
created
one
for
back
end
maintainers
too,
because
I
work
with
both
database
maintainers
and
back-end
maintainers
for
the
back-end
maintainer
one
I
targeted
january,
since
we're
approaching
the
holidays,
but
looking
for
any
kind
of
feedback
anybody
wants
to
participate
and,
yes
to
answer
your
question
christopher,
I
think
any
any
specialty
maintainership
would
be
great.
E
Yeah,
if
anybody's
interested,
let
craig
and
myself
know,
and
otherwise
craig
I'll
try
to
find
somebody
within
the
next
month,
awesome.
A
All
right,
thank
you,
craig!
Well,
that's
it
for
today!
So
thank
you.
Everyone
for
sharing
today
we're
at
the
end
of
the
retrospective.
Please
go
to
the
top
of
the
document,
and
you
will
see
the
text
iteration
for
13.7
retrospectives
that
link
there
will
take
you
to
an
issue
that
will
capture
any
feedback
you
have
from
today's
retrospective
thanks
again,
everyone
for
attending
and
enjoy
your
day
bye.