►
From YouTube: Plan stage weekly - 2020-03-04
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
Hi
I
just
want
to
give
an
update,
for
it
looks
like
the
f
121
headcount
looks
like
we're:
gonna
get
three
new
engineers
for
certify
and
new
back
in
engineering
manager
plan,
and
then
we've
also
requested
three
additional
engineers,
sir
I
think
you're
in
the
contingency
phase,
which
is
not
exactly
short.
That
means
but
I
think
it's.
Basically.
B
If
we
hit
certain
benchmarks
to
the
company
in
terms
of
like
revenue
growth
that
sort
of
thing,
then
we
may
be
able
to
get
those
additional
three
at
some
point.
So
it's
not
as
many
people
as
we
had
hoped
for,
which
means
I
think
we're
gonna
have
to
take
a
slightly
different
mentality
this
year
and
like
with
ruthlessly
prioritize
things
and
like
work
on
getting
more
efficient
from
process
standpoint,
so
that
we
can
make
meaningful
progress
which
I
think
and
at
the
end
of
the
day,
we
should
be
able
to
do
so.
A
Yeah
so
a
couple
points
there
mark
there's
three
new
back-end
engineers
for
certified:
it's
my
understanding
that
that
doesn't
necessarily
mean
we
have
to
get
three
back
in
engineers
for
certified.
If
we
decide
throughout
the
year
that
we
need,
we
have
more
money
for
a
front-end
engineer
for
project
management.
We
can
switch
that
around
when
the
when
the
time
comes.
A
The
the
main
point
of
the
three
new
engineers
is
that
we
have
headcount
allotment
for
three
engineers
within
a
play
on
stage,
so
that
second
part
is
I,
think
be
from
what
I
just
saw
Tim
put
out
his
initial
order
of
when
we're
going
to
hire
these
three
engineers
and
it's
lower
compared
to
some
of
the
other
stages
within
dev.
So
we
may
not
actually
make
our
first
hire
until
later
on
in
the
year,
but
that,
just
like
the
their
part,
is
I,
think
flexible.
A
B
Yeah
I
think
that,
like
I
know
the
park
managers
needed
to
get
together
and
kind
of
look
at
the
goals
for
the
year
and
what
we
originally
planned
and
and
adjust
the
plan
a
little
bit,
but
also
think
this
means
like
we
should
really
focus.
We
can
get
a
lot
of
love
leverage
just
by
improving
how
we
work
and
I
think
there's
a
lot
of
it's
a
good
exercise
to
go
through.
So
that's
just
something:
I
want
to
continue
to
explore
together
this
team.
B
B
This
is
one
of
those
like
high-priority
things
that
was
handed
to
us
from
a
PI
which
is
totally
fine
and
I.
Think
we're
going
to
run
with
it
as
far
as
you
can,
but
this
also
means
we
have
to
make
some
trade-offs
on
what
we
don't
work
on
an
immediate,
so
we're
gonna
continue
exploring
that
I.
Think
John
has
the
next
point
to
talk
about
that.
Further
John,
you
wanna,
take
it
away.
Yeah.
D
C
Why
put
two
people
on
it
when
we
can
put
four
well,
my
question
is,
and
what
are
we
prepared
to
drop
to
make
this
a
success?
So
I've
listed
some
of
the
stuff
we're
currently
working
on
requirements,
management,
MVC,
health
status
and
epics,
real-time
sidebar,
sprint
time
boxes
and
data
collection
for
burn
up
the
burn
down
charts,
but
that's
only
part
of
this.
We
have
other
stuff.
We
have
blocking
issues
diffs
and
if
issue
descriptions,
we're
also
collecting
mentions
for
the
eventual
notification
center,
so
we're
doing
a
lot
of
stuff.
B
B
Will
that
be
efficient
use
of
people
on
their
time
if
it
is
deemed
it
could
be
like
I've
had
the
experience
where,
when
you
starting
something
new
and
an
NB
C,
it's
unknown,
if
you
put
more
than
two
people
on
it,
you
end
up
like
turning
until
you
get
to
a
point
where
there's
clear,
like
groupings
of
work
that
can
be
worked
on
in
parallel
and
so
I
don't
want
to
throw
more
people
on
something.
What
is
it
Brooks
off?
Like
you,
add
more
people
to
the
team,
that's
already
late.
It
just
makes
it
later.
B
A
Yeah
I
agree,
especially
I
mean
cuz.
We
can.
We
might
be
able
to
get
away
with
like
two
back-end
engineers
working
on
the
back-end
stuff
and
then
two
front-end
engineers
working
in
parallel,
but
even
at
that
point,
they're
going
to
be
working
like
on
the
front
end
side,
they'd
be
working
on
separate
I
mean
the
only
way
to
do
this
efficiently
would
be
if
they
were
working
on
like
separate
routes
or
separate
parts
within
the
within
the
app
I.
A
Don't
know
if
there's
a
whole
lot
of
parallelization
that
we
can
do
on
the
front
end
on
the
back
end
I,
don't
know
I
kind
of
I
kind
of
agree
with
Gabe,
but
John.
You
probably
answer
that
a
little
bit
better
than
anything
more
than
two
engineers
working
on
the
back
and
again
in
separate
parts
of
the
app
would
be
diminished
returns.
C
Yeah
I
mean
we
have
the
work
split
into
separate
parts
of
the
app,
so
it
is
possible
to
do.
But
my
feeling
on
it
is
that
it's
not
just
that
you
you're
going
to
be
writing
code
you've
to
keep
all
the
state
in
your
mind
as
well.
So
every
engineer
working
on
it
has
to
understand
the
parts
around
their
part,
not
just
the
part
that
they're
working
on
so
there's
all
this
overhead
as
well.
C
So
honestly,
like
guys
I,
think
two
people
is
probably
fine,
but
we
are
still
going
to
have
to
drop
some
things
that
are
in
progress
and
I
just
wanted
to
to
put
it
right
there
in
a
call
where
all
three
PM's
are
on
and
so
that
you
know
you
can
work
it
out
fairly
amongst
yourselves
or,
however,
you
want
to
do
it,
but,
but
nevertheless,
we
will
have
to.
We
will
have
to
have
some
risk
of
stuff
slipping,
that
we
expected
to
do
in
12,
9
and
12
10.
That
simply
won't
happen.
I.
E
Mean
for
my
experience,
I
think
our
best
bet
is
to
you
understand.
You
know
if
you
can
paralyze
work
and
you
need
additional
resources
that
lots
make
the
call
sooner
rather
than
later,
to
cut
something
and
just
say
it's
cut:
let's
not
try
to
linger
on.
They
said
there's
four
or
five
other
things.
If
we're
gonna
cut
something,
let's
just
completely
cut
it
and
free
those
people
up
sooner
rather
than
later,
rather
than
get
six
things
that
are
partially
done,
I'd
rather
see
of
that
list.
E
A
E
Been
looking
at
it,
it
doesn't
look
like
a
bad
priority
list.
To
be
fair,
I
mean
we
can
definitely
debate
things.
I
know
that
you
know
JIRA
importer
is
coming
from
on
high.
That
is
something
that's
incredibly
important.
I
also
know
the
requirements.
Management
is
under
kind
of
scrutiny,
so
those
two
to
me
I
know,
are
up
there
in
the
list.
I
can't
speak
necessarily
to
relative
priority
to
the
other
ones.
We
have
to
probably
sit
down
and
churn
through.
F
B
C
Just
there's
one
thing
about
the
the
sidebar
and
that's
that
it's
it's
work
that
involves
multiple
teams
and
it's
taken
a
long
time
to
to
reach
decisions
and
I
that
it's
underway.
For
example,
we
have
to
make
some
changes
to
the
reverse
proxy.
We
have
to
make
some
changes
to
I'm
nipa
Stan
included
for
cell
phone
with
self
hosted
customers.
C
So
that's
a
little
bit
of
an
outlier
like
there
I
believe
there'd
be
extra
cost
to
putting
that
aside,
because
we
put
outside
now
it
will
take
a
long
time
to
run
for
backup,
I'd
actually
say
the
same
with
requirements
management,
but
for
different
reasons
and
I.
Don't
know
if
that
helps
at
all
I
think.
B
The
Sprint
time
boxes,
we
can
probably
push
a
little
bit
there's
some
people
that
are
gonna
be
out
of
happy
about
that,
especially
high
paying
customers,
but
I'm
also
not
happy
with
the
proposed
solution
in
it.
It's
not
it's
not
the
right.
One
like
it
will
solve
60%
of
the
problems,
but
it
also
and
I'll
talk
about
this
a
little
bit
further.
B
When
I
asked
for
a
feedback
on
it,
but
that
one
we
can
probably
shelve
the
the
data
collection
and
the
burn
up
charts
been
we
this
for
releases,
because
that
I
think
we
need
to
get
it
done.
I
agree
with
that.
We
could
probably
side
table
the
migration
stuff
and
for
notifications
and
pick
that
back
up
when
we
have
a
little
bit
extra
capacity.
It's
like
that's
been
like
a
long
run
theme,
but
it's
not
a
like
urgent
matter.
B
So
I
don't
know
if
that
helps,
but
I
do
agree
with
real-time
stuff
like
we
need
to
get
the
base
underlying
functionality
working.
If
we're
at
that
point
where
it's
finally
moving
I,
don't
want
to
like
kill
the
momentum
there,
even
though
it's
not
like
dramatically
gonna
impact
revenue
in
the
next
release
or
two.
It's
like
one
of
those
underlying
things
that
we
have
to
have
in
place
for
our
overarching
strategy
and
usability
of
the
proc
to
be
where
we
wanted
to
be
in
a
year.
So.
A
That's
really
like
cross
across
group,
touching
so
I,
don't
know
if
I
don't
know,
I
think
this
is
a
good
exercise,
but
I
think
each
of
you
three
PMS
should
really
go
through
and
prioritize
what
we
currently
have
in
the
backlog
and
then
maybe
we
can
just
remove
like
the
bottom,
the
bottom
ask
or
the
bottom
the
lowest
priority
item
from
each
of
the
groups,
and
then
we
make
the
JIRA
importer
just
be
the
top
priority
for
each
group.
You
know:
does
that
make
sense
and
I
think
from
this
list.
A
F
We
have
any
feedback
from
the
engineers
that
would
be
working
on
the
giro
report,
if
dropping
only
one
would
help
on
achieving
the
goals
delivering
it.
One
12.9
and
also
in
regards
to
like
how
many
people
should
work
on
a
specific
you
should.
We
think
this
should
be
better
answered
by
the
developers
themselves.
Then,
plant
managers,
that's.
H
H
H
B
When
you
run
across
those
weird
things,
you
can
always
like
ask
the
question
and
JIRA
feature
channel
and
I
can
help
jump
on
that
too,
and
like
look
into
it
aside,
I
stumbled
across
the
same
thing,
where
there's
a
ton
of
like
different
statuses,
there's
not
just
open
in
progress
and
closed
there's
like
35
or
40
different
statuses,
they've
all
map
to
different
meetings,
so
I'm
happy
to
help
serve
that
stuff
out
with
you.
Whatever
you
get
there.
H
F
Have
also
some
concerns
of
like
starting
something
new,
why
we
have
a
lot
in
progress
having
to
stop
things
that
have
already
started,
means
that
we
will
simply
be
starting
more
things
than
finishing,
which
is
a
huge
problem.
So
I
would
like
to
understand
more
the
reason
for
dropping
things
that
have
already
started
to
start
something
else
than
finishing
what
is
already
in
progress
and
starting
something
new
when
we
have
delivered
what
is
already
closed,
I.
B
The
the
underlying
reason:
why
is
there
right
now
as
the
company's
getting
ready
to
go
public?
We
have
to
make
a
decision,
no
go
go
decision
by
May
18th,
which
is
not
that
long
way.
Cid
is
identified,
I
guess
the
list
of
18
plus
things
the
calls
and
fishin
see
improvements
that
he
believes
are
key
drivers
and
that
we
need
to
deliver
as
soon
as
possible.
C
I
share
that
concern
as
well.
Follow
me
buy
anything.
We
delay
will
take
longer
to
pick
up
again
and
start
running
with,
but
it's
a
simple
fact
that
if
we
allow
current
running
things
to
complete
before
asking
engineers
to
take
up
the
Jairam
porter
stuff,
we
simply
won't
make
12
10.
All
the
evidence
shows
like
just
although
our
past
velocity
just
shows
that
we
won't
make
it
so
yeah.
This
is
our
only
only
only
choice
really
want
to
make
up
a
12-ton.
G
Yeah,
it's
a
good
thing
to
bring
out
I
just
want
you
guys
to
know
that
we
hear
that
or
that
we
hear
that
and
I
would
strongly
suspect.
This
will
not
be
a
Reds,
not
a
regular
occurrence.
This
is
not
a
normal
function
that
we're
gonna
what
we
want
to
foster.
So
we
understand
over
here
that
it's
it's
uncomfortable
for
for
all
of
us
and
it's
it's
been
a
little
bit
of
a
interrupts
cycle,
but.
H
Person
working
on
the
people,
who
should
be
more
than
enough
I,
guess
and
even
the
second
one
might
be
like
at
least
for,
like
being
able
to
cover
in
case
I,
just
need
to
take
a
day
off
or
something
like
that,
but
yeah
I,
don't
think
we
need
to
for
people
on
the
back
end.
It's
especially
for
the
NBC
to
be
working
on
so
just
together.
E
Let's
excellent
feedback
I
mean
to
be
honest,
the
things
that
have
slowed
us
down
in
the
past
I
think
have
been
reviews,
for
you
know,
Andy
through
a
database
reviews
in
those
types
of
things,
I
think
our
efficiency
gains
may
be
best
utilized
by
ensuring
that
there's
proper
support
for
the
back
of
the
front
teams
as
in
more
people
and
then
figuring
out.
How
are
you
expedite
the
rest
of
the
process
surrounding
the
work.
A
Yeah,
so
that
that's
a
great
point
since
this
is
such
a
high
priority
item,
not
just
within
our
stage
but
for
the
organization
once
we
get
something
in
review,
use
myself
and
John
and
we'll
bring
in
anyone.
We
have
to
to
to
use
some
of
our
art
art
collateral,
to
get
things
moving
quickly
in
review.
It's
like
once.
A
Something
gets
into
review,
go
ahead
and
ping
us,
and
we
can
keep
on
the
review
process
to
make
sure
that
you
get
feedback
quickly,
we'll
work
through
and
figure
out
as
far
as
time
zones,
because,
ideally
we
can
get
someone
that
has
bandwidth.
Look
at
reviews
right
after
right
when
it's
ready,
so
just
just
use
us
and
we
can
help
guide,
guide
things
through.
That
process
create.
B
I
Just
wondering
those
those
18
things
if
they're
all
fundamentally
features
the
team's,
some
were
working
on,
whether
it
would
be
helpful
if
the
company
had
visibility
of
those
that
way
if
you'll
review,
oh
and
one
of
those
things
lands,
you
know
it's,
you
know
p1.
B
Yeah
now
all
there
were
features.
Here
I
am
pacing
this
in
the
summer
9.
If
and
I
mean
it's
public
to
the
company,
so
anybody
can
look
at
it,
but
yeah
they're
not
all
features.
Some
of
them
are
like
it,
Jenkins
importers,
another
one.
That's
got
prioritized
or
Jenkins,
rapper,
I,
guess
other
small
things
like
reducing
CI
minutes
from
for
core
for
free
limit,
storage
and
free,
just
like
a
bunch
of
different
things.
So
this
is
this
list.
You
can
look
at
it.
They
have
meaning
about
it.
Every
day.
B
Cool
all
right,
I
might
have
to
drop
in
just
a
minute
for
another
meeting
with
a
customer.
There's
I
put
down
here
to
a
couple
like
bugs
type
issue,
things
performance,
things
that
need
to
be
addressed
as
well.
It's
run
into
the
mix
and
then
key
and
also
linked
a
couple
critical
bugs
that
need
to
be
addressed
in
timely
manner.
T-Mobile
got
hit
with
the
performance
stuff
on
the
filter
bar
and
the
database.
Query:
it's
not
optimized,
then
we
have
performance
problem,
one
comments
on
merge,
requests
and
probably
issues
as
well.
B
G
Yes,
I
think
they're
heard
they're
already
in
flight,
so
I
was
just
calling
them
out
that
we
used
to
make
sure
you
don't
cross
the
line.
I
think
it's.
It
really
just
comes
down
to
the
performance
bugs
around
the
epic
tree
and
handling
creation
edition
of
issues
to
the
to
an
epic.
They
were,
you
can
see.
If
you
go
through
and
read
the
comments,
they
were
looking
forward
to
those
updates
and
waited
for
a
couple
releases
for
him,
and
then
they
were
fairly
frustrated
when
they
didn't
operate
properly.
G
So
there
is
a
cab
meeting
coming
up,
there's
a
virtual
one
in
like
an
hour,
but
the
one
there's
one
in
April
that
you
know
we
have
to
shake
that
guy's
hand
so
or
a
fist
bump
because
of
health
concerns.
But
we
should
wait.
Lee
just
need
to
get
those
done,
because
it's
not
only
causing
problems
for
like
big
customers
but
causing
hard
adoption
issues
internally
as
well.
B
This
kind
of
goes
back
to
the
Sprint's
time
box
thing
and
why
I
like
I'm,
not
happy
with
it
right
now,
so
like
the
basic
proposals
that
stands
is
to
put
Prince's
like
another
time
box
that
you
know
you
can
turn
on
in
a
group
or
that's
already
on
by
default
in
a
group
or
project
the
whole
point
of
having
a
sprint
and
being
able
do.
Sprints
is
so
that
you
can
measure
your
velocity
one
from
one
sprint
to
another.
B
If
you
look
at
that
whimsical
diagram,
it's
like
the
basic
brain,
teaser
problem
that
is
like
hard
solve,
given
our
current
constructs
in
the
product
like.
If,
if
we
as
a
team,
let's
say
the
planned
stage
want
to
have
our
own
sprint
and
let's
say
the
manage
stage
wants
to
have
their
own
sprint
and
we
both
like
because
of
the
way
the
group
structure
works.
We
have
to
do
that
either
on
the
project
itself
or
at
the
top-level
group
or
group.
We
would
be
running
the
the
two
sprint
sprint
objects,
but
they
wouldn't
be
related.
B
They
would
be
four
different
teams,
and
so
you
still
can't
calculate
the
velocity
for
each
team.
You
couldn't
have
like
a
workflow
for
our
team
and
a
workflow
for
their
team
and
so
like
the
the
underlying
contract,
like
I'm,
not
sure
how
to
solve
this,
like
in
a
fundamental
level
within
the
product
like
the
idea
of
it's
great,
but
it's
also
usually
in
other
products.
B
It's
scoped
to
a
project
which
has
a
specific
team
or
its
scope
to
a
specific
team
of
people
which
we
don't
have
that
and
get
lab,
and
so
like
I,
don't
want
to
just
rush
forward
and
build
this
into
the
product.
If
it's
not
really
going
to
solve
the
underlying
problems,
and
it's
not
scalable
to
accomplish
the
customer
jobs
that
we
intended
it
to
so
I
didn't
know.
If
anybody
had
any
thoughts
about
how
to
solve
this.
D
G
Well,
I
mean
I.
We
also
have
an
interesting
internal
problem
with
it,
simply
because
it's
a
shared
project
across
New,
York
right
so
often
times
and
other
tools
and
other
companies.
Its
milestones
are,
like
you
know,
probably
just
pointing
out,
are
often
associated
it
directly
with
the
team,
and
then
those
teams
are
usually
associated
with
one
or
a
few
projects
or
repos
or,
however,
you
want
bracelet.
So
our
construct
brings
that
a
little
bit
so
I
think
that
I
guess
just
some
context
on
why
this
is
a
head-scratcher.
A
Yeah
and
I
don't
have
any
answers
or
solutions,
but
I
will
definitely
add
that
it
is
something
we
should
solve
for,
because
one
Spotify
kind
of
made
the
whole
cross-functional
team
approach
popular
one
of
their
biggest
things
where
that
teams
are
autonomous
and
should
be
able
to
have
their
own
sprint
sprint.
Lengths
essentially
have
their
own
workflows
and
you're
right.
We
have
no
way
of
accounting
for
that
and
that's
how
a
majority
only
may
not
a
majority,
but
a
lot
of
our
customers
are
going
to
want
to
want
to
handle
to
workflows
yeah.
B
So
that
this
is
like
why,
if
we
want
to
get
people
to
switch
over
to
plan,
we
have
to
solve
for
this
problem.
So
is
it
an
X
action?
Should
I
schedule
like
just
an
open
forum
for
us
to
discuss
this
and
like
an
office
hour
type
format
or
what
would
be
the
best
format
to
work
together
on
this
I?
Think.
G
That'd
be
good,
and
if
we
come
with
a
couple
like
strong
examples,
saying
look
Cupid
here
we
put
it
here.
We
cater
pros/cons
just
to
have
conversation
starters
and
then,
as
a
group
like
point
out,
what
doesn't
what
wouldn't
work,
what
would
be
complicated,
wouldn't
be
hard
and
then
we
can
try
to
maybe
come
up
with
a
ambassador.
A
Cool
that
sounds
good
and
then
okay
I
know
you
have
belief,
but
your
last
point
around
whip
limits.
Yes,
we
should
definitely
document
what
they
are.
I
think
we
have
a
little
bit
of
documentation
in
the
group
back
in
pages,
and
then
we
have
a
little
section
in
the
group
or
in
that
staged
front-end
engineering
section.
A
B
G
A
Think
so
John
created
a
bunch
of
issues
this
morning
this
my
morning,
mind
a
tweet
good
morning
all
so
this
is
my
really
early.
I
went
in
there
and
added
some
front-end
work.
I
know
alexandria's
doing
some
a
little
bit
more
investigation
into
into
more
detailed
requirements
for
each
of
those
issues.
So
I
think
we
have
a
plan
for
that
and
we
are
already
starting
to
like
Alexandra
I
think
is
and
isn't
a
constant,
but
I
think
that's
your
priority.
Right
now
is
going
through
the
dreary
importer.
H
I
actually
started
today,
working
on
a
concept
just
to
get
the
workflow
so
to
say
in
place
yeah.
So
if
I
don't
like
I
said
I
at
least
I
stumbled
on
the
states,
as
we
discussed
using
the
author
as
a
taking
Porter
and
so
on,
so
there
is
more
stuff
coming,
but
but
then
this
fee.
This
is
the
next
kind
of
thing
right
now.
I
just
said
it
to
import.
Everything
is
open
issues
which
is.
H
G
That's
great
progress.
That's
really
good
here
and
I
just
want
to
echo
what
Gabe
said
like
as
you
run
into
anything
or
even
if
you
just
like,
want
to
showcase
what
you
pulled
off
and
when
you
get
done
just
drop
it
in
that
slack
channel
like
we'd
love
to
see
it,
and
then
that
helps
us
gonna
communicate
up
as
well,
and
hopefully
that
will
reduce
any
friction.
G
C
Yeah,
it's
gonna
be
mostly
a
bit
more
technical,
I
guess,
but
the
six
issues
that
are
on
that
epoch
currently
I
think
almost
all
of
them
have
some
one
unanswered
questions
in
the
description.
Some
of
them
are
technical.
Some
of
them
are
could
be
answered
by
a
PM.
So
please
do
have
a
look
through
and
see.
C
If
there's
anything
you
can
answer
and
one
example
would
be,
for
example,
in
the
original
in
the
epic
description,
it
has
a
requirement
that
new
projects
and
existing
projects
can
import
issues,
but
the
solution
that
we
currently
have
that's
the
easiest
to
build
is
to
do
for
an
existing
project,
so
the
person
creates
a
project
and
they
are
the
credentials
and
then
they
issue
the
import.
So
if
we're
going,
you
know
if
we're
going
with
that
one,
it's
much
easier.
C
G
Know
for
sure
I'll
go
get
that
one
and
clean
it
up,
because
I
think
that
probably
might
just
be
a
copypasta
issue.
But
of
course
any
time
if
there
is
a
question,
as
you
can
imagine,
we
get
tons
of
notifications
and
pings
and
we'll
keep
us
on
the
top
of
stack.
But
if
there
is
something
that
needs
an
answer,
just
ping
us
right
away
anybody
who's
working
on
it.
Well
one
of
this'll
hop
in
there
at
all
sorry.
C
D
C
C
D
C
D
F
A
F
Would
say
so,
I
think
it's
more
about,
like
the
most
common
classes
of
service,
that
I'm
aware
of
are
like
expedite
things
that
can't
waiting,
cubes
standard
features
or
bugs,
or
whatever
things
that
have
a
due
date-
that
if
we
don't
deliver
in
that
specific
due
date
like
be
penalized
or
lose
some
market
opportunity,
or
something
like
that,
and
there
is
another
one
that
I
don't
remember
from
the
top
of
my
mind
that,
but
those
are
the
three
that
I
remember
from
the
top
of
my
head.
Yes,.
A
I,
don't
know
if
we've
defined
using
classes
of
services
explicitly
yet
I
think
the
idea
for
now
is
if
something
is
a
high
priority
that
we
need
to
get.
The
idea
we
have
of
having
separate
columns
with
with
limits
is
that,
if
something
needs
to
get
into
a
column
that
is
over
the
WIPP
limit,
we
now
have
the
ability
to
move
that
thing
to
the
top
of
the
list.