►
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
All
right
so
this
week
we're
discussing
chapter
six,
which
is:
why
have
we
stopped,
and
this
is
the
APAC
and
emeritance
session
of
the
staff
Engineers
path
book
club
I
have
the
first
item
here.
So
I
thought
this.
This
chapter
was
kind
of
interesting
it.
It
was
a
little
less
dense,
I
thought
than
some
of
the
other
chapters,
but
there
was
still
kind
of
a
lot
of
different
topics
covered.
A
So
there
are
a
lot
of
reasons
given
why
a
project
might
get
stalled
and
at
gitlab
I've
seen
a
few
of
these,
but
the
two
biggest
ones
were
being
blocked
by
another
team,
which
kind
of
seems
to
come
up
when
we
have
cross-team
projects
and
that
sort
of
specifically
comes
up
with
misaligned
priorities,
whereas
you
know
one
team
has
their
top
priority.
Is
this
project
and
the
other
team
is
just
kind
of
helping
out
and
I've
also
seen
this
in
community
contributions,
where
maybe
there's
a
community
contributor?
A
A
Secondly,
it
wasn't
necessarily
one
of
the
the
reasons
that
people
get
blocked,
but
in
the
loss
or
your
lost
section
there's
the
reason
of
you
don't
know
how
to
get
there
and
so
I
think
that
kind
of
overlapped
with
what
I've
seen
where
we
jump
into
something
without
necessarily
having
fully
planned
for
it
or
understanding
how
big
it
is,
and
then
it
just
continues
to
grow
until
we
realize
like.
A
Oh,
this
is
much
bigger
than
we
originally
thought
and
that
ultimately
leads
to
a
reprioritization
and
possibly
like
postponement
of
the
project
entirely.
A
So
I'm
curious
what
you've
seen
at
gitlab
and
and
what
kinds
of
roles
you've
seen
the
staff
and
Beyond
Engineers
play
in
the
resolution
of
these
types
of
situations.
B
I'll
I'll
start.
We
have
a
actually
an
interesting
topic
right
now
with
one
of
our
with
a
community
contributor,
with
a
Mr,
with
probably
close
to
2000
lines
of
code
being
changed.
So
it's
a
pretty
big
Mr.
Some
of
our
staff
plus
engineers
in
verify
have
no
just
just
mentioned
some
concerns
with
this
Mr
I've
already
got
one
approval,
and
so
what's
been
interesting
with
this
is
they've.
We've
been
working
pretty
closely
with
product
trying
to
understand.
B
If
there's
a
way
to
sort
of
you
know,
maybe
you
know
we
basically
need
to
I
think
stop
some
of
the
Mr.
What
the
progress
in
the
Mr,
but
it's
difficult,
because
you
know
we
we
are
trying
to
you-
know,
solicit
more
contributions
from
the
community,
and
so
it
seems
like
staff
plus
Engineers
have
been
sort
of
gently
nudging.
The
contributor,
like
you
know,
maybe
consider
performance
concerns
in
this
area.
B
So
it's
an
interesting
situation
for
me
as
it
relates
to
the
book,
because
I
think
it
is
something
that
needs
to
be
stopped
and
I.
Think
in
some
of
the
staff
plus
Engineers
roles.
A
Yeah
I,
agree,
I,
think
the
community
contributions
can
be
very
tricky
and
we
run
a
lot
around
or
we
run
across
this
a
lot
with
like
in
the
merge
request
coach
group,
where
we
there's
like
a
it's
a
lot
like
it's
easy
to
invite
people
to
contribute,
but
then,
like
there's
some
times
where
we
we
want
to
say
like
okay,
this
isn't
going
to
work
for
us,
or
you
know
this
isn't
going
the
direction
that
we
we
would
like
it
to
so
like
working
around
those
situations
is
definitely
much
more
difficult.
C
Yeah
I
I
see
this
more
with
like
Upstream
container
registry
than
gitlab,
but
it
can
be.
It
could
be
challenging
to
have
to
like
sort
of
direct
Community
contributions
because
they've
they
have
volunteered
their
time.
C
You
know
they
may
have
not
allotted
in
their
minds
more
time
to
do
it
than
they
did
like
they
might
be
in
their
head
finished
and
not
really
prepared
to
do
major
changes
to
the
to
the
work
they've
already
done,
but
at
the
same
time
there's
definitely
cases
of
some
historical
code
in
the
registry
that
got
merged
without
enough
scrutiny-
and
you
know
you
do
have
to
live
with
that
for
such
a
long
time,
because
you
have
to
support
the
you
know
if
it
is
causing
a
detectable
Behavior.
A
Yeah,
that's
a
really
good
point
of
you
know.
Once
you've
set
that
sort
of
example
you
you
really
have
to
stick
with
it,
so
it
is
a
matter
of
being
very
careful
on
you
know
what
kind
of
example
you're
setting,
especially
a
git
lab
where
everything
is
so
transparent.
So
you
know
Community
member
could
easily
say
like
well
like
this.
Just
got
merged
and
I
don't
see
how
mine
is
different.
You
know
and
having
to
work
around
anything
like
that
foreign.
A
Does
anyone
have
any
other
thoughts
on
that
General
thread
or
on
you
know
where
we've
seen
projects
get
stalled
and
and
staff
engineers
get
involved
at
Goa.
C
C
Originally,
we
had
decided
that
we're
going
to
have
two
separate
instances
of
the
registry
that
are
configured
differently
and
then
there
would
be
a
load
balancer
that
was
able
to
tell
like
what,
where,
where
requests
should
go
and
we
we
got
the
feedback
that
you
know
you've
put
a
lot
on
deliveries
played
without
their
knowledge,
basically
without
consulting
them,
and
we
had
to
redesign
you
know
we
had
to
find
another
way
to
make
it
work
and
send
Hugh
and
Camille
were
able
to
work
with
us
and
like
really
find
a
way
to
do
it
all
within,
like
the
registry
deployment
and
keep
it
the
same.
A
That's
a
really
good
example
and
all
I
can
just
verbalize.
Tom
was
never
here.
On
a
positive
note,
I've
worked
with
the
contributor
to
an
area
that
the
team
explicitly
said.
They
don't
have
time
to
work
on.
So
it's
nice
to
help
out
as
an
MR,
coach
and
yeah
I.
Think
that's
that's
a
really
good
point
that
we
do
have
like,
like
systems
set
up
to
try
to
help
with
this.
B
Sure
yeah
I
just
wanted
to
ask
a
question
to
the
folks
on
the
call.
Has
anyone
worked
on
any
projects
or
seen
some
ideas?
You
know
that
they
wish
they
had
more
time
to
work
on.
Maybe
some
of
these
projects
are
the
ones
that
end
up.
As
you
know,
your
loss,
it
could
be
some
really
really
interesting
idea
that
you
wish
you
had
more
time
on,
for
example,
I
can
just
verbalize
for
Tong.
He
said
not
gitlab
directly
I've
tried
to
enhance
bundler
and
got
stuck.
A
Yeah
definitely
like
had
a
lot
of
projects
that
have
been
on
my
mind
that
I've
wanted
to
work
on,
but
like
either
haven't
had
the
time
or
you
know
they
weren't
prioritized
high
enough,
and
sometimes
I
I
made
the
time
to
work
on
them,
because
I
I
really
wanted
to,
but
other
but
I
think
as
a
as
we've
been
reading
through
this
book,
especially
having
just
gone
through
this
section
on
working
on
large
projects.
A
I'm
realizing
that,
like
some
of
the
things
I
wanted
to
work
on,
were
not
ready,
like
they
weren't
planned
out
enough
or
I
didn't
have
enough
information
to
necessarily
decide
that
these
were
necessary.
It
was
just
maybe
something
that
I
thought
like
seemed
cool
at
the
time,
and
so
I
think
this
book
has
been
really
helpful
and
kind
of
making
me
think
a
bit
more
about
you
know
or
thinking
a
bit
more
objectively,
I
guess
about
those
types
of
things.
C
C
You
know
make
this
code
a
lot
more
beautiful,
but
it's
never
it's
it's
never
as
compelling
as
like
fixing
the
problems
that
we
have
better.
You
know
resulting
in
behavior
and
all
this
kind
of
stuff.
So
like
definitely
definitely
just
like
the
project.
C
Some
days,
but
it
just
doesn't,
you
know
it's
really
hard
to
find
the
time
for
that.
B
Yeah
I
was
just
gonna
add
for
me:
I've
not
been
part
of
some
of
these
initiatives,
but
I've
seen
a
lot
of
great
discussion
around
you
know
having
gitlab
events
more
event,
driven
architecture.
So
these
are
the
kinds
of
things
I
see
that
would
be.
You
know,
amazing,
to
have
a
git
lab,
but
I
can
imagine
also
just
folks
finding
the
time
or
you
know
not
being
their
top
priority
or
their
team's
top
priority
can
be
hard
to
find
time
for
these
kinds
of
initiatives.
A
So
I
thought
a
lot
of
these
suggestions
of
like
like
how
to
handle
these
situations
kind
of
fell
into
the
category
that
that
we
see
as
manager
of
one
at
gilad
and
the
examples
that
I
gave
like
in
in
the
first
area.
Above
about
you
know,
stalled
projects.
They
were
often
just
resolved
by
like
a
senior
person
on
the
team,
or
maybe
a
manager
just
kind
of
stepping
in
and
getting
things
moving
again,
especially
when
it
came
to
like
the
cross
team
collaboration.
A
It
was
just
a
matter
of
like
someone
had
to
go
talk
to
the
team
and
and
see
what
was
going
on
and
that's
kind
of
mentioned
in
the
book.
There's
the
quote
that
you're
responsible
for
understanding
why
things
are
stopped
and
getting
it
started
again.
A
So,
given
that
the
manager
of
one
is
part
of
gitlab's
efficiency,
value
like
how
would
you
as
a
staff
engineer
or
or
as
any
engineer,
really
not
just
implement
the
suggestions,
but
also
help
other
Engineers
to
feel
empowered
to
kind
of
do
the
same
and
take
steps
to
unblock
things
when
they
see
them?
A
Because
there's
there's
definitely
like
you
know
moments
of.
Like
oh
I,
don't
want
to
mess
with
that.
That's
not
my
responsibility
or
you
know,
I,
don't
know
if
I
have
the
authority
to
do
that,
but
kind
of
like
growing
people
to
feel
a
bit
more
empowered
in
doing
those
things
would
be
good.
Some
curious
about
General
thoughts
about
that.
A
A
C
I
think
part
of
it
is
surfacing
information.
The
book
talked
about
like
a
team
that
didn't
realize,
then
you
did
load
balancing
so
kind
of
using
your.
C
A
And
Tom's
writing
that
this
is
interesting
and
I.
Do
it
to
First,
unblock
and
then
make
sure
to
document
what
was
done.
A
All
right,
what
other
things
from
this
chapter?
Would
people
like
to
discuss
not
being
blocked
being
stalled,
being
lost.
C
Yeah
I
guess
I
wonder
how
people
handle
surprises,
because,
with
a
lot
of
the
bigger
project,
support
on
here
is
often
the
things
that
you
think
are
going
to
be.
A
big
problem
are
not
and
like
stuff
will
come
up
at
inopportune
times,
and
it
can
just
really
feel
it
could
feel
like
something
that
would
have
been
hard,
but
a
lot
more
manageable.
If
you
had
known
it
first.
So
how?
How
have
people
been
dealing
with
kind
of
these
last
minute,
but
larger
issues.
A
Yeah
I
think
I
think
the
main
thing
with
with
surprises
is
like
servicing
them
early
so
like
as
soon
as
you
identify
it
like
sharing
that
information
with
anyone
involved,
so
that
you
know
you
kind
of
have
like
everyone
that
can
help
knows
about
it
as
soon
as
they
possibly
can
and
then
from
there
you
know,
hopefully,
there's
there's
some
collaboration
involved
in
finding
the
right
or
or
most
efficient
path
forward,
rather
than
having,
like
one
person
struggle
on
it
for
a
week
or
two
and
then
finally
like
asking
for
help.
B
B
B
A
Okay
and
I
guess:
we've
got
a
couple
minutes
here,
so
I'll
jump
back
there
there's
a
question
posed
by
Tom
on
the
last
item
about
how
to
help
other
people
feel
empowered
to
take
on
or
to
feel
empowered
to
unblock.
A
You
know
installed
projects,
and
so
Tanya
mentioned
that
like
documenting
what
had
happened
and
yes
is
documentation
enough,
though,
or
do
others
need
more
guidance
or
permission
to
try
I
think
that's
a
very
I
think
it
depends
on
the
person
a
lot
like
some
people
will
see
that
and
say
like
okay.
A
I
can
do
this
now,
but
then
there's
other
people
like,
depending
on
their
confidence
level
and
experience
level
that
that
might
appreciate
the
nudge
from
someone
or
or
you
know
like
like
having
the
suggestion
come
personally
rather
than
necessarily
from
a
doc
but
yeah
I
think
it's
it's
very
Case
by
case
almost
I
do
think,
there's
a
a
factor
of
in
in
order
to
make
it
less
Case
by
case
trying
to
build
that
sort
of
culture
of
like
if
something's
documented,
it's
okay
to
do
this
or
if
some,
if
someone
is
doing
something,
it's
okay
to
do
it.