►
A
B
I'm
actually
working
on
this
futureflux
story
for
some
time
and
like
if
you
look
at
this
topic
that
I
think
there
is
like
a
lot
of
different
type
of
the
usages
and
like
they
are
not
very
aligned.
So
I'm
kind
of
like
slowly
iteratively,
going
through
all
these
different
disruptances
and
trying
like
to
address
them.
B
But
I
also
like
try
to
gather
some
data,
so
I
I
had
like
I
have
my
match
request
that
tries
to
like
do
a
strong
validation
of
the
features
like
you
search,
and
I
had
like
the
data
points.
I
could
like
recover
data
points
from
two
times
in
the
june
and
like
today,
so
we
we
cannot
really
compare
like
13.0
and
13.1,
but
we
can
compare
like
let's
say
like
just
before
13.1
and
at
the
time
of
the
13.1
and
13.2
to
have.
B
B
I
try
to
categorize
a
lot
of
these
feature
flags
into
types
that
represent
the
different
life
cycle
on
the
feature
flags
because,
like
we
have
a
lot
of
different
usages
that
we
use
feature
plugs
for,
and
only
some
part
of
them
is
really
like
for
the
development
purposes.
But
there
is
also
like
other
types.
A
And
camille,
actually
the
spreadsheet
is,
it
looks
like
you
have
it,
you
haven't
opened
up
the
permissions
called
gitlab.
So
if
you
could
do
that,
that'd
be
great.
So
can
you
also
go?
This
is
the
spreadsheet
I
tried
to
open
it
and
I
don't
know
permission
so
maybe
we
could
add
permissions
to
whoever
open
it
up
to
everybody
at
gitlab.
A
A
B
A
B
B
I'm
gonna
share
that
on
the
chat.
It's
a
link
to
my
note
on
the
www
github.com,
so
you
could
as
well
follow
the
different
things.
So
we
had
560
different
feature
flags
for
three
different
categories.
If
we
talk
about
future
products
that
are
considered
like
development,
so
technically
like
for
the
type
of
the
for
something
like
a
feature
rollout,
we
have
309.
B
B
C
B
C
B
And
I'm
actually
talking
only
about
the
development
type
like
licensed,
are
by
definition,
kind
of
actually
we
removed
some
licensed
features.
We
removed
pre-licensed
features
so
like
we
removed
from
the
mapping
between
different
plants.
These
three
different
types,
maybe
like
we
migrated
them
to
the
core
git
dot
core.
So
maybe
this
is.
This
would
be
the
one
reasons
why
we
remove
them,
because
there
is
no
really
other
reason
for
removing
them.
C
B
Not
really,
I
guess
like
from
my
perspective
from
what
I
saw
like
the
future
of
black
lives
cycle,
is
like
it's
kind
of
free
fall
process.
It's
not
really
like
that.
We
actively
work
on
removing
future
flux
like
we,
I
I
some
time
ago.
I
also
did
analysis
of
how
many
feature
flags
are
configured
on
github.com,
but
they
are
no
longer
present
in
the
code
base
and
there
was
like
pretty
high
number.
B
I
found
like
at
least
a
few
disruptances
between
the
configuration
so
like
the
tricky
part
about
our
feature
effects
usage,
which
is
maybe
the
most
tricky
part
like
we
test
a
on
premise.
We
run
b
on
staging
queue,
run
c
on
qa
we
run
d
and
on
github.com
we
run
e,
because
this
states
they
are
distinct
in
in
a
number
of
cases,
because
people
just
test
the
future
flux
they
enable
disable
them.
Sometimes
they
don't
remove
them.
B
They
change
their
code
base,
for
example.
Today,
when
I
was
preparing
this
analysis
today,
I
found
six
ambiguous
users
of
the
future
flags,
which
was
basically
like
someone
not
changing
in
all
places.
Whether
the
history
is
false
or
true.
I
kind
of
reached
to
these
people
and
they
kind
of
started
correcting.
A
B
Basically,
that
we
had
these
feature
flags.
We
moved
on
to
other
topics
and
like
we,
we
didn't
really
treat
the
development
type
of
the
future
price
as
a
like
technical
debt
that
you
should
get
rid
of
as
soon
as
possible,
and
this
is
this
was
kind
of
my
impression
like
trying
to
untangle,
like
the
feature
plugs
that
I'm
trying
to
do
like
it's
a
little
all
over
the
place.
We
are
we
kind
of
have
trouble
on
ensuring
the
consistency
we
test,
something
completely
different
that
we
ship
on
github.com.
B
C
Do
you
think
we
should
do
you
think
we
should
improve
it
or
do
you
think
it's
even
though
it's
on
like
the
way
you
just
describe
this
it's
unmanaged
and
the
question
always
is:
whenever
we're
looking
faces,
do
we
start
managing
it,
which
takes
time
and
resources
time
time?
People's
energy
actually
should
not
say
resources,
but
time
and
people's
energy,
or
do
you
view
it?
C
B
C
B
B
So,
making
this
slightly
more
like
managing
moving
these
responsibilities
to
other
people
would
make
it
actually,
I
think,
simpler
to
the
people
using
the
feature
files,
because
they
would
have
like
very
simple
working
like
just
create
this.
By
definition,
we're
just
gonna
generate
all
like
these
graphs
data.
For
you,
like
with
the
comprehensive
table
between
different
releases,
every
pm
and
generic
manager,
we
they
will
have,
they
will
know
exactly
what
is
in
the
release
of
how
it's
configured
and
how
it's
configured
differently
to
what
we
run
on
github.com.
B
So,
I
think,
like
we
are
over
the
scale
of
unmanaged
like
given
that
we
had
like
50
new
feature
vlogs
every
month,
and
I
didn't
even
check
like
how
many
we
change
it's
really
hard
to
keep
track,
how
how
it's
kind
of
like
moving
on.
I
mean,
like
also
from
the
from
the
different
perspective
like
it's.
B
B
C
C
Of
what
needs
to
be
cleaned
up
so
then
we
can
basically
get
some
time
devoted
to
those
activities.
Another
one
is
for
anything.
That's
currently
off.
That's
you
know
been
off
for
a
long
time
is,
you
know,
basically
notify
them
about
it
as
well
and
like
I
want
to
disperse
from.
I
don't
want
this
to
be
camille's
problem,
they're
very
clear
on
this
point,
because
it's
it's
really
the
the
management
team
and
getting
up
now,
I'm
like
I'm
like
I'm,
taking
like
the
approach,
I'm
just
like.
C
B
It's
not
that,
like
you,
have
a
string
in
the
code
that
you
can
easily
grab
and
find
like
there's
a
number
of
the
feature
effects
that
are
like
implicit
based
on
like
other
features.
So
I'm
kind
of
like
thinking
that,
if
we
make
this
explicit
have
like
separate
space
where
we
stole
all
these
names,
it's
not
going
to
be
a
victory
to
the
developer.
B
It's
going
to
be
similar
to
creating
a
changelog
entry,
but
from
our
perspective
it's
gonna
be
super
simple
like
to
create
this
table
from
any
point
of
time
because,
like
you,
only
get
like
this
space
and
you
compare
this
space
against
other
space,
so
it's
also
gonna
be
pretty
simple.
To
get
like
a
graph.
B
So
I
I
mean
I
I'm
not
gonna
be
able
like
to
get
to
the
dopeytrade.com,
but
my
current
plan
is
like
to
update
our
procedures
to
kind
of
have
that
change
block
type
workflow
you
just
if
you
want
to
add
a
new
feature
crack
you
just
create
this
feature:
flag
definition
and,
and
then
the
magic
happens.
If
you
change
the
state
of
the
feature
flag,
you
just
update
this
picture,
like
definition,
and
then
we're
gonna
really
figure
out
how
we
want
to
consume
the
definition.
B
It
still
allows
allows
all
the
flexibility
that
we
have
of
the
feature
flux
so
from
the
development
perspective,
it
doesn't
change
how
you
use.
It
only
really
requires
you
to
create
the
feature
flag
explicitly.
So
it's
documented.
So
your
grammar
is
really
like
documentation
and
part
of
the
kind
of
this
yaml
definition
is
like.
B
Ideally,
I
think
it
would
be
great
if
people
would
provide
in
this
yamu
emerge
request
that
introduces
that
feature
flag
and
like
and
on
the
other
side
they
would
create,
like
some
templated
issue,
feeling
some
initial
details
about
the
feature
flags.
So
then
it
could
be
scheduled
using
some.
I
will
our
regular
issue.
Board
and
kind
of
this
is
how
you,
then,
if
you
then
would
go
to
github.com,
you
would
have
like
a
list
of
their
future
flags
their
state.
B
C
B
I
I
I
really
want
to
finish
this
milestone
like
this.
This
procedure,
like
I,
I've,
been
doing
that
for
like
for
around
one
and
a
half
or
two
milestones
so
far
like
going
through
different
random
improvements
in
the
code
base,
but
I
I
want
to
close
out
my
part
in
this
milestone
and
I
want
to
close
out
the
issues
that
are
have
the
current
bison
there
aside
to
me
and
all
other
that
are
part
of
the
backlog.
B
So
I
just
generated
the
table
from
from,
like
from
the
basically
from
the
work
that
I
am
doing
right
now.
I
I
just
need
to
somehow
at
some
point
put
all
these
definitions
without
like
putting
a
lot
of
details
about
them
into
codebase.
So
I
have
like
one
of
my
merch
requests:
has
this
magic
function
that
it
generate
like
it
persists
the
feature
flux
as
it's
been
as
it's
used?
B
A
A
B
So,
like
so
like
to
to
update
the
data
from
today,
I
had
to
spend
about
two
or
three
hours
and
like
have
like
four
or
five
different
iterations
on
the
pipeline,
to
ensure
that
I
fix
the
ambiguous
usage
of
the
feature,
flux
and
have
the
pipeline
green.
Okay.
And
it's
given
the
fact
that,
like
a
number
of
my
agendas,
are
already
merging
them
in
the
master.
So
to
have
like
the
data
point
before
july
sorry
june,
I
would
have
to
like
port
a
number.
C
Yeah,
I
think
I
think
this
gives
me
an
overall
trend
and
else
gives
me
a
little
bit
of
a
story.
I
think
the
main
thing
wayne
you
and
I
need
to
think
about
is
once
camille
gets
to
centralize
his
kind
of
next
steps,
and
you
know
maybe
how
we
either
engage
kyle
or
think
about
it
from
a
management
perspective.
C
C
D
Yeah,
I
just
wanted
to
call
out
that
ci
is
starting
to
use
that
rollout
template,
and
so
we
could.
We
could
tie
that
in
with
what
you
know
with
what
camille's
talking
about
as
a
way
to
you
know,
there's
probably
a
way
to
programmatically.
Do
this,
but
regardless
of
automation
like
just
tie,
it
tie
it
together,
so
that
there's
a
so
that
we
don't
lose
track
of
the
the
cleanup
work
that
needs
to
be
done.
You
know
once
a
feature
is
this
is
shift
and
like
in
production.
B
B
How
we
could
approach
like
this,
creating
this
piece
of
like
description
like
it
could
be
even
like
dancer,
creating
that
for
you,
when
you
create
a
merch
request
and
system,
discover
that
a
new
feature
fact
is
created,
like
I
don't
really
sure
exactly
like
how
strictly
will
not
be
about
like
reaching
future
facts
as
a
technical
depth.
But
it's
not
really
like
my
decision
to
make.
So
I
I'm
kind
of
like
like
making
this
like
super
flexible
process
like
let's
make
it
like
decide
like.
B
If
you
don't
want
to
create
issue.
It's
fine
like,
like
word,
not
gonna
break.
It's
like
just
just
give
us
some
hint
about
like
who
created
and
why
I'm
I
mean
not
individual,
but
rather
like
the
group
they're
owning
the
feature
flag
is
so
the
current
process
is
not
strict,
really
like
the
strict
part
on
is
that
you
need
to
always
create
some
definition.
B
B
If,
if
you
are
the
owner
of
them
to
have
actually
some
initial
understanding,
how
many
feature
flags
each
group
has
and
like
do,
we
have
some
issues,
merchandise
for
them
or
do
we
need
to
schedule
like
the
removal,
but
like
I
I
I
don't
really
like
yet
create
this.
I
don't
really
want
to
go
into
making
this
process
trick,
rather
like
small
improvement
to
what
we
have
today
to
make
it
explicit.
B
But
then
we
need
to
figure
out
exactly
how
strict
we
want
to
want
to
be
about
the
features
like
search,
because
one
one
aspect
really
that
I
I
don't
that
I
don't
want
to
lose.
It's
like
a
future
track
is
to
help,
so
it
should
be
super
simple
to
for
you
to
use
the
future
flux.
So
I
I
don't
want,
like
my
chances
to
the
process
to
be
a
toy,
the
people
would
decide
to
not
use
feature
flux
in
the
first
place,
because
this
is
not
the
intent.
B
The
internet
is
really
like
to
make
everyone
around
to
be
better
about
how
to
use
the
future
flux.
So
I'm
not
really
exactly
sure
how
to
find
this,
like
the
balance
between
removal
and
flexibility,
but
this
is
like
the
implementation
detail
to
figure
out
next,
when
we
better
understand
how
many
and
for
how
long
we
have
historically.
C
And
we
can
adjust
the
wording
as
we
get
some
history,
but
I
think
starting
starting
from
what
we
have
now
and
going
forward,
will
give
us
a
visibility
in
a
few
months
that
we
can
help.
We
can
help
with
that.
From
that
perspective,
cool
to
your
point,
I
don't
want
to
make
it
too
onerous.
If
it
becomes
onerous,
then
that
becomes
problematic
in
and
of
itself.
So
we
don't
want
slow
development
down
cool
thanks
for
the
hard
work
appreciate
it.