►
From YouTube: Plan group weekly meeting
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
I
was
to
be
here
for
the
next
couple
of
weeks,
actively
just
handing
over
and
making
sure
that
nothing
falls
through
the
cracks,
but
very
shortly.
Donna
will
be
just
fully
responsible
for
everything
that
that
touches
front
end
on
plan
and
yeah
with
that
Donald
I,
don't
know
if
you're
gonna
say
a
few
words.
The
team.
B
But
not
a
lot
of
not
everyone.
Obviously
so
I'm
Donald
nice
nice
to
formally
meet
everyone.
You
probably
I've,
been
lurking
kind
of
in
the
last
plans.
C
This
came
out
with
retro
for
11.7
I
think
talking
about
issues
to
work
on
so
like
you
know.
Why
is
that?
So
you
know
there
are
basically
two
ways.
We
could
look
at
this
because
the
hacker
one
program
became
public
in
December
and
before
that
I
think
it
was
still
ramping
up
being
invited.
Different
people
are
being
invited
to
it,
but,
like
you
know,
either
we,
oh
sorry.
Potentially
we
are
both,
but
you
know
two
different
mix
introducing
new
security
issues
that
we
then
need
to
go
back
and
fix.
C
So
you
know
we
release
a
feature
that
includes
a
security
issue.
They'd
have
to
go
back
and
fix
that
or
we
are
fixing
a
security
issues
that
were
already
there
that
either
weren't
reported
or
when
prioritized
previously.
So
in
that
issue,
I
took
a
look
at
the
last
six
milestones.
We've
worked
on
from
11.4
through
to
the
current
one.
C
So
obviously
the
caveat
is
that
if
we
have
introduced
security
issues
recently,
they
might
not
be
reported
yet
and
another
caveat
is
that,
because
we've
been
doing
so
many
security
issues
and
recent
releases,
we
haven't
been
doing
as
many
features,
so
we've
had
fewer
chances
to
introduce
security
issues
because
of
that,
but
in
general
looks
pretty
good.
You
know
one
of
them
had
version
2
point
something
some
of
them
are
just
literally
like
since
we
introduced
this
feature
which
has
been
in
get
lab
basically
forever.
C
You
know
it's
had
this
issue
which,
just
you
know,
either
wasn't
reported
or
wasn't
prioritized
before,
but
the
ones
from
the
11
dot
X
series-
you
know
we
haven't
had
any
of
those
reported
and
scheduled
in
the
last
three
months
and
the
majority
are
from
pre
get
lab
9.0,
which
was
like
two
years
ago.
So
that's
pretty
promising.
C
D
Thanks
Shawn,
so
I
just
wanted
to
give
a
heads
up
about
the
changes
that
are
coming
up
in
the
quality
team.
So
there's
a
new
person
who's
joining
us
this
coming
Monday.
His
name
is
Panama
and
he's
from
Netherlands
and
he'll
be
working
closely
with
the
plantain
he's
actually
be
dedicatedly
working
with
the
planting
and
so
I
think
some
of
you
might
have
known,
like
I'm,
actually
transmissions
transitioning
into
the
QA
manager,
role
for
the
depth,
sub,
Department
and
I
mean
the
angel
face
right
now.
E
F
E
If
you
click
on
Google,
the
okiya
orc
and
you
look
at
a
roadmap
which
I
know,
Kershaw
has
been
frantically
fixing
over
the
past
couple
weeks.
So
thank
you
for
shell.
It
looks
pretty
awesome
now,
in
my
opinion
and
I,
think
I
think
my
opinion
was
worth
something
because
I
look
at
this
like
every
day
so
I.
To
me
this
looks
pretty
amazing
right
now
and
I
wanted
to
mentioned
sorry.
The
same
thing
is
very
mean:
that's
yeah,
so
we
have
a
lot
of
things
that
we're
working
on
in
the
plan
area.
E
But
if
you
squint
your
eyes,
then
probably
have
to
organize
this
a
little
bit
better
or
maybe
we
need
some
more
features.
You
see
that
most
of
these
things,
at
least
for
the
next
couple
of
months,
are
not
new
things
in
the
sense
that
it's
continuing
to
be
making
incremental
improvements
on
what
we
already
have,
but
we're
not
inventing
any
new
same
object
or
really
feature
functionality.
I
would
say
this.
One
is
a
pretty
big
new
thing
manual
ordering
of
issue
lists,
but
that's
again
it's
not
new
UI.
E
Fundamentally,
it's
we're
not
inventing
any
new
abstraction
right.
It
seemed
like
this
one
there's
boards
it's
iterating
on
boards
is
entering
on
discussions,
iterating
on
portfolio
management
and
issue
management,
so
on
and
so
forth.
So
the
really
and
then
searches
is
going
to
create,
but
so
the
really
big
two
new
things
that
are
coming
down
as
we
hit
like
second
quarter
2019
or
calendar
years,
is
really
custom
point
loads,
which
is
key
value,
labels
and
value
stream
mapping.
So
these
are
the
really
two
big
things.
So
sorry.
C
E
So
that's
that's
really
confusing,
so
maybe
I
should
just
use
the
word
key
value
labels
instead
of
just
custom
fields,
so
I'm
gonna
just
delete
that,
instead
of
so
custom
fields
as
a
topic
is
something
or
as
a
problem
is
something
that
customers
really
want,
and
so
everybody
sort
of
knows
inherently
what
custom
fields
is,
but
our
first
stab
at
least
for
now.
The
plan
and
there's
still
actually
I,
think
some
debate
here.
E
Is
that
we're
going
to
design
key
value
labels
and
we're
going
to
use
labels
to
achieve
custom
or
solve
part
of
the
problems
that
custom
fields
claims
to
solve
so
key
value.
Labels
essentially
is
just
having
labels
and
and
making
formalizing
the
word
DevOps
:
to
become
a
first-class
citizen
logic
inside
your
lab,
so
that
if
you
have
DevOps
planned
and
you
cannot
have
DevOps,
create
or
DevOps
managed,
for
example,
and
so
that's
at
least
the
initial
concept
of
how
we're
going
to
do
adjust
the
problem
of
custom
fields.
E
So
what
we
thought
along
about
is,
should
we
do
this
or
value
stream
mapping?
First
and
and
I've
been
really
emphasizing
that
we
shouldn't
do
both,
because
these
are
both
pretty
big
changes
to
get
lab
and
I.
Don't
want
too
many
things
going
on
big
changes,
especially
because,
while
we're
doing
all
these
things,
we
still
have
to
move
forward
with
portfolio
management.
E
And
so
in
the
past
or
in
the
past
half
year,
we've
always
put
custom
fields
first,
because
it
seems
like
a
quick
win,
something
we
can
get
out
of
the
way,
but
really
value
stream
management,
especially
at
the
product
level,
has
become
it's
its
own
product
category,
first
of
all,
and
secondly,
as
I
mentioned
last
time.
And
secondly,
we
said
that
as
a
goal
as
an
okay
are,
we
need
to
make
strides
toward
I
forgot
exactly
what
it
is
I'll
link
to
it
later,
if
I
can
find
it,
but
essentially
we
need
to
make.
E
We
need
to
move
forward
in
that
particular
product
category.
Where
I
say,
custom
fields
belongs
to
project
management,
which
is
an
existing
category.
So
from
like
a
breadth
perspective,
we
need
to
make
some
and
we
need
to
move
in
value
stream
area
right
now
we
keep
saying
value
stream,
as
we've
been
talking
about
the
constant
value
stream
measure
for
over
a
year,
but
we've
essentially
have
zero
things
to
show
for
it.
In
terms
of
new
things,
I
mean
we.
E
E
We've
been
trying
to
shy
our
ways
ourselves
from
that,
because
we
think
that's
too
much
configuration,
but
that's
clearly
something
that
customers
want,
and
it's
also
necessary
re-argue
for
VSM,
because
we
need
those
custom
stages
in
order
to
articulate
a
feature
like
somewhere
like
this,
like
Annabelle
created
a
while
back,
like
I,
think
like
half
a
year
and
they're
almost
on
to
say
that
you
know
you
have
these.
You
know
say
each
stages
in
your
organization
and
you
want
to
customize
them,
and
you
want
to
articulate
what
is
the
end
cycle
time
for
that.
E
So
right
now
and
Gila
we
have
cyclone
analytics,
but
that's
just
not
enough
for
customers,
because
we
can't
assume
that
they're
they're
already
using
issues
and
murdered,
plus
or
even
if
they
are
and
they're
using
everything
in
Gil
lab.
They
have
the
intense
cycle
time,
but
do
they
really
care
about
how
much
time
you
spend
in
issues
rich?
Does
merge,
request,
first
to
say
pipelines
or
do
they
do
they
care
about
more
specifically
the
stages
that
they
customize
and
care
about?
E
E
E
You
know
realistically
I,
don't
expect
us
to
be
writing
any
code
in
1110,
but
you
know
how
we've
been
working
very
well
in
planned,
at
least
in
my
perspective-
and
you
know,
engineering
managers
can
can
then
feedback
and
especially
if
you're
tracking,
certain
metrics,
but
the
fact
that
we
are
starting
to
like
if
we
have
an
issue,
scoped
and
designers
are
talking
about
in
engineers
or
talking
about
in
collaborating
and
thinking
about
it
and
writing
down.
Words
and
pictures
I
think
that's
a
success
for
that
milestone.
E
So
so
that's
the
caveat
of
putting
in
1110,
and
so
this
is
the
initial
concept
yeah
of
having
you
know
some
states
that
you
can
configure
and
you
can
go
through
them
and
then
it
can
go
to
eventually
the
state
goes
to
close.
So
the
initial
concept
here
is
that
we're
gonna
have
to
have
some
state
transition
scheme
right
so
workflow
state,
and
but
what
I
don't
want
to
do
is
break
everything
in
good
lab
automatically
right.
So
if
you
right
now
and
Gil
lab,
there's
two
states,
there's
open
and
closed
right.
E
So
if
you
the
moment,
you
introduce
additional
ones,
you're
gonna
break
everything
in
your
lab,
like
you
know,
just
showing
the
word
open
here
right
or
you
know,
Kevin
closed
issues
or
merge
request
that
closed
issue.
So
how
what's
a
way
to
not
break
everything
with
one
feature:
release
and
I
I'm,
you
know
open
to
more
ideas,
but
I
think
this
is
a
good
way
to
do
it,
which
is
the
way
we
do.
E
It
is
that
the
workflow
states
they're
not
on
the
level
of
open
versus
closed
states,
are
oh
there's
only
ever
going
to
be
to
issue
states
open
and
close
and
workflow
states
are
workflow
stages,
whatever
we
call
them
are
going
to
be
quote
unquote
like
sub
States
or
sub.
Whatever
of
sorry
I
have
to
take
this
call,
you
guys
can
keep
looking
at
it.
C
C
C
G
E
Okay,
yeah
yeah,
so
thanks
for
holding
folks,
this
is
my
son's
take
care
calling
so
nothing
serious.
So
that's
why
I
can
keep
keep
talking
so
so
yeah.
So
so
that's
that's
what
I'm,
showing
here
and
I,
think
that's
a
good
design
again
if
you
have
better
ideas
right
now,
please
just
shout
or
comment
issue
later.
If
you
have
better
ideas,
thank
you.
Go
ahead,
shot!
Sorry.
C
This
this
is
not
directly
related,
but
one
relevant
and
sort
of
concept
from
juror
is
that
you
have
an
issue
status
and
you
have
an
issue
resolution,
but
resolutions
only
apply
to
close
statuses.
This
is
kind
of
the
opposite
of
that.
Where
a
workflow
states
only
apply
to
open
statuses
and
then
I
guess
we
can
add
resolutions
in
future
like
say,
close
right.
F
E
G
E
Exactly
exactly
and
that's
actually
super
relevant
John
as
I'm
gonna
highlight
a
couple
of
problems
and
what
I
think
are
good
solutions
are
probably
better
ones
related
to
exactly
that.
The
multiple
schemes,
as
you
mentioned,
like
I,
use
the
word
scheme
and
transition
scheme,
because
that's
what
Jared
calls
them
I
like
I,
think
when
I
used
it
like
five
years
ago
and
they're
over
confusing
right,
because
there's
like
all
this
level
of
indirection
but
but
to
wrap
up.
E
At
least
this
point,
I
wanted
to
again
emphasize,
like
John
said:
there's
only
ever
gonna
be
two
issue.
States
and
I.
Think
that's
crucial,
for
example,
like
I
want
this
to
be
at
the
Gila
ultimate
ear,
and
so,
if
you're
using
reg,
you
know
you
lab
and
you
tear
lower.
Then
you're
not
gonna.
Have
these
states
and
you
know,
you're
going
to
be
used
to
open
and
close,
and
the
moment
you
add
you
go
to
you
know
a
good
lab
ultimate
like
how
are
your
issues
gonna
behave
like
what
is
the
migration
gonna
be
like?
E
Is
everything
going
to
be
screwed
up?
So
I
think
this
is
a
relatively
safe
way
to
do
it,
because
it's
additional
the
sense,
like
the
information
architecture,
is
additional
and
it
doesn't
replace
anything.
So
I
think
this
is
a
pretty
safe
route
to
go
about
it.
But
again,
please
please
and
give
us
better
ideas
and
again
the
the
problem
to
be
solved.
E
You
know,
we
don't
expect
them
to
be
there
just
users
of
the
software,
and
so
in
particular
the
feedback
we
get
specifically
is
when
they're
using
issue
boards
to
do
workflows.
So
this
is
great
in
the
sense
that
your
lab
users
are
already
wanting
this
feature
and
Dennis
have
demonstrated
by
using
your
lab.
They
want
this
feature
because
we're
giving
them
your
lab
issue
boards
to
use
this
feature
with
labels
and
they're
really
struggling
and
it's
a
pain.
So
how
come?
E
Sometimes
when
I
transition
issue
on
the
board,
it
works
fine,
but
when
I
I
just
no
way
to
transition
an
issue
between
states
on
an
issue
itself,
you're
asking
me
to
remove
a
label
and
add
a
label:
that's
really
silly
and
people
are
asking
for
like.
Oh,
if
you're,
adding
a
board
label
then
treated
differently,
and
so
you
can
see
how
that's
really
really
messy
design.
E
It's
really
crazy
and
one
of
the
reasons
I
do
not
think
that
this
should
be
built
on
top
of
labels
because
of
all
that
messiness-
and
this
should
be
a
new
first-class
citizen
native
object.
So
keep
in
mind,
as
you
read
through
these
and
offer
designs,
those
are
the
underlying
problems.
Those
are
the
existing
feedback.
We
have
what
customers
saying
that
they're
already
using
this.
They
think
they
love
the
concept
with
the
board,
but
it
just
doesn't
work
good
enough
right
now
and
then
also.
E
Another
point
is
that
once
we
have
this
workflow,
then
we
can
create
a
board
whether
it's
at
the
project
or
group
level
and
I'll
get
to
how
that's
relevant
a
second
and
you
can
create
a
specific
type
of
board
that
doesn't
use
label
list
assignee
list
or
milestone
list
anymore
and
uses
workflow
state
lists.
And
then
you
can
say:
yep
I
want
this
scheme
and
then
I'm
done
and
then
the
board.
Is
there
right
away
and
there's
no
confusion
right.
So
that's
that's
yet
another
win
for
how
this
will
be
super
useful,
I'm.
G
Gonna
kick
their
please
please,
our
question:
do
you
imagine
that
these
stages,
workflow
stages
would
be
applied
if
someone's
doing
Kanban,
would
they
build
a
Kanban
board
with
these
as
workflow
stages?
Do
you
imagine
that
or
do
you
think
they
would
continue
to
use
labels
as
a
way
to
define
that
I
mean?
Is
it
in.
G
E
Yes,
I
would
I
would
I
would
definitely
I
mean
when,
when
you're
saying
comma
do
you
mean
like
it
goes
from
ready
to
development
to
review
and
then
there's
an
assumption
that?
Okay,
if
it's
in
the
development
stage,
it's
gonna
be
associated
with
the
engineering.
If
it's
in
you
know
review
our
testing
is
gonna
be
associate
with
get
yeah
like
yes,
I,
think
I.
Think
I'm
answering
my
own
question.
G
E
Has
the
problem
with
labels
that
we've
observed
in
in
customer
people,
it's
just
too
crazy
right,
there's
just
too
it's
just
too
flexible
and
we're
building
the
building
blocks.
That
sounds
dumb.
We're
we're
setting
up
the
building
blocks
so
that
we
can
have
features
on
top
of
this,
and
so,
if
we
have
the
concept
of
stages,
which
I
think
is
a
pretty
atomic
unit
of
these
workflow
processes,
we
can
build
so
many
things
on
thought.
We
can
build
with
limits
that
you
ping
me
on
earlier.
We
can
do
the
auto.
E
E
So
again,
when
you
look
at
JIRA
and
you
configures
things
like
projects
and
you'll,
have
these
things
called
transition
schemes
so
you're
defined
like
John
said
you
can
transition
States,
you
can
define
States
ABC
and
then
you
can
say,
like
my
transition,
seam
is
gonna,
be
a
goes
to.
B
goes
to
C
or
it
can
be.
A
goes
to.
E
C
goes
to
B,
R
can
be,
B
goes
to
a
goes
to
C
and
you
can
have
like,
like
a
bazillion
transition
schemes,
and
you
can
have
arrows
pointing
every
way
and
that
defines
what
are
allowable
transitions
between
any
given
state.
And
then
you
can
probably
have
cycles
and
probably
JIRA
will
allow
you
to
do
that
fine,
but
what
Gera
will
say
is
that
per
project
again.
E
This
is
like
Ivan
will
look
at
this
in
detail
recently,
but
from
what
I've
seen
in
the
past
per
project,
you
have
to
choose
one
specific
transition
scheme
and
to
me
that
makes
sense
right,
that's
a
good
design,
but
it's
it's
really
messy.
Sorry
I
again
have
to
take
this
call.
So
please
continue
talking
about
what
you
were
talking
about.
A
Have
a
question
for
Sean
I:
remember
previously:
we
work
on
something,
or
at
least
we
planned
on
working
for
something
regarding
tracking
label
changes
or
something
to
kind
of
do
this
tracking
for
military
management.
Do
we
ever
ended
up
doing
that
and
the
question
that
I
actually
have
is:
will
this
be
done
on
this
stages
as
well,
so
that
we
can
track
that
so.
C
Yeah
and
did
this
for
labels,
so
I
did
not
use
labels
for
it.
So
agree
we
have
parables,
but
we
don't
use
it.
I
am
imagine
we
will
do
the
same
tracking,
because
the
whole
reason
we
added
the
tracking
to
labels.
We
could
do
the
VSM
part
of
this,
but
I
don't
actually
know
what's
blend
yeah,
oh
yeah,
I
haven't,
haven't
looked
into
the
details,
but
I'm
pretty
sure
that
we
will
be
tracking
it
sure.
A
The
other,
the
other
comment
I
would
have
is
that
I,
so
part
of
me
is
already
thinking.
What's
the
limit,
a
UI
wise?
How
are
we
gonna
put
like
10
stages?
Cuz
people
make
mistakes
and
they
will
go
overboard,
but
that's
a
problem
for
designer
for
the
for
Annabel,
I,
guess
and
the
other
is
I'm
expecting
not
to
have
very
strict
rules
of
what
stages
can
transition
to
which
stages.
A
E
There's
there's
a
discussion
somewhere
I
forgot
where,
but
we
don't
want
to
make
this
enforced
yet
and
it's
actually
in
a
handbook
somewhere.
That
says
like
no
enforced
workflows.
I
was
like
the
product
principle,
so
we
technically.
We
need
to
change
that
if
we
want
to
even
make
this
enforced,
but
going
back
to
there's
only
two
states
open
and
close
right.
So
this
should
not
break
merge,
request,
closing
an
issue.
E
So
if
you're
in
one
of
those
earlier
states-
and
you
have
a
merge
request
that
closes
the
issue,
then
you
skip
the
stages
right
then
like
we
don't
want
to
enforce
that,
because
you
would
have
to
solve
that
problem
as
a
first
release.
Instead,
I
think
that
approach
would
be.
We
have
this
great
state
flow
diagram.
You
can
use
it
in
a
board
and
you
can
click
the
button.
E
So,
for
example,
we
could
enforce
it
technically
in
the
UI
by
saying
that
when
you
click
the
button
that
the
thing
you
can
transition
to,
it
will
only
give
you
the
one
that
makes
sense
like
to
me.
That's
a
design
detail
but
like
yeah
I,
agree
the
break
like
the
merge
request,
closing
issue
aspect,
yeah
or.
A
E
G
E
Clears
case
for
it,
yeah
John,
I,
don't
okay,
yeah
I
wanna.
Make
sure
that
that
that's
exactly
clear,
you
see
part
it,
but
it's
one
of
those
it's
great,
because
we
don't
have
to
decide
now
or
like
the
decisions
we
make
now
will
not,
but
will
not
be
that
test
from
and
providing
those
constraints,
whereas
the.
E
Like
if
we
do
a
constraint
now,
then
we
can't
we
can
do
the
reverse
right.
So
I
think.
That's
that's
why
it's
a
safe
approach
so
again
I
apologize
for
the
interruption
so
for
this
particular.
So
as
I
was
talking
about,
there's
all
those
schemes
and
gets
really
crazy,
but
I
think
what's
crucial
is
if
you're
looking
at
one
issue,
you
should
be
have
some
because
we
keep
thinking
about
it
or
at
least
what
I
kept
thinking
about
it.
E
Maybe
you
don't
I
kept
thing
about
it
or
from
an
issue
board
perspective
or
you're,
looking
at
multiple
issues,
and
you
just
drag
them
through
the
stages.
But
if
you're
like
a
single
developer
or
an
engineer
which
most
many
of
you
here
are
and
you're
looking
at
a
single
issue,
you
want
to
be
able
to
move
that
issue
from
one
stage
to
another
stage,
and
so
there
should
be
actually
not
be
very
little
confusion.
E
Whether
you're
looking
at
issue
a
and
the
issue
be
that
it
has
the
same
state
transitions
right
so
say:
you're,
a
member
of
the
plan
team,
a
plan
group
and
you're
working
on
one
issue
today
and
you're
working
on
another
issue.
Two
tomorrow
and
they're
both
plan
features.
It
would
seem
pretty
ridiculous
in
my
mind
that
how
come
you
know
today,
they're
called
like
in
you,
eighty
and
whatever
and
tomorrow
it's
it's
called
like
in
business
testing,
like
the
names
of
the
state's
totally
change
I,
think
that's.
That
would
be.
That
would
be
crazy
right.
E
So
that
to
me
brought
the
fact
that,
given
a
certain
project,
you
have
all
the
issues
in
the
project.
It
probably
should
all
share
the
same
state.
You
know
workflow
state
scheme
right.
You
shouldn't
have
one
particular
issue
having
a
different
scheme
and
another
issue
having
a
different
scheme,
because
that
would
just
be
confusing,
especially
to
say
an
engineer
or
designer
who's
working
on
multiple
issues,
even
maybe
in
the
same
board.
E
So
but
at
the
same
time.
Another
problem
is
that
you
want
to
offer
flexibility
so
that
one
team
wants
to
do
it.
One
way
or
another
team
wants
to
do
another
way
and
then
yet
another
point
is
that
maybe
you
want
to
view
this
at
an
executive
level
and
you
want
some
type
of
standardization.
So,
even
though
those
two
teams
have
independence
and
they
should
have,
but
maybe
in
your
particular
organization
or
in
that
particular
part
of
the
organization
say,
the
director
says
that
I
want
all
my
five
teams
to
have
the
same
state.
E
So
I
can
see
an
executive,
our
director
type
view,
and
so
that's
what
I'm
trying
to
comment
on
in
this
particular
paragraph
here
and
have
a
particular
suggestion
here.
First
of
all,
is
that
I
think
we
should
not
do
this
at
the
project
level,
at
least
as
a
first
iteration,
because
the
customers
that
are
asking
for
this
in
the
first
place
apologize
hopefully
uses
the
last
time.
A
G
I
agree-
and
you
know
the
thing
about
this-
the
dis
capability,
while
it's
focused
on
value
stream
management,
this
will
bring
us
so
much
closer
to
parity
into
a
place
in
the
market.
We're
competing
head-to-head
with
these
other
planning
and
management
tools.
I
think
this
is
gonna,
be
a
huge
plus
for
us
in
the
market.
Yeah.
A
While
you
said
that
John
I
I
was,
this
might
have
to
do
with
my
multiple
part
here
and
multiple
personality,
but
I
am
kind
of
seeing
this
applicable
to
merge
requests
as
well
I'm
wondering
if,
when
we
build
this
for
issues,
there
is
some
way
that
we
can
then
use
that
in
some
way
to
have
it
consistent
with
merge
requests.
I
want.
E
E
F
Think
the
Mersey
requests
workflow
is
is
so
much
simpler
than
any
issues
or
flow
because,
like
you,
don't
have
there
many
stages
in
a
measure
fest
you
like
develop
it,
and
then
we
put
it
in
review
or
testing
and
that's
freedom.
I
mean
I.
Maybe
there
is
some
some
spatial
creativity
rather
like
I,
don't
think
the
freedom
magic
was
it
stared
much
complicated
over.
C
A
Thinking
more
of
the
security
merge
requests,
but
that's
probably
because
there
are
too
complex
at
this
point,
but
we
can
definitely
there's
a
stage
when
they're
closed
they're,
not
closed
the
merge
requests,
but
they
are
ready
to
be
merged,
although
we
do
have
approvals
for
it.
That
might
be
better
for
that
particular
case,
but
anyway,.
C
E
Right,
no,
no,
that's
great
Andre,
so
hopefully,
I
won't
have
any
more
interruptions,
I
shouldn't,
so
so
so
just
cutting
to
a
chase
here.
So
what
I'm
suggesting
is?
Do
it
at
the
group
level,
because
customers
are
asking
for
this
at
the
group
level.
You
know
enterprise
customers
who
need
these
workflows
are
typically
doing
things
at
groups
with
you
know,
with
multiple
projects
in
the
groups
of
issues
from
multiple
projects
in
the
group
and
then
what
I'm
proposing
is
in
the
future.
E
But
my
thinking
is
that
if
you
define
it
at
say
group
say
you
have
this
structure
right
group
ABC
and
if
you
define
it
at
Group
C,
then
it's
well
defined
so
that
project,
P
and
project
Q
and
project
car
all
use
the
state
transitions
of
Group
C,
because
that's
well-defined,
that's
its
immediate
parent
group.
But
the
moment
you
have
also
group
a
has
its
own
state
transitions
and
Group
B
as
its
own
state
transitions
and
Group
C
has
its
own
transitions.
E
What
I
argue
is
that
it
should
just
be
an
overloading
sort
of
mechanism,
so
the
most
immediate
ancestor
that
workflow
state
you
use
that
and
if
your
most
immediate
ancestor
doesn't
have
a
workflow
state,
then
you
use
the
one
of
your
next
ancestor
going
up
and
so
on
and
so
forth.
So
with
that
structure,
you're
able
to
have
some
high-level
organization,
so
if,
like
your
director
is
at
gup-a,
you
can
just
say
to
your
team
members
like
group,
B
and
Group
C.
Don't
have
workflow
States
and
we'll
define
it.
E
Our
group
a
and
so
all
your
downstream
groups
and
projects
will
use
that
workflow
saying
and
everything
will
be
welded
by.
So
this
is
my
take
on
how
to
do
it.
I
still
think
is
actually
pretty
confusing.
I
think
it
may
be
can
be
saved
with
some
clever
UI,
but
I
still
think
this
is
actually
pretty
confusing,
but
I
can't
think
of
anything
better,
so
happy
to
entertain
better
ideas.
If
you
have
any
just
off
the
top
of
your
head
right
now,.
E
So
so,
if
there
isn't
two
salient
consequences,
given
a
project,
people
issues
and
people
have
the
same
workflow
States
and
that's
always
true,
provided
we
never
do
workflow
states
at
the
prom
or
even
if
we
do
yeah
so
so.
This
will
always
be
true,
which
is
good.
So
at
least
when
you're
working
in
a
same
project
you'll
never
have
craziness
like
Oh
like.
Why
is
it's
the
same
project?
Why
is
it
different?
E
But
given
group
G,
different
issues
in
G
may
have
different
workflow
states
which,
because
there
might
be
different
issues
and
different
layers
and
they
they
might
have
different
community
appearance.
So
this
might
be
really
messy
if
you're
looking
at
a
workflow
issue
board
in
G
and
some
issues
do
not
appear
by
definition
because
they
don't
fall
into
the
right
particular
workflow
state
so
like
how
do
you
present
that,
from
a
UI
perspective,
will
that
be
confusing?
E
That
you're
looking
at
a
group
issue
board
and
you're
looking
for
an
issue
that
should
be
in
the
scope
under
that
group?
But
it
doesn't
appear
in
that
board
because
of
this
thing,
that
is
like
a
problem.
I
think
I.
Don't
think
it's
a
deal
breaker,
but
it's
something
that
again,
that's
why
I
wanted
to
bring
on
this
meeting
if
like,
if
something
jumps
out
to
you
like
a
good
way
to
solve
it.
Please
comment
but
to
me
this
is
this
is
a
messy
one.
F
B
G
G
But
when
it
goes
from
one
to
another,
you
could
simply
have
an
automation
and
assigns
a
label
to
it
when
it
goes
from
one
to
another
which
would
keep
the
older
boards
still
working.
So
you
could
have
a
board
that
illustrates
where
things
are
at
based
upon
what
label
was
attached
to
it
like
could
be
in
state
A
or
B
or
C
right.
E
E
And
it's
in
that
particular
case
of
that
issue,
in
that
other
project
follows
a
different
scheme
of
workflow
States
and
therefore
it
would
not
show
up
in
group
A's
board
and
so
I'm,
just
commenting
that
that's
that's
confusing,
because-
and
maybe
that's
just
like
an
edge
case
that
we
deal
with
like
like
that.
Shouldn't
happen,
like
you
know,
so
so
a
director
idea
lab
says,
like
I,
want
to
see
all
my
issues
and
why
is
like
team?
You
know
why
Shawn's
team's
issues,
not
in
my
borden
and
Shawn's
answers.
E
Oh,
we
started
using
our
own
workflow
States.
Sorry
like
well
we'll
get
a
fix
like
maybe
that's
the
answer
to
that
problem,
or
maybe
it's
like
just
a
specific
list
of
like
issues
that
do
not
fall
into
these
stages
or
something
like
that,
so
it
can
be
solved.
But
to
me
that's
that's
just
something:
that's
not
elegant!
That
I
know
this
and
so
I
wanted
to
call
it
out.
Yeah.
A
I
think
that's
a
very
good
point
too,
to
call
out
I
think
eventually
in
the
UI,
so
I
never
like
when
things
don't
appear
silently
things,
I'll
be
okay,
I'll
be
okay
and
having
some
sort
of
warning
like.
If
we
see
that
the
the
scope
of
the
issue,
the
workflow
issue
board
effects
issues
from
projects
that
are
not
in
the
same
workflow
state
scheme,
whatever
right.
C
A
A
E
Something
to
be
addressed
good
good
point
thanks
thanks
Anya,
so
finally
getting
to
actually
Valley
Stream
management.
This
is
related
to
something
John,
wrote
and
I
can't
find
it.
I
saw
yesterday
John
your
comments
on
the
time.
There's
a
cycle
done,
but
we,
the
goal
of
value
stream
management,
is
to
actually
measure
these
times
right
so
like
how
do
we
do
that
and
Gill
lab?
So
if
you
like,
we
have
all
these
states.
It's
easy
to
measure
time
right,
so
you
we
actually
have
to
do
it.
So
the
easy
part
is
in
one
of
this.
E
These
intermediate
stages
right.
So
if
you're,
if
you're
an
issue
and
then
you're
going
to
review
and
then
it
leaves
review,
you
can
just
record
this
timestamp
so
boom.
That's
pretty
easy
to
measure
that
time
you
can
store
in
the
database.
Both
love,
there's
gonna,
be
weird
edge
cases
where
you
sometimes
skip
it,
and
but
we
can
probably
you
know.
Fines
come
up
with
a
list
of
you
know,
rules
and
algorithms
to
address
that.
E
So
I'm
not
worried
from
the
perspective
of
like
say
considering
the
intermediate
states
but
defining
where
your
cycle
time
starts
and
ends.
That's
I
think
is
is
a
problem
that
needs
to
be
addressed,
and
so
let
me
start
at
sort
of
the
top
and
well,
why
don't
john
you
you,
you
sort
of
motivate
the
problem
of
lead
time
in
cycle
time
and
why
that
matters
and
so
forth.
E
G
So
these
concepts
date
back
to
lean
manufacturing
the
idea
of
flow
and
managing
flow
of
work
through
an
assembly
line,
and
this
is
where
Kanban
and
the
idea
of
juicing
original,
but
it's
cool,
victor
yeah,
but
the
idea
that
is
that
understanding
cycle
time
tells
me
how
long
it
takes
a
widget
to
go
through
my.
So
when
I
get
an
order
or
we
get
an
order
for
something
I
mean
we
could
use
this
team
as
an
example
when
Victor
says:
let's
build,
you
know
the
custom
workflows.
G
The
cycle
time
is
going
to
tell
us
how
long
it
takes
the
team
to
engineer
and
deliver
that
from
start
to
finish,
and
that
means
Victor
would
know
that
if
it
takes
30
days
or
60
he
days,
it
means
that
from
the
time
Victor
knows
he
has
something
he
needs
to
deliver
for
a
customer.
He
has
it's
a
60-day
cycle
and
that's
often
translated
into
also
into
lead
time,
which
is
how
far
in
advance
it's
gonna
impact
a
customer.
G
So
if,
in
one
view,
it's
from
a
customer
saying
I
want
a
new
feature
too,
while
it
sits
in
the
backlog
and
it
gets
churned,
that's
one
definition
of
measuring
this
at
the
time.
That's
not
cycle
time!
That's
think,
that's
lead
time.
So
it
says
it's
gonna
go
into
here
and
see
it
come
out
here.
So
that's
another
measurement
that
people
are
focusing
on
and
a
lot
of
times
focusing
on
lead.
Time
is
what
the
people
in
the
industry
are
focusing
on,
because
that's
what
the
customer
sees,
but
a
key
thing
that
drives.
G
It
is
cycle
time,
which
is
the
process
into
the
middle
of
it.
So
these
are
key
and
as
as
people
and
our
customers
are
trying
to
figure
out
how
to
go
faster.
Having
insight
into
this
is
going
to
be
one
of
the
things
that
drives
them
to
improve.
Now
it
plays
into
the
comment
I
made
yesterday
about
whip
and
whip
limits
of
you
know
a
lot
of
times.
People
who
are
practicing
Kanban
will
say:
I
have
a
whip
limit
of
no
more
than
three
things
at
one
time
and
therefore
I
will
not
pile
things.
G
On
top
of
someone
and
increase
the
amount
of
work
in
progress
they
have
and
that
forces
people
to
focus
on
flow,
and
it
actually
makes
things
go
faster.
So
that's
something
we're
gonna
have
to
think
about
as
we
implement,
because
I
know,
people
are
going
to
look
to
do
this
and
I
did
say:
I
was
in
an
agile
conference
yesterday
and
it
was
it
kept
coming
up
and
which
sort
of
sparked
me
pinging
Victor
on
an
issue
where
it
was
outstanding.
If
we
need
to
probably
think
about
it,
thanks.
E
E
That
is
actually
the
best
way
I
can
think
of
to
do
to
build
a
tool
or
deuce
a
comparative
analysis
like
if
you
want
to
compare
your
company
versus
another
coming
in
the
same
industry.
How
else
would
you
compare
like
you
can't
compare
like
I
added
a
button
like
your
button
versus
my
button,
has
different
benefits
to
my
respective
customers?
It's
you
almost
cannot
compare
them
and
then
now
we're
comparing
buttons
in
different
industries.
E
It's
like
ridiculous
right
so
like
to
do
any
type
of
objective,
comparative
analysis
or
to
do
any
just
doing
it
measuring
this
for
the
for
the
purpose
of
improving
it
again,
you
just
need
some
metric
and
to
me
time
is
like
the
best
metric,
because
it's
so
objective
and
can
can
like
you
cannot
almost
you
cannot
bias
it
really
and
so
leap
that
that's
why
intently
time
is
important.
The
problem
with
Angela
anytime
is
it's
also
ill-defined
right
so
like
and
I'll
get
to
in
a
second,
why?
E
That's
all
define
so
that's
why
the
cycle
time
specifically
is
better
defined
and
if
it's
better
defined,
it's
actually
easier
to
build
a
tool.
Show
the
porgy
lab
everything
that
we've
been
saying
that
I've
been
saying
is
is
true,
but
when
it
comes
to
get
labs,
active
building
the
feature,
there's
all
these
constraints,
and
so,
for
example,
cycle
time
is
easier
to
define,
because
you
can
have
clearly
defined
when
you
start
working
on
a
feature
you
can
say
the
milestone.
E
So
so
this
is
where,
like
I
don't
know
what
the
design
is,
and
so
this
were
again
I
want
to
invite
ideas.
It
could
be.
The
very
first
stage
is
not
when
you
start
counting
the
clock
is
the
moment
that
a
person
on
the
team
drags
it
to
the
second
stage.
That's
when
you
start
the
clock
and
that's
when
you
start
counting
the
cycle
time.
So
that's
one
way
to
do.
The
counting
another
way
is
to
integrate
closely
with
Sprint's
or
milestones
as
we
call
them
and
say
when
this
milestone
begins.
E
That's
when
the
clock
starts
ticking
for
those
issues
and
you
do
the
math
there
so
there's
that's
at
least
two
ways
to
start
counting
the
clock
and
then
once
you
get
into
the
first
Asian
or
fourth
stage,
it's
it's
relatively
well
defined
how
you
count
the
clock
there.
So
that's
why
I
think
cycle
time.
E
We
should
build
it
first,
purely
because
it's
just
low-risk,
easy
to
define
and
and
and
it
still
has
value
it
has
less
value
than
customer
time,
but
there's
because
it's
not
as
correlated
to
this
direct
business
benefit,
but
you
can
argue
it
has
amazing
benefits
to
operational
excellence
is
like
the
term
that
I've
been
throwing
around
because
as
an
engineering
manager,
maybe
you
don't
like
your
Johnson
at
good
lab.
Maybe
you
care
less
about
customer.
E
You
know
you
care
about
custom,
freebie
I'm
sure
he
does,
but
maybe
he's
like
hyper
uber
focused
on
just
engineering,
doing
an
amazing
job
of
getting.
You
know,
features
shipped,
and
so
he
cares
about
cycle
time
a
lot,
and
so,
if
he
can
improve
that
and
make
that
awesome,
that
is
great
for
his
organization
as
a
stakeholder
and
for
his
company
gitlab.
It's
also
amazing
right,
because
you're
shipping
features
faster
so
and
as
John
you
know
made
a
point
cycle.
Time
is
also
a
big
piece
of
don't
end
thing.
E
E
Is
that
that's
not
a
good
idea,
we're
not
going
to
build
it,
so
we
close
it.
So
so,
what's
the
time
there?
Is
it
like
two
seconds?
Is
it
two
hours
we
have
an
issue?
It's
moved.
It's
closed
its
reopened,
it's
promoted
to
an
epoch
like
what
happens
to
all
those
issues
like
how
do
we
measure
time?
What
is
the
inherent
metric
that
we're
trying
to
quantify?
Are
we
trying
to
say
that
a
customer
gave
us
an
issue
I'm
thinking
of
the
example
of
Gila,
and
we
responded
them
to
them
really
quickly.
E
Do
we
care
about
that
as
an
organization
as
your
lab
I?
Actually,
don't
care
about
that
too
much
that
the
fact
that
I'm
responding
to
people
bring
it
over
the
fact
that
Mark
Fletcher
was
able
to
ping
me
really
quickly
and
we
were
able
to
respond
to
that.
That's
important,
but
I
think
that's
secondary
to
get
lab
as
as
a
company
like
our
priorities,
are
really
about
shipping
code
really
quickly
and-
and
you
know
getting
triaging
the
the
plethora
of
issues
from
a
customer.
E
So
that's
much
easier
to
build,
because
those
issues-
probably
every
single
issue
in
that
case
or
like
99%
of
them-
will
eventually
be
implemented,
and
none
of
them
will
be
closed
because
it
didn't
make
sense.
So
how
you
define
that
to
me
is
a
really
really
hard
problem
to
solve.
So
that's
why
I,
just
I
just
don't
want
to
solve
it
at
the
beginning.
I
just
want
to
focus
on
cycle
time,
so
that
I
try
to
articulate
all
that
in
in
here.
E
E
Like
I
mean
these
are
my
designs,
so
I've
taken
a
stab
at
it,
and
so
animal
is
going
to
make
it
more
super
more
awesome,
but
to
me
I'm,
actually
not
that
concerned
about
the
visual
design
right
because
to
me
like
making
sure
that
these
are
well
considered
in
the
NBC,
not
not
as
part
of
the
NBC
but
well
considered
how
they
impact
future
iterations
I
think
will
be
super
crucial,
sorry
again
and
bite
everybody
to
to
think
more
and
participate
more
as
we
get
to
it
all
right.
I
was
a
Victor.
A
A
E
So,
yes,
so
so,
for
example,
in
this
particular
NBC.
So
thanks
for
asking
about
like
so
what
exactly
are
we
building
as
an
NBC?
So
we're
definitely
not
going
to
build
an
issue
board
or
a
new
issue
board
type
right.
So
that's
definitely
out
of
the
picture.
I
think
we
need
to
probably
build
the
configuration
to
this
and
maybe
a
way
to
surface
the
fact
that
your
issue
is
moving
between
states
right.
So,
like
sorry,.
A
A
A
Only
one
issue
here,
my
question
is
this-
would
be
very
because
right
now
on
create'
we're
kind
of
struggling
with
ordering
of
issues
and
we
kind
of
love
boards,
but
there
is
no
way
to
like
strict
the
ordering
do
not
having
accidental
reordering
basically,
so
this
manual
ordering
we
very
beneficial
for
boards
as
well
I
just
want
to
make
sure
that
this
hasn't
been
discussed
before
going
ahead
and
creating
an
issue.
Could
I
only
see
one
issue
here
on
the
epic,
so
this
is.
E
You
look
if,
if
you
look
at
the
issue,
all
the
design
is
there
there,
it's
well-defined,
it's
UX
ready,
it's
go
for
eleven
point.
Nine
doesn't
look
like
we'll
get
to
it.
So
then
working
on
it
11.10
I
will
not
do
what
I've
done
like
maybe
like
a
year
ago,
which,
if
it
wasn't
done
I,
would
throw
it
further
out.
What
I
want
to
do
right
now
is
to
the
barring
any
crazy,
like
P
ones,
just
work
through
that
backlog
and
so
it'll
move
to
eleven
ten
and
we'll
work
on
it.
E
A
E
It
is
a
please
great,
an
issue
if
what
I'm
saying
is
incorrect
but
or
missing,
but
this
is
the
same
ordering.
What
we're
proposing
in
this
issue
is
that
any
ordering
inside
an
issue
board
between
e2
issues,
a
and
B
that
same
ordering
right
now
is
shared
in
the
any
issue
board
inside
UK
lab
instance,
and
it's
shared
inside
any
epic
of
attached
issues,
so
that
ordering
is
consistent.
It's
the
same
ordering
in
the
database
and
then
this
manual
ordering
it
will
also
use
that
same
ordering.