►
From YouTube: Plan Stage Weekly 2020-05-13
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).
B
C
Yeah
I'm
really
excited
to
be
here.
Obviously
my
name
is
Jake.
I
live
right
outside
DC
on
the
east
coast
of
the
US
I
most
recently
was
actually
running
an
entire
engineering
team
at
a
much
smaller
company,
so
company
was
about
120
people.
The
engineering
team
was
about
40
people
and
that
was
focused
on
renewable
energy,
which
was
really
cool
and
really
fun,
but
also
extremely
stressful
and
difficult.
So
I
am
excited
to
have
a
slightly
smaller
in
scope
role
here
for
a
larger
company.
D
D
It's
only
thanks
Donald,
it's
only
ten-thirty
him
I'm,
just
out
of
college,
so
hello,
everyone,
my
name
is
Julian,
so
Donald
recommending
that
I
just
videotape
my
introduction,
but
since
it's
our
first
meeting
I
insist
that
I
do
this
in
person
again,
my
name
is
Julian.
It's
hard
for
nouns.
I
live
just
outside
on
the
top,
just
on
the
outskirt
of
Seoul
South
Korea,
but
I
went
to
college
in
the
US
and
Michigan
I
returned
two
weeks
ago.
I
studied
computer
science.
D
In
fact,
I
still
have
one
more
year
to
go
to
finish
my
Master's
I'm
doing
a
sequential
program,
so
that
gives
me
both
bachelor's
and
master's.
So
how
I
ended
up
here?
I
ended
up
here
at
get
lab
because
a
get
lap
member
gave
a
talk
about
this
company
and
its
remote
culture
in
Ann
Arbor,
like
I,
was
last
fall.
D
There
was
before
this
whole
ko
v19
thing
happened,
so
I
applied
for
the
internship
and,
to
me
be
honest
with
all
of
you
as
I
was
with
Donald
I,
initially
applied
for
a
back-end
role,
just
because
I
slightly
more
experienced
in
that.
But
I
was
offered
to
interview
for
the
permanent
fernand
role
and
I
said
yes
and
Here.
I
am
I,
think
front.
End
seemed
bit
daunting,
just
because
it's
where
the,
where
we
meet
end
users
directly
and
as
with
everything,
human,
it's
just
always
difficult
outside
of
work.
I
enjoy
soccer.
D
E
E
F
All
right,
Keenan,
you
are
up
yeah
I
just
want
to
say
you
know
we.
We
got
the
hierarchy
and
milestones
on
the
roadmap.
We
kind
of
tighten
down
the
bolts,
clean
up
bugs
and
so
I,
that's
just
great
it
so
Congrats
to
the
team.
Please
share
my
excitement
and
things
for
hard
work
that
went
into
that,
and
you
know
that,
in
conjunction
with
the
progress
indication
we
rolled
out
two
releases
ago
is
delivering
the
top
three
requested
roadmap
features.
So
that's
what
we
should
be
quite
excited
about.
F
Just
since
that's
an
area
we
kind
of
just
started
investing
in
heavily
just
thanks
for
that
and
the
next
point
Lexus
has
done
a
ton
of
really
good
work
on
some
designs
for
epic
swim
lanes
on
issue
boards.
So
I
would
encourage
everyone
to
check
that
out,
provide
feedback,
ask
questions
and
start
thinking
about.
You
know
what
that
would
mean
for
scoping
and
NBC
from
an
engineering
side
so
know
it
looks
like
she
added
a
YouTube
video
of
how
it
works
as
well.
G
Yeah
hi,
so
so
I've
gone
through
the
issues
in
the
plan.
Kanban
board
that
had
the
feature
level
and
added
documentation
level
for
those
that
I
think
makes
sense
to
have
documentation
that
didn't
have
the
label.
G
You
know
if
you
see
that
I
did
it
in
a
place
that
doesn't
make
any
sense.
Let
me
know
so
I
plan
to
do
this
kind
of
thing,
maybe
once
a
month
to
just
stay
on
top
of
what's
happening
and
at
the
risk
of
sounding
like
a
broken
record,
I
encourage
everybody,
who's,
making
front-end
code
changes
to
add
the
dogs
with
the
code
if
possible.
G
B
Yeah
so
yeah
this
come
up
a
couple
of
times
now,
I'm,
not
sure
if
we
discussed
it
before,
but
I
thought.
Maybe
we
might
want
to
consider
running
this
meeting
at
alternate
times
on
other
weeks
every
other
week
and
I
wanted
to
gather
some
thoughts
on
it
and
I
tried
to
do
the
maths,
I
failed,
but
I
think
if
we
were
to
I
think
there's
a
way
we
could
maybe
run
the
meeting
in
a
way
that's
friendly
to
people
in
a
pack,
but
also
includes
some
people
on
the
west
coast
of
America
or
sorry.
B
H
B
Don't
think
there
are
too
many
options
well,
we'd
need
to
accommodate
I,
think
from
UTC,
plus
it
to
UTC,
plus
twelve
right
so
yeah,
whatever
I
think
that
from
having
done
the
on
call
agenda,
I
think
the
max
when
we
go
back
to
is
UTC
it
would
that
be
right.
So,
whoever
like
is
in
the
the
working
day
there
and
also
like
like,
is
that
something?
I
C
E
K
So
just
quickly
in
marketing,
if
you
folks
aren't
aware,
we've
moved
to
a
use
case
based
marketing
approach
rather
than
a
stage
based
marketing
approach,
we're
trying
to
market
reasons,
people
would
buy
get
lap.
One
of
those
is
agile.
There's
some
discussion
about
exactly
what
that
means
and
I
think
it's
a
very
healthy
discussion,
because
it's
a
discussion
we
haven't
had
before
I've
started.
Looking
through
the
site
and
I've
found
some
terrifying
things
that
need
to
be
burned
with
fire.
K
We
have
not
had
a
lot
of
consistency
on
the
site
in
the
past
about
how
we've
talked
about
agile
from
a
marketing
perspective,
so
we're
going
to
be
ripping
things
apart
and
consolidating
them
and
I'll
be
working
with
the
PM's
I.
Normally
work,
but
I
want
to
make
sure
everyone
here
has
because
I
know.
Everyone
here
has
very
strong,
very
informed
opinions,
so
I
will
be
linking
Mrs
here
in
future
meetings
and
if
you
have,
if
there's
anything,
just
burning
desire
to
make
sure
that
we
do
or
don't
talk
about
something
in
a
certain
way.
K
J
J
J
This
is
what
this
is.
The
argument
going
on.
It
emerged
not
argument.
Discussion
going
on
emerge.
Request
right
now
is
like
there's
some
folks
who
are
like
just
call
them
sprints,
but
I'm,
saying
they're,
not
not
all
Sprint's,
not
all
iterations
are
Sprint's
to
spread
specific
to
scrum,
not
everyone
practices,
scrum
Zucco,
any
iteration
is
iterations.
It
is
more
inclusive
of
all
methodologies.
Would
you
agree
with
that
or
not
plus
+1.
K
B
J
I'm
excited
the
other
thing
too
is:
would
it
make
sense
that
we
try
to
figure
out
how
to
align
the
use
cases
with
our
job
stories
or
jobs
to
be
done?
They'll
be
working
on
first,
like
a
great
maturity,
yeah.
K
J
Yeah
we
have
an
open,
Mr
I'll
tag
you
on
that,
where
we're
moving
it
into
like
a
data
file,
there's
a
yellow
file.
Now
that
adds
all
the
jobs
to
be
done
from
across
different
stages.
So
that
way
you
can
include
the
partial
in
different
pages
and
stuff.
So
I
don't
know
if
that's
useful,
but
I'll
ping
you
on
it.
So.
A
J
Think
I
have
the
next
thing.
So
historically,
what
we've
done
is
these
groups
within
the
plant
stages.
We
have
a
shared
planning
issue
for
each
milestone
or
each
release
and
I
think
you
know
the
different
product
managers
dump
things
in
there
and
then
we
can
have
some
basic
conversations,
but
to
get
the
most
bang
for
our
buck.
I
think
it's
worth
and
and
we're
starting
to
have
more
overlapping
things
like
swimlanes
on
boards,
like
real
times,
can
affect
everything
we
want
to
work
on
sticky
headers,
which
should
affect
like
epics
and
issues.
J
All
that
to
say
is
like
there's
some
things
that
we
want
to
focus
on.
So
I
think
we
wanted
to
do
a
little
bit
of
synchronous,
have
a
conversation
around
13.1
release
goals
and
talk
through
trade-offs,
figure
out
how
we
can
move
the
ball
forward
with
these
various
things
that
we
have
in
the
air.
I
don't
know.
Do
you
want
to
add
any
context
that
Keenan
Mark
Justin,
that's
great
cool,
so
I
don't
know
how
we
want
to
do
this
because
we've
never
done
it
before.
J
J
J
J
L
J
See
miss
Byng
weird,
but
the
basic
issue
is
like
the
flow
for
creating
is
there
but
I
think
the
next
thing
to
talk
about
is
the
little
like
the
actual
report
chart,
and
so
this
looks
similar
to
like
a
mouse
oon,
how
it
looks
now,
but
we're
kind
of
cleaning
things
up
a
little
bit
consolidating
getting
rid
of
the
sidebar
and
moving
the
information
into
like
the
main
view
where
you
need
it.
So
we
can
have
a
little
bit
more
context
there.
J
Don't
know
if
we're
going
to
do
this
start
manual
start
at
this
point
or
not
because
it's
based,
like
you
said
it's
start
date
and
end
date
and
that's
required
so
I
think
that's
already
done
and
we'll
kind
of
see
I
think
eventually
we're
gonna
move
to
making
it
even
more
automated,
but
still
offering
the
ability
to
manually
start
it
going
back
and
forth
on
that.
But
it's
something
we
can
iterate
on
and
I
think.
J
The
report
view
is
a
little
bit
different
where
we're
trying
out
kind
of
sort
of
a
group
by
function
where
you
can
group
by
is
like
in
within
a
group
milestone
or
iterations
or
is
a
group,
so
you
can
group
by
project
and
see
percent
complete
for
each
one.
You
can
group
by
labels
by
signing
the
either
by
epics
eventually,
so
that
way
like
E,
is
you
scroll
through
I
think
we
might
want
to
make
it
so
that
users
can
pick
which
labels
they
want
to
group
by
here?
J
That
was
some
feedback
we've
gotten
from
showing
this
to
customers
filtering
by
Sinese
or
grouping
by
Sundays
and
then
grouping
by
epics,
and
that
will
I
kind
of
bring
more
context
to
what
the
issues
belong
to
within
the
like
this
kind
of
view.
This
is
where
we're
at
right
that
we're
still
like
showing
this
around
and
getting
some
feedback
on.
J
F
J
And
yeah
and
building
this
is
a
view
app,
but
then
backporting
this
into
the
mouse
sense
view,
because
right
now
the
milestones
view
is
not
performant
finding
means,
especially
at
scale,
and
you
don't
have
a
lot
of
these
contextual
like
things
that
would
be
helpful.
So
we've
been
doing
like
user
research
on
milestones
for
a
while.
F
G
J
They
built
their
workflows
around
it,
but
not
really
I.
Think,
though,
the
folks
that
know
that
it's
a
survey
accurate,
don't
use
it
all
fit
it
that
way
a
lot
of
our
customers.
They
export
all
their
issues
and
put
it
into
a
spreadsheet
and
build
a
report
there.
So
that's
like
the
main
problem
we're
trying
to
solve
with
that
is
like
we
want
people
to
use
our
reports
and
not
spreadsheets,
and
every
spreadsheet.
J
That
I've
seen
is
about
the
same
as
a
correct
for
a
down
chart
on
it
and
a
burned-out
burn-up
charter,
and
that
sort
of
thing
so
I,
don't
think
they'll
be
surprised
and,
like
the
the
other
thing,
is
it's
not
our
burden
on
charts
aren't
broken
until
you
move
all
of
your
issues
out
of
it
right,
so
they
work
correctly
until
you're
done
with
the
milestone.
And
then
you
move
watch
things
to
dig
get
done
into
the
next
milestone,
and
it
shows
that
you're
a
hundred
percent
complete
when
that's
not
actually.
J
A
About
this
real
quick
gauge,
so
it
looks
like
four
thirteen
one,
we're
gonna
focus
on
the
individual
iteration
page,
which
I
think
is
great
whatta
plans
on
like
the
list
view
or
the
create
iteration
view.
Are
we
planning
on
any
undoing
anything
they
are
in
thirteen
one
or
we
hoping
to
get
user
feedback
before
we
before
we
touch
those?
What.
A
So
scarred
well
yeah
yeah,
something
like
that,
because
right
now,
like
the
creation
of
iterations,
are
essentially
it's
fairly
similar
to
the
creation
of
milestones.
I
mean
there
are
things
like
with
requirements:
management
where
we
have
in
mind
creation,
which
I
think
would
be,
would
be
nice.
Just
things
like
that.
That
I
think
we
can.
J
Yeah
I
think
I
would
like
to
improve
on
that.
I
think.
The
thing
that
we
need
to
get
to
is
these
quickly
as
possible
is
showing
the
velocity
over
a
number
of
previous
milestones
and
then
like
improving
everything
else
like
after
that.
So
the
problem
right
now
is
that
people
want
to
be
able
to
like
assign
issues
to
multiple
milestones,
which
is
a
milestone
and
then
an
iteration.
But
then
they
also
need
to
report
on
how
like
much
they've
completed
that.
J
A
A
J
We're
gonna
have
to
figure
out
what
that
looks
like
on
a
board,
because
you
can,
you
know,
add
the
course
like
a
milestone
list.
Should
you
build
that
in
iteration
list,
there's
like
lots
of
things
across
the
park,
that
I
think
we
should
spend
13.1
figuring
out
while
we
work
on
this
view,
and
then
that
way,
we
at
least
have
a
good
idea
of
how
it
should
be,
because
I
think
it
is
you.
J
Okay,
the
next
thing:
there's
a
UX
okay,
are
for
improving
low
ability
of
issues
or
like
the
planned
stages
at
all.
Basically,
so
one
of
the
things
that
we
wanted
to
do
was
fixing
the
selected
search
inputs
across
the
product,
basically
mean
playing
objects.
So
if
you
want
to
move
an
issue,
it's
hard
to
do
that.
If
you
want
to
select
the
right
project
when
you're
creating
an
issued
an
epic
it
only
loads
20,
it
basically
only
looks
20
results,
and
sometimes
that's
not
the
project
that
you
want.
J
B
Coming
includes
performance
issues
in
this
as
well,
because
I
think
the
issue
show
page
has
been
identified
as
kind
of
one
of
the
less
well
performing
parts
of
the
site,
and
maybe
we
could
combine
that
as
well,
because
you
know
like
if,
like
performance
things
kind
of
map
to
customer
value
as
well,
I
guess
if
something
is
not
performant
and
can't
be
used
or
won't
be
used,
it's
not
very
valuable.
So
should
we
include
performance
things
in
this
as
well.
100%.
J
So
this
is
one
of
the
things
that
is
I've
noticed
about
having
Despero
key
arch,
where
your
ex
has
okrs
about
like
qualit
like
you
improve
the
UX
and
then
engineering
has
about
performance
and
then
proc
Tazo
cares
about
adoption
and
other
things
like
that,
like
they're
competing,
and
we
need
to
figure
out
how
to
like
make
them
all
line
up
and
I.
Think
that's
a
great
suggestion.
So
do
you
have
a
list
of
items
that
we
need
to
focus
on
because
I
would
love
to
add
it
to
this?
J
I
do
agree
that
performance
and
if
issues
are
loading
slowly,
which
they
do
sometimes
that's
gonna,
make
things
not
lovable
too,
and
that
was
a
lot
of
the
feedback
from
the
MPS.
Since
us
course
was
that
the?
U
UI
is
sluggish
and
slow
and
I.
Think
that's
the
sort
of
thing
that
they're
referring
to
so.
J
B
So
the
like,
technically,
the
exit
criteria
for
the
working
group
is
two.
There
are
two
of
them.
One
is
to
get
ship.
The
first
working
feature
to
self-hosted
customers
and
one
is
to
ship
first
working
feature
on
comm.
Those
are
different
in
terms
of
the
one
on
comm
will
be
done
through
containerization
and
kubernetes.
The
one
that's
shipped
to
South.
Those
two
customers
will
work
through
Anubis.
In
both
cases,
the
Omnibus
work
is
quote,
unquote
done,
the
containerization
is
also
in
review
and
you
can
actually
hold
on
the
latest.
B
The
latest
versions
of
master
on
both
those
projects
actually
not
master
on
containers.
But
if
people
down
the
branch
you
can
do
it
and
you
can
enable
the
feature
flag
and
you
can
see
the
feature
working
so
the
next
step.
For
us
there
might
be
to
deploy
the
Omnibus
fer
to
staging
and
switch
the
feature
Flygon,
and
then
we
can
actually
use
an
in
staging
so
yeah
we're
we're
going
at
a
healthy,
cliff,
like
I
mean
where
will
be
blocked
on
the
kubernetes
work.
J
Thanks
and
then
the
other
thing
is
the
second
iteration
of
the
JIRA
importer.
I
think
the
big
things
here
is
getting
the
parser
working
for
the
description
and
then
giving
the
user
mapping
working.
So
we
can
import
comments,
assignees
reporters
there
are
a
couple
other
small
fields
that
I
think
are
worth
getting
done.
If
we
can,
like
you
know,
mapping
story
points
to
wait,
which
is
pretty
straightforward.
You
know
like
the
one
labels
like
if
a
figure
issue
has
labels,
we
should
bring
the
labels
over
and
then
I
think
at
some
point
soon
ish.
J
J
There
I
proposed
that
yesterday,
when
I
was
doing
an
opportunity,
cameras,
review
and
I
need
to
talk
to
Harris
to
see
if
like
how
that
will
work,
but
there's
some
other
things
that
I
think
are
more
important
for
us
is
a
tea
collective
stage
to
focus
on,
and
we
already
have
an
importers
group,
that's
responsible
for
importer.
So
it's
kind
of
logical
but
I'll
keep
everyone
updated
on
the
ongoing
discussions
about
that.
F
Stuff
its
yeah,
so
you
know
for
me,
I
think
it's
no
surprise.
I'm
super
passionate
and
kind
of
order,
winning
state
about
moving
forward
with
swimlanes
like
not
only
is
that,
just
like
the
top
internal
requests
that
we
have
for
portfolio
management.
It's
also
now
our
top
customer
request
for
the
group,
so
I
mean
I
need
to
move
forward.
We
need
to
move
forward,
and
so
I
would
love
to
find
how
we
can
start
taking
steps
in
that
direction.
F
Of
course,
I
think
alexis
has
already
moved
a
lot
of
the
big
rocks
through
the
design
phase,
so
I
think
we're
moving
forward,
but
I
want
to
make
sure
we're
talking
about
it
and
haven't
planned
for
it.
That's
a
little
more
tactical,
and
on
top
of
that
you
know,
we've
talked
to
I've
talked
to
Donald
and
brought
this
up
before.
You
know
the
idea
of
actually
providing
more
robust
filtering
on
the
roadmap,
so
users
can
actually
craft
and
customize
the
view
they're.
F
Looking
for
now
that
we
put
more
information
on
it-
and
you
know
from
an
internal
use
case-
and
you
know,
with
the
health
status
feature,
we
rolled
out
last
release
being
able
to
surface
that
through
filtering
or
searching
on
the
issue
list,
as
well
as
on
the
issue
board.
So
there's
a
three
top
items
on
my
head.
F
But
I
know
we
keep
top.
We
keep
discussion
the
need
for
boards
to
be
refactored
or
updated
before
we
make
major
changes
like
I,
guess,
I'm
still
trying
to
understand
what
the
balance
is,
we
can
strike
towards
moving
swimlanes
forward,
but
not
creating
not
digging
us
a
hole
that
we're
gonna
hard
time
getting
out
of.
If
that
make
sense,
let's
do
it.
A
A
J
Yeah
I've
doing
it
with
flower
building
and
features
the
right
way
to
do
it
so
like
I,
just
want
to
make
sure
that
since
people
rotate
in
and
out
of
features
like
if
there's
an
overall
vision
for
what
what
the
end
state
of
refactoring
looks
like,
so
they
can
be
more
extensible
so
like
in
the
future.
We
don't
know
exactly
what
it's
going
to
look
like,
but
there's
gonna
be
epic
boards
right
which
hopefully,
we
can
reuse
some
of
the
same
like
code
for
that
and
apply
to
different
object.
So.
F
Boards,
if
we
have
epic
swim
wings,
yes,
the
epic
program
board
hits
a
different
use
case,
that
you
see
it
like
scaled
agile
shops
or
larger
enterprises,
where
they
actually
have
a
separate
workflow
for
epics
prior
to
an
actual
development
process
story.
So
yes,
that
that
is
the
next
big
tentpole
item
after
swim
lines,
at
least
from
my
end,
would
be
epic
boards
and.
J
Also,
there's
a
growing
desire
to
have
merge,
request
ports
so
like
when
I
think
about
interaction
models
like
this,
where
I've
kind
of
talked
about
this
before
but
like
you,
have
a
list
write
a
list
of
things
that
are
next
to
each
other.
You
can
move
items
into
it,
sliced
by
some
course
sort
of
common
data
attribute.
That
is
what
is
in
the
list,
and
this
swimlane
is
basically
slicing
it
by
another
data
attribute.
It's
almost
like
a
pivot
table
and
the
same
interaction
model
applies
to
epochs
when
you're
playing
at
the
epoch
level.
J
It
applies
to
issues,
it
applies
to
merge
requests.
It
probably
applies
to
other
things
like
who
knows
incidence,
requirements,
requirements,
and
so
that's
where
the
the
kind
of
thing
that
we've
been
talking
about
in
product
is
like.
Can
we
take
the
interaction
model
and
create
a
common
pattern
and
a
common
set
of
like
UX
interactions
that
you
can
then
just
over
like
different
objects
into
this
interaction
model?
So
it's
a
common,
consistent,
reusable
and
we're
building.
A
M
Lanes
do
it,
let
me
do
it
it's
a
little
early
here,
yellow
so
bear
with
me.
Yeah
I
tried
to
keep
changes
fairly
minimal
for
MBC
I
didn't
want
to
have
like
overhaul
right
away,
so
the
latest
iteration
here
I
feel,
like
we
say,
iteration
a
lot
would
be
pretty
similar
actually
to
the
milestone
view,
just
grouping
these
issues
in
a
different
way,
so
for
MBC
that
would
be
epics
right,
so
I
go
in
here.
M
I
gripped
my
issues
by
epic
I
then
see
these
epic
swim
lanes
the
biggest
change
here,
because
we're
adding
that
mention
of
ROS
kind
of
like
Gabe,
said
a
pivot
table
almost
scrolling
within
each
individual
list
is
just
like
not
usable,
so
you
would
have
to
scroll
the
entire
board
in
this
view.
So
that's
a
pretty
big
change
that
I
really
can
get
around,
and
the
other
larger
change
here
would
be
collapsing
lists.
M
Currently
we
show
information
in
that
collapsed
state,
so
we
both
see
that
that
column
in
a
minimized
state-
and
we
see
information
about
the
column
in
event
of
NIH's
state,
and
now
we
have
these
titles
here
that
could
get
fairly
large.
So
thinking
about
how
to
show
with
that
information,
still
it
still
needed
tried
to
play
around
with
that.
It
could
be
some
kind
of
just
an
indication
that
there's
more
information
on
that
collapse
column.
Maybe
a
user
can
hover
to
view
more
information.
M
So
that's
that's
another
larger
change
there
and
then
the
other
things
are
not
quite
if
they're
more
added
value,
like
you
know,
collapsing
swim
lands.
I
can
also
now
hide
the
open
and
closed
columns.
So
I
move
the
hide
labels
toggle
and
this
edit
board
model,
and
we
could
talk
about
that.
But
I'm
assuming
users
aren't
toggling
that
on
and
off
constantly
so
I
think
it
would
be
acceptable
for
that
to
be
in
the
Edit
board
area,
and
then
it
allows
us
to
group
this
with
other
configuration
options.
M
So
if
the
user
goes
in
here
and
hides
to
open
and
close
lists
that
really
don't
do
into
the
list
they
care
about
and
the
issues
they
care
about.
So
this
this
helps
us
get
around
that
problem
of
having
an
open
list
with.
You
know
600
issues
there
and
you
know
200
epics
attached
to
those
issues
which
would
then
cause
200
epic
swim
lanes
to
appear
on
the
board.
M
So
a
combination
of
that
and
better
scoping
of
the
board
would
be
helpful
and
then,
in
this
view,
users
can
also
view
this
with
without
epics,
so
I
mean
apply.
So
that's
that
in
a
nutshell,
I
think
the
main
things
would
be
the
behavior
of
the
board
on
scroll
and
collapsing
would
list,
as
well
as
how
we
will
drag
things
around
with
this
one
lines
in
place,
especially
with
dragging
the
siblings
themselves,
I
think
for
MVC.
We
would
not
allow
that
or
any
reordering
of
the
sirloins
I'm
dragging
at
the
columns.
M
I've
said
that
could
be
a
little
strange.
So
when
we
work
on
that,
we
definitely
have
to
like
pair
closely
on
implementing
that's
make
sure
it's
usable,
but
I
did
open
the
issue
around
drag
and
drop,
so
I'll
be
working
with
the
Foundation's
team
in
13:1.
Work
on
that.
So
that's
that
is
strimling,
so
doesn't
mean
changes
but
go
ahead
and
stop
sharing.
J
That's,
that's
wonderful,
I!
Think
it's
a
great
next
step.
You
know
the
low-hanging
fruit
on
boards
that
I've
heard
a
lot
of
complaints
about.
Is
that
the
way
you
scoped
the
board
when
you
edit?
It
is
not
the
same
as
the
filter
bar
and
you
can't
do
things
like
not
filtering
when
you're
trying
to
scope
your
board,
primarily
so
I,
don't
know
if
there's
like
a
way
to
like
just
only
have
one
way
to
scope
your
board
and
that's
using
like
a
filter
bar
that
you
can
save
that
scope.
J
F
F
Up
itself
doesn't
need
to
go
away
and
actually
get
as
a
user
an
opportunity
to
do
a
quick
refinement
if
they're
just
trying
to
discover
something
or
clarify
something
or
displace.
Yes,
I
think
we
we've
trained
people
to
use
the
filter
bar
as
a
second
layer
of
configuration,
rather
than
what
I
think
it
should
be
intended
for,
which
is
like
I
need
to
make
a
fast
tweak
that
isn't
permanent,
so
I
can
get
a
better
view
to
take
a
screenshot
or
chair
or
a
my
presentation
or
whatever.
It's
almost
like.
H
H
Guess
I'm
most
interested
in
how
we
break
this
down
and
iterate
on
it,
both
epic
swim
lanes
and
then
this
broader
sort
of
refactor
in
the
direction
of
having
more
extensible
boards.
So
I,
don't
know
when
we're
gonna.
Do
that,
but
that's
interesting
to
me
and
how
we
staged
that
work
and
how
we
plan
that
out
over
the
next
couple
couple
milestones
or
whatever
it
takes.
I
think.
J
The
other
thing
that
I
noticed
just
about
that
I
agree
with
the
locking
scroll
for
everything
when
you're.
You
know
that
will
have
potential
performance
implications.
We
should
think
about
because
right
now
we
do
infinite
scroll,
pagination
per
list,
and
so
we
would
basically
have
to
load
all
lists
on
scroll
which
I
don't
know
what
that
do,
or
that's
a
performance
problem.
But
that's
just
one
thing
that
came
to
mind:
I'm
looking
at.
M
I'd
say
we
could
do
either
I'll,
probably
I'd,
like
that,
better
understand
the
use
case
of
scrolling
by
lists
versus
by
the
entire
board.
We
could
do
both
to
make
it
consistent
if
there
is
not
a
really
great
use
case
for
each
individual
list,
or
we
can
silence
the.
E
Don't
know
no
with
the
obvious
problem
with
it
on
the
issue.
Boards
is,
if
you
have
the
open
on
there,
you'll
have
something
like
2,000
issues
in
the
open,
which
means
your
page
will
be
2,000
issues
long,
which
is
wasted
space
on
that
page.
It
makes
sense
in
the
swimlanes
view
entirely
and
I
fully
support
that.
But
when
you're
talking
about
the
actual
issues
view,
the
pagination
by
column
is
actually
quite
nice
because
then
you
don't
get
this
incredibly
long,
useless
page
well,.
M
E
As
long
as
we
allow
them
the
option
to
turn
it
on,
we
have
the
option
or
that
we
have
the
problem
in
this
giant
page.
If
we
remove
the
option
entirely,
which
I
am
very
okay
with
is
I,
think
they're
dumb
in
the
board,
but
that's
a
whole
other
discussion.
As
long
as
we
give
them
the
option
to
turn
on,
though
we're
gonna
face
the
problem
of
having
the
2000
issues
in
a
row.
A
A
If
you
really
need
to
see
what
is
in
the
next
column
as
you're
working
on
the
initial
column,
because
then
you
can
go
to
the
bottom
of
the
list
in
the
first
column,
and
you
can
still
see
that
stuff
in
the
second
column,
I
feel
like
there's,
not
a
lot
of
people
that
work
like
there's,
not
a
lot
of
users
that
work
like
that
like
do
they
really
care
about.
What's
in
other
columns
when
they're
focused
on
a
single
column,
the.
E
Devil's
advocate
for
a
moment
here,
I
mean
the
way
the
PM's
reissue
boards
is.
We
prioritize
things
in
each
column
right.
So
if
I
have
a
column
with
15
things
in
it
and
I
need
to
move
it
to
the
top
Euler
column,
I
need
to
scroll
to
the
top
of
that
one
in
the
bottom
of
this
one,
because
I
need
to
go
from
the
bottom
to
the
top.
So
what
this
will
force
us
to
do
is
if
we
get
rid
of
that,
individual
scrolling
is
dragged
to
the
next
column
and
then
drag
it
up.
E
A
J
The
other
thing
that
I
want
to
add
is
the
ability
to
like
hockey
or
right-click
and
move
a
card
to
any
list
in
any
position,
a
list
via
the
UI.
So
Trello
does
this
nicely
so
like
if
I
basically
can
right-click
or
use
a
hockey
and
click
move,
and
then
I
basically
can
say
which
list
and
in
which
position
that
list,
which
is
a
number
and
that
way
like
if
I'm
way
down
somewhere
else,
I'd
only
move
it
up.
J
This
is
like
feedback
that
we've
gotten
that
people
hate
about
JIRA,
as
you
can't
do
that
the
back
look.
You
got
feedback
about
that
in
kit
labs.
You
can't
like
you,
can't
see
the
relative
order
of
everything
like
that's,
not
a
parent,
but
then
you
also
can't
quickly
change
that
value
if
you
want
manually
without
drag-and-drop.
So
that
could
be
another
way.
A
E
So
now
I
didn't
realize
we
were
putting
them
in
the
agenda,
so
I
actually
went
updated.
The
issue
to
have
the
proposed
theme
for
certify,
which
is
effectively
just
trying
to
figure
out
how
to
get
the
quality
of
life.
Improvements
in
we've
have
a
lot
of
ongoing
work
there
and
I'm
trying
to
sort
of
use
this
as
a
milestone
to
kind
of
finalize
some
of
that.
So
like
requirements,
management
we've
got
the
trace
between
requirements
and
test.
Is
ongoing.
E
Work
I'd
like
to
try
to
sort
of
nail
that
down
in
13:1,
if
at
all
possible
from
a
service
perspective,
we've
been
working
on
the
private
comments
on
come.
A
comment
below
this
has
grown
into
a
company-wide
change,
which
is
fantastic.
It's
a
great
input
into
what
things
are
going
on
here,
but
any
kind
of
comment
about
resource.
Now
you
can
put
private
comments
on
so
I'd
like
to
try
to
get
through
some
of
that
work
and
finalize
that
we
also
are
continuing
to
work
on
formalizing
the
designs
for
adding
email
participants.
E
I
know
this
has
been
ongoing
and
Nick
has
done
a
great
job
sort
of
doing
the
design
work
on
that
he's
been
getting
a
lot
of
feedback
from
lots,
different
people
trying
to
kind
of
figure
out
the
best
way
to
go
about
this.
It's
both
performant
secure
and
meets
the
needs
of
the
users
and
then
the
other
one
is
blocking
issues.
E
This
isn't
actually
a
certified
category,
I
sort
of
owned
it
by
association,
it's
more
of
a
overall
plan
category
since
it's
more
issues,
but
it
seems
like
we're
getting
a
lot
of
great
feedback
on
it.
So
we're
still
working
on
these
sorting
issues,
but
the
number
of
items
are
blocking
I
know,
there's
multiple.
It's
been
broken
down
nicely
now,
thanks
to
I
believe
John
did
that
work.
E
We've
moved
some
things
into
30,
no,
but
I,
don't
think
it'll
complete
until
thirteen
one,
so
that's
sort
of
on
the
list
to
finish
up
and
then
the
final
thing
I
had
proposed
was
the
tracking
interactions
with
locking
issues
which
is
another
snow,
pile
or
snowflake.
We've
got
to
figure
out
how
to
do
it
but
effectively.
We
want
to
make
sure
that
these
are
being
used
and
understand
their
use
because,
as
a
stage
I
don't
want
to
spend
a
ton
of
time
adding
more
features
to
this.
E
If
we're
finding
that
they're
not
being
used,
I
suspect
they
are,
we
used
them
greatly
internally
to
great
success,
so
I
mean
internally
I
really
like
them,
but
that's
not
enough
of
a
justification
to
keep
spending
lots
and
lots
of
time
on
them.
So,
with
this
we'll
be
able
to
track
that
and
understand
better
how
people
are
using
them
and
understand
better
how
to
prioritize
additional
work
on
walking
issues.
So
that
was
my
proposal
again.
You
know
feel
free
to
make
comments
on
that.
E
I'm,
not
wedded
to
this
and
any
means,
but
that
was
sort
of
my
first
put
on
this
so
cool.
Have
we
gotten
any
feedback
yet
on
you?
I
have
gotten
some
excellent
feedback
from
a
lot
of
Tam's
and
essays.
I
actually
was
on
a
call
this
morning
with
a
tam
who
said
that,
since
we
released
requirements
management
in
1210,
he
has
had
four
customers
who
had
never
talked
about
it
before
call
him
and
immediately
ask
when
we're
gonna
be
doing
more
on
it,
because
they
very
much
are
interested.
E
So
we
have
spurned
interest
by
releasing
something
which
is
fantastic,
I,
think
a
lot
of
people
never
asked
for
it
because
they
never
thought
of
integrating
it
into
their
DevOps
tool,
training
because
it
never
has
been
before
in
a
meaningful
way.
Now
that
they
hear
we're
going
down
this
road,
there's
been
a
lot
of
interest
there,
which
is
fantastic.
E
I
also
had
another
call
with
a
serious
set
of
sales
people
last
week
in
the
sales
side,
they
were
saying:
they've
got
a
lot
of
interest
in
the
federal
sector
right
now
and
they're,
trying
to
figure
out
a
timeline
and
they'd
like
us
to
put
together
sort
of
a
roadmap,
so
I'm
working
on
that
for
them,
so
they
can
better
status
their
customer.
So
there
has
been
a
lot
of
interest
to
people
who've
used.
H
E
Is
such
a
hard
category,
because
there's
really
two
distinct
user
groups,
there's
a
regular
industries
and
then
there's
everyone
else
for
the
regulated
industries
until
we
offer
tres
they
can't
really
adopt.
So,
yes,
that's
a
major
factor
for
them
adopting
for
everyone
else.
Actually,
Nick
is
doing
a
really
great
job
on
a
research
sort
of
work.
Right
now
trying
to
understand
how
people
view
it
and
how
they'd
like
to
proceed
forward
and
the
responses
were
getting
there
is
they
want
to
be
able
to
comment
and
discuss
requirements
internally,
so
it
looks
like
and
I'll.
E
Let
him
summarize
his
findings
entirely
when
he's
done
with
all
the
interviews,
but
it
looks
like
there's
actually
a
couple
things
like
labels
and
discussions
on
requirements
that
seem
to
kind
of
bubble
to
the
top
for
the
non
regulated
industries,
as
they
can
adopt
much
sooner
and
they're,
looking
more
for
future
features
or
to
expand
the
future
set
in
different
ways.
So
it's
kind
of
a
hard
balance.
We
can
easily
collect
data
on
the
non
regulated.
The
regulated
people
generally
are
in
their
own
instances
and
do
not
allow
metrics
tracking
for
specific
reasons.
E
J
It
like
because
everyone
under
this
when
I
talk
to
customers
who
they
think
gitlab
doesn't
do
can't
do
defect
tracking
right,
so
you
can't
add
a
defect
or
which
is
just
an
issue.
We
call
it
or
that
we
don't
have
user
stories
right.
Is
it
the
case
where
sometimes
folks
are
thinking
that
requirements
are
a
different
name
for
what
we
call
issues
to
a
certain
degree?
I
have.
E
Received
that
a
lot
I
think
people
don't
crack.
Generally
speaking,
the
SAS
world
doesn't
think
of
requirements
at
all
like
the
regulated
world,
which
is
why
we're
trying
to
kind
of
bridge
this
gap.
The
the
work
is
similar
even
in
like
the
world
we're
in
right.
Now
we
have
user
stories
and
we
want
to
write
issues
and
epics
to
fulfill
the
user
stories.
Those
are
requirements,
we
do
design
work
and
we
attach
the
designs
to
issues.
Those
are
requirements.
E
People
don't
like
the
word
requirements
because
they
think
it
means
regulated
and
it
doesn't
have
to
we're
kind
of
down
this
hole
where,
if
we
don't
call
them
requirements,
people
don't
really
understand
what
they
are.
But
there
is
a
large
educational
gap
here
right
now
that
we're
trying
to
kind
of
overcome.
You
know
in
the
future,
I
think
a
lot
of
people
want
to
tag
design
as
a
requirement,
and
that's
we've
heard
that
from
a
lot
of
them
non-regulated
people,
because
they
design
is
requirement,
and
so
is
the
user
story.
E
But
what
we're
trying
to
convince
people
of
is
the
design
should
be
attached
to
the
requirement
and
the
issues
and
epics
should
be
the
implementation
of
the
requirement
and
the
design
not
like
the
issue
is
a
mode
of
change
or
a
mode
of
work.
It
is
not
the
design
of
the
requirements
and
we're
trying
to
kind
of
figure
out
where
we
fit
in
there
and
it's
been
a
little
bit
challenging
so
far,
but
I
think
we're
making
some
great
headway
so.
A
J
J
You
know
and
like
we've
gotten
a
lot
of
feedback
where,
if
you
also
want
quality
management,
so
they
think
it
lab
doesn't
do
tests
so
like
I,
don't
know
where
that
misconception
comes
from,
but
I've
noticed
all
these
weird
things
where
people
call
things
different
things
based
on
what
market
they're
in
or
their
company
culture,
and
it's
all
over
like
we
have
a
lot
of
those
same
things.
But
I
just
want
to
be
clear
that,
like
you're,
absolutely
the
right
object
for.
E
The
right
solution,
my
absolutely
correct,
with
your
idea
that
our
requirement,
you
were
right
tests
against
your
right
code
to
implement
that
is
fairly
what
a
requirement
is
in
any
way.
You
want
to
phrase
it
job
to
be
done
requirement.
There's
lots
of
names
for
the
same
concept,
however,
traditionally
in
in
like
well
I,
think
a
lot
of
the
methodology
is
right.
Now
you
read
an
issue
to
implement
the
requirement.
We
were
in
an
issue
to
create
a
feature,
and
then
the
software
teams
go
out
and
they
write
the
feature
based
on
the
design.
E
That's
been
provided
and
the
issue
they're
looking
they're
referring
back
to
the
issue
and
then
when
it's
done,
they
close
the
issue,
which
is
fine,
but
we
don't
have
any
long-standing
record
of
the
product
except
for
the
product
itself.
We've
lost
it
because
the
issue
is
closed
and
it
gets
buried
in
over
years
it
kind
of
goes
away,
whereas
when
you
keep
requirements,
you
write
through
the
design
and
the
requirements
in
the
requirements
section.
You
have
an
issue
that
says:
hey
we're
gonna
implement
this
feature.
E
You
often
implement
it,
but
the
requirements
are
long
lived
and
the
tests
are
long
lived
and
the
test
tests
requirements,
and
they
you
will
continue
to
run
that
test
potentially
for
years
and
years,
because
you
want
to
make
sure
nobody
broke
your
feature
and
you're
running
it
against
those
requirements.
If
you
want
to
change
the
feature
you
go
in
and
change
the
requirements,
then
you
again
have
that
that
long-standing
permanent
goal
of
what
you're
actually
building
and
the
issues
are
the
method
of
change.
E
J
Traceability
is
important,
but
for
the
non
regulated
it's
more
compliance
related
where
like
they
need
to
look
at
and
verify
that
things
are
done
basically
and
that
they're
compliant.
So
that's
where,
like
I've
gotten
a
lot
of
requests
for
doing
gated
checkpoints
on
issues
or
which
is
basically
a
set
of
approvals
where
you
say
who
can
approve
this
issue
before
it
goes
on
this
next
workflow
stuff
just
and
because
they
want
to
be
able
to
programmatically,
have
traceability
through
the
decision
tree
and
also
the
output
tree.
J
E
Absolutely
and
that's
the
one
thing
I
keep
saying
and
I
know
that
people
have
been
on
calls
to
me
of
heard
this
a
million
times,
but
requirements
and
the
the
testing
of
requirements
indicates.
Reading
product
is
complete,
it
is
not
an
indicator
in
your
product
is
correct,
so
you,
your
requirements,
define
the
product
and
the
testing
defines
the
completion
of
the
product.
Correctness
has
to
do
with
the
validation
of
the
requirements.
That's
a
whole
other
process.
E
That
organizations,
especially
in
the
regulated
world,
will
go
off
and
validate
those
requirements,
but
it
has
nothing
to
do
with
a
software
lifecycle.
You
built
a
product
that
meets
the
requirements.
The
product
is
complete,
whether
or
not
it
works.
If
it
doesn't
work,
that's
whoever
gave
you
the
requirements
is
fault,
not
the
now,
that's
slightly
different
in
in
sort
of
our
way
of
thinking,
whereas
if
it
doesn't
work,
we
go
and
figure
out.
Why?
Where
do?
We
went
wrong
in
the
requirements
and
we
make
those
necessary
updates
when
we
flow
back
through
our
process?
J
Not
that
in
conflict
with
the
original
agile
manifesto,
where
I'm,
like
the
basis
of
extreme
programming
where
you're
your
stakeholder
rights,
the
rights
the
test.
Basically
it
gives
you
the
things
Diego
implement,
based
on
like
business
in
business,
language
right
and
then
the
team
goes
and
builds
it
and
then
shows
it
to
the
stakeholder
and
says
hey
here.
This
is
what
you
said:
here's
how
its
complete
here
to
test
the
show,
that's
complete,
and
it's
it's
very
common
I.
Think
it's
just
in
regular,
like
regulated
industries,
I
feel
like
they
do.
E
And
what
the
regulated
industries
have
done
is
they've
actually
done
a
series
of
mini
waterfalls
to
make
water
flow,
more
agile,
so
they'll
break
the
product
into
hundreds
of
small
pieces.
They'll
run
those
individually
through
the
waterfall
method
and
then
they'll
get
their
feedback
faster
because,
instead
of
building
the
whole
thing,
they're
building
just
a
small
piece
that
plays
into
the
next
small
piece,
and
they
do
that
simply
because
the
regulatory
authorities
will
not
allow
a
jille
to
certify
for
right
now,
I
believe
it's
automotive,
medical
and
aerospace
cannot
certify
if
they
don't
Waterfall.
E
To
some
degree,
you
have
to
show
your
design
is
fully
reviewed
after
your
requirements
are
fully
reviewed,
which
you
reviewed.
You
know
the
design
has
to
be
reviewed
prior
to
starting
the
code,
like
everything
has
to
be
done
in
lockstep
because
of
the
certification
agencies,
but
they're
breaking
those
steps
into
smaller
pieces
to
get
a
more
agile
flow.
It's
all
the
same
thing
in
the
end.
It's
just
what
we're
naming
things
and
I
think
that's.
The
biggest
thing
is
you're.
Absolutely
right.
Angel'
can
play
nicely
with
requirements
very
easily.