►
From YouTube: GitLab Feature Flag tracking discussion Aug 27, 2020
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,
and
craig
thanks
thanks
for
joining
as
well
last
night
was
it
was
michelle
and
darby,
and
I
so
glad
to
have
you
part
of
the
discussion
too
so
about
three
weeks
ago.
We
had
well.
So
what
do
we
want
to
do
just
to
do
a
quick
review
of
that?
You
know.
We
wonder
how
many
features
were
in
existence
in
each
release.
A
How
many
features
were
default
on
versus
default
not
default
on
in
each
release
and
then
more
information
on
the
on
the
feature
flags,
because
we
want
to
ones
that
are
we
want
to
manage
them
over
time
of?
If
I
reduce
the
number,
so
we
don't
have
technical
debt
of
ones,
for
example,
that
are
default
on
and
also
understand
how
many
are
default,
often
when
they
might
be
on
in
the
future.
A
I
think
that's
kind
of
the
summary
of
the
kinds
of
things
we
want
to
know
and
then
action
items
that
we
we
discussed
about
three
weeks
ago
was
meeting
again,
which
we're
doing
now
creating
an
issue
to
track
the
effort
which
we
haven't
done
yet,
at
least
not
that
I
remember
and
then
potentially
after
thirteen
three
just
gonna
quickly
read
these
after
thirteen
add
an
updated,
updated
feature,
flag
training
will
be
offered,
require
all
new
feature
flags
to
be
in
the
ammo
file
and
then,
after
that,
communicate
to
all
teams
that
we
should
explicitly
define
their
feature
flags
in
the
yaml
file
for
everything
created
prior
to
133..
A
B
B
So
two
weeks
from
friday,
and
so
that
takes
care
of
three
and
then
on
four,
it
says
communicate
to
all
teams.
They
should
explicitly
define
the
existing
ones.
I
had
thought
because
there's
an
issue
that
he
created,
I
had
thought
that
that
was.
We
were
going
to
need
to
do
that,
but
he
said
that
he
would
automatically
be
doing
the
first
kind
of
like
whatever
is
in
there
today.
He'll
he'll
go
ahead
and
add
automatically
and
then
moving
forward.
We'll
pick
up.
So
I
I
suppose
that
takes
care
of
four
as
well,
the
downside
being.
B
I
don't
know,
but
I
believe
craig
might
know,
I
believe
he
was
gonna
block
with
dangerbot.
If
there
was.
D
So
michelle
on
number
three,
you
said
two
weeks
this
will
be
required.
Does
that
mean
the
end
of
this
milestone
or
is
it
was
it
a
man?
I
saw
the
magic
hands
going
there.
Was
it
just
kind
of
a
rough.
B
As
you
probably
heard,
we
have
a
new
yaml,
based
definition
for
feature
flags
used
in
the
code
base,
and
this
makes
it
easier
to
gather
important
info
there's
already
a
few
people
using
it.
Currently
it's
optional,
but
in
around
two
weeks
time
it
will
become
the
only
way
to
create
a
feature
flag.
So
please
try
it
out.
C
B
C
B
I'm
gonna
put
it
in
the
chat
because
well
maybe
I
need
to
refresh
the
page
to
get
okay.
A
B
D
Yeah,
I
was
just
I
was-
I
will
ask
now,
which
epic
is
our
single
source
of
truth.
So
I
have
this
one
here:
the
improved
internal
usage
of
feature
flags,
which
is
roughly
what
camille
has
been
driving
all
of
his
implementation
off
of.
Is
that
the
one
we're
following
for
this
effort,
because
I
know
there's
other
efforts
going
on
about
dog
fooding,
about
which
underlying
technology
we're
gonna
use?
And
you
know
there
there's
a
lot
of
conversations
going
on
and
I'm
trying
to
focus
on
just
this
one.
D
Okay,
so
let's
make
this
our
single
source
of
truth
and
then
we
can
start
identifying
where
there
are
gaps
like
what
was
just
mentioned
in
slack.
If
we
have
a
rollout
date,
we
should
have
an
issue
for
that
and
I
don't
believe
we
do.
The
description
for
that
epic
is
is
non-existent
right.
It's
it's
largely
the
makeup
of
the
issues
underneath
and
I'm
I'm
happy
to
coordinate
this.
D
If
nobody
else
is
owning
it,
it's
something
camille
and
I
kind
of
talked
about
earlier
this
week,
there's
kind
of
a
management,
product
management
piece,
that's
missing
and
sorry,
I'm
really
not
trying
to
offend
anybody.
Who's
been
working
on
this
michelle.
I
know
you've
been
doing
a
lot
of
coordination
and
other
people
are
involved,
but
there's
it
could
use
some
more
coordination
and
if
there
are
no,
if
there's
nobody
else
doing
it,
I
I
will
volunteer.
B
B
D
A
Up
what
we
have
and
being
able
to
answer
some
of
them,
and
and
also
doing
that,
so
we
can
answer
some
of
the
questions
above
on
how
many
we
have
at
various
states
over
time,
not
to
use
the
the.
I
don't
know
if
it's
new,
but
the
features
in
gitlab
itself
that
we
recommend
for
customers.
That's
not
ready
for
our
use.
Yet
yep.
D
Instead
of
you
guys
listening
to
me
type,
I
will
write
it
up
in
if
you're
not
already
listeners
on
there
I'll
ping,
you
on
the
description
for
that
epic
to
make
sure
it
is
correct,
and
one
of
the
other
questions
I
had
was
a
rollout
plan.
It
sounds
like
we
have
talked
about
a
rollout
plan,
but
it's
not
really
written
down.
Maybe
I'll
just
create
an
issue
for
it.
So
we
have
a
single
place
to
go.
D
Look
at
that
and
then
once
once
we
hit
the
mvc
of
this
to
first
roll
out
which
team
owns
it
going
forward.
I
don't
think
it's
a
memory
team
thing
I
think,
from
what
I've
seen
of
the
other
epics
I
looked
at
it
looks
like
the
progressive
delivery
team
might
be
owning
it,
and
I
don't
know
if
there's
any
representatives
for
that
team
here.
So
I
don't
want
to
volunteer
someone
who's
not
here,
but
does
anybody
have
an
idea
of
which
team
would
own
future
flag
maintenance
going
forward?
C
This
was
kind
of
a
a
weird
split
because
I
used
to
work
in
progressive
delivery
and
we
would
get
a
lot
of
questions
about
like
our
internal
feature,
flag
implementation,
which
they
don't
really
like.
That
team
doesn't
really
focus
on.
I
think
back
then,
when
we
would
run
into
these
issues.
It
would
be
that
I
think
the
delivery
team
I
want
to
say
that
was
was
kind
of
like
owning.
C
You
know,
upgrading
of
the
flipper
gem
and
stuff
like
that,
but
no
one
from
that
team
is
here
either
so,
okay,
I
can.
C
Okay-
and
I
mean
if,
if
they,
if
they
don't
feel
like
it,
fits
with
them
it,
it
may
make
sense
to
move
it
to
progressive
delivery
with.
You
know,
obviously,
coordination
with
that
team,
but
if,
if
our
intention
is
to
set
the
stage
for
how
we're
gonna
like
implement
the
gitlab
product
within
gitlab,
like
that
would
start
to
tie
those
two
things
together
and
I
think
there's
been
a
bit
of
a
gap
there
up
until
now,
yep.
C
A
So
to
confirm,
when
this
work
is
complete,
that
we
described
earlier,
we'll
have
all
future
flags
tracked,
only
new
ones,
newly
introduced
ones.
B
A
A
One
we'll
know
how
many
we
can
use
that
going
forward
to
figure
out
how
many
we
have
in
each
release
right,
because
we
can
look
at
the
ammo
file
for
each
release
and
know
how
many
feature
flags
were
default
on
versus
not
default
on
each
release.
We
won't
know
historically
right
but
we'll
know
going
forward
and
that's
that's
more
important
for
each
feature
flag
and
which
release
was
it
introduced.
We
won't
know
except
for
going
forward,
but
I
think
that's.
A
Okay,
like
we'll
just
know
it
was
at
this
release
when
we
started
tracking
it
or
sometime
earlier
and
for
ones
that
are
not
default
on.
We
can
then
start
talking
to
the
teams
about
you
know
if
it's
not
default
on
and
it's
been
around
a
while,
you
know
talking
about
you
know:
why
should
it
still
exist?
Is
there
a
plan
to
turn
a
default
on
and
the
answer
might
be?
A
A
If
that's
a
valid
use
case,
I
mean
there
might
be
a
reason
to
keep
a
feature
flag
that
is
default
on,
so
that
somebody
can
turn
it
off
if
they
want
to.
But
if,
if
that,
if
that's
not
a
valid
use
case,
then
we
can
reduce
technical
debt
by
getting
rid
of
it.
A
So
it
sounds
like
there's
a
lot
of
work
in
four
and
five,
but
at
least
we'll
have
the
data
in
one
two
and
three,
and
it's
not
cut
and
dry
on
the
decision
at
all.
It
has
to
be
the
the
team
that
maintain
that
that
created
the
feature
flag
or
maintains
it
making
a
educated
decision
based
on
it.
It's
not
cut
and
dry,
like
oh,
it's
default
on
so
and
it's
been
there
for
six
months,
get
rid
of
it.
That
would
not
be
that
that
that
may
not
be
a
valid.
D
Yeah,
that's
my
understanding
too.
I
think
to
me
it
seems
like
four
and
five
would
be
a
handoff
issue
to
whichever
team
owns
it
later
on,
like
not
something
we
would
ask
camille
and
whoever
else
he's
pairing
with
right
now
to
work
on
those
implementation.
Details
three
is
that
that's
probably
something
they'll
have
to
figure
out
right.
It's
not
going
to
be
in
the
ammo
file.
You'll
just
have
to
look
back
at
the
history.
Maybe
I'm
not
sure
how
that
would
be
extrapolated.
B
D
B
A
Sounds
great,
so
I
think
we
should
go
sync
again,
just
at
some
point
in
the
future,
just
to
check
where
we
are
versus,
where
we
expected
to
be
and
see
how
things
are
going,
etc.
Maybe
a
month
from
now.
D
If
we're
gonna
roll
out
in
a
couple
weeks-
maybe
shortly
thereafter
so
maybe
three
weeks
from
now
make
sure
everything
is
either
close
to
on
time
or
we
know
why
it
didn't
go
out
if
it
doesn't
go
out.
So,
okay,
oh.
A
Yeah
three
weeks
sounds
good,
and
you
mentioned
there
are
a
couple
of
teams
not
represented.
I
know
we,
you
know
we're
as
async
as
we
can
be,
so
I
heard
mention
of
creating
of
issues
to
track
various
things.
That's
definitely
the
way
to
go
versus
a
google
doc,
but
when
we
go
sync
again
in
addition
to
the
four
of
us,
who
else
should
be
invited.
D
I
think
that's
tvd
right
if
we
find
that
it's
either
delivery
or
progressive
delivery,
then.
C
One
of
those
teams,
one
of
those
delivery
teams-
yes,
so
the
star
delivery,
someone
will
share
yeah,
so
craig
you're
you're
going
to
are
you
going
to
handle
the
communications
of
the
of
the
change
like
making?
Sure
teams
are
aware
of
that.
Is
that
on
your
radar
that
that
that
would
be
number
four
from
the
list
on
the
bottom
there,
which
I
think
I
think
was
just
telling
people
that
this
new
check
is
going
to
be
in
place.
B
I
can
take
this
because,
when
camille
said
that
he
was
going
to
require
that
these
get
defined,
I
said
I
would
really
love
it
if
we
could
roll
out
that
feature
flag,
training
alongside
it,
so
that
people
know
how
to
use
it,
and
I
already
have
to
communicate
that
anyway,
so
I'll
just
communicate
them
both
at
the
same
time,
okay,.
C
Just
wanted
to
make
sure
we
had
that
track
and
then
and
then
craig
you
were
going
to
to
to
sync
up
with
the
delivery
or
progressive
delivery
teams
or
or
do
you
want
to
hand
with
that.
D
When
I
I
will
create
an
issue
for
that
to
make
sure
we
find
the
handoff
team,
I
will
copy
you
on
it
and
then
I
will
ping
the
other
managers
for
those
teams
and
let
them
know
that
this
is
a
discussion
point.
We
need
to
find
a
long-term
owner
for
this
and
then,
if
we
need
to
have
a
synchronous
conversation
we'll
go
from
there,
we'll
async
within
the
shoot.
For
now.
A
Cool
thanks
I'll
schedule
next
in
three
weeks,
based
on
our
schedules-
and
you
know,
of
course,
add
anyone
and
everyone,
you
think,
might
be
interested
and
I'll.
Also
post
the
google
doc
the
recording
edge
managers
and
I'll
tag.
Camille
ann
kinney,
since
he
seems
interested
in
the
related
subject
and
also
I'll
make
a
note
of
an
engineering
week
in
review,
so
a
better
interest
you
can
find
out
about
it
anything
else
we
should
discuss
today.