►
From YouTube: UX Showcase - Feature Flags as an Issue Type
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
A
I'm
really
excited
to
share
with
you,
because
it
was
a
trial
of
a
lot
of
different
attributes
coming
together
and
creating
this
really
great
vision
and
wait
for
our
team
to
move
forward
with
this
area
to
clarify
a
few
things
feature
collect
is
inside
of
the
release
section,
and
I
know
a
lot
of
us
are
used
to
hearing
me.
Talk
about
packages
and
containers
and
dependency
proxies.
A
I've
been
covering
the
release
date
as
there
has
been
some
reorganization,
as
well
as
realignment
priorities
and
stuff
like
that.
So
I
was
here
trying
to
help
cover
the
design
needs
for
the
release
days
during
this
transition,
as
well
as
kind
of
trying
to
make
sure
we're
moving
things
forward.
A
Today,
I
wanted
to
talk
about
the
feature
flags
work
that
we
did
and
so
to
keep
up.
I
kind
of
want
to
share
the
overall
view
of
the
work
we
wanted
to
do.
There
was
a
lot
of
change
in
priority
and
there
was
a
lot
of
unknowns
as
we
were.
First,
getting
started
and
the
team
came
together,
and
so
we
decided
to
focus
our
efforts
around
feature
flags.
A
The
hypothesis
was
by
creating
a
single
source
of
truth
for
feature
flags
users
would
be
able
to
easily
find
investigate
and
act
on
feature
flag
inside
of
the
gitlab
product.
We
had
heard
from
a
lot
of
users
in
a
lot
of
different
cases
where
they
weren't
able
to
fully
utilize
the
different
parts
of
feature
plugs.
They
were
wondering
if
there
were
parts
that
were
missing
and
then
classic
work
around
that
we
had
to
look
for.
A
A
A
This
is
the
view
where
you
get
to
see
all
the
feature
flags.
Looking
at
the
current
view,
it
had
a
bit
of
a
buggy
layout.
We
were
using
tables,
which
means
they
were
kind
of
inflexible
and
we
had
some
content.
It
was
really
short
other
content
that
was
really
long,
and
so
things
would
overlap
with
each
other
or
you
would
end
up
with
kind
of
that
pill.
Ui.
That
was
several
lines
tall
things
that
didn't
quite
feel
up
to
the
caliber
that
we'd
like
to
see
nick.
A
We
also
heard
a
report
that
the
actions
in
the
listview
was
a
little
bit
chaotic
and
again
the
long
tech
limited
horizontal
space
was
becoming
a
shoe.
The
other
half
of
the
work
that
we
looked
at
was
in
a
detail
view
starting
off.
We
really
didn't
have
a
detail
view
for
feature
flags
and
for
something
that
had
such
an
impact
on
users.
It
felt
really
strange
most
to
me
and
see
users.
There
was
no
place
they
could
just
look
at
what's
going
on
with
this
feature
flag.
A
The
interface
that
we
offer
is
just
an
edit
view,
so
some
users
felt
uncomfortable
being
there.
They
weren't
going
to
change
the
feature
flag.
The
interface
had
some
limited
data.
The
overall
content
hierarchy
and
structure
was
lacking,
some
of
what
they
needed
and
able
to
really
quickly
digest
the
information
and
some
of
the
controls
that
they
really
expected
to
have
just
felt
missing.
A
Taking
a
look
at
all
the
work
we
wanted
to
do
around
feature
flag
and
then
bringing
into
account
the
fact
that,
as
a
designer,
I'm
only
supporting
the
release
stage
at
half
time,
I
wanted
to
best
utilize
my
time
to
make
sure
that
we
were
utilizing
efficiency
and
getting
results,
living
the
gitlab
way
for
aretha
product
manager
and
the
release
team.
The
think
big
idea
was
kind
of
new,
especially
for
the
designer
they
were
used
to
working
in
a
way
where
iteration
happened
and
then
designs
were
reactive.
A
We
found
the
iteration.
We
had
to
create
a
design
for
this
milestone,
so
they
can
work
on
it
in
the
next
milestone,
and
we
heard
when
we
were
talking
about
the
other
designers
that
were
involved
that
sometimes
it's
hard
to
keep
up.
They
felt
like
they
were
always
just
trying
to
fill
in
the
next
milestone,
instead
of
thinking
about
things
from
a
strategic
advantage.
A
So
with
limited
time
on
my
part,
knowing
that
we
were
going
to
bring
someone
on
board
soon,
we
wanted
to
make
the
best
use
of
our
time
and
run
this
experiment
together
in
case
you're,
curious
about
what
think
big
is
and
what
I
mean
by
that.
We're
actually
opening
up
an
mr
to
have
this
exact
conversation.
A
We
went
through
the
design
process,
lots
of
conversations
with
engineering
and
with
some
customers
that
were
really
involved
in
the
conversation,
and
we
came
up
with
two
different
designs.
The
first
one
was
a
listview,
we
kind
of
tailored
it
down.
We
used
progressive
disclosure
in
some
areas
and
kind
of
cleaned
it
up
with
the
data
that
users
had
told
us
was
most
important
to
them.
A
The
other
thing
we
looked
at
was
the
detail
view
and
I'm
hoping
for
a
lot
of
us.
This
looks
somewhat
familiar.
We
were
exploring
the
idea
of
creating
feature
flags,
an
issue
type,
meaning
that
it
would
have
all
of
the
same
controls
and
mechanisms
and
organizational
tools
that
we
have
for
issues
we
could
assign
it
to
a
milestone,
give
it
a
due
date.
Add
labels
things
like
that.
Participants
and
users
could
put
their
feature
flag
work
into
their
milestones
that
they
were
planning.
A
For
this
we
did
moderated
testing
focusing
on
determining
if
participants
could
rock
the
interface
itself,
find
the
newly
introduced
data
and
data
architecture
useful
and
determine
if
the
issue
type
aligned
with
their
workload,
what
we
did
for
the
actual
solution,
validation
during
the
moderated
testing
is
we
asked
users
to
first,
we
presented
them
with
the
problem.
We
need
you
to
investigate
this
feature
plug
and
determine
the
next
step.
We
asked
them.
What
do
you
expect
your
process
to
be
around
here
and
we
kind
of
gather
their
expectations
next,
using
the
prosthetic?
A
We
ask
them
to
find
a
specific
feature,
flag,
understand
and
kind
of
describe
what
they
were
seeing
in
terms
of
what's
going
on
with
that
feature
flag
and
determine
the
next
step.
The
last
part
of
the
solution,
validation
was
focused
on
individual
pieces
of
bui,
so
we
walked
from
the
top
to
the
bottom.
What
does
this
ui
moment
mean?
What
does
this
ui
moment
mean
really
go
through
the
effort
trying
to
understand
what
users
were
seeing
and
what
it
meant
to
them?
A
Validate
that
the
data
we
were
trying
to
present
was
being
received
solution
about
solution,
validation,
results,
they're,
always
really
exciting.
We
had
a
lot
of
wins.
Every
participant
was
able
to
complete
the
task,
so
they
were
able
to
find
the
feature
flag.
They
were
able
to
understand
the
data
that
was
being
shown
stuff
like
that.
A
A
A
We
added
a
history
and
discussion
section
similar
to
what
we
see
at
the
bottom
of
issues,
users
really
love
that
they
wanted
we're
excited
by
the
idea
that
not
only
could
they
see
the
rollout
pattern.
Now,
but
they
could
see
when
it
started
and
if
there's
a
bug
in
production
they
can
see
like
the
feature
flag
started
in
production
two
weeks
ago,
when
we
started
having
bugs
two
weeks
ago,
this
lined
up
for
them
a
lot.
A
A
Some
things
we
did
learned,
unfortunately,
featured
like
an
issue
type
didn't
quite
resonate
with
their
users.
They
found
it
kind
of
confusing
at
times
and
when
they
did
understand
it
and
were
able
to
kind
of
walk
me
through
it.
What
we
discovered
is
for
a
lot
of
organizations,
the
individuals
and
team
members
that
were
in
the
backlog,
engineers
and
product
designers,
weren't,
really
directly
impacting
feature
flags
when
compared
to
an
sre
whose
job
it
is
is
to
make
sure
rolling
out,
goes
effectively
and
so
combining
the
two
of
them
didn't
quite
work
for
them.
A
This
was
doubled
down
on
the
controls
became
really
confusing.
So
if
I
close
the
issue
for
the
feature
flag,
does
it
turn
off
the
feature
black
things
like
that?
Just
didn't
quite
line
up,
and
when
we
tried
to
explore
a
little
further
with
the
users,
they
couldn't
really
come
up
with
an
answer
that
made
sense
to
them
and
then
the
last
thing
we
learned
is
this:
we
talked
to
a
lot
of
different
people.
The
different
needs
of
different
work
sizes
were
completely
different.
A
Small
scrappy
startups
had
one
person
the
engineer,
managing
a
feature
flight
from
start
to
finish,
and
so
it
kind
of
made
more
sense,
but
it
wasn't
an
issue.
Larger
organizations
there's
a
whole
other
team
that
handled
this,
and
so
putting
them
together
didn't
quite
work
for
them.
They
did
like,
however,
that
they
were
all
connected,
so
what
we
walked
away
from.
We
made
some
edits
to
the
list
view.
A
We
know
and
had
a
lot
of
confidence
and
things
tested
well,
the
people
were
feeling
really
excited,
and
so
we
have
a
lot
of
work
that
we
could
work
on.
One
of
the
advantages
is
because
we
were
thinking
bigger
and
trying
to
expand
the
view
of
what
we
were
looking
at
to
create
that
vision,
even
though
the
issue
type
part
of
the
conversation
wasn't
quite
what
we
like
what
we
were
looking
for,
a
lot
of
what
we
were
doing
and
showing
to
our
users
resonated
it
tested
very
well
and
they
liked
the
improvement.
A
A
There
was
a
very
large
hazard
fee
in
this
new
release
group
that
we
were
going
back
to
waterfall,
that
we
had
done
this
really
big
design
and
then
just
kind
of
handed
it
off
to
them,
and
now
they
expected
to
just
build
everything,
and
that
goes
against
our
values
of
innovation.
How
focused
we
are
in
nbc,
this
just
didn't
feel
right
to
them
and
understandable.
So
what
we
did
is
I
asked
them
for
a
little
bit
of
trust.
A
What
we
ended
up
doing
was
really
demonstrating
that
think
big
work,
small
model
so
based
on
the
testing
based
on
the
exploration,
all
the
design
work
we
did,
we
were
able
to
create
13,
unique
and
independent
issues.
Some
of
the
issues
were
really
simple.
This
issue
was
devoted
to
updating
the
button
to
the
brand
new
styling
that
we
should
be
using
making
that
primary
button
blue
instead
of
green.
Some
of
them
were
a
lot
larger,
like
adding
the
markdown
description
and
edit
state
for
the
issues.
A
This
is
a
lot
of
interconnected
parts
and
we'll
probably
have
to
be
broken
down
a
little
bit
further,
but
they're
actionable
now
for
engineering
there's
also
from
the
research.
This
refinement
area,
where
we
know
we're
going
to
have
to
investigate
further
the
history
and
discussion
section
being
able
to
see
the
history
of
the
feature
flag
and
add
comments.
We
know
already
that
there's
going
to
be
a
need
for
a
technical
investigation,
we're
going
to
have
to
explore
whether
we
can
just
copy
and
paste
what's
already
there
into
the
feature
flag.
A
What
happens
if
I
get
tagged
in
it?
Does
it
also
make
a
dupe
to
do?
How
do
we
handle
that?
So
we
know
we're.
Gonna
have
to
have
those
conversations,
but
when
we
have
that
unified
vision,
it's
easy
for
engineers
to
take
the
lead
in
those
conversations
and
come
forward
with
ideas
instead
of
kind
of
asking
the
binder
the
product
managers
to
define
a
lot
of
things
for
them,
it
makes
it
a
lot
more
of
a
collaborative
experience,
and
this
is
the
same
thing
with
the
expanding
the
filters
and
sorting
capabilities
and
enhancing
the
strategy.
A
We
know
we're
going
to
put
a
little
more
work
in
there.
The
other
thing
that
we
get
to
add
to
this
thing.
Big
model
is,
we
now
know
some
more
areas.
We
need
to
explore.
We
found
some
things
that
we
know
kind
of
worked
and
we
should
do
more
investigation
on
it.
The
big
one,
that's
kind
of
obvious,
is
the
connection
between
issues
and
feature
flags.
A
That's
my
spiel.
For
today
it
was
a
really
fun
exercise,
especially
considering
that
I
was
at
halftime.
So
there
was
a
lot
of
efficiency
in
delivering
and
setting
expectations.
It
was
really
wonderful
to
work
with
the
release
team,
orie
and
nicole,
and
absolutely
everybody
was
wonderful
to
work
with
lots
of
great
communication.
A
A
lot
of
you
on
the
release
team
took
a
chance
and
expressed
me,
and
I
hope
that
you
are
very
excited
with
the
outcome,
as
some
of
the
engineers
happen,
that's
it
for
my
presentation,
so
thank
you.
B
That's
awesome.
Thank
you.
Ian
I've
seen
how
future
flag
has
evolved
as
a
capability,
so
it's
very
exciting
to
see
the
next
steps
and
how
we
can
make
it
a
first-class
capability
with
gitlab.
So
thank
you
for
sharing
that
and
it
looks
like
we
have
a
couple
of
questions
in
the
agenda
holly.
Would
you
like
to
voice
your
first
comment.
C
Sure
it's
just
kind
of
an
fyi.
We
have
a
lot
of
really
interesting
and
exciting
things
happening
surrounding
the
topic
of
issue
types
right
now.
So
there
are
a
couple
of
issues
related
to
that
and
I
think
hayana
you
were
also
working
with
amelia
on
yet
another
type.
So
we
are
all
in
coordinating
our
issue
types
conversations
so
that
we
can
ensure
that
we're
in
alignment.
But
if
you
want
to
dig
a
little
deeper
into
that,
there's
some
helpful
links.
D
Yeah,
okay,
michael,
don't
we
that's!
That
was
great
ian!
I
love
the
feature
flag
work
and
I
noticed
in
the
design
issue.
Under
intended
users,
we
list
basically
every
persona
and
I'm
wondering
if,
if
there
was
when
you
were
designing,
if
you
had
a
primary
kind
of
roller
persona
in
mind
when
you
envision
someone
using
this.
A
Virtual
world,
you
bring
up
a
great
point:
figure
like
couldn't
possibly
be
used.
A
That
when
we
were
describing
it,
the
users
that
we
focused
on
there
were
two,
the
main
one
was
the
engineers,
and
these
are
generally
the
individuals
who
are
creating
the
feature
flags
adding
into
the
code
and
managing
it,
at
least
in
the
beginning,
for
smaller
organizations
that
carried
through
all
the
way
into
roll
out
for
larger
organizations.
We
still
focused
on
the
engineer,
but
there
was
this
other
persona,
the
sre,
who
was
basically
the
person
on
the
team
who
was
responsible
for
rolling
out
things
effectively.
Making
sure
production
is
good.
A
Those
are
the
individuals
that,
for
example,
when
there's
an
incident
on
production
that
there's
a
problem,
they
would
likely
need
to
quickly
find
a
feature
flag
and
turn
it
off
to
stop
whatever
that
problem
is,
and
so
they
have
a
very
different
need
and
set
of
things.
They
need
to
do
very
action,
oriented
versus
engineers,
which
is
very
management,
oriented
making
for
the
features
behind
the
feature
vlogging
and
working
and
testing,
and
all
those
things.
D
Cool
yeah,
both
of
those
roles,
kind
of
have
a
high
stake
in
how
well
they
how
easily
they
can
find
the
feature
flag
right,
that's
awesome,
and
then
at
the
next
question.
What
is
our
path
to
dog
food
visit?
Gitlab.
A
That
is
a
great
question
we
have
internally
on
the
gitlab
project.
We
don't
currently
use
our
feature
flag
offering,
but
the
fulfillment
team
is
starting
to
use
it,
and
that
was
actually
really
great
because
we're
starting
together
with
package,
but
this
was
the
first
chance
that
I
could
do
solution
validation
with
dog,
fooding
and
hearing
about
what
our
engineers
and
what
people
who
work
on
fulfillment
actually
have
as
an
experience
using
gitlab
to
manage
the
feature
flags
of
gitlab.
While
talking
about
these
replies
in
gitlab,
it
was
a
really
quite
circular
bond
experience.
D
A
That's
a
really
good
question.
This
process
was
a
very
collaborative
one,
so
I
spent
some
time
with
engineers
of
the
different
parts
of
the
release
team,
saying
here's
where
we
want
to
go.
How
would
you
break
it
up
if
you
had
a
magic
wand,
you
could
just.
G
A
This
is
how
we're
going
to
do
it.
We
started
off
with
those
conversations
I
was
able
to
take
notes
of
these
two
pieces
are
connected.
This
is
isolated
and
kind
of
separate
out
the
pieces
and
then
from
there.
This
is
the
left
elegant
thing,
but
it
seems
to
be
really
effective
for
me,
as
I
kind
of
take
the
current
state
and
figure
out
what
is
the
smallest
change
I
can
make
to
the
current
state
to
get
me
into
where
I
want
to
go,
which
is
that
vision
and
so
for
this
example.
A
I
mentioned
earlier
changing
the
button
from
the
green
to
the
new
blue
primary.
That's
the
first
issue,
because
it's
just
the
first
easiest
thing
to
get
us
where
we
want
to
go,
and
basically
once
I
have
that
first
one,
then
you
look
at
the
same
thing,
be
like
okay,
when
I'm
looking
at
the
second
screen.
What's
the
smallest
change,
I
can
make
to
get
here
and
it's
a
really
cool
exercise.
A
It
sounds
kind
of
laborious,
but
what
you
actually
end
up
doing
is
validating
all
of
your
design
choices,
especially
when
you're
thinking
a
bit
bigger,
saying
it's
actually
really
important
to
add
this
tab
to
the
top
of
the
page
by
itself,
because
it
makes
the
content
hierarchy
so
much
easier
to
digest.
Instead
of
here's,
absolutely
everything
I
design
it
all
works
and
it
had
to
do
well.
So
just
trust
me,
it
was
a
very
different
kind
of
conversation.
H
Yeah,
so
I
was
trying
to
understand
how
you
took
that
vision
and
broke
it
down
with
your
engineering
team.
I
saw
you
closed
your
design
issue
for
the
vision.
Did
you
like
promote
that
vision
into
an
epic
and
then
broke
down
those
13
issues
and
tied
them
back
up
to
that?
Epic?
I've
definitely
run
into
this
problem,
too,
of
like
trying
to
keep
the
vision
there,
but
then
also
trying
to
delineate
all
the
issues.
H
A
I
will
be
totally
honest
with
you
austin
I
haven't
gotten
there,
yet
this
is
fresh
out
of
the
oven
design
work.
I
have
it
broken
down.
My
team
is
very
excited
about
how
we're
going
to
bring
it
down,
and
now
I
get
to
create
all
these
issues.
My
plan
around
that
I
can
tell
you
closed
the
design
issue,
because
the
design
issue
was
dedicated
to
spending
time,
creating
a
vision
for
feature
flags
which
that
work
is
completed.
Solution
validation
is
also
in
that
epic
that's
completed.
A
The
next
step
is
that
epic,
I'm
going
to
refine
it
to
match
our
full
vision
and
put
that
really
pretty
mock-up
right
at
the
top
of
here's.
Where
we
want
to
go,
then
what
I'm
planning
on
is
creating
two
subjects.
One
is
for
that
list
view
that
we
talked
about.
One
is
for
the
detail
view
and
then
just
creating
one
of
those
issues,
one
by
one,
I'm
going
to
use
the
lean
feature
proposal,
because
it's
the
shortest
I'll
be
honest.
It's
also
the
easiest
one
to
like
get
started
with
and
create
the
issue.
A
Here's
the
current
state,
here's
what
we're
going
to
change!
Here's!
Why
it's
relevant
I
like
to
connect
user
research
into
those
issues
as
well,
so
here's
the
insight
that
said
users
really
like
this
and
why
we
need
to
prioritize
this
into
things
and
then
basically
kind
of
go
through
until
we're
there.
The
only
exception
is
every
once
in
a
while
that
issue
that
I
know
is
going
to
be
broken
down.
A
H
E
B
G
A
great
presentation
really
appreciate
it,
and
this
like
really
feels
like
design
for
me,
so
like
it's
sort
of
the
design
and
design
thinking
approach
that
I'm
really
familiar
with.
So
it's
great
to
see
this
in
gitlab
and
this
being
sort
of
balanced
in
all
remote
environment,
and
I
was
just
wondering
when
I've
done
this
stuff
synchronously.
G
Typically,
we've
driven
engagement
for
engineers
by
getting
everyone
together
in
a
workshop,
getting
people
sort
of
pumped
up
and
getting
getting
like
everyone
sort
of
engaged.
That
way
have
you
got
any
tips
for
how
you
can
engage
engineers
and
other
team
members
in
this
sort
of
async
context
or
in
this
sort
of
remote
context.
A
That's
an
excellent
question.
My
biggest
tip
is
get
engineers
involved
earlier,
so
when
you're
doing
that
initial
stage
of
sketching
off
wireframes
there's
zero
harm
in
just
pinging
a
couple
of
the
engineers
on
your
team
and
saying
this
is
the
concept
I
want
to
build
towards.
A
We've
clearly
not
even
started
the
official
design
here,
but
what
do
you
think
and
going
through
and
touching
base
with
them
on
the
regular
means
that,
when
it's
time
to
break
up
that
thing
and
get
them
more
involved,
they're
already
aware
of
all
the
context
of
the
things
you're
talking
about,
so
you
remove
the
need
for,
like
here's,
20
minute
presentation
of
where
my
design
is
and
then
five
minutes,
let's
quickly
figure
out
the
next
step.
Instead,
those
few
moments
where
you
are
synchronous,
it
is
purely
devoted
to
you
know
the
plan.
A
You
know
where
we
want
to
go.
How
do
you
want
to
build
it
because
ultimately
you're
the
ones
building
it?
So
this
is
the
most
important
step
for
you
to
determine
your
workload.
How
you
want
to
work
those
kinds
of
questions,
kind
of
positioning
it
that
way,
has
really
enabled
engineers
to
feel
empowered
to
jump.
In
especially,
I
mentioned
the
history
section.
This
is
the
perfect
example
of
it
seems
like
it
should
be
easy
because
we
have
it
everywhere,
but
it's
actually
technically
very
difficult.