►
From YouTube: Plan | Weekly Stage Sync 2022-05-11
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
try
to
pre-amp
some
questions,
but
please
add
any
questions
you
have
so
yeah.
I
realize
there
are
pros
and
cons.
However,
one
of
the
pros
is
that
when
you
have
vertical
integration
like
this
planning
should
be
more
efficient
and
that
the
work
that
we
plan
should
be
more
sustainable.
In
the
long
term,
we've
already
started
handing
over
team
members,
so
everybody
affected
already
knows.
A
We've
also
started
with
triage
issues,
planning
tools,
but
team
pages
and
bamboo
will
take
a
bit
longer
and
as
yet,
there's
currently
no
plan
for
full
stack
engineering
roles
just
for
full
stack
teams.
B
Yeah
more
in
the
the
formulation
is
it
like
it
is
currently.
The
key
word
here
is
like:
are
we
moving
towards
that
on
the
engineering
side
or
not,
because
that,
at
least
on
my
side,
I'll
involve
quite
a
bit
of
a
learning
curve
on
the
on
the
front-end
things
of
of
engineering
so
yeah?
I
was
just
like
I'm
curious
if
there
is
any
discussion
in
that
sense,
where
yeah
it's
more
on
on
management,
stuff,.
C
I'm
just
I'm
just
joking
okay,
so
I
can.
I
can
take
the
first
attempt
at
that.
No,
I
don't
think
it's
I
I
don't
think
like.
I
haven't
heard
of
any
plans
in
and
even
the
long-term
future
that
we
would
move
to
full
stack
roles
or
full
stack
engineering
roles.
C
I
have
my
thoughts
on
full
stack
roles
in
the
I
think
I
mean
both
sides
have
become
so
complex
that
it's
hard
to,
in
my
opinion,
it's
hard
to
be
really
good
at
both,
but
we
also,
we
do
have
some
full
stack
engineering
roles
within
the
organization
and
that
hasn't
really,
I
don't
think,
expanded
beyond
like
the
initial
teams
that
implemented
those,
maybe
with
the
exception
of
single
engineering
groups,
but
that
was,
I
think,
like
going
into
the
going
into
the
creation
of
those
types
of
teams.
C
It
was
known
that
they
wanted
to
get
more,
and
it's
not
just
full
stack
on
the
engineering
side
like
it's
also
they're
looking
for
people
with
skill
set
skill
sets
outside
or
people
that
want
to
do
stuff
outside
of
engineering.
Also,
so
no,
I
don't.
I
don't
see
it
expanding
towards
the
the
the
roles
that
we
have
within
teams.
I
think
we'll
always
have
specialties,
especially
within
the
deaf
sub
department,.
A
A
B
Yeah,
I
think
we
have
a
couple
who
who
do
dive
in
both
front
and
back-
and
here
I
would
refer
to-
I
think,
helium
and
heinrich-
and
maybe
someone
else
that
I'm
missing.
But
I
think
that
those
two
are
someone
who
I've
seen
more
frequently
than
than
me
that
myself
doing
doing
stuff
on
both
front
end
and
back
ends.
A
B
Technological
stack
that
we
have,
I
think
it
would
go
more
specialized.
I
can
see
like
in
other
instances
where
you
usually
know
chaos
on
the
back
end
right.
There
kind
of
feels
more
of
a
environment
for
for
full
stack.
Who
can
do
it
feels
kind
of
it's
not
the
same,
but
it
feels
closer
to
having
a
full
stack
engineer
in
in
like
where
you
use
gs
both
on
backhand
and
front
end,
but
yeah
yeah.
I
can
only
speak
for
myself.
It
will
be.
B
B
How
do
you,
how
do
you
both
feel
as
manager
managers
transitioning
to
full
stack
managers
because,
like
on
gitlab,
we
do
have
a
part
of
this
technical
kind
of
responsibility?
I
would
guess
for
the
managers
as
well:
it's
like
not
purely
a
people's
managers
right.
It
does
require
some
level
of
technical
detail
and
technical
understanding
of
stuff.
Does
that
pose
to
you
too
now
a
challenge
and
how
big
that
would
be.
A
But
the
main
thing
I'm
concerned
about
as
an
em
is
quality
in
the
sense
of
like.
Are
we
keeping
regressions
under
control?
Is
the
code
secure?
Are
we
estimating
properly
and
meeting
our
estimates
more
than
like
the?
I
think
when
it
comes
down
to
judging
like
the
quality
of
the
code,
that
should
be
done
on
code
review
and
anyway,
there
are
some
metrics
that
can
give
you
an
indication
of
whether
you're
trending
in
the
right
direction
in
the
wrong
direction.
A
They're
not
perfect,
but
like
mean
time
to
merge,
would
be
one
yeah,
so
I
think
there
there
are
a
couple
of
levers.
You
can
pull
to
sorry
levers
you
can
pull
to
that
are
like
consistent
between
front
end
and
back
end
right,
but
yeah
like
it's
definitely
gonna
be
a
challenge.
I'm
not
gonna
pretend
I
did
some
backbone
js
professionally
back
probably
over
a
decade
ago.
I
don't
know,
I
don't
know
if
that
qualifies
me
at
all
I'll
leave
that
to
the
front
end
engineers
to
decide.
C
It
does,
I
mean
backbone,
is
pretty
foundational,
it
gives
you
enough
experience
in
javascript
to
to
to
it
gives
you
enough
to
know
essentially
but
yeah
from
my
side
pretty
much
the
same
as
as
john
like
yeah.
I
know,
and
I
mean.
C
As
I've
been
and
I'm
on
the
the
front
end
side
of
things,
I
don't
I'm
not
the
the
most
talented
front,
end
engineer,
I
don't
I
don't
know
nearly
as
much
as
the
front-end
engineers
on
the
team.
C
C
It's
essentially
the
same
thing
or
the
plan,
for
me
at
least,
is
essentially
the
same
thing
that
I've
been
doing
on
the
front
end
where
a
lot
of
it
is
partnering
with
or
a
lot
of
it
is
going
to
be
partnering
with
you
all
and
when
you
do
have
questions
on
on
back
end
implementation,
just
knowing
knowing
who
to
to
go
to
for
for
the
answers
that
you
all
need.
C
So
I'm
I'm
excited
about
the
change
primarily
because
it
allows
me
to
kind
of
focus
on
a
single
group,
and
then
it
allows
an
external
folks
if
they
need
any
if
they
have
any
technical
questions
for
like
project
management
or
even
product
planning,
they
have
kind
of
one
em
to
go
to.
C
They
have
one
one
kind
of
source,
so
I
think
it'll
it'll
prevent
a
bit
of
the
confusion
that
we
had
before,
where
people
maybe
weren't
sure
whether
to
go
to
myself
or
jake
or
myself
or
john.
E
So
I
I
dropped
out
for
the
first
couple
of
minutes
here
after
I
joined
so
maybe
you've
explained
it
and
you
know
if,
if
so,
I
can
just
go
and
watch
the
recording,
but
so
just
to
make
sure
I
understand
the
change
for
non-engineers
so
like
for
myself,
for
example,
or
alexis
or
nick
what
is
changing.
What
is
going
to
be
new
is
that
you,
donald,
are
going
to
suddenly
be
managing
also
backend
engineers
and,
like
you
said,
be
responsible
for
one
group
and
the
same
but
reverse
for
john.
E
C
Yeah
and
no
we're
still
going
to
have
backend
and
front-end
engineers,
it's
just
going
to
be
so
a
team
is
going
to
involve
both
front-end
and
back-end
engineers,
so
the
team
in
that
sense
will
be
full
stack,
but
the
engineers
on
the
team
as
of
now
and
now
and
for
a
while
at
least
like
we
have
no
plans
of
bringing
in.
As
of
now
full
stack
engineers.
C
How
do
you
all
feel,
how
did
that
engine
engineers
feel
we've
all
kind
of
known
or
been
told
individually
for
a
bit
now?
How
are
you
all
feeling.
B
I
think
it
sounds
good
to
me
in
the
perspective
that,
like
we,
one
doesn't
have
to
go
to
two
managers
now
to
coordinate
stuff
for
a
given
feature
set
or
for
a
given
like
group
question.
So
I
I
think
there
is
some
efficiency
to
be
had
there
from
at
least
that
perspective.
So
yeah.
B
B
I
know
that
there
are
already
other
teams
that
are
doing
that
right,
like
I
think,
in
manage
or
somewhere,
and
now
that
I
think
that
like
do,
we
have
any
kind
of
feedback
from
those
teams
in
terms
of
these
are
the
things
that
we
found
like
challenging
and
with
like
some
sort
of
a
retrospective,
in
that
sense,
from
people
like
moving
from
front
end
to
back
like
to
full
step
or
upward
the
other
way
around
right.
E
C
Yeah
manage
is
the
the
team
that
most
recently
switched
from
having
separate
teams
to
the
full
stack
teams
and
dennis
who
was
one
of
the
ems
that
went
through
that
transition
yeah
offered
to
to
help
us.
So
we
should
definitely
schedule
a
meeting
with
with
them.
C
B
Like
I'm,
I'm
wondering
this
transition
was
meant
as
trying
to
make
it
more
efficient
or
or
was
it
a
derivative
of
of
like
a
lack
of
engine
of
engineering
manager
so
like
like
there
is
a
deficit
of
engineering
managers,
so
it
kind
of
feels
both
like
making
it
more
efficient
right
for,
for
one
person
like
to
have
this
single
full
stack
teams,
but
also
like
you
kind
of
so
so
in
our
case,
you'd
think
you'd
need
like
four
managers
right
like
if
we
take
the
planning
and
the
project
management
groups,
and
then
you
also
divided
by
from
the
end
and
backend,
then
you
kind
of
want
to
have
four
managers
and,
and
in
this
instance
you
get
sort
of
two
managers.
B
Sorry,
I'm
just
like
curious.
Was
it
driven
by
by
the
by
the?
I
think
there
is
a
problem
with
the
hiring
not
only
not
like
not
on
gitlab,
but
in
general
in
software,
what
I've
heard
of
in
chats
being
discussed.
So
I'm
wondering
if
that's
one
way
to
kind
of
address
this
problem
with
hiring
or
or
it's
not,
that.
A
Yeah,
I
don't
think
it's
because
of
that,
like
I'll
split
the
question
there's
definitely
something
going
on
in
hiring
not
with
it
in
the
market
generally,
like,
I
have
to
say,
like
having
just
hired
for
the
team,
I
didn't
find
it
as
difficult
as
I
thought
I
was
gonna
find
it
just
from
what
I
know
about
the
market.
A
That's
not
why
we
did
this,
though
I
think
in
the
end,
we'll
still
need
in
order
to
make
our
plans
in
the
long
term,
we'll
still
need
roughly
the
same
number
of
managers
and
we
still
have
to
have
the
same
maximum
report
to
manager
ratio
which
is
currently
maxed
out
for
donald
and
I
anyway,
but
that's
okay,
temporarily
so
yeah.
I
wouldn't
say
it's
because
of
that
we
just
with
jake
having
left
when
he
did.
B
C
So
yeah
we
still
have
jake's
backfill
we're
still
going
to
hire
for
that
role.
There's
still
conversations
on
beyond
that.
What
we're
going
to
do
beyond
that?
C
If
we're
going
to
bring
on
try
to
bring
on
another
vm,
I
don't
think
we
have
the
it's
called
the
head
count
allotment
for
for
a
fourth
em
as
of
now,
but
there
has
been
a
lot
of
conversations
with
with
tim
and
leadership
on
adding
an
additional,
but
for
now
we're
just
looking
for
jake's
backfill
and
then
once
we
hire
that
role,
we'll
figure
out
what
we're
going
to
where
they're
going
to
kind
of
sit.
C
Sorry
that
that
was
my
understanding,
john,
is
that
what
yours
is
to
that
we
hired
a
jake's
backfield
now
and
then
we
try
to
add
a
another
em
in
the.
I
don't
know
this
year,
but
sometime
in
the
short
term,
future.
F
I
was
just
going
to
add.
I
think
that
this
will
actually
make
collaboration
a
little
bit
more
efficient,
just
so
like
from
a
product
person.
I
have
had
to
coordinate
with
two
different
ems
across,
like
everything
and
so
just
being
able
to
work
with
one
vm
to
do
some
planning
and
project
management
stuff.
I
think
I'm
excited
to
try
that
out.
So.
A
Yeah,
and
also
like
in
terms
of
planning
full
stack
work
right
like
if
we're
planning
a
full
new
feature,
I
think
it'll
be
more
efficient
and
that
you
know
it
doesn't
have
to
go
through
like
like
back
end
engineer
speaks
to
me
and
then
I
speak
to
donald
and
donald
speaks
to
one
of
his
reports
and
so
on
back
and
forth.
Until
you
know,
we
figure
out
how
to
plan
a
piece
of
work
so
that
everything
aligns
properly
and
the
back
end
is
done
in
time
for
the
front
end
and
so
on.
A
G
Yeah,
so
I
have
already
linked
to
the
conversations
that
we
have
here.
One
is
basically
so
what
we
are
planning
to
do
this
release
is.
We
are
updating
the
styles
for
the
state
badges
across
all
issues
that
includes
issues,
merge,
requests,
epics
and
test
cases,
and
we
are
basically
adding
an
icon
representing
the
issuable
type
within
the
badge
itself,
along
with
the
style
of
the
badge
to
use
gitlab
ui
instead
of
custom
styles.
Now
the
there
is
this
conversation
around
whether
to
put
tooltips
or
not.
G
If
we
want
to
put
tooltips,
then
what
would
be
the
ideal
text
that
we
put
there
for
each
state
types?
So
I've
already
linked
the
dmr
in
which
the
changes
are
there.
It
has
a
lot
of
screenshots
as
well
of
how
it
looks
right
now
and
whether
we
want
to
go
ahead
with
the
tooltips
or
not.
G
G
Up
so
alexis
you
want
to
yeah.
H
I
was
kind
of
just
like
they
look
good
good
job.
I
think
yeah.
We
could
totally
add
those
as
like
a
next
iteration.
Maybe
we
could
look
a
little
bit
kind
of
like
audit.
What
states
we
have
available
like
archived,
make
sure
those
make
sense.
H
Maybe
at
some
point
we
want
to
revisit
requirements
and
think
about
how
we
might
you
know,
look
at
that
as
well,
and
then
there's
some
things
like
the
test
case
icon
and
a
few
other
things
that,
like
you,
may
have
to
revisit
those
as
well,
because
I
don't
think
we
have
states
for
all
of
our
like
quote-unquote
work
items
available
right
now.
So
I
don't
you
know
we
don't
have
like
a
archived
test
case
icon,
for
example,
so.
G
Is
awesome
yeah,
so
for
test
cases
I
reuse
the
existing
test
case
icon
for
both
open
state
and
archived
state,
so
yeah.
We
will
eventually
have
to
update
the
icon
there,
but
yeah.
G
We
don't
want
to
include
tooltips,
at
least
in
this,
mr,
so,
given
that
this,
mr
is
already
large,
and
I
already
got
the
review
started,
because
we
only
have
two
days
for
the
seminar
to
be
merged.
So
I
didn't
want
to
wait
further
on
having
a
decision
regarding
tooltips,
like
which
particular
text
we
want,
because
we
had
a
lot
of
opinions
both
from
create
team
as
well
as
our
team.
G
So
I
wanted
to
basically
given
more
time
on
what
tool
tip
we
want
to
go
with,
and
for
now
we
can
go
with
just
the
badge
ui
updates
and
in
in
15.1,
once
we
have
the
decision
in
whether
we
want
to
keep
tooltips
or
not,
we
can.
H
I
don't
know
what
the
the
dog
liked
that
decision
yeah.
That
sounds
good.
I
think
that's
fine
and,
like
I
said
we
can
kind
of
think
a
little
bit
higher
level
too.
But
I
think
this
is
a
really
nice
iteration
towards
more
guidance
with
the
state
changes
and
the
icons.
So
it's
awesome,
gabe
can't
read
so
gabe
or
john.
Whoever
wants
to
talk.
F
Well,
I'll
just
verbalize,
I
think,
it'd
be
really
cool,
because
eventually
we're
going
to
have
sort
of
different
statuses
within
each
state
and
it'd
be
really
nice
just
to
be
able
to
click
on
that
to
change
the
status
eventually.
So
like
there's,
no
interface
right
now
for
marking
something
as
a
duplicate
for
other,
like
the
other
close
statuses
that
make
sense.
F
There's
only
just
one
open
state
but
they're
sort
of
actually
sort
of
different
statuses
for
closed
already
in
terms
of
moved
duplicate
and
that
sort
of
thing-
and
I
don't
know
if
all
of
them
belong
there,
but
switching
between
like
open
close,
would
be
really
nice
from
that
area
too.
I've
seen
a
lot
of
products
to
do
that,
and
once
we
have
more
statuses,
it'd
be
cool.
That
was
also
like
an
interactive
thing.
H
No,
I
like
that,
like
I've
been
thinking
that
as
well
gabe,
and
especially
it's
like
you
said,
if
we
get
more
statuses
or
for
states
like
you
could
just
change
it
from
to-do
done
up
there.
That
kind
of
thing
would
be
interesting.
I
think
that's
what
users
expect
and
one
thing
I've
seen
in
a
lot
of
research
studies.
H
Users
want
to
go
or
participants
want
to
go
to
the
header
for
things
like
confidentiality
as
well.
So
when
I
say
like
hey
change
this
issue
to
confidential,
they
always
go
to
the
header.
So
I'm
thinking
like
those
kind
of
status,
things
that
could
be
interesting
to
have
up
there
as
a
control
as
well.
F
Yeah
nick-
and
I
were
nick
was
not
me,
but
mainly
nick
was
exploring
doing
like
a
new
action
bar
on
the
top
for
the
new
work
item.
Ui.
To
put
some
of
those
controls
up
there,
so
that'd
be
a
cool
thing
for
y'all
to
slap
onto.
A
Promoted
to
epic
is
another
one,
another
interesting
state
for
closed
issue
which
won't
be
around
forever.
I
guess
because
we'll
get
rid
of
it
when
we
have
work
items,
because
they'll
literally
just
be
promoted
to
epic
and
it'll
be
the
same
work
item,
but
it
is
in
the
meantime
like
something.
That's
like
a
little
painful.
That's
not
my
item.
A
The
the
my
item
was
just
a
brain,
thump
yeah,
one
of
the
things
that
really
like
I
spend
way
too
much
time
doing,
is
scrolling
to
the
bottom
of
mrs
to
find
out
when
they
were
merged,
so
it'd
be
really
cool
if
the
tooltip
had
the
date
at
which
the
mr
was
merged,
so
I
didn't
have
to
do
that.
Just
a
thought.
F
I
I've
always
found
it
kind
of
strange
how
we're
airing
our
grievances
about
the
design
that
the
created
by
is
so
prominent
like
it
takes
up
a
big
part
of
the
real
estate
and
that
information
is
not
always
uber
relevant,
especially
here
at
gitlab,
where
some
issues
that
we're
working
on
are
like
two
years
old
right
like
who
wrote
it
initially
is
less
relevant,
it's
more
about
like
who's
assigned
to
it.
Now
who's
been
the
latest
person.
That's
made
an
update,
so
that's
also
something
to
consider.
H
Yeah,
I
think
annabelle's
and
I'm
helping
her
with
some
of
this,
but
with
the
beautify
effort
going
on
this
milestone,
she's
kind
of
just
like
tinkering
on
a
few
things,
especially
with
mrs
and
then
we're
also
looking
into
some
mr
redesign
stuff,
so
awesome
feedback
and
thanks
for
adding
notes,
melissa's
trying.
D
Yeah
yeah,
thank
you,
hey
everyone,
so
I
just
figured
this
would
be
a
good
time
to
maybe
discuss
this.
I
already
talked
to
you
donald
about
it.
I
still
feel
like
we
don't
have
a
clear
plan
on
how
to
do
this.
I
mean
I
know
we
have
been
doing
differently
before
and
I
think
the
reason
why
we're
discussing
this
so
much
is
because
we
want
to
do
it
better.
D
This
time
I
guess
so
yeah
I
mean
donald
proposed
an
mr,
which
has
one
of
the
ideas
of
how
we
would
be
able
to
do
this,
so
I
wanted
to
get
feedback
from
more
people
on
on
what
do
you
all
think?
We
all
also
discuss
a
little
bit
with
the
game
at
some
point,
but
some
of
the
ideas
we
have
are
like
should
we
well
the
proposed
idea
from
donald's.
D
Mr
is
what
if
we
create
a
separate
future
flag
for
things,
we're
talking
about
working,
the
work
items
feature
flag,
and
so
the
idea
is
what,
if
we
create
a
new
feature
flag
for
things
that
are
more
stable
and
kind
of
more
ready
to
be
rolled
out
to
a
general
audience
into
the
new
facts.
So
we
can
at
some
point
enable
that
one
by
default-
I
guess-
or
maybe
not
even
that,
but
simply
add
more
people.
I
mean
enable
it
for
more
groups
and
then
make
the
feature
more
generally
available.
D
At
some
point,
I
guess,
while
still
leaving
the
some
code,
especially
front-end
code
on
the
original
feature
flag,
which
will
live
longer.
I
guess
but
yeah
as
we
were
discussing
in
the
issue.
I
linked.
That
might
not
be
a
a
good
idea,
especially
because
then
we
would
have
dependency
between
the
front
end
and
the
back
end.
I
mean
if
we
are
planning
to
release
some
things
into
the
into
the
new
feature
flag,
especially
back
and
stuff.
D
Then
it
would
mean
that
for
the
future
to
work,
we
would
need
to
enable
both
future
flags
at
the
same
time,
and
if,
for
example,
we
enable
only
the
front
end
one
then
it
would
break
because
the
back
end
won't
send
the
right
responses,
because
it's
also
behind
the
feature
fire
so
yeah.
That's
so
not
sure
if
anyone
else
has
some
ideas
on
how
we
should
roll
this
out.
D
This
time
I
mentioned
once
that,
perhaps
one
thing
we
could
do
is
like
kind
of
stage
out
the
the
work
we're
doing,
for
example
in
work
items.
Let's
say,
for
example,
we
have
reached
at
this
point
we
have
gathered.
I
don't
know
a
set
of
features
that
are
stable
enough
to
be
released,
so
maybe
new
things
like
in
this
case,
the
widget
implementation
of
fields-
might
start
development
under
a
new
feature
flag.
Something
like
that.
So
features
are
like.
D
I
don't
know
grouped
under
the
the
same
thing
and
then
maybe
work
items
which
is
the
current
feature
flag
at
some
point
can
be
made
defaulted
to
on
and
at
some
point
removed.
While
we
still
have
the
new
stuff
under
another
feature
flag,
I
mean
that's
one
idea
I
have,
but
I'm
not
sure
that's
what
I
wanted
to
discuss
here.
If
anyone
else
has
ats.
D
B
So
that's
that's
a
separate
piece
of
work
and
then
in
code
we
can
do
if
this
feature
flag
and
this
feature
flag.
That's
that's
where
you
can
kind
of
roll
out.
The
newer
thing
does
that
does
that
make
sense
because
like,
but
obviously
it
all
starts
at
the
like
the
found
defining
the
boundaries?
B
What
does
this
feature
flag
actually
mean
right?
What
what
does
this.
B
Like
showing
to
the
user
everything
like
from
what
what
is
meant
by
a
vertical
slice
like
the
front
and
the
back
end,
everything
does
define
they
like
the
the
apis.
That
needs
to
be
there.
So
everything
is
covered
by
one
feature
flag
and
then,
if
we
need
to
extend
that
with
any
kind
of
new
functionality
or
adding
new
functionality,
that
should
go
under
a
different
feature
flag
so
that
that
we
do
not
prevent
the
initial
feature
flag
being
rolled
out.
Just
because
the
new
feature
flag
is
not
like.
B
The
new
functionality
is
not
yet
ready
where
it
is
adding
some
some
stuff
to
that.
D
Right
and
another
alternative
yeah,
it
makes
sense
one
thing,
and
I
think
we
just
did
discuss
this
approach
and
yeah.
I
think
the
only
con
was
the
same,
as
I
already
mentioned
that
we
would
still
have
dependent
feature
flags
right.
I
mean
for
some
features
we
would
have
to
have
both
enabled
for
them
to
work.
So
that's
a
con,
but
one
thing
we
could
do.
D
There
is
instead
of
doing
this
future
flag,
and
this
feature
flyer
simply
write
the
new
feature
in
a
way
that
we
use-
or
instead
you
know
like
if
this
new
feature
uses
a
new
feature
flag
check
for
this
feature
flag,
but
if
it
also
requires,
I
don't
know,
a
mutation
that
was
previously
behind
the
the
older
feature
flag.
D
We
enabled
that
mutation
for
the
older
feature
flag
or
the
new
future
flag,
if
enabled
so
if
either
of
those
is
enabled
the
mutation
is
available.
So
by
using
or
I
mean,
we
would
have
to
to
write
the
code
with
that
logic
in
place,
but
then
we
wouldn't
be
dependent.
I
mean
one
future
fly
wouldn't
be
dependent
on
the
other
and
also
just
two
other
two.
I'm
sorry
go
ahead.
If
you
have
something
else
to
add
here,.
I
I
just
want
to
understand
the
intent
of
the
multiple
features
flags
right
since
new
to
the
approach.
So
in
layman
terms,
I'm
trying
to
understand
what
you're
trying
to
do
basically
there's
ongoing
development
for
work
items
which
we
intend
to
keep
behind
a
feature
flag,
and
then
some
of
it
will
become
beta
ready,
but
not
ga
ready,
and
we
want
to
keep
that
behind
a
feature
flag
but
then
also
have
another
one
for
sort
of
like
in
development
things
within
a
milestone.
Am
I
understanding
that
correctly.
D
Able
to
make
some
things
available
at
some
point,
but
we
continue
to
drag
stuff
because
we
continue
to
develop
new
stuff
on
the
same
feature.
So
we
are
not
able
to
to
release
the
the
the
more
stable
and
older
things,
but
that's
what
I
was
going
to
add
before
I
mean
what
we
have
been
doing
so
far.
Is
I
don't
know
with
what
we
did
with
iteration
cadences
right?
D
We
had
a
single
future
flag
and
simply
waited
for
for
the
whole
thing
to
be
more
mature
to
enable
it
that's
what
we
have
been
doing
so
far.
I
guess
so.
That's
another
alternative.
D
I
guess
what
melisa
just
said
is
that
the
main
reason
why
we're
considering
doing
something
new,
that's
yeah,
that's
the
thing
I
mean
if
we
should
do
something
like
that,
and
if
not
because
the
alternative
is
to
continue
to
have
one
a
single
feature
flag,
and
then
I
mean
donald.
I
think
the
main
problem
was
what
the
dependency
we
have
with
the
front
end
right,
I
mean
because
well
even
with
multiple
or
a
single
feature
back,
the
front
will
continue
to
have
to
wait
for
an
entire
milestone.
C
What
does
that
entail
like
work
items
is
going
to
be
tasks
and
feature
and
moving
epics
like
you
can
consider
everything
a
work
item,
so
does
that
mean
we
like?
I
think
the
original
intent
was
to
use
the
work
items
feature
flag
for
for
a
very
long
time,
for
everything
that
you
can
consider
a
work
item.
C
But
then,
if
we
do
that,
the
problem
we
were
trying
to
solve
was
how
do
we?
How
do
we
move
smaller
features
within
work
items
to
to
kind
of
to
be
allowed
to
be
tested
by
more
users
and
then
to
get
into
production?
C
So
I
think
this
approach
that
melissa,
wrote
there
is
is
one
of
the
proposals
to
do
this.
Another
is,
I
think,
what
mario
and
alexandria
are
talking
about
in
that
just
creating
a
new
feature
flag
for
all
of
these
features.
So
right
now
the
thing
we're
trying
to
do
is
get
get
tests
to
get
tasks
turned
on
and
then
defaulted
to
on.
C
So
we
could
create
another
feature:
flag
for
four
tasks,
move
everything
that
we
have
right
now
into
tasks
and
then
turn
on
that
feature
flag
for
like
gitlab.org
or
for
all
of
gitlab.com,
or
we
could
right
now
because
I
think
the
only
thing
that
is
in
work
items
the
work
items
feature
flag
right
now
is
everything
task
related
like
I
don't
think,
we've
added
any
description
based
stuff,
so
we
could
technically
just
kind
of
take
that
feature
flag
for
tas
and
then
create
a
new
feature
flag
for
upcoming
work,
item
types
or
upcoming
features.
C
Just
if
we
do
that,
like
mario
stated
we
have
to,
we
have
to
be
really
good
about
vertically
slicing
because
we
don't
want
to
get
into
a
place
where
maybe
having
one
dependency
on
a
future
flag.
Isn't
too
bad.
But
if
we
start
building
on
top
of
that
and
have
like,
if
there's
ever
any
delays
in
the
in
the
in
the
root
feature
flag
that
cause
us
to
or
and
we're
working
on,
other
features.
It'll
just
build
up,
so
we
want
to
make
sure
not
to
do
that.
D
So
this
should
also
be
available
on
the
new
feature
flag.
So
for
them
making
a
request
to
the
back
end
with
only
the
new
feature
flag
enabled
should
fail,
so
it
should
be
at
that
moment
that
they
erase
that
we
should
add
another
check
for
the
mutation
on
the
vacuum.
Something
like
that.
I
I
mean
talking
about
the
ore
thing.
Like
is
tasks,
work,
work,
item,
task,
feature,
flag,
enabled
or
is
widgets
work
items
feature
flag,
enabled
so
enable
this
mutation
for
either
of
those
cases
so
yeah.
I
Something
that
I
was
thinking
about
is
just
the
concept
of
moving
away
from
really
long-lived
feature
flags.
They
get
hard
to
manage
right,
and
then
we
have
this
really
long
package
of
value
at
the
end,
right
versus
more
incremental
changes
and
then
easier
feedback.
I
So
I
think
I
now
realize
alexandria.
You
were
saying
sort
of
like
what
I'm
saying,
but
in
different
ways,
right
of
just
like
being
more
intentional
about
how
we
break
up
the
phases
of
work
so
that
we
don't
need
to
have
these
long
live
feature
flags.
Maybe
it's
two
releases
right
ambitiously
like
wanting
it
to
be
like
in
a
single
milestone.
I
We
have
something
that
is
releasable
right
on
its
own
and
moving
more
toward
thinking
about
that.
Now
that
we're
past
this
first
phase
of
work
items
so
that
we
don't
end
up
in
a
situation
where
we
have
multiple
feature
flags
to
like
enable
things
right
and
it's
difficult
for
to
manage
for
us
and
it's
difficult
for
users,
then
to
discover
and
get
the
value
out
of
the
work
that
we've
been
doing.
B
Obviously
it's
it's
harder
to
do,
but
yeah!
That's
where
I'm
at
right
now.
B
D
Yeah
yeah,
that's,
it
will
be
very
small
and
I
have
at
the
right
time
for
for
us
back
in
the
front
to
be
able
to
deliver
on
the
same
mods.
A
The
actually
on
that,
so
the
crm
feature,
that's
not
going
to
be
released
in
this
milestone.
We
ran
into
exactly
this
problem
and
the
decision
was
what
the
consensus
was
that
we
could
release
the
feature,
because
it's
a
brand
new
feature,
and
we
would
simply
accept
that
during
the
deployment
some
customers
might
experience
unexpected
behavior
as
long
as
we
could
quantify
the
unexpected
behavior
right.
A
So
in
a
multi-version
compatibility
issue,
if
it
was
going
to
create
a
data
integrity
problem,
then
we
couldn't
proceed
right
example
of
that
would
be
the
rollout
of
forget
specifically,
but
it
was
something
that
generated
tokens,
but
the
reader
of
the
tokens
was
changed,
and
so
the
tokens
that
were
generated
were
invalid
and
we
ended
up
with
invalid
data
in
the
database
indefinitely
and
that
caused
problems.
However,
like
it
really
depends
on
the
feature,
is
what
I'm
getting
in
terms
of
feedback.
It
depends
if
it's
a
brand
new
feature,
then
it's
possible.
A
We
can
roll
it
out
in
one
release
and
simply
accept
it.
The
other
way
is
defensive
programming,
either
on
the
front
end
of
the
back
end
design
the
front
end
to
deal
with
the
fact
that
the
back
end
might
fail
or
the
fields
you're
looking
for
in
graphql
is
not
there
and
there
may
be
work
on
the
back
end
to
do
there
as
well
like
because
I
think
graphql
just
silently
fails.
If
you
ask
for
a
field
that
isn't
there,
so
maybe
there's
something
we
need
to
do
there
as
well.
A
And
the
third
thing
is
that
it's
a
misconception,
the
future
flags
actually
help
this
problem.
Anyway,
they
don't.
You
have
to
still
roll
out
over
a
large
deployment,
a
feature
flag
can
take
minutes
to
roll
light,
and
so
you're
still
going
to
have
some
nodes
with
the
new
front
end
code,
some
of
the
old
back
and
co,
and
so
on,
and
the
node
that
serves
your
front
end
code
doesn't
know
what
node
is
going
to
serve
the
requests
that
it
issues
whether
it's
got
the
new
code
or
the
old
code.
A
D
D
C
I
think
if
we
get
a
lot
of
the
the
core
work
item
functionality
in
now,
it's
going
to
make
it
a
little
easier
for
future
for
future
features
to
to
be
smaller
and
vertically
sliced.
C
It
may
all
so
what
do
you
think
with
the
description
work?
So
maybe
not
so
much
with
the
description
work,
but
in
future
widgets,
where
we're
using
the
architecture
we've
been
talking
about
in
yan's
poc.
C
D
D
Should
the
new
widget
implementation
be
already
under
a
separate
feature
flag
and
also
should
the
front
end
already
start
using
the
new
future
flag
for
for
things
that
are
already
under
development,
for
example,
if
we
wanted
to
release
something
on
the
next
iteration,
perhaps
for
example,
the
delete
task
mutation
is,
is
something
that
the
front
end
should
start
using
under
a
new
new
future
flag,
because
it
was
released
recently
in
150.
D
Something
like
that,
but
not
sure.
If
that's
what
you're,
seeing
and
also
we're
running
out
of
time,.
C
C
C
Okay,
so
I'm
going
to
start
treating
we're
going
to
start
treating
work
items
as
really
that's
work,
item
tasks,
but
I'm
not
going
to
change
the
name
of
that
we'll
just
work
on
like.
Are
we
at
a
point
right
now,
where
I
can
turn
on
the
work
items
feature
flag
for
a
larger
group
other
than
just
plain
stage.
I
turn
that
on
for
gitlab
org.
C
Okay,
marchands
is
read
only
so
we
can
call
it
three
minutes
early.