►
From YouTube: Feature Flags Office Hours 8th April 2021
Description
Discussed moving feature flags to a previous maturity level and dogfooding Unleash
B
B
Screen
and
there's
a
discussion
here
around
feature
flag,
dog
footing
and
product
feature
flags,
and
we've
talked
about
this
several
times
in
our
future
flag
office
hours.
But
just
to
recap,
we're
not
intensively
dog
fooding
unleash
feature
flags,
even
though
that's
what
we're
offering
as
a
product
we
are
using
it.
We
are
using
flipper
mainly
for
development
of
gitlab
and
our
current
maturity
level.
B
Yeah
so
we're
currently
at
viable
and
when,
when
we
gave
this
definition
of
viable,
the
definition
was
that
real
users
can
use
the
functionality
to
solve
real
problems
right.
So
it's
the
third
of
the
categories.
It's
not
planned
because
we
have
some
features
implemented.
It
wasn't
minimal
at
the
time
because
it
may
not
be
ready
for
production
and
viable
at
the
time.
B
Now
there
are
some
teams
in
gitlab
that
are
dog
footing
it,
but
I
would
say:
90,
plus
percent
of
the
actual
users
are
not
dog
food,
so
I
don't
think
that
we
can.
Actually,
you
know,
check
mark
this
requirement
as
the
as
the
maturity
level
and
the
cm
scorecard
was
not
done
for
future
five.
So
there's
a
discussion
here
whether
or
not
we
should
reduce
the
maturity
level
and
go
back
to
minimal
and
the
main
reason
is
not
just
because
the
we
didn't
follow
the
process,
because
the
definition
was
changed
after
the
fact.
A
A
B
So,
to
be
perfectly
honest,
due
to
all
the
different
changes
in
the
team,
we're
really
not
very
working
on
future
flags
that
intensively
as
we
were
last
year
and
so
right
now.
The
features
that
are
on
the
top
priority
list
are
the
contextual
issues
and
not
you
know
the
performance
or
scalability
ones.
On
the
other
hand,
we're
not
handling
any
of
the
performance
issues
because
they're
not
coming
up,
because
not
enough
people
are
using
it.
B
So
so
it's
kind
of
like
the
chicken
and
the
egg
situation
here,
because
we're
not
going
to
end
this
loop.
What
I
had
talked
about
with
nicole
in
our
weekly
meeting
was
maybe
we
as
the
release
team
start
using
unleash,
as
our
development
feature
flag
instead
of
flipper,
and
maybe
we
can
uncover
some
of
the
problems.
A
A
You
need
to
every
time
you
create
it.
You
need
to
create
a
few
issues
for
rolling
out
this
feature
flex.
Removing
it
then
you
yeah,
you
need
to
commit
something
in
the
code
base
with
the
definition
of
the
feature
flag
and
who
responsible
for
working
with
it,
like
which
team
responsible
for
it
and
it
kind
of
if
we
starting
to
use
unleash
we
kind
of
violate
all
this
process,
and
also
we
still
have
this.
I
mean
it
doesn't
really
matter
from
performance
standpoint.
B
B
You
know
and
making
sure
that
it's
a
feature
that
is
not
high
volume
or
something
similar
so
that
we
can
just
test
it
out
and
see
really
if
there
are
performance
control
concerns,
because
right
now,
there's
performance
concerns.
We're
not
sure
they're
really
concerns
we're,
not
sure
when
we
need
to
handle
them,
we'll
need
to
handle
them
when
they
show
up,
but
we're
not
sure
when
I
think
it's
better,
that
we
surface
it
than
our
customers.
A
Yeah,
that's
definitely
true,
sorry,
I
would
start
like
not
on
the
product
area,
but
maybe
on
the
try
to
use
this
feature,
flux
on
some
kind
of
side
project
like
runner
pages,
or
something
like
that
when
there
is
like
a
smaller
fleet
of
applications
running
because
they
will
create
less
load
for
dot
com
er
for
ops
instance.
If
we
speak
about.
B
B
It's
like
it's
like
this
site,
where
you
can
sign
up
it's
a
little
bit
separate
it's
it's
like
it's
called
the
customer
site
or
portal,
or
something
so
it's
not.com
for
sure.
Maybe
that's
why
they're
using
it,
but
I
actually
do
want
to
find
someplace
in
dot
com
that
we
can
use
it
without
making
too
much
problems.
A
A
A
B
A
Yeah,
basically,
what
I
would
do
I
would
create,
create
a
project
on
the
ops
instance
of
gitlab
and
then
using
the
flipper
feature
flag
flux.
I
would
test
the
single
feature
flag.
Using
on
this
ops
instance.
It
will
be
like
completely
unrelated
to
any
code
like
any
to
completely
unrelated
to
any
feature
on
gitlab.
Just
like
test
feature
flag
number
one-
I
don't
know,
but
do
it
for
a
percentage
of
the
users,
so
let's
say
not
users
but
requests.
A
I
I'm
this
is
kind
of
a
mix
of
these
two,
I'm.
What
I'm
suggesting
is
to
use
fischer
flick
flipper
feature
flags
to
control.
How
often
we
try
to
access
unleash,
feature
flags,
and
this
way
we
can
test.
Basically,
what
I'm
trying
to
do
is
not
roll
out
tests
for
for
the
100
of
dot
com
and
just
roll
out
it
for
the
small
portion
of
it
like
one
percent
two
percent-
maybe
you
can
just
create
this
issue
and
just
ping
me
on
it
and
I'll
yeah.
B
A
I
mean
that's
actually
questionable
assumption,
because
basically,
any
client
who
will
try
to
use
gitlab
future
flex
as
a
for
production
makes
gitlab
like
eric,
makes
it
a
requirement
to
run
gitlab
100
of
the
time.
So
they
can't
just
shut
it
down
for
a
couple
hours
in
the
night
right
since
yeah,
since
futureflux
all
will
become
disabled
for
these
two
hours.
A
So
I
don't
know
for
massive
scale,
my
I
myself
wouldn't
use
it
even
if
we
run
it
on.com
for
100,
because
then
you
need
to
make
your
own
gitlab
instance
as
reliable
as
dot
com
is,
which
may
be
not
true.
But
if
you,
if
you're
a
dot
com
user,
then
maybe
it's
safe,
because
yeah
dot
com
is
probably
way
more
reliable
than
some.
Our
customers
projects.