►
From YouTube: Iteration Office Hours with CEO (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).
B
All
right,
hi
everyone,
I'm
crystal,
I'm
the
engineering
manager
for
the
backend
health
team.
What
we
have
on
the
agenda
is
a
little
bit
of
a
process
change
that
we've
been
working
on
within
the
team,
and
this
has
been
evolving
since
about
12
nine,
so
the
team
was
building
out
this
new
feature
set
for
the
status
page,
which
was
a
brand
new
category.
B
B
So
when
we
got
to
1210,
we
decided
to
have
we
had
another
feature
set
that
was
coming
up
and
we
have
one
engineer
who
is
managing
this
kind
of
feature
flag
process
where
we
have
features
broken
down
by
minimal
subsets,
so
that
we're
always
ready
to
release
whatever
is
done
by
removing
the
feature
flag?
And
so
this
worked
out
very
well.
B
The
health
teams
had
the
opportunity
to
build
out
a
couple
of
new
like
brand
new
categories,
where
we
have
lots
of
small
features
and
we
want
to
release
as
much
of
it
as
possible
each
time
through,
and
so
we've
been
building
up
to
this
ability
to
just
clear
the
feature
flag
right
before
the
final
release
candidate
goes
out
and
then
ship,
whatever
we
have
that's
done,
and
so
this
has
been
working
out
really
great
for
our
team
and
we're
continuing
to
kind
of
build
on
it
as
we
go
through
each
milestone.
A
Cool
thanks
for
sharing
did
so
it
missed.
12.9
was
12.9
the
only
kind
of
release
in
which
you
were
working
on
this
functionality,
or
was
there
also
worked
on
in
12.8.
B
I
believe
it
was
all
part
of
12.9
for
the
status
page.
This
was
before
I
joined
the
team,
so
I
wasn't
there
for
12.8,
but
I
believe
that
this
was
all
a
pretty
small
feature
set.
That
was
going
in
to
do
the
minimal
set
of
features
for
the
status
page.
A
Cool
thanks
for
that
was
the
work
started
immediately
on
this
foundational,
mr
the
26717.
B
So
I
think
the
the
way
this
happened
was
like
all
of
these
features
were
built
up
in
12.9.
B
It
was
almost
ready
to
go
and
then
barely
missed
by
this
one
piece
and
then
again
in
1210,
the
team
was
working
on
something
different
and
kind
of
all
of
this
work
was
already
done
and
then
even
at
the
end
of
1210,
there
was
a
problem
that
came
up
and
it
almost
slipped
again
and
so
really,
I
think
the
the
key
takeaway
from
all
this
is
that
we've
broken
things
down
into
like
deliverable
sub
features
instead
of
having
one
foundational
piece
and
then
we
lay
the
back
end
on
top,
and
then
we
lay
the
front
end
on
top.
A
B
Yeah
definitely
with
the
the
latest
work
that
we've
been
doing
for
we've
been
working
on
the
alerts
in
incident
management.
We
have
things
broken
up
by
list
and
detail,
but
then
we
also
have
features
that
are
like
column,
sorting
or
adding
additional
columns
or
adding
additional
details
to
the
detail
page,
and
that
way
we
always
have
something.
That's
ready
to
go.
B
I
think
so
that
was
really
just
so
that
the
production
releases
weren't,
releasing
anything
that
wasn't
totally
done
yet.
We
also
have
a
lot
of
involvement
from
our
product
designer
to
make
sure
things
are
in
really
good
shape
before
they're
fully
released.
So
I
think
a
lot
of
that
is
just
to
kind
of
guard
things
from
being
released
before
they're,
completely
ready
and
vetted.
A
Yeah,
ideally
an
ideal
world,
and
I
don't
this
is
more
in
general.
I
don't
know
about
this
specific
one,
but
you
shouldn't
need
feature
flags
feature.
Flags
are
extra
work,
they're,
so
yeah.
A
You
you
also
need
to
do
a
feature
flag,
you're
gonna,
take
away
from
from
some
of
the
work,
and
it
might
be
worth
it
might
be
a
good
trade-off.
A
But,
for
example,
if
it's
just
a
background
thing,
like
the
ad
background
worker
to
publish
incident
to
status
base,
you
can
just
release
that
might
not
do
anything
because
you
haven't
released
the
front-end
stuff,
but
doesn't
matter
you
can
still.
You
can
still
merge
that
to
production,
no
need
to
put
it
behind
the
feature
flag.
A
Unless
it's
because
you're
afraid
the
background
worker
will
go
berserk
and
the
operations
team
needs
a
way
to
turn
it
off
or
something.
That's
that's
a
different
one,
but
just
talking
about
it's
okay,
to
release
something
that
doesn't
do
anything
as
long
as
not
affecting
the
interface
too
much,
and
the
other
thing
you
mentioned
is
like
it
needs
to
be
in
a
really
good
shape.
A
Well,
maybe
not,
maybe
it
doesn't
need
to
be
in
a
really
good
shape.
Maybe
if
you're
not
super
happy
about
the
interface
and
you
think
it's
in
a
really
bad
shape.
Maybe
you
don't
publish
the
release
post
yeah,
but
you
do
have
it
available
as
a
functionality
in
gitlab
or
you
publish
it
in
the
release
post,
and
you
say
this
is
alpha,
looks
horrible
and
you
get
two
release
posts
to
announce
your
feature,
which
is
great.
D
A
Yeah
iteration
is
hard
and
I
I
in
this
meeting
I
get
to
sit
from
a
laundry
chair
and
talk
about
it.
I
thought
I
anticipated
a
performance
concern,
so
I
was
like
product
analytics.
It's
going
to
get
a
ton
of
data
so
receiving
that
data
is
a
performance.
That's
a
performance
concern
concern
if
it
hits
our
real
stack.
A
So
we
should
write
that
in
goal,
so
I
went
off
learned
a
bit
of
go,
wrote
it
and
go,
but
you
could
also
say
like
hey:
maybe
we
should
have
iterated
because
dimitri
decided
to
make
it
in
rails
and
because
of
that
he
didn't
need
collaboration
from
the
omnibus
team
to
package
up
that
go
binary
in
our
stack
and
everything
else.
So
that
was
a
simpler
thing.
I
could
have
programmed
that
no
omnibus
team
required.
A
I
was
like
prematurely
optimizing
and
then,
when
it
becomes
a
success
and
there's
too
much
load
on
the
rails,
workers
and
everything
else,
then
we
can
rewrite
it
and
go
better.
Go
by
the
way.
Write
and
go
is
pretty
tedious,
so
maybe
it's
even
faster
to
iterate
in
rails
for
a
while.
Just
until
we
know
what
we
want
to
make
until
we
know
it's
popular
and
then
optimize
it,
so
I
think
it's
a
great
question,
and
this
was
the
biggest
biggest
thing
that
comes
to
mind.
E
Leave
here
yeah,
that's
fine
thanks.
I
was
curious
if
we
have
already
identified
some
possible
pitfalls
that
get
in
the
way
of
iteration
as
the
company
is
growing,
because
as
we
are,
we
are
growing.
We
have
more
and
more
groups
that
get
defined,
so
I
think
it's
creating
more
boundaries
between
those
group
and
product
areas,
so
it
increase
the
risk
of
stepping
over
each
other's
toes
and
we
have
multiple
people
that
will
try
to
contribute
on
the
same
piece
of
the
product
or
same
part
of
the
application.
A
Yeah,
it's
certainly
a
concern
so
far.
I've
not
seen
it
affect
us
a
lot.
I
think,
first
of
all,
we've
done
a
great
job
in
kind
of
delineating
like
who's
doing
what
I'm
very
proud
of
the
categories
page.
If
you,
google
gitlab
categories
where
we
clearly
say
who's
who's,
doing
what
I
think
that
led
to
a
lot
of
help.
A
I
also
think
that
if
all
the
teams
are
iterating
and
shipping
small
pieces,
it's
easier
to
coordinate
the
super
hard
is
like
someone
lands,
something
really
big.
Just
just
before
you're
about
to
merge,
and
now
you
have
to
incorporate
all
those
changes.
So
the
changes
are
gradually
it's
easier
to
accommodate.
A
A
Security
is
non-negotiable,
so
we
got
to
make
sure
we
always
take
our
security
precautions
before
releasing
code,
but
we
try
to
avoid
as
many
others
as
we
can
like.
There's
no
central
ux
cabal.
That
needs
to
approve
everything.
There's
no
central
architecture,
cabal,
there's
no
central,
I
don't
know
I
could,
I
could
think
of
a
few
other
ones,
but
we
want
to
prevent
you
every
time
you
change
something
from
having
to
get
approval
from
multiple
other
groups.
E
Well,
I
would
have
a
very
great
counterexample
to
what
you
just
said,
which
is,
I
think,
the
secure
area,
because
I
think
it's
also
tied
to
the
way
gitlab
is
in
a
unique
position
to
do
something
different
from
competitors.
We
are
trying
to
compete
with
multiple
companies
that
do
single
product.
We
have
one.
We
are
trying
to
integrate
all
those
into
one
single
application,
which
means
we
have
an
aggregation
path.
E
A
I
think
what
you're
going,
what
you're
referring
to
is
kind
of
our
vulnerability
management,
like
all
these
tools
are
spewing
out
vulnerabilities,
if
not
just
feel
free
to
clarify
that,
and
we
have
a
vulnerability
management
group,
who's
kind
of
doing
that,
but
they're
called
the
threat
insights
group-
that's
that's,
probably
not
correct,
that's
probably
an
historical
artifact
and
that
they
that
that's
not
renamed
gives
me
cause
for
concern
and
then
hearing
you
saying
it's
hard
to
bring.
Everything
together
gives
me
cause
for
even
more
concern.
A
So
I'm
not
sure
how
to
solve
that
feel
free
to
kind
of
give
me
an
example
slack
or
something
that
I
can
bring
up
in
the
product
scaling
meeting
or
something
like
that.
E
It's
something
we're
trying
to
solve
for
quite
a
long
time.
It's
really
hard
to
to
find
that
delineation
and
yeah.
It's
a
constant
issue,
but
this
is
a
problem.
We
don't
see
a
final
solution
that
that
fits
all
the
the
usage
because,
for
example,
one
category
is
dependency
scanning,
and
this
covers
both
from
the
beginning
of
getting
that
information
about
security
vulnerabilities
to
showing
it
into
the
ui
and
managing
it.
E
So
it's
clearly
overlapping
the
part
of
verifying
management,
because
when
you
compare
that
dependency
king
feature
with
a
standalone
product,
they
have
this
spot
also
part
of
the
dependency
scanning
capabilities.
So
it's
even
from
the
product
perspective.
There
is
an
overlap
to
me.
This
is
more
painful
for
us
as
engineers,
because
we
clearly
overlap
at
the
time
of
implementation,
but
even
from
the
product
side.
I
think
there
is
an
overlap
here
and
I
actually
don't
see
any
solution
to
avoid
that.
A
E
I
don't
know,
to
be
honest:
it's
been
something
we're
debating
from
quite
some
time
insecure.
I
think
we're
coming
to
something
better
recently
so,
but
if
we
keep
having
issues
I'll
come
and
bother
you
with
that,
then.
E
A
Do
it
but
I'll
wait
until
I
get
an
invite
and
I'd
love
to
have
a
25-minute
meeting
to
to
discuss
and
dive
in
a
little
bit
thanks
for
putting
it
on.
D
Absolutely
it
comes
from
a
greedy
how
to
balance
iterations
in
overhead
of
too
many
chained.
Mrs.
A
If
the
so
iteration
is
means
scoping
it
down
to
something
that
creates
value
by
itself,
so
if
you
have
chained,
mrs,
that,
like
you
need
to
merge
the
next
thing
before
creating
any
value
like
that's,
that's
kind
of
a
warning
sign,
it
might
be
inevitable
or
it
might
not
be.
So
maybe
you
can
read
the
description.
A
So
traffic
can
you
beat
6a.
D
Absolutely
apologies
there.
I
worked
on
this
geo
sub
epic
in
small
iterations,
always
aiming
for
short,
merge
requests
that
are
easy
to
review.
That
means
I
broke
down
a
work
lot
and
ended
up
with
many
merger
quests
across
two
projects
dependent
on
each
other,
such
that
the
review
cycle
was
much
longer
than
the
total
time
for
development.
D
A
Yeah
well,
since
the
person
is
not
in
a
cold,
I
put
it
on
there.
I
I
we
need
to
dive
into
the
substance
to
see
how
this
is.
Maybe
it
can
be
split
up
in
different
ways,
but
I
think
that's
hard
for
me
to
opine
on
without
diving
in
so
I
I'd
ask
akriti
to
please
during
the
call
next
time
would
be
super
cool
to
kind
of
dive
in
together
and
maybe
maybe
there's
a
better
way,
maybe
not-
and
maybe
maybe
there's
a
case
for
making
something
bigger
in
this
case.
F
He
said
I
might
be
able
to
add
a
little
more
context
to
it.
It
was
she
was
adding
individual
features
to
some
pre-flight
checks
for
failover,
so
each
one
of
these
editions
was
was
valuable
in
and
of
itself,
but
they
were
kind
of
small
but
and
you
could
have,
but
they
were
small
enough
that
they
could
be
sorry.
My
dogs
are
going
a
little
crazy.
F
Yeah,
so
so
there
were,
there
were
small
improvements
that
could
be
separated
into
mrs
separate,
mrs,
but
but
kind
of
the
way
that
they
were,
but
since
they
were
in
the
same
piece
of
code
doing
these
pre-flight
checks,
it
made
sense
to
to
wait
for
one
to
merge
before
trying
to
get
the
other
one
merging.
A
I
I
don't
understand
why
the
review
cycle
took
so
long,
but
it
seems
these
are
simple.
Pre-Flight
checks,
pre-flight
checks
by
definition,
almost
can't
break
anything,
so
it
should
be
like
you
finished
one,
and
even
before
you're
ready
to
make
the
next,
mr,
it
should
already
have
been
merged.
So
I,
I
think
the
the
fact
that
she
was
able
to
create
multiple
ones
in
the
time
to
like,
like
that,
she
was
able
to
create
the
next
one
before
the
first
one
was
reviewed.
I
think
the
problem
is
in
the
review
cycle.
What
do
you
think.
F
A
Why
do
you
need
to
hold
off
on
getting
emerged?
Just
like?
I
could
see
you
heard
like
make.
The
first
pre-flight
check
takes
you
two
days,
send
it
out
for
review
so
a
day
later
gets
merged
and
spent
two
days
like
making
the
next
one.
So
after
four
days
I
have
one
merged
already
and
at
day
three
and
the
fourth
day
I
send
in
the
next.
Mr.
F
Yeah,
I
think
that
makes
sense
and
something
in
there.
There
were
some
longer
like
some
longer
review
times
in
there.
F
So
so
I
think
that's
that
was
part
of
the
issue,
something
that
came
up
in
it
that
I
think
could
have
been
an
improvement
for
this
one
and
came
up
in
some
other
front-end,
mrs
that
our
team
specifically
had
was
that,
since
the
work
was
related
and
it
kind
of
came
one
right
after
the
other,
we
found
that
if
we
were
using
different
reviewers,
each
of
them
had
to
sort
of
get
up
to
speed
on
what
was
going
on
and
and
that
took
some
time
and
so
something
that
we
actually
tried.
F
I
think
this
was
maybe
a
month
or
two
ago
something
that
we
tried
after
that,
that
helped
was
to
if,
if
we
knew
that,
we
were
going
to
have
a
series
of
mrs
like
this,
that
that
were
kind
of
dealing
with
the
same
thing
to
just
try
to
make
sure
to
see
if
we
could
use
the
same
reviewers
for
that
series
of
mrs-
and
we
start,
we
had
some
success
with
that.
A
Yeah
for
sure,
like
stable
counterparts,
counterparts
is
always
helpful
and
then
yeah.
You
can
only
iterate
if
you
have
a
fast
cycle
time.
So,
if
you're,
if
you
review
cycles
longer
than
your
development
cycle
like
this,
is
all
going
to
break
down,
so
your
reviews
need
to
be
quick,
especially
if
it's
something
that
doesn't
directly
impact
data,
reliability
and
retention.
So
I
think
that's
that's
where
the
fix
is
here-
and
I
can
imagine
if
you
have
like
five,
mrs
out
in
flight
being
reviewed.
Yet
then
you
have
the
merge,
conflicts
and
everything
else.
That's
that's!
A
G
Hey
happy
you
wednesday,
so
we've
touched
on
the
heart
of
this
question
and
or
at
least
part
of
it
earlier,
so
I'm
reframing
this
one
on
the
fly
so,
but
with
insecure.
There
is
a
library
that
is
used
across
the
entire
stage
and
it's
really
not
owned
by
any
one
group.
It's
got
its
shared
custodianship,
the
the
what's
happening
with.
That,
though,
is
that
any
updates
to
this
repository
are.
G
I
have
to
go
through
multiple
groups,
it's
leading
to
tight
coordination,
and
it's-
and
it's
also
requiring-
and
it's
also
leading
us
to
do-
updates
to
a
lot
of
other
repositories
that
cross
groups
as
well,
which
is
leading
which,
which
is
causing
us
churn
and
making
it
really
slow
to
iterate
and
realize
these
the
issues
that
are
in
hand.
So
what's
the
reframed
question
is
we're
running
into
situations
with
this,
where
it's
making
it
seem
like
collaboration
and
iteration,
are
at
odds
with
each
other?
A
Yeah,
if
you
deal
with
a
shared
library,
one
way
around,
it
is
versioning.
So
if
you
make
changes,
make
sure
you
bump
the
version
number
so
that
some
people
can
the
people
can
move
over.
The
rest
of
the
teams
can
incorporate
the
change
gradually
that
removes
kind
of
the
coordination
problem.
A
Another
thing
might
be:
maybe
it
needs
an
owner
just
talked
about.
I
just
showed
the
vulnerability
management
category
that
was
all
alone
in
the
threat,
research
or
something
like
that,
a
group-
maybe
they
they
need
to
take
control
of
this
as
well
or
maybe
it's
something
where
the
the
teams
kind
of
need
to
make
sure
that
there's
for
every
release,
there's
a
there's,
there's
there's
some
buy-in
to
the
to
the
shared
roadmap,
so
different
solutions,
I
don't
know
which
one
is
preferable,
but
those
are
a
couple
of
options.
G
G
Yeah,
let
me
yeah
understood,
let
me
let
I
would
like
to
take
this
and
let's
see
where
we
can
see.
If
we
can
take
some
see
if
we
can
pick
a
strategy
and
then
move
forward,
and
if
and
if
we
need
some,
we
need
some
assistance.
We'll
post.
A
And
also
feel
free
to
bring
it
up
in
the
next
office
hours
brad,
you
have
the
next
one.
Thank
you
for
that.
H
Thanks,
I
can't
see
the
google
doc
for
some
reason,
my
computer's
having
a
little
problem,
but
I'll
go
off
my
memory
of
typing
it
I'm
interested
in
ways
we
can
iterate
on
some
of
the
conversion
efforts
from
ce
to
ee.
So
I
know
that's,
obviously,
a
large
company
goal
there
and
we've
got
multiple
strategies
in
marketing
and
of
moving
customers
into
paid
subscriptions,
but
some
of
the
some
of
the
efforts
are
very
large
they're.
You
know
big
big
changes
in
pricing,
packaging,
tiering,
feature
movement,
etc.
A
A
A
A
I
just
talked
to
an
engineer
and
said:
hey.
I
want
to
use
netlify
with
gitlab,
I'm
like.
Oh,
you
use
gitlab
pages,
no,
not
sure,
never
heard
of
it.
So
the
easier
we
make
it
to
to
kind
of
discover
and
start
using
another
stage
at
gitlab.
A
The
more
successful
will
be
at
a
company-
and
I
see
I
think
inside
the
product
and
the
documentation,
there's
tons
of
opportunity
to
kind
of
lead
people
to
the
next
step
and
that
that
journey
that
user
journey,
I'm
gonna
share
that
quickly,
the
basics
of
it.
Look
a
bit
like
this
most
of
the
time.
This
is
the
core
thing
to
focus
on
or
create
verify,
release,
configure
or
create
verify
release.
A
A
I
I
actually
did
this
at
a
pass
company.
We
were
on
ce
from
source
and
then
we
went
to
ee
from
package
and
we
did
it
for
a
number
of
reasons.
One
of
them
was,
we
were
moving
into
a
fed,
ramp,
boundary,
okay,
okay,.
A
A
H
I'm
curious
if
you've
got
any
thoughts
on
wipe
or
or
others
do
you
think
our
users
purposely
start
with
ce
because
they
want
non-proprietary
code
or
do
you
think
they're
looking
for
a
free,
the
free
edition
of
git
lab
give
an
opinion
on
that.
A
I
think
in
the
past
we
said
hey,
if
you
want
to
pay
us
do
ee,
and
if
you
want
to
use
the
free
edition
do
ce
and
to
this
day
you
refer
to
ce
as
an
as
something
for
the
free
edition,
so
that
we
need
to
change
that
ce
and
ee
are
just
a
distribution.
If
you
want
to
use
gitlab
for
free,
the
best
thing
is
to
always
install
ee,
and
you
can
use
that
for
free.