►
From YouTube: Ecosystem Weekly Meeting 2019-10-02
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).
B
All
right,
so,
yes,
just
make
sure
that
you've
read
the
mr
regarding
availability
over
velocity
and
then
there
was
an
act
form
sent
out
to
acknowledge
that
you've
read
that
and
understand
it.
So
if
you
haven't
filled
out
that
google
form
yet,
please
do
so
and
make
sure
it's
submitted.
I
have
the
item
two.
So
just
another
friendly
reminder
that
on
slack
we
only
keep
ninety
days
of
slack
history.
So,
mrs
issues,
google
docs,
are
the
preferred
avenue
for
communication
around
work
items
and
team
process
stuff.
B
I
think
if,
if
we're,
if
we
end
up
going
back
and
forth
a
lot
about
something
in
slack,
that
might
be
an
indication
that
we
need
to
take
it
to
an
issue.
So
it's
not
something
that
I'm
not
thinking
of
a
specific
example
right
now.
It's
just
something
that
somebody
reminded
me
oats
and
I
think
it's
just
a
good
thing
to
keep
in
mind
as
our
team
ramps
up
and
we
start
having
more
in-depth
discussion
around
issues
and
our
team
process.
B
Yeah,
I
think
it
makes
a
lot
of
sense,
I
mean
as
a
newbie.
It's
not
something
that
has
directly
affected
our
team
much,
but
I
think
it
makes
a
lot
of
sense.
I!
Think
it's
one
of
those
things
where
you
kind
of
have
to
go
slow
to
go
fast.
So
the
more
we
focus
on
availability
and
security,
the
faster
we'll,
be
able
to
move
and,
and
so
I
think
they're
all
interrelated.
And
you
can't
you
can't
have
good
long-term
velocity
without
availability
and
and
that's
the
sentiment.
B
A
Think,
in
particular,
with
the
kind
of
work
that
we're
gonna
be
doing
in
ecosystem.
There
is
at
least
an
opportunity
to
build
things
that
are
somewhat
fragile,
we're
relying
on
and
integrating
with
external
services,
and
so
there's
a
high
level
of
risk
of
fragility
to
the
kinds
of
things
things
that
we
are
proposing.
A
So
to
that
end,
with
that
availability
over
velocity
in
mind
like
it
is
worthwhile,
especially
for
ecosystem,
it's
worthwhile
for
everyone,
but
it's
worthwhile,
especially
for
ecosystem,
to
really
make
sure
we've
got
solid
test
coverage
that
we're
thinking
through
monitoring
and
and
and
quantitatively
viewing
like
usage
metrics
to
make
sure
that
the
things
that
we're
building
are
always
available
and
that
they're
they're
continuing
to
work.
Even
though
there
are
changes
on
these
external
surfaces
which,
hopefully
that's
not
an
issue,
we
run
into
a
ton,
but
it
definitely
happens
right.
A
B
Yeah
great
I
think,
with
these
integrations
and
having
to
consider
different
services,
there
will
be
some
very
fun
and
interesting
testing
scenarios
to
think
through
and
especially
if
we,
if
we
want
to
get
into
like
test
automation
around
these
services,
I
think
there
are
some
very
unique
challenges
around
that
and
making
sure
that
that
we
can
test
for
regressions
yeah,
as
updates
come
through
and
and
be
able
to
understand
what
is
happening
in,
say.
Various
versions
of
JIRA.
C
So
this
a
this
week,
I'm
being
working
in
different
issues,
but
the
last
three
that
I
pick.
Basically
the
problem
is
they
they
are
like
berry
or
like
one
or
two
years
old.
So
I
cannot
reproduce
the
thing
so
I'm.
What
I'm
doing
is
I,
try
to
reproduce
a
day
issue
and
maybe
write
the
steps
that
I,
follow
and
other
questions
that
I
could
have.
Are
the
issue
and
I
think
that
I'm
going
to
wait
like
a
couple
of
days
and
if
no
one
say
anything
out,
they
see
oh
I'm,
going
to
close
the
issues.
C
I
know
that
this
this
is
going
to
happen
at
the
beginning,
because
I'm
kind
of
picking
things
and
also
understand
a
issue
and
then
becoming
familiar
with
the
problem.
But
yes,
as
I
said
last
week,
I
expect
that
I
am
with
more
time.
Probably
we
don't
have
this
problem
anymore.
You
know
like
picking
something
that
means
we
are
not
able
to
to
work
on
that
yeah.
So,
yes
to
let
you
know
about
saying
this.
C
And
something
that
I
think
we
say:
Nick
was
about
coming
because
they
kpi's
and
we
have
an
affair.
They
are
related
to
my
request.
So
maybe
you
know
what
case
may
make
sense
to
confine
you
method
that
this
basically
is
close,
because
maybe
we
close
five
of
we
are
going
to
close
five
issues
without
any
request.
C
A
And
I
know
so:
okay,
a
few
things
there
I
think
of
so.
First
of
all,
that
sounds
great
I
think
it's
awesome,
I'm
sure
you
will
just
make
sure
that
you're
pinging
Nick
and
myself
on
anything
that
you're
closing,
because
you
can't
reproduce
it
just
for
visibility
and
I'm
sure
you
will
and
that's
great
so
I'm
not
worried
about
anything
there.
I
think.
All
of
that
is
fine
to
your
second
point:
I
think
that
you're
right,
like
in
time
I,
think
this
is
going
to
become
less
and
less
of
an
issue.
A
A
That
I
have
already
closed
out
a
few
myself
before
y'all
got
here.
There
was
a
bunch
of
stuff
that
just
required,
like
technical
validation,
that
I
was
unable
to
do
and
that
we'll
continue
to
see
some
of
that
stuff
come
through,
but
my
hope
is
over
the
next.
Probably
six
months,
like
my
assumption,
would
be,
we
probably
get
those
down
to
almost
zero.
It's
just
gonna
be
this
first
period
where
we're
gonna
run
into
a
lot
of
stuff.
That's
just
been
languishing,
and
no
one
is
really
given
it.
A
A
solid
look
and
we're
gonna
be
the
first
people
to
really
touch
it.
So
I,
don't
think.
That's
a
problem.
Now
around
a
KPI
for
issues
being
closed,
resolved,
I'm,
not
sure
I,
know
I
was
just
in
the
the
development
group
conversation.
There
was
some
discussion
around
using
a
slightly
different
KPI
Sid
brought
up
some
really
great
points
around.
A
What
possible
KPIs
you
can
use,
and
so
kind
of
the
short
version
of
that
discussion
was
that
you've
got
three
possible
metrics
that
you
could
use
for
measuring
velocity.
So
you
can
look
at
weight.
The
problem
with
weight
is
that-
and
this
doesn't
help
for
solving
for
closed
I'm,
just
giving
you
a
overview
of
the
conversation
right,
so
you
can
look
at
weight.
The
problem
with
in
weight
is
that
sometimes
people
will
inflate
weights.
A
So
all
of
that
kind
of
a
side,
I
think
I
think
it's
fair
to
say,
like
we
should
be
keeping
an
eye
on
things
that
have
been
closed
and
resolved,
but
I
honestly
I
wouldn't
worry
too
much
about
it
at
this
juncture,
because
my
assumption
is
we're
gonna
see
less
and
less
of
it
over
the
next
few
months.
So
I
don't.
A
C
Know
the
water
is
basically
if,
if
we
are
tracking
productivity
in
some
way
a
we
are
productive,
but
in
a
different
way
that
is
not
be
measured.
Is
si
our
discussion
with
mr.
ding
in
our
101,
and
how
do
you
say
like
do?
Have
a
metric
and
people
can
cut
the
material
you
know
do
whatever
it
is
needs
in
order
to
satisfy
the
metric
so
yeah,
it's
always
tricky
with
metrics.
B
We
also
closed
this
many
issues,
even
if
there's
not
say
an
automated
way
to
track
that
we
I'd
like
to
just
keep
tabs
on
that
as
a
team,
so
that
we
can.
We
can
explain
that,
along
with
whatever
throughput
metric
that
are
yes,
whatever
to
put
metric,
that
our
team
ends
up
or
number
that
our
team
ends
up
at.
A
C
So
next
thing
me
say
something
that
maybe
we
could
have
a
conversation
because
he's
going
to
be
more
efficient,
that
just
writing,
and
so
basically
we
have
this
weekly
meeting
that
I
know.
So
what
is
the
purpose
of
the
meeting,
because
I
mean
we?
We
are
talking
about
scheduling
the
iterations
and
also
a
retrospective
for
the
duration,
I,
guess
and
I'm,
not
sure
if
that
or
maybe
the
scheduling
could
be
part
of
this
meeting
just.
C
B
So
it
seems
like
if
we're
trying
to
keep
this
to
a
fairly
short
call.
Those
could
be
broken
up.
I
think
that
with
this
type
of
weekly
meeting,
it's
sort
of
a
face-to-face
sync
up
with
product
and
engineering
kind
of
general
updates
and
announcements
reminders
things
like
that.
I,
don't
think
we
should
get
into
any
in-depth
discussions
about
issues,
because
I
think
that
if
we're
doing
that,
then
that
might
be
indicative
that
we
need
to
actually
take
it
into
a
discussion
in
the
issue
itself
or
in
an
M
R.
B
A
Yeah
I
think
in
general,
I
I
can
I
will
thumbs
up
to
all
of
that.
My
view
on
it
is
I
want
to
try
to
keep
I
wanted.
The
things
that
are
going
to
block
engineering
are
gonna,
be
the
I
guess
all
of
them,
but
the
the
retrospective
I'd
like
to
keep
asynchronous,
which
is
I,
think
it
seems
to
already
be
the
company's
perspective,
but
especially
with
with
respect
to
the
different
time
zones
that
we're
in
want
to
make
sure
that
as
much
as
we're
doing
as
possible
is
asynchronous.
A
I
think
that
for
the
most
part,
my
like
Nick
and
I
have
yet
to
do
this
for
the
first
time.
Yet
so
we're
gonna
see
how
it
works
out
and
like
we'll
just
let
it
evolve.
My
take
on
scheduling
at
the
moment
is
I'm
gonna,
be
setting
a
priority
inside
of
the
the
product
workflow
board
that
I
have
set
up,
and
then
Nick
and
I
will
work
together
on
moving
those
things
over
into
scheduling
and
then
I
think
we
can
asynchronously
have
a
discussion
with
the
rest
of
the
team
on.
Does
that
make
sense?
A
Is
that?
Is
there
something
in
there?
That's
no
good
and
kind
of
help
us
provide
that
feedback
asynchronously,
because
I
don't
I.
Don't
think
that
we
need
to
make
sure
that
you
know
Arturo
and
Justin
are
available
in
different
time
zones
to
sit
there
and
have
an
hour-long
discussion
about
like
do.
We
want
to
do
this
now
or
like
two
weeks
from
now
or
that's
let
us
let
us
do
that.
Synchronously
and
then
y'all
can
chime
in
a
sink
and
perhaps
I'm
like
I'm
totally
fine
with
taking
that
feedback.
B
C
I'm
not
sure,
if
probably-
and
maybe
we
can
do
it
this
before
the
company
called
not
after
because
after
you
say
sure
is
model
is
custom
between
a
I
notion.
Where
are
you
I
based
a
lien
but
I
know
Mike
and
Patrick?
They
are
like
twelve
hours
for
ingesting.
Some
is
a
conversation
between
you,
I
guess,
because
for
me,
I'm
in
the
middle.
So
for
me
is
not
a
problem.
C
A
A
Seeing
all
your
wonderful
faces,
I
think
it's
probably
important
for
us
to
be
very,
very
a
sync
and
as
we
grow
this
team,
it's
the
problems
only
gonna
get
worse,
so
I
think
that's
why
it's
important
right
and
that's
why
it's
important
as
a
get
lab
value
to
try
to
favor
asynchronous
communication.
So
but
you
know
what
let's
keep
iterating
on
it
and
we'll
figure
out
something
that
works
for
everybody
cool.
A
A
E
Mean
for
me,
usually:
okay,
I'm,
quite
okay,
with
like
slightly
off
hours
but
I-
think
we'll
probably
need
some
trial
and
error
in
this
and
and
I
do
think.
That
is
a
sync
communication
here
would
be
better
because
as
much
as
I
am
usually
awake
at
this
hour,
being
productive
is
not
always
the
same
like
right
now,
I'm
mainly
listening
in
and
I,
don't
really
have
to
think
much
don't
have
to
contribute
much,
but
if
I
actually
had
to
and
I'm
not
sure
like
you
know
the
these
people
to
give
at
this
hour
sure.
A
Well
and
I
think
that's
also
why
it's
important
that
we
try
to
and
Nick's
been
doing
a
great
job,
but
try
to
make
sure
we
have
good
notes
in
the
agenda
doc.
So
if
you
can't
make
it
or
you
choose
not
to
make
it
because
it
just
doesn't
work
out
for
you,
that's
I
think
we
need
to
make
sure
that
that's.
Why
that's
why
I
get
lab
in
general,
like
we
have
really
good
agenda
Docs
that
have
really
good
notes
in
them
so
that
you
can
always
catch
back
up.
A
B
B
All
right,
yeah,
before
I,
move
on
to
this
I,
will
also
just
put
in
another
reminder
that
we
have
an
issue
open
on
our
team
subgroup
for
are
discussing
weekly
meeting
time.
So
I
think
all
these
points
that
everyone
brought
up
here.
We
should
add
those
to
the
issue
with
our
preferences
and
suggestions
and
keep
the
discussion
going
there
yeah.
My
item
is
just
that
in
this
dashboard
that
I
linked
to
I
noticed
a
lot
of
group
ecosystem
bugs
without
a
priority
or
severity,
and
you
just
want
to
see
who
is
responsible
for
triaging
those.
A
Yeah
so
yes
agreed,
we
need
to
start
going
through
there.
I've
just
been
trying
to
I
already
knew
there
was
enough
work
in
the
pipeline,
so
I
wasn't
gonna
push
on
it
further,
but
yeah
the
the
two
of
us
can,
let's,
let's
think
about
this
in
our
next
one-on-one
and
in
the
scheduling
all
right.
We
can
start
going
through
those
together
and
working
on.
Are
you
on
the
debris
on
spot
lists?
Yet
I,
don't
think
so?
Okay,
we
need
to
get
you
on
triage
spot.
I
think
Jen
was
on
it
previously.
A
We
need
to
get
him
taken
off
and
you
added
to
it
triage
bot
can
help
us.
What's
all
that?
Oh
it's
you!
It's
an
automated
reminder
of
issues
that
have
not
been
scheduled
that
have
certain
very
levels,
so
cool
anything
else,
so
good,
so
weird,
nope,
that's
it
okay!
So
the
last
piece
I
just
really
want
to
call
out
Eileen
for
doing
such
a
great
job,
Eileen
you're
the
best.
Thank
you
for
helping
me
with
all
this
stuff.
A
I
am
doing
the
problem,
validation
or
calling
up
a
problem,
a
product
development
flow
process,
so
I'm
working
through
that
with
Eileen's
help
and
trying
to
validate
the
JIRA
group
level
integration,
a
that
it
is
a
real
problem
and
be
the
integrating
at
a
group
level
solves
that
problem.
Our
what
I'm
going
to
be
looking
to
find
out
and
so
I'll
be
working
with
her
to
interview
customers
and
collect
that
data
and
talking
throughout
our
business
with
stakeholders
to
understand
better
how
to
do
it.
A
I
think
it's
a
really
big
issue
impacts,
some
really
big
customers,
so
I
think
it's
I
think
it's
going
to
be
really
cool
and
important
sport
that
is
going
to
be
very
exciting
for
a
lot
of
places
inside
the
company.
So
if
you
want
to
read
more
there's
a
ton
of
info
in
that
issue
feel
free
to
check
it
out,
feel
free
to
send
me
or
Eileen
or
whatever
leave
comments
in
the
issue
cool,
that's
all
yeah
and
we
have
two
minutes
and
the.
B
Awesome
yeah
I
just
wanted
to
quickly
go
through
the
issue
overview.
We
have
a
couple
moved
from
12
five
to
12,
for
so
thanks
for
doing
that,
Arturo
and
art
also
has
has
another
Mr
created.
That's
in
review.
Did
you
want?
Were
there
any
specific
issues
you
wanted
to
quickly
highlight
Parker,
oh
yeah,.
C
C
So
early
I'm
going
to
move
more
things,
but
I
don't
want
to
take
more
and
more.
You
know,
because
I
have
these
like
kind
of
block
tickets,
that
I
know
so
define
I
need
to
work
I'm
going
to
flops.
So
at
the
moment,
maybe
I'm
not
going
to
move
more
things
until
because
there's
so
many
plates
at
the
same
time.
You
know
so
unless
close
things,
but
I
still
have
work
to
do
so.
Homebody,
okay,.