►
From YouTube: Development Group Conversation (Public Livestream)
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
Good
morning,
good
afternoon,
good
evening
to
everybody
at
gate
lab,
this
is
christopher
allah
Fults
and
I
am
running
the
development
group
conversation
today.
The
slides
are
in
the
section
of
the
documentary
related
to
today's
group
conversation.
We
already
have
a
number
of
questions,
so
thank
you
for
the
folks
who
posted
questions.
Early
I
will
try
to
do
a
I'll.
Try
to
do
answer
questions
in
line
as
well.
So
please
don't
hesitate
to
help
me
with
that.
If
anybody
was
going
to
jump
in
and
type
as
I'm
responding
to
further
questions
associated
with
this.
A
B
A
It's
good
question
the
and
I
try
to
basically
say
it
in
there
does
some
effect
the
the
basic
there's,
there's
always
a
challenge
of
you
know.
Do
you
want
to
make
your
organization
predictable,
or
do
you
want
to
choose
just
to
move
very
quickly,
and
you
know
planning
is
a
good
example
where
you
know
you
want
to
do
just
the
bare
amount
of
planning
to
organize
work
and
then
get
people
working
on
it
right
like
that's.
A
A
The
one
aspect
that
we
have
started
to
see,
particularly
from
a
product
management
perspective,
is,
is
that
we've
apparently
promised
to
customers.
You
know:
hey
here's
somewhere
down
the
road,
three
four
releases
from
now
or
four
to
seven
releases
from
now.
We'd,
like
this
we're
gonna
have
this
feature
in
there,
and
customers
are
kind
of
starting
to
think
in
terms
of
you
know:
hey
that
future
is
gonna
come
up
so
when
they
see
those
four
to
seven
releases
later
come
up
and
that
issue
or
that
feature
gets
pushed
out
another
four
to
seven
releases.
A
That's
when
they
start
saying:
okay.
What
are
we
doing
here
so
products
coming
with
this
idea
of
this
planning
priority
label,
which
we
have
started
to
see
items
being
listed
in
that
fashion,
and
this
is
an
idea
for
us,
basically
to
say:
okay,
here's
some
things
that
we
definitely
want
to
see
land
and
see
some
focus
associate
with
it.
So
it's
giving
the
product
manager
an
opportunity
to
you
know
remind
themselves,
okay,
here's
something
they
did
promise
to
somebody,
and
it
also
gives
a
engineering
the
opportunity
that
potentially
say.
A
Okay,
like
let's
focus
on
make
sure
the
focus
is
here
now.
Does
that
mean
that
it
shows
up
exactly
in
a
certain
release?
No,
does
it
mean
that
we're
gonna
do
it
for
everything?
No,
so
we
still
have
velocity
for
predictability
and
I
kind
of
just
use
that
ratio
there.
If
you
know
we
want
to
keep
it
to
maybe
four
to
ten
or
release,
and
we
have
17
issue
roughly
1700
issues
being
close
to
release
now
how
many
of
those
are
mr-s
and
productivity
versus
things
just
getting
closed
automatically.
A
That's
the
thing
we
gotta
quit
they're
gone,
but
it
still
feels
like
with
two
orders
of
magnitude.
Difference
between
those
two
we've
got
some
little
room
there.
If
we
ever
see
those
ratio
is
getting
too
close
to
each
other,
then,
and
that's
when
I
would
throw
up
the
flag
and
say:
okay,
we're
actually
predictable
over,
which
is
in
predictability
over
velocity
and
that's
kind
of
the
way
I'm
thinking
about
it.
Remember
to
do
so
so
understanding
the
needs
of
hey.
A
We
are
communicating,
customers
and
they're
important
to
us,
so
we
want
to,
you,
know,
serve
them
well
and
when
we
say
something
is
you
know
a
time
a
rough
time
frame
is
given.
We
should
try
to
be
in
that
to
the
rough
timeframe,
but
also
understanding
the
fact
that,
for
majority
of
our
work
we
don't
want
to
have
that,
at
least
at
this
point
in
the
company's
lifecycle.
So
is
this
then.
A
So
a
good
question
and
it
may
be
the
wording
of
it-
needs
to
be
reworked
a
little
bit
there.
I
think.
What
it
is
at
this
point
is
is
is
get
a
process
in
place
around
the
planning,
Prarie
and
then
based
on
that
see
how
we're
doing
and
then
determine
it
so
improve.
Is
we
don't
have
one
right
now,
so
the
improvement
would
be
is,
is
actually
get
something
in
place,
and
then
you
know
whether.
B
A
A
Problem,
okay
and
the
next
question
we
have
is
from
Shawn
McGivern
Shawn,
says
he's
not
here,
so
I'll
go
ahead
and
read
it,
which
is
also
on
slide
8.
The
second
key
result
says,
while
hiring
at
current
rate,
if
we
fail
to
hire
at
current
rate,
we
miss
this
K
key
result
and
the
first
hiring
cube
result.
Did
we
mean
to
have
that
dependency
between
the
two?
A
So
this
is
a
great
example
of
did
I
mean
to
happen,
but
dependency
between
the
two,
no
actually
I
wouldn't
like
to
have
to
dependency
between
the
two.
However,
science
says
that
you
know
both
in
the
data
that
we've
analyzed
and
also
in
the
in
the
in
the
results
we've
seen
so
far
that
you
know
just
from
a
timespan
perspective.
A
There
is
a
relationship
between
the
two,
so
I
probably
need
to
update
that
wording
to
be
a
little
bit
crisper
to
say
you
know
we're
gonna
attempt
to
hire
at
this
rate
and
that
obviously
affects
our
ability
to
deliver.
So
it's
a
kind
of
the
way
to
think
of
this
is
is
we're.
We're
gonna
spend
time
on
hiring
so.
Consequently,
we
would
expect
our
philosophy
from
an
mr
per
engineer
to
be
lower.
When
we
slow
down
our
hiring.
We
would
expect
that
to
go
up
and
that's
kind
of
the
expectation
around
it
here.
A
A
Cool
and
then
he
says
thanks
so
eight-point-three
is
due
to
the
hiring
drag
down
the
average
yeah.
So
that's
kind
of
okay,
good
good
day
see
you
got
the
explosion,
then
second,
one
was
as
a
from
Sean
was,
is:
do
we
plan
to
complete
ten
times,
Headroom
for
background
job
processing,
this
quarter
or
get
up
plan
to
ten
times
a
point,
so
I
didn't
get
to
talk
to
Craig
Gomes
ahead
of
time
about
this,
but
you
know
the
goal
right
now
at
this
point
is,
is
to
actually
get
that
implemented.
A
I'd
like
to
point
out,
though,
that
we
have
been
notoriously
known
for
updating
our
okrs
mid-quarter,
based
on
how
our
results
are
looking
associated
with
that.
So
if
we
find
it
mid-quarter
that
only
getting
a
plane
in
places
is
gonna
be
feasible,
we'll
adjust
accordingly
associated
with
that,
but
right
now
the
goal
is
very
much
to
get
the
ten
times
Headroom
into
background
jobs
processing
in
place,
and
in
fact
that
Craig
has
an
issue
open
on
that.
B
I
guess
no
one
is
speaking
of
soul.
Ask
another
one
Christopher:
if
you'd.
A
B
A
We
we
put
this
in
place
as
kind
of
a
global
to
the
group,
and
we
knew
that
because
of
that,
we
may
have
folks
joining
calls
that
maybe
don't
have
as
much
experience.
Part
of
the
idea
behind
down
calls
is
to
give
our
developers
more
exposure
to
the
infrastructure
team
and,
what's
going
on
with
the
infrastructure,
to
get
a
better
understanding
of
it.
That's
not
typically
how
you
think
about
on
calls.
Typically,
what
do
you
think
about
on
calls?
Is
this
the
person
you
bring
in
to
fix
arrears
all
but
problem
quickly?
A
Typically,
when
you
get
to
code
changes,
they're
not
going
to
happen
as
fast
as
you
would
ideally
hope.
So
so
you
know
from
an
exposure
perspective,
that's
kind
of
the
first
intent
of
this
I
actually
have
been
pleasantly
surprised
in
regards
to
the
level
of
collaboration
we
had
on
this
Chen
Chen
do
had
a
really
good
did
a
really
good
job
of
working
hard
to
come
up
with
a
proposal.
We
had
a
follow-up
Q&A
with
it.
A
We
had
alternative
proposals
which
came
up,
which
we
effectively
I
should
say,
alter,
but
a
complimentary
proposals
which
we
effectively
incorporated.
So
I
think
that
that
helped
a
lot
to
basically
address
some
of
the
concerns
raised
by
the
team
give
us
an
in
a
put
us
in
a
spot
where
we
can
potentially
use
it.
A
They
determined
that
we
needed
to
put
it
in
some
actual
monitoring
capabilities,
and
there
are
observability
capabilities,
I
should
say
monitoring,
but
its
ability
capabilities
on
here.
So
it's
a
good
example
of
something.
That's
you
know
it's
not
a
direct
causal
to
speed
up
infrastructure
issues,
but
I
do
view
it
as
a
positive
change
for
the
organization
as
a
whole.
I.
C
Have
a
few
observations
that
it's
also
because
we
just
executed
a
four
oh
one,
half
weeks
so
we
are,
we
seek.
We
need
to
see
some
wrinkles
there
to
on
execution
side,
so
we
are
continuously
monitoring
the
situation
and
doing
the
work,
and
you
can
see
a
lot
of
follow
up,
I
Mars
to
the
process
itself
and
we
are
trying
to
address
the
issues
as
we
learn.
So
this
is
definitely
a
learning
process.
We
continuously
to
improve
it.
Hopefully
that
walk
will
reach
to
a
point
that
it
works
efficiently
and
effectively.
C
C
A
E
Your
question:
absolutely
thanks
for
the
debt
Cristofori
appreciate
it.
So
my
question
is
about
our
plan
to
increase
the
amount
of
maintained
errs.
I
know
that
the
code
review
process
in
some
cases
is
probably
not
as
efficient
as
we
want
it
to
be,
which
kind
of
comes
down
to
maintainer
availability.
So
what's
the
plan
to
increase
our
amount
of
maintainer
x'
to
help
with
increasing
the
velocity
of
the
code
review
process?
Is
their
plan
documented
and
how's
it
going
yeah.
A
So
a
great
question,
a
couple
couple
of
points
there
associated
with
that
so
far,
this
is
gonna,
be
probably
counterintuitive
to
a
lot
of
people
in
the
organization.
So
far,
we've
been
able
to
maintain
a
pretty
consistent
ratio,
maintainer
x'
to
developers
in
part.
What
we
did
at
the
start
of
the
year
was,
as
we
started,
by
assigning
a
particular
director
with
an
organization
as
an
okay
hour
for
their
quarter
to
make
sure
that
they
kept
increasing
that
and
as
the
time
thing
to
keep
the
ratio.
A
At
the
same,
there
has
been
some
debate
about
whether
we
should
actually
have
the
ratio
go
lower,
meaning
the
ratio
number
of
maintainer
x'
is
or
the
number
of
developers
is
smaller
to
the
the
number
of
maintainer
x'.
When
we
looked
over
the
data
of
our
throughput
overall,
we
didn't
see
any
real,
dramatic
changes
based
on
those
ratios,
believe
it
or
not.
So
right
now,
from
a
perspective
of
velocity,
it
is
actually
not
affecting
our
velocity.
That's
not
to
say
that
we
shouldn't
continue
to
increase
it
because
at
some
point
obviously
would
become
a
problem.
A
Also,
there's
a
both
maintainer
and
developer
happiness,
which
we
need
to
focus
on
as
well.
So
that's
a
key
important
aspect
of
it.
The
kind
of
the
way
my
thinking
of
it
right
now
is
is
that,
because
we've
kept
the
ratios,
mostly
in
check,
we've
seen
that
you
know,
there's
a
certain
amount
of
lag
associated
when
we
complete
a
review
and
when
it
actually
gets
or
when
you
can
cleated
a
feature
and
when
it
gets
reviewed,
but
in
general,
that
lag
is
an
acceptable
amount
that
isn't
affecting
our
overall
productivity.
A
You
know
we
could
optimize
it
to
make
it
shorter,
I,
don't
I,
don't
know
if
that
necessarily
draws
as
much
benefit.
But
that
being
said,
because
of
the
growth
we
want
to
focus
on
it.
It's
an
OK
our
this
week.
This
this
quarter
for
Bartek,
Martin
I,
think
somebody
actually
posted
the
the
issue
in
there
basically
associated
with
that
and
the
plane
is,
is
to
continue
to
see
those
increase
in
and
hold
our
director
of
our
director
for
the
quarter
or
accountable
to
that.
A
So
if
anybody
went
and
looked
at
the
security
training
link
and
clicked
on
that,
it
sends
you
to
the
middle
of
a
document
or
it
should
send
you
in
the
middle
of
a
document
which
talks
about
the
security
training,
but
isn't
actually
the
securing
training
itself.
There's
a
couple
more
links
below
that,
but
just
as
a
healthy
advertisement
for
everybody.
A
The
document
is
now
82
pages
long
and
it's
our
engineering
Week
in
Review,
which
talks
about
everything
that's
gone
on
the
week
and
all
sorts
of
important
announcements
and
everybody
is
in
engineering,
is
required
to
read
a
read
it
if
you're
looking
the
handbook,
there's
a
page
around
communication
on
there
and
put
in
which
is
excellent
from
this
perspective
and
I
would
like
to
thank
everybody.
Who's
started
to
contribute
to
this
document
because
it's
brought
a
lot
of
things
to
light.
A
E
Hey
Christopher,
I'll
chime
in
with
one
more
question
just
so
I
could
get
a
little
bit
more
context
on
this
statement
and
slide
for
you
have
a
challenge
that
August
is
off
to
a
little
bit
of
a
slow
start
and
you've
asked
the
directors
to
check
vacation.
Would
you
expand
on
what
does
that
mean?
What
have
you
actually
asked
your
directors
to
do
in
checking
vacation.
A
Yes,
a
checking
vacation
is
just
understanding.
The
lay
of
the
land
August
is
a
classic
month,
both
in
the
States
and
I
believe
in
Europe,
where
folks
are
starting
to
get
back
to
school
and
Families
usually
take
a
week
of
vacation
off,
and
if
you
have
a
disproportionate
number
of
folks
taking
that
week
of
vacation
and
that's
an
example
where
you
would
expect
actually
see
throughput
slowdown
effectively.
So
I
am
seeing
the
lagging,
and
you
know
a
indicator
that
says
throughput
for
the
month
is
probably
going
to
be
a
little
bit
slower.
A
Let's
say
it,
the
1800m
are
arranged
that
includes
step
which
is
going
to
be
a
10%
reduction
in
the
overall
results
FYI,
but
you
know
1800
versus
2100
that
we
peaked
at
in
July.
So
so
what
I
asked
them
specifically
do
is
go
figure
out
who,
on
your
teams,
have
basically
taken
a
week
or
two
weeks
of
vacation
in
August
and
add
it
up
so
I'm.
A
Looking
for
the
like
the
pros
approximation,
accuracy,
so
I
remember,
the
team
took
a
week
off
in
the
month
of
August,
then
you'd
be
at
75%
capacity,
not
a
medical,
personal
capacity,
and
you
know
that's
just
recognizing
the
fact
that
people
should
take
time
off.
We
should
encourage
it,
we're
where
it's
needed
spending
time
with
families
who
are
important
to
me
personally
and
also
should
be
important,
or
at
least
I
view
it
as
important
as
making
sure
that
we
allot
the
time
associated
with
it.
A
D
A
Yes,
a
good
question,
typically
what
we
think
about
when
we
were
thinking
about
targets,
is
we
don't
target
a
specific
month
in
an
amount?
What
we
do
is
target
for
the
quarter
and
say
during
the
next
three
months,
we'll
see
that
so
it's
kind
of
a
peak-to-peak
kind
of
analysis
associated
with,
or
at
least
that's
kind
of
how
it's
currently
set
up
associated
with
that.
So
so
the
question
becomes
is,
would
we
ever
have
a
three
month
all
associate
with
that,
and
it's
conceivable
we
could
do
that.
A
We
could
have
a
contribute
and
then
November
in
December,
which
are
classically
a
lower
months
in
the
same
quarter.
So
we
might
have
a
q4
as
an
example
from
that
perspective,
and
we
probably
would
want
to
be
predictive
in
that
fashion,
but
so
far
the
limited
amount
of
data
we
have
we've
been
able
to
see
one
month
where
we've
gone
from
peak
to
peak
associated
with
it.
A
B
A
A
All
right,
I
think
we've
exhausted
our
question
list
so
as
such
I'm
going
to
close
the
group
conversation.
Thank
you.
Everybody
for
attending
really
appreciate
everybody
joining,
and
everybody
have
a
great
morning
afternoon
or
evening,
depending
on
your
time
zone
and
where
you
are
in
your
day.
Thank
you
very
much.