►
From YouTube: Feature Flags Office Hours Aug 13th 2020
Description
Feature Flags Office Hours Aug 13th 2020
A
So
the
the
application
itself
stores
the
environment
name,
but
unfortunately
it
seems
like
the
the
ability
to
set
like
an
environment.
Specific
feature,
flag
doesn't
work,
and
I
was
curious
if
I
could
get
like
some
a
second
pair
of
or
third
pair
of
eyeballs
on
it,
and
if
this
is
the
right
meaning
great.
If
not,
I
can
hit
up
another
mean
or
medium
for
that
yeah.
B
No,
this
is
the,
I
think,
that's
a
good
place
to
chat
about
that.
So
I
remember,
I
think,
in
our
conversation
last
that,
like
the
the
some
of
the
documentation,
things
were
a
little
bit
misleading
about,
like
you
know,
the
the
alignment
of
what
act
name
is
to
and
like
app
name,
environment,
name,
kind
of
thing
right
and
so
you've
kind
of
you've
you've
resolved
that
or
you
or
you're,
trying
to
get
around
something
else
and
feel
free
to
like
share
your
screen
or
whatever
yeah.
A
A
C
D
A
C
C
A
C
The
app
name
is
just
an
easy
value
that
is
used
by
that
was
used
by
unleash
beforehand
as
part
of
like
a
registration
process,
yep
and
they're,
slowly,
adding
the
support
for
like
a
custom
environment
section
as
well.
But
as
far
as
I'm
aware,
that's
not
100
percent
there
yet,
and
we
got
to
support
that
part
of
the
api.
A
A
So
that
because
they
don't
want
developers
to
always
have
access
to
their
feature,
flags
and
right
now,
there's
not
really
any
good
way
to
lock
that
down.
So
one
of
the
approaches
that
I've
recommended
is
like
we'll
just
create
a
new
project,
have
your
feature
flags
there
give
your
developers
the
access
token
and
the
registration
entry
and
then
and
then
you
can
console
it.
You
can
have
one
feature
flag
project,
but
then
it
would
be
nice
to
be
able
to
like
designate
you
know
app
name
and
environment
name
together.
C
A
E
So
those
should
be
joined
for
the
customer's
application.
The
get
lab
customers
application
yep.
I
wrote
code
that
essentially
does
that
it
it's
compr
the
environment
doesn't
need
to
be
staging
or
production.
I
actually
named
the
environment,
customer
staging
and
customers
production
and
even
expose
an
environment
variable
that
you
can
use
locally
so
that
you
can
target
your
specific
development,
environment
or
development
in
general.
Does
that
make
sense
so.
B
A
Yeah,
so
so
one
of
the
use
cases
that
they
they
do
have,
though,
is
like
the
ability
to
and
currently
whatever
what
we're
implementing,
is
totally
feasible
right
like
having
the
having
a
project,
that's
designated
for
feature
flags
outside
of
the
source
code
repository
and
I'm
assuming
like
when
we
move
to
dog
food.
This
within
a
like
our
own
production
environment,
I'm
assuming
gitlab.com
will
be
going
out
to
get
lab
staging
for
feature
flags.
Is
that
the
end
goal.
C
A
A
D
A
A
Yeah
yeah
and
that
I
think,
that's
totally
fine
yeah
and
honestly,
I
think,
like
I've,
seen
a
lot
of
customer
interest
in
future
flags
so
and
we
we
just
met
with
a
customer
that
was
really
wanting
to
utilize
future
flags,
but
can't
move
forward
with
premium
premiums,
not
costs
justifiable
for
them.
So
well.
A
D
Yes,
great
question,
so
we're
moving
to
core
what
we
have
right
now,
excluding
one
thing.
So
what
we
currently
have
is
a
very
basic
way
to
configure
future
flags.
What
we
do
want
to
monetize
on
is
the
extra
value
connectivity,
so
we
added
in
the
last
milestone
a
way
to
link
issues.
For
example,
that's.
D
D
Metrics
is
another
one,
so
the
ability
to
get
client
metrics
a
b
testing
is
a
huge
one
which
we're
going
to.
We
just
finished
some
user
research
user
interviews
on
that
and
we
plan
to
start
coming
up
with
some
implementation
plans.
For
that.
So
that's
really
exciting.
That's
for
sure
going
to
be
paid.
A
A
E
Can
you
guys
hear
me
there
you
go
yes,
yeah,
I'm
here
on
the
from
the
growth
team
and
we're
going
to
be
implementing
the
unleash
stuff
for
experiments,
and
so
we're
specifically
looking
for
a
b
and
variant
testing.
So
that's
that's
sort
of
what
I'm
investigating
specifically
and
and
how
we
can
expose
that
to
customers.
Ultimately,
nice.
A
F
F
F
So
I
just
quickly
looked
up
the
source
code
and
then
it
seems
that
app
name
is
sent
as
a
unless
app
name.
This
is
sent
to
the
header
and
in
gitlab
this
is
a
gitlab
site,
the
api
yep,
and
it's
get
the
other
shop
name
right,
and
this
is
considered
as
a
environment
name.
So
if
there,
if
you
wanna
fetch
production
feature
flag,
you
have
to
set
up
name:
okay,
production
to
the
app
name
yeah.
Otherwise
you
don't
get
anything
cool.
F
A
G
I
had
a
let's
say
the
outer
question
about
the
putting
there
the
discussion
attribute
or
the
discussion
area
as
it
seems
to
me
that,
let's
say
the
biggest
ground
for
collaboration
in
github
is
the
discussion
on
issues
and
the
fear
that
starting
to
split
the
possible
discussion
about
the
future
flag
can
be,
can
make
this
harder.
So,
of
course,
maybe
I
miss
some
imagination
about
what
kind
of
discussion
can
happen
on
a
feature
flag
section.
D
You
know,
do
something
which
sounded
very
similar
to
our
assignee
and
then
they
had
this
way
to
tag
feature
flags
for
for
different
purposes,
for
like
search,
filtering
and
so
on.
So
that
sounded
a
little
like
labels
to
me,
and
then
I
thought
to
myself.
This
sounds
like
an
issue.
It
sounds
like
we
have
this,
a
bunch
of
things
that
that
are
very
similar
between
feature
flags
and
issues,
and
it
turns
out
that
there's
a
few
more
teams
that
are
looking
at
making
other
entities
issue
types.
D
The
first
one
which
we're
going
to
follow
suit,
is
incidence
response.
So
the
monitor
team
is
now
creating
an
issue
type,
which
is
an
incidence
response
which
is
taking
a
bunch
of
modules
from
the
issue
type,
not
everything,
but
what
made
sense
and
that's
kind
of
where
I
want
to
go
with
feature
flags.
So
the
proposal
is
very
light
because
I
it's
worth
the
discussion.
D
D
Exactly
so,
we
do
have
some
audit
log
capabilities
for
feature
flags
and
and
each
new
functionality
has
audit
log,
but
there's
a
lot
of
benefits
to
using
an
issue,
and
even
the
conversation
is,
I
think,
beneficial,
because
you
can
have
a
conversation
there
between
the
team
saying
hey,
I
added
this
feature
flag.
Here's
what
it's
doing
or
have
people
ask
questions
on
it
or
open
additional
items.
D
G
G
Some
clients
had
a
need
to
some
somehow
shield
the
feature
flight
from
some
groups
that
could
not
activate
it
or
could
activate
it,
so
maybe
having
a
smears
or
something
like
that
on
a
future
flag
would
also
help
in
permissions
and
condo
right.
So
that's
a
great
great
suggestion
that
you
that
you
made
so
yeah
thanks.
A
Hey,
I
was,
I
was
just
thinking
about
adding
the
contextual
issue
of
like
linking
an
issue
to
a
feature
flag.
If
staging
is
the
source
of
truth
for
all
of
our
future
flags
that
will
fundamentally
not
work
because
so
like
we
wouldn't
be
able
to
associate
a
feature,
a
feature
flag
hosted
in
staging
with
a
issue
in
gitlab.com.
D
Yeah,
I
do
want
to
mention
that,
regarding
the
feature
flags
as
an
issue
type
we're
also
thinking
of
future
flags
like
in
a
broader
sense,
we
want
to
make
them
a
first
class
citizen,
so
making
them
an
issue
type
is
the
first
like
one
of
the
steps
to
get
there.
We
also
want
to
move
it
out
from
its
current
location.
So,
right
now,
future
flags
is
under
the
operations
menu
which
isn't
very
intuitive,
and
it's
really
hard
to
find
so
we're
thinking
of
a
better
place.
D
To
put
it,
there's
some
discussion
of
consolidating
a
bunch
of
release,
activities
under
one
menu,
so
like
environments
and
releases
and
feature
flags
and
maybe
even
deployments,
even
though
deployments
is
currently
under
like
you
need
to
get
there
from
environments
but
we're
thinking
of
taking
that
out
as
well.
So
there's
a
lot
of
different
discussions
of
making
this
more
visible
and
more.