►
From YouTube: Feature Flags Office Hours 2020-07-02
Description
Feature Flags Office Hours July 2nd 2020
A
A
A
Nope
so
the
first
question
that
we
had
on
the
agenda,
which
no
one
really
answered,
but
it's
really
important
for
us
to
understand,
is-
is
this
a
good
time
for
the
meeting,
because
we
want
to
make
this
a
reoccurring
meeting.
So
we
wanted
to
know
if
there's
any
pushbacks
regarding
the
time
or
if
we
can
leave
this
in
this
slot.
A
A
A
But
this
is
a
big
concern,
also
in
terms
of
internal
development
in
lab
itself,
because
at
the
moment,
for
example,
one
of
the
differences
between
flipper
and
unleash
is
that
flipper
you
have
to
have
specific
permissions
in
order
to
enable
it.
Sometimes
you
need
to
ask
the
delivery
team
to
to
merge
a
request
or
to
turn
on
a
flag
and
with
unleash
that
currently
isn't
the
process.
C
Just
quick
correction
that
actually
the
permission
feature
is
not
implemented
in
flipper.
Flip
is
just
like
same
system
as
as
well
as
unleashers,
but
you
know
we
have
a
chat,
ops
and
the
chat.
Ops
is
a
controller
for
future
flag
flip
by
future
flag,
and
this
chat,
ops
tool
has
a
bunch
of
like
permission,
stuff
and
also
like
advanced.
C
A
Yeah,
thank
you
for
correcting
me
yeah.
Absolutely
the
the
chat
ups
project
has
different
permissions
than
than
the
development
of
gitlab
and
that's
how
basically,
we
control
the
permissions
there.
The
next
question
is
about
the
user
list
in
the
deployment
strategy,
so
just
to
give
a
quick
overview
about
what
we're
talking
about.
This
is
a
really
new
feature
that
we
just
rolled
out
in
13.1.
A
We
previously
supported
user
ids
as
a
strategy
where
you
can
make
a
long
list
of
ids,
comma,
separated
and
say
that
these
are
the
users
that
are
going
to
have
the
feature
flag
enabled
and
we
created
a
new
strategy
called
list
which
is
a
kind
of
container
for
all
those
user,
ids
they're
still
comma
separated.
But
the
lists
can
be
reused,
so
you
only
need
to
manage
them
in
one
place
and
then
you
can
copy
them
to
different
flags,
and
there
was
a
bit
of
it
of
confusion
about
what
we
need
to
do
there.
A
So
I
added
some
clarifications
to
the
documentations
hope.
Hopefully
that
mr
will
be
merged
soon.
The
confusion
is
around
the
user
id
and
how
we
perceive
it
in
terms
of
gitlab.
So
when
users
use
feature
flags,
we
don't
know
their
user
ids,
it's
a
third
party
user
id,
so
it
can
be
an
email
or
a
numeric
identifier
or
a
username
doesn't
really
matter.
A
It
doesn't
have
to
be
known
to
get
that
it's
totally
third
party
in
that
sense-
and
that's
that's
the
clarifications
that
I
added
next
is
feature
flag
strategy
for
user
percent.
It's
also
confused
with
our
deployment
strategy
incremental
rollout,
so
actually
future
flags
and
incremental
rollout
are
kind
of
the
same
idea.
A
Just
one
is
for
infrastructure
and
the
other
one
is
for
a
feature
level.
So
when
we
do
incremental
rollout,
the
idea
is
that
we
take
entire
development.
Everything
and
we
start
incrementally
rolling
it
out,
deploying
it
to
production
very,
very
slowly.
But
it's
it's
everything
and
feature
flags
lets
you
do
the
same
thing,
but
on
a
smaller
scale,
it's
feature
level.
A
So
it's
much
more
granular
and
it's
coming
to
be
much
more
popular
to
actually
combine
the
two
so
feature
flags
with
canary,
so
that
you
have
control
both
on
the
traffic,
the
audience
that
is
going
to
get
the
entire
deployment.
That's
the
canary
or
the
encroachment
rollout
and
on
a
feature,
granularity
level
for
future
flags.
So
that
way
you
can
not
only
turn
slowly
turn
off
the
entire
deployment.
You
can
start
deploying
everything
with
all
the
flags
turned
off,
see
that
the
deployment
is
working
properly
and
then
slowly.
A
A
Okay,
there
are
concerns
about
on
how
to
implement
future
flags
as
best
practices
code
samples.
I
think
this
is
really
good
feedback.
We
probably
need
to
add
more
documentations
and
demos,
and
we
have
quite
a
few
people
now
working
on
demos,
both
from
the
marketing
team
and
from
the
sales
team,
so
hopefully
we'll
get
a
deck
across
that
could
show
users
exactly
how
to
use
it,
or
at
least
be
a
good
starting
point.
A
A
A
A
A
D
To
have
these
like
different
types
of
defeating
flags
and
also
like
kind
of
this
kind
of
strong
validation,
but
not
really
yet
enforced,
it's
kind
of
more
like
a
voluntary
very
day.
Soon
it's
it's
like
merged.
Today,
it's
like
we
don't
use
that
anything
with
that.
Yet
because
we
don't
like
have
these
yammer
definitions
as
part
of
the
repository,
but
this
is
actually
the
fundamental
piece
for
the
point
b
and
point
b,
based
on
like
on
point
a.
D
I
use
my
proof
of
concept
to
perform
this
kind
of,
like
a
consistency,
validation
of
our
feature
flags
to
ensure
that
the
feature
flags
that
we
use
they
are
used
only
in
the
specific
context
like,
for
example,
license
type
of
the
feature
flag
or
the
ops
type
feature
flag,
but
also
they
have
like
the
consistent
usage.
I
mean
the
default
enabled
setting.
D
How
how
like
what
kind
of
changes
require
like
the
code
base,
the
minimum
amount
of
the
changes
that
codebase
requires
to
ensure
that
we
have
this
kind
of
strong
validations
of
the
future
flux.
But
this
plc
will
never
gonna
be
merged.
It's
kind
of
like,
like
a
showcase,
to
show
like
the
amount
of
the
changes
in
the
complexity,
but
it's
gonna
be
much
like
the
slices
of
this
poc,
and
this
is
exactly
what
is
right
now
happening.
A
D
We
I
have,
I
had
five,
mrs
out
of
this
poc
created
two
of
them
got
merged
and
more
are
under
like
being
orchid
on
right.
Now,
I'm
not
sure
if
it
really
answers
your
question
mark
and
fear,
but
like
poc
describe
shows
here
like
the
end
pitch
and
picture
and
picture
that
is
never
gonna
be
merged.
But
right
now,
like
I'm
kind
of
striking
that
into
things
that
could
be
like
iterated
managed
merged
without
breaking
anything
that
how
we
use
the
the
gitlab
and
the
futureflux
usage
today
so
kind.
A
What
would
it
take
and
roughly
how
long
before
we
would
be
confident
rolling
out
this
across
the
other
gitlab.com
projects
such
as
gitlab
org
and
the
question?
The
answer
is
that
it
is
already
available
for
or
for
all
the
projects,
since
thirteen
one
and
self-managed
customers
will
get
it
as
part
of
thirteen
two,
so
it
is
available
for
everyone.
B
A
Sure
I
think
I
think
we're
kind
of
still
in
a
preliminary
stage,
so
it's
really
important
to
say
that
up
front.
I
don't
think
that
we're
giving
our
competition
a
lot
to
worry
about
at
the
moment,
but
the
most
the
best,
the
biggest
advantage
that
a
customer
using
gitlab
with
feature
flags
would
get
is
the
fact
that
it's
a
single
tool
and
the
fact
that
everything
integrates
and
talks
together
with
one
another.
So
we
are
working
right
now
in
this
milestone
for
connecting
a
contextual
issue
with
future
flex.
A
So
that
means
that
when
you
have
an
issue
that
you're
working
on
you
can
link
the
feature
flag,
that's
linked
to
it
and
you
can
see
the
status
on
it.
So
so
you
know,
if
there's
a
flag
on
an
or
off
in
that
issue,
we're
going
to
do
expand
that
also
for
merge
requests
and
for
epics
some
other
nice
things
that
we're
doing
in
terms
of
the
all-in-one
product
is
allowing
markdown.
B
A
So
contextual
issue
is
coming
up
in
this
milestone
and
I
think
that's
the
first,
the
first
of
of
everything
that
I
mentioned
and
then
we're
going
to
expand
on
them.
So
really,
if
you
use
everything
you
get
an
all-in-one
experience,
which
is
great
another
thing
that
is
really
interesting
that
we're
looking
at
though
it's
not
it's
still
in
in
an
epic
and
not
yet
in
in
actionable
issues.
A
Is
the
idea
of
com
combining
review
apps
with
feature
flags
which
is
super
awesome.
The
idea
is
that
you
set
a
feature
flag
and
then
you
can
choose
to
be
whatever
user.
You
want
to
be
as
a
developer
and
you
can
see
how
the
feature
behaves
for
different
users
inside
your
review,
app,
which
is
super
powerful,
and
I
think
that
would
be
also
a
really
big
win
for
us.
C
C
But
this
this
process
seems
having
your
edge
case
that,
like
sometimes
we
roll
out
the
future
vlog
globally
on
gilab.com
and
then
like
test
out
the
future
monterey
performance,
etc.
And
meanwhile
the
feature
is
exposed
to
all
users.
But
user
has
no
reference
about
this
feature
so
like
they
don't
know
how
to
use
it,
but
it's
just
exposed
for
the
test
purpose.
So
actually,
what
muscle
said
was
that
we
should
add
a
feature
we
should
add
a
documentation
at
first
before
adding
anything
to
the
code
base.
D
I
don't
really
know
it
really
depends
because,
like
let's
say
if
like
if,
if
the
feature
flag
is
like
disabled
by
default,
but
like
you
enable
that
for
the
system-wide
club
as
part
of
your
rollout
and
then
like,
everyone
sees
the
new
awesome
button
in
the
sidebar
and
they're
gonna
start
asking.
Why
is
this
button
dark?
For?
D
Is
it
the
time
where
we
should
have
a
documentation
for
this
button,
or
is
it
still
too
early,
even
though,
like
the
default
enabled
is
not
really
true
yet
does?
Is
it
mean
that,
like
it's
like
it's
ready
for
the
prime
plane,
or
we
still
like
kind
of
expect,
like
a
major
changes
to
this
feature
so
like
the
documentation,
would
be
not
fully
accurate.
D
Maybe
if
something
like
is
like
so
dynamic
that
we
still
work
on
and
like,
we
know
that
it's
going
to
be
presented
under
this
button,
instead
of
like
going
into
very
extensive
documentation.
Just
start
with
the
like
very
shallow
documentation,
saying
we
work
on
the
like
dark
type
of
the
visualization
and
just
link
to
the
issue
related
to
that,
to
kind
of
like
the
rights
awareness
and
like
as
soon
as
we
kind
of
like
concluded,
the
design
like
we
changed
that
part
with
the
actual
documentation.
D
But
then,
like
the
question,
is
really.
Is
it
really
needed
at
that
point
because,
like
one
of
the
changes
that
I
planned
like
to
push
with
martha
or
like
someone
from
the
technical
writer
teams,
it's
like,
since
all
our
feature,
flags
cannot
be
like
it's
kind
of
documented.
By
default,
we
could
really
create
a
list
of
all
the
feature
flags
that
got
added
with
their
state
and
the
link
to
the
documentation.
D
Because,
like
I
mean
it's
like
it's
much
bigger
aspect,
it's
like
the
visibility
for
ourselves
and
like
our
internal
users,
which
is
like
json,
for
example,
product
manager,
like
it's
really
kind
of
hard
like
for
the
product
manager,
to
discover
that
we
have
this
feature
behind
the
feature
flag.
But
this
feature
flag
is
not
yet
enabled
so
it's
like.
Is
it?
Should
we
announce
that
like
what
we
should
communicate?
D
Some
so
maybe
like
this
problem
is
really
like.
We
should.
We
shouldn't,
like
preliminary
document,
dates
the
documents
these
things,
but
maybe
we
should
have
like
the
comprehensive
table
where
we
have
all
these
features
for
us
kind
of
like
automatically
generated
the
list
with
the
place
where
you
could
read
more
description
about
what
this
feature
flight
brings
and
make
it
easier
like
to
discover
like
what
was
added
and
when
and
and
how
it
changed.
D
So
if
someone
is
running
on
prem,
they
may
be
willing
to
try
this
awesome
duck
visualization,
and
maybe
they
would
would
be
waiting
like
to
see
that
list
of
the
feature
files
that
got
like
enabled
or
disabled
or
like
that
they're
starting
to
charge.
So
I
I
have
no
idea
about
how
to
answer
your
question.
It's
like
probably
it's.
It's
very
great
like
how
to
approach
that,
but
maybe
like
it
doesn't,
have
to
be
approached.
If
we
have
like
slightly
more
comprehensive
overview
of
what
feature
flags
are
there
what
they
are
meant
for?
D
Who
owns
that?
What
is
their
state
and
where
I
can
find
more
details
about
like
what?
What
created
that
feature
flag?
I
mean
the
change
and
where
it's
like
the
description
about
the
rollout
that
features
like
so
maybe
so
maybe
this
would
be
like
better
way
to
kind
of,
not
really
add
a
lot
of
to
the
processes,
because
it
would
be
automated,
but
rather
like
make
it
comprehensive
to
everyone
to
have
like
the
same
understanding.
What
this
like
description,
those
provide.
B
I
think
what
you're
describing
camille
could
even
be
a
feature
in
the
product
like
there
could
be
a
group
page.
That's
like
the
feature
flag
overview
that
you
know
if
you
go
to
get
in
our
case.
If
you
go
to
gitlab.org
and
go
to
like
feature
flags,
there's
just
a
list
of
all
the
feature
flags
there
the
context
whether
they're
turned
on
or
often
in
what
environments
and
yeah.
B
You
also
pull
that
into
the
docs
or
whatever
and
can
generate
it
live
on
the
fly
there,
because
people
should
naturally
check
the
docs.
But
if
I
you
know
had
my
own
little
product
and
it
had
a
few
feature
flags
in
it,
I
could
send
people
there
and
say
like
hey.
If
you're
curious,
what's
turned
on
or
off,
you
know,
go
just
check
out,
gitlab.com
slash,
my
project
name
feature
flags,
and
it
will
tell
you
the
status
of
everything
that
would
be
pretty
cool.
D
And
yes,
it's
actually
pretty
interesting
because,
like
one
of
the
like
aspects
that
we
are
also
like
discussing
with
xenia
and
others
is
like
annotating,
the
feature
flag
in
which
context
is
being
used
because
some
feature
plugs
are
scoped
to
the
project.
Some
future
flags
are
scoped
to
the
user
and
right
now
like
we,
don't
really
make
it
like
very
well-defined.
C
I
was
just
thinking
that,
like
maybe
you
know
future
flag,
I'm
I'm
now
talking
about
our
gitlab
future
flag
and,
like
developers
of
the
project,
can
go
to
the
features
like
page
and
edit
it
and
show
that
see
the
list
of
future
track
right.
But
the
this
future
list
is
not
exposed
to
end
users
so
like,
like
they're,
already
think
they're
deploying
any
application
to
the
world.
C
But
the
end
user
has
no
idea
like
what
official
which
future
flag
is
on
and
off,
and
I
was
thinking
that
how
about
like
we
published
status
of
future
flags
to
the
world
with
scala
pages,
for
example
like
we
can
like
gitlab,
can
summarize
the
future
flag
state
and
expose
it
in
real
time
expose
if
your
flag
stays
in
the
public
place
in
real
time.
So
maybe
it's
kind
of
interesting
like
like
expose.
D
So,
like
kind
of
like
trying
to
have
and
like
because
the
current
dashboard
of
the
future
plug
is
like
very
feature
flux-centric,
but
probably
the
another
dimension
that
you
may
be
interested
to
look
at
is
like
environment-centric.
I
want
to
see
what
feature
effects
are
configured
on
that
environment
versus
maybe
another
or
just
that
environment
right.
D
If
you
would
like
to
ask
the
question
my
staging
how
it's
actually
configured
what
feature
effects
are
actually
like
enabled
what
feature
tracks
are
have
like
their
own
specification.
That
is
specific
to
the
staging
like
today,
like
with
the
github
picture
facts,
it's
pretty
hard,
probably
to
answer
that
question.
If
I'm
right.
A
Actually
in
unleashed
feature
flags
that
we're
developing
the
ui
has
a
dashboard
that
tells
you
the
feature
flags
and
we
have
a
bunch
of
issues
that
allow
sorting
and
filtering,
because
once
you
hit
a
large
number
of
feature
flags,
it's
really
hard
to
know.
What's
going
on
there
and
you
could
you
know,
filter
by
your
environment
or
by
your
scope
or
by
your
strategy,
so
that
would
be
more
visible.
E
Sorry,
it's
a
little
hectic
at
my
house.
I've
got
people
working
on
my
roof,
so
I'll
be
as
quick
as
possible,
but
back
to
the
subject
of
when
should
we
be
documenting
during
the
iteration
retrospectives,
we
kind
of
talked
about
well,
let's
just
document
all
the
time,
and
then
we
can
clarify
like
this
is
experimental
or
this
is
beta,
so
that
was
kind
of
my
question.
Can
we
just
do
that
more,
rather
than
waiting
on
it
to
be
enabled
waiting
on
it
to
be
complete
things
like
that.
E
D
D
I
mean
like
it's:
it's
like
a
good
suggestion.
Maybe,
like
you,
would
be
willing
to
create
an
issue
in
the
epic
that
I
think
because,
like
it's
about
like
our
internal
uses
of
the
feature
plugs
and
it
could
be
like
interesting,
talking
points
like
your
question
and
xenia,
I
think
they
are
very
deeply
related
like
how
we
should
handle
documenting
of
the
feature
that
is
behind
the
feature
flag
and
maybe
not
yet
enabled
like
when
it
should
happen,
and
maybe
we
could
figure
out
exactly
some
practice
that
would
work
for
everyone.