►
From YouTube: Feature Flags Office Hours - 24 Sep 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,
hello,
welcome.
This
is
the
future
flag
office
hours
meeting
for
september.
24Th
ori
is
out
on
pto,
and
so
I'm
going
to
try
and
help
cover
this
and
move
the
conversation
forward
as
necessary,
so
yeah.
I
did
not
prepare
anything
for
this,
so
the
agenda
is
empty.
A
Happy
to
see
where
this
goes.
I
know
we
have
camille
is
joined
and
I
know
you've
written
a
interesting
like
architectural
blueprint
for
the
internal
usage
of
future
flags
and
you've
done
some.
You
continue
to
have
announcements
about
like
how
to
like
what
the
process
is
going
through
to
improve
that
that
the
like
the
the
the
new
yaml
way
of
organizing
future
flags
and
things.
A
So
that
could
be
a
topic
for
conversation
here
for
the
group,
I
think,
like
one
thing
that
is
on
my
mind,
is
sort
of
how
do
we
take
what
we
there's
another
like
a
large
conversation
that
was
sparked
by
ken
johnson,
about
the
sort
of
like
dog,
fooding
efforts
and
marrying
the
two
things
I
think
could
be
a
like.
A
You
know:
where
do
we
take
the
eternal
usage
of
future
flags
and
how
do
we
move
forward
in
making
the
like
the
usage
for
future
flags
from
like
teams
like
growth
or
someone
else
who
is
trying
to
dog
through
these
efforts?
That
could
be
an
interesting
thing
to
talk
about
too.
So,
can
you
look?
Do
you
want
to
take
it
away?
You
know,
with
the
things
you've
had
there
about
that
stuff.
I
just
rambled
on
about.
B
Yes,
so
I
created
this
blueprint
to
like
to
describe
the
reasons
why
this
improvement.
Why
I'm
doing
these
improvements
to
kind
of
document,
exactly
the
goals
that
I
want
to
achieve,
and
they
are
not
exactly
the
same
goals
that
you
have
with
the
dog
fooding
right,
because.
B
Say
treating
feature
flux
as
a
technique
of
depth.
I
mean
this
is
my
perception.
An
introduction.
Introduction
of
the
future
fact
is
an
additional
toil
that
we
put
on
every
one
of
us
using
them,
and
it's
like
related
to
developer,
adding
they
have
to
cover
the
tests
engineering
manager
to
understand
how
many
future
tracks.
B
We
have
then
developer
having
tried
to
roll
out
that
and
remove
that
product
manager,
understanding
like
what
future
flags
are
configured
and
where
and
on
what
environments,
esther
and
support
team
understanding
how
these
feature
flags
play
with
the
rest
of
the
features
product
manager,
understanding
like
if
feature
that
they
are
about
to
announce
it's
enabled
or
it's
not
and
like
mine.
B
B
So
I
kind
of
consider
this
like
the
prequel,
because
today
our
future
flux
uses
is
very
undefined
on
so
many
layers.
B
I
hope
that,
like
with
my
work,
we
make
this
defined
and
explicit
and
we
can
use
the
that
known
behaviors
and
then,
like
once.
We
start
the
fooding
it's
much
easier
for
us
to
check
exactly
what
behaviors
we
use,
because
there
is
only
a
few
of
them
which
are
asked
to
understand
what
feature
flags
and
what
requirements
are
there
because
they
are
experiencing
defined
so
and
like
the
third
item
like
once,
like
other
people
around
github,
start
using
this,
let's
say
descriptive
way
of
managing
fisher
flux.
B
B
How
usually
feature
plugs
about
like
making
this
visible
and
understood
to
anyone
outside
engineers
writing
a
pure
eyes
of
the
code
which,
from
like
the
random
conversations
that
I
saw
like,
was
pretty
like
confusing,
because
I
even
myself
like
I,
I
look
at
the
list
of
the
people
that
I
should
reach
to
update
the
details
about
the
future
flux,
and
there
is
at
least
maybe
10
mentions
of
the
future
flags
that
are
owned
by
me
that
I
actually
forgot
to
like
to
even
remove,
because
I
did
them
they
got
deployed.
B
B
This
easy
to
track
and
treat
that
as
a
technical
depth,
make
it
more
aggressive
like
to
remove
when
it's
not
needed
and,
like,
I
think
like.
If
you
look
at
my
blueprint,
the
dog
fooding
effort,
I
I
think
that
it
should
answer
these
goals.
How
we
make
this
like
easy
for
other
people
to
track
and
like
to
answer
these
questions.
B
So
this
is
my
whole
perception
about
this
internal
process,
but
the
other
perception
is
like
it's
like.
We
have
so
many
feature
flags.
We
have
so
many
developers
adding
them
basically
daily.
There
is
something
that
the
tuning
needs
to
kind
of,
be
easy
to
use
and
and
and
fast
to
iterate,
as
well
so
kind
of
like
the
touring
I
mean
like
the
touring
should
encourage
usage
of
the
feature
flux.
B
The
process
should
not
discourage
you
such
as
the
feature
part,
because
you
have
so
much
process
around
the
usage
of
the
feature
effects
that,
like
you,
you're
rather
not
gonna,
add
the
feature
flag.
Because
of
that
it's
so
much
toy.
I
think
the
whole
idea
is
like
to
cut
the
toy
but
make
it
like
a
visible
in
slightly
different
way.
B
So
kind
of,
like
the
feature
flag
being
not
owned
by
the
individual,
but
rather
like
the
group
and
the
group
understanding
what
feature
flights
they
have
when
they
should
be
removing
these
feature
flags
and
knowing
what
is
the
correlance
between
the
feature
flag
and
the
feature
and
like
it
could
be
also
related
to
like
a
simple
example
like
we
deploy
gitlab.com
kind
of
daily
or
every
second
day,
we
kind
of
create
a
q,
a
issue
to
ask
developers
to
click
if
they
validated
that
their
feature
works.
B
On
the
staging
and
like
with
my
changes,
we
can
actually
extend
that
information
with
the
indication
what
feature
flux,
got
added,
removed
and
changed,
because
it's
much
easier
to
like
to
go
to
get
this
data.
So
now,
like
the
developer,
the
delivery
engineer
or
srm
associated
with
the
group
can
go
into
this
q
and
a
issue
and
see
like
what
new
feature
flux
could
introduce
if
they
see,
for
example,
some,
let's
say
downgrade
on
the
performance.
So
since
they
know
since
they
I
better
know
what
challenge
they
can
much
more
targetly.
B
B
A
No,
it's
fine,
but
I
think,
like
the
central
themes
here
are
like
it's
like
an
efficiency
thing.
It's
a
you
know
it's
a
code,
quality
problem
and
it's
like
a
communication
problem.
So
like
yeah.
This
is
super
interesting.
So,
like
you-
and
you
also
have
like
there's
some
associated
epic
in
here-
about
like
sort
of
a
sort
of
a
breakdown.
B
A
Of
tasks
or
whatever
right
so
one
of
the
questions
I
had
from
like
another
conversation
was
like
since
progressive
delivery
is,
like
you
know,
owns
the
future
flags
service
for
customers
and,
like
the
what,
like,
the
the
the.
A
Blueprint
and
the
breakdown
of
tasks
and
issues
for
for
that
blueprint
wondering
about
like
the
sort
of
like
where
the
two
groups
will
like
your
efforts
in
here
and
if,
if
this
is
going
to
be
on
the
memory
team
or
some
other
internal
team,
or
if
there's
going
to
be
like
where
the
boundaries
are
between,
like
what
progressive
delivery
does
to
support
the
internal
usage
of
future
flags
versus
how
we
support
the
future
flags
service
for
customers,
do
you
have
any
thoughts
or
suggestions
there.
B
Like
you
get
the
difference
between
these
two
teams,
there
is
like
around
like
deploying
github
and
progressive
delivery
is
about
the
building
product,
but
I'm
kind
of
thinking
that
it's,
maybe
not
the
most
efficient,
like
I'm
kind
of
thinking
that,
like
for
the
dog
footing
aspect
how
to
approach.
You
need
to
fully
understand
the
our
usage,
and
I
like
the
the
scale
of
our
usage
and
the
problems
associated
with
that.
B
Now
the
question
is
like:
how
do
you
get
this
information
quickly
and
like
how
you
know
exactly
what
changes
you
have
to
make
to
make
this
transition
seamless
to
something
that
is
using
creeper
to
something
that
is
using
guitar
picture
flux?
And-
and
I
think
that
this
is
the
challenge
like
like.
B
Maybe
that
you
are
very
working
on
the
improving
internal
research,
maybe
like
after
me,
would
be
the
right
place,
because
you
would
be
very
close
to
the
problems
that
this
solves
and
then
you
could
that
it
could
affect
the
the
outcome
of
the
product
parts
that
actually
can
handle
our
usage,
which
is
big
actually
right.
The
amount
of
the
changes
that
we
make
how
we
deploy
application
is
completely
different
to
in
the
skirt
compared
to
like
to
what
gitlab
product
feature
flux
currently
offers.
B
I'm
kind
of
thinking
that,
if
you
would
change
today
to
use
github
product
feature
flux,
we
would
kind
of
fail
miserably
because
of
like
degreeing,
be
meeting
in
the
times
of
the
workforce
that
you
support,
how
auditing
who
can
change
the
future
flux
and
how
you
can
change
that.
B
C
B
That
is
being
done
by
the
by
the
other
group,
but
for
time
being
it's
we
need
to
be
familiar
with
all
these
problems
and
how
we
approach
them.
So
yeah
my
concept
around
behind
it
sure.
A
Yeah,
that
makes
a
lot
of
sense.
I
mean
I'm
just
as
you're
describing
the
problem
there.
I'm
thinking
of
you
know
just
like
from
a
product
designer
perspective
of
like
how
would
dimitri
solve
the
problem?
What
would
we
do
and
how
does
that
define?
How
would
that
like?
C
A
That
we
would
have
to
support
a
very
large
number
like
of
future
flags.
It
probably
changes
the
our
approach
and
the
and
what
designs
would
you
know
would
come
through
there.
So
even
from
like
that,
like
one
small
slice
of
the
problem
yeah,
it's
pretty.
B
Interesting
yeah,
it's
it's
also
interesting
because,
like
you
have
to
manage
these
features
across
different
environments,
having
different
configurations
so
like
how
how
it's
being
also
approached
and
like
there
is
another
problem,
how
you
manage
future
flights
for
our
premise:
customers.
They
still
also
use
this
feature.
The
support
team
uses
these
feature
flag
struggles
like
to
solving
some
intermediate
problems
with
the
customers
as
well.
So
I
I
think
it's
like
multi
contextual
problem
to
solve
that.
A
Yeah
that
does
that
is
like
a
I'm
sorry,
I
left
my
train
of
thought
there,
but
like
yeah,
I
I
can.
I
I'm
I'm
falling
with
you.
I
think
I
understand
and
I
can
see
like
the
I
think
I
can
better
see.
I
don't
know
that
I
can
see
a
technical
path
through
yet,
but
I
can
definitely
see
the
have
a
better
understanding.
I
can
see
sort
of
the
conceptual
vision
and
sort
of
like
the
you
know,
sort
of
the
justifications
and
reasoning
behind.
A
A
B
Yeah,
so
I
think
the
whole
intent
of
my
work
is
like
make
it
better
and
more
explicit,
so
like
putting
effort,
would
be
easier
in
a
terms
that,
like
you,
would
know,
what
is
there,
how
it's
being
used,
how
different
parties
use
these
picture
products
and
then
like?
B
You,
could
then
figure
out
exactly
how
this
fits
into
the
product
part
and
how
product
has
to
be
improved
and
like
how
you
can
switch
these
internal
things
to
use
the
product
part,
because
right
now,
like
even
like
changing
flavor,
it's
like
very
challenging
to
do
because
we
use
we
sidestep
flipper,
even
like
on
different
occasions
occasions.
So,
like
usage,
is
like
completely
freestyle
to
be
fair
and
like,
and
like
my
my
work
is
really
like
to
make
it
more
explicit
context
in
which
you
use
how
you
configure
that
who
owns
that.
B
So
you
kind
of
have
much
better
understanding
who
what
how,
when
and
things
like
that-
and
this
should
give
you
like
some
perspective-
how
to
approach
this
dog
fooding,
because
you
have
slightly
different
and
more
focused
process
that
involves
not
only
developers
but
kind
of
like
a
group
of
different
people
that
consumes
this
information
in
a
different
way
from
different.
A
Yep,
that's
true
from
your
perspective,
like
the
usage
of
the
future
flags,
as
is
there
like
thinking
about
those
those
different
personas
right?
Is
it
mostly
developers
and
maybe
sres
if
they're,
trying
to
to
to
try
to
mitigate
a
problem
or
they're
like?
Are
there?
What's
it
called
like
products?
A
Managers
or
you
know
some
other
kind
of,
like
somebody
say
like
on
jerome's
team
like
saying
growth
or
something
that
are
like
adjusting
feature
flags
separately
through
chat
officers
through
some
other
mechanisms
that
are
that
we're
not
like
fully
considering
yeah.
I
think
there's
like
a
stable
of
people
that
we
need
to
like
understand
for
sure.
A
You
have
a
second
bullet
point
here.
We've
only
got
a
few
minutes
left
the
the
reach
get
labs
to
update
ownership
of
feature
flags.
Isn't
it
as
of
like
a
large
like
it
looks
like
a
checklist
of
of
people,
anything
anything
we
need
to.
B
It's
pretty
well
documented
and
like
we
have
a
lot
of
feature
flux
and
it's
gonna
make
it
easier
if
we
clearly
define
who
is
owner
of
these
future
flux.
Okay,
this
is
this
is
like
semi-automated
way
to
find
the
the
right
people
to
to
pick.
B
If
people
have
to
like
to
manually
update
it,
you
ask
about
like
different
consumers
of
the
future
flux,
I'm
kind
of
thinking
that
right
now
developers
is
a
central
piece.
B
Central
ingredients
like
to
consume
feature
flux,
where
I'm
kind
of
thinking
that
it
doesn't
have
to
be
developers
could
focus
on
something
more
interesting
than
like
managing
the
let's
say
life
cycle
of
the
future
flag
or
like
understanding
and
like
spoiling
these
details,
I'm
kind
of
even
thinking
like
about
the
case
like
you
have
product
manager
that
needs
to
validate.
B
If
the
feature
works
properly,
why
need
to
ask
developer
to
toggle
that
can
just
product
manager
like
go
to
some
page
or
maybe
to
some
chat
ups
command
say
I'm
gonna
enable
it
on
my
project
because
all
the
details
are
known
and
like
it
can
validate
that
on
on
his
own
or
her
or
her
own.
Another
case,
like
product
manager
prepares
a
release.
Cost
usually
like
a
product
manager,
needs
to
ask
engineer
and
needs
to
find
the
right
engineer
that
did
introduce
the
feature
flag
to
ensure
that
it's
enabled
by
default.
B
Why?
We
cannot
like
kind
of
expose
this
information
in
like
in
the
easy
form
can
like
product
manager
see
so
this
release
post
is
behind
this
gated
feature
flag.
I'm
just
gonna
go
to
our
docs
github
page
to
check
if
it's
enabled
by
on
or
not
if
it's
not
enabled
I'm
gonna
go
into
rollout
issue
and
I'm
gonna
find
all
the
details.
B
So
I'm
kind
of
like
the
idea
behind
that
is
not
making
developer
to
be
a
central
contention
point
it's
rather
making
the
progress
to,
let's
say
on
introduction
and
the
rollout,
maybe
with
sre
but
kind
of
making
this
information
accessible
to
others,
which
is
can
be
product
manager.
It
can
be
you,
as
an
engineering
manager,
to
understand
how
many
future
flux
your
team
owns
right
and
if
it
poses
the
problem,
or
maybe
we
should,
if
you
maybe
you're,
going
to
notice
that
some
of
these
features
like
they
are
for
six
months
already.
B
It's
pretty
long
right
right,
but
there
is
another
aspect
like
if
we
have
problem
understanding
if
features
are
configured
and
how
what
our
customers
can
say
really
about
like
on-premise
installation,
so
I'm
kind
of
thinking
that
they
kind
of
scrape
documentations,
maybe
even
code-based,
to
finding
some
random
names
and
they
kind
of
care,
maybe
with
them.
So
it's
another
venue,
like
future
frank,
is
kind
of
uneventable
toggle
that
we
may
have
to
use
to
safely
roll
out.
B
But
in
some
cases
like
the
like,
we
gave
some
features
behind
the
feature
tracks
to
allow
to
disable
them
for
the
performance
reasons,
and
customers
could
as
well
find
this
information
in
some
way
or
some
another
and
change
their
gitlab
configuration.
That
is
running.
A
C
Not
at
the
moment,
I
do,
I
do
kind
of
agree
that
I
feel
like
we
need
to
shake
out
how
we
want
to
use
feature
flags
before
we
can
really
start
looking
at
the
gaps
in
our
own
product.
I
know
there
are
many
out
there
and
there's
like,
but
as
long
as
the
target
is
moving,
we're
it's
impossible
to
to
hit
it
right,
or
at
least
extremely
difficult,
especially
as
we
we
iterate
on
our
process
faster
than
we
iterate
on
our
product.
A
A
Well,
we
have
like
60
seconds
left.
I
don't
have
anything
else,
camille,
thank
you
for
joining
and
sharing
the
stuff
with
us
and
I'll
be
sure
to
put
the
recording
in
into
the
channel
and
into
the
document
for
others
who
are
not
here
to
review
later
and
yeah.
I
look
forward
to
my
continued
discussions
on
the
architecture
and
sort
of
that.
A
Like
how
we,
how
we
make
that
hand
off
to
increasing
like
progressive
deliveries,
ownership
or
like
participation
in
the
in
the
internal
feature
flags
process,
so
we
can,
we
can
make
the
product
better.
So
thank
you
all
right.