►
From YouTube: Plan Team Weekly 2020-09-30
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
D
All
right
plan
stage
weekly
meeting
what
date
is
the
30th
of
september
2015..
I
have
the
first
item
yeah
so
like
this.
Mr
came
up.
I've
been
turning
it
over
on
my
head
for
a
couple
of
weeks,
and
I
wanted
to
talk
about
it
in
the
meeting
here.
While
we
have
a
few
different
like
stable
counterparts
here,
because
I
mean
like
we
should
be
doing
this
anyway,
so
the
mr
encourages
engineers
to
prefer
vertical
feature
slices
over
horizontal
slices.
D
Luckily,
we
have
lots
of
examples
that
we're
currently
working
on
where
we've
done
both
but
yeah.
I
had
some
concerns
about
it
originally,
like
the
idea
in
xp.
I
suppose,
is
that
feedback
loops
when
you're
programming
the
length
of
the
feedback
loop
is
really
important
to
reduce
in
cycle
time
and
so
in
extreme
programming.
D
You
kind
of
reduce
that
to
zero
practically
by
pairing
all
the
time,
and
I
was
worried
that
this
would
actually
increase
feedback
feedback
loop
times
because,
like
if
there's
a
fundamental
change
that
needs
to
be
made,
you
have
to
go
right
back
to
the
beginning
when
the
code
review
comes
in.
D
On
the
other
hand,
like
I
think,
it's
a
pretty
good
foursome
function
to
like
radically
think
about
how
we
iterate
and
so
two
examples
right.
Typically,
what
we
would
do
is
take
a
feature.
That's
coming
up,
like
epic
assignees,
it's
very
very
hard
to
think
about
how
we
could
do
that
any
more
atomically
than
simply
apply
assignees
to
epics.
D
You
break
it
down
to
the
level
of
maybe
we
could
ship
it
as
a
graphql
back-end
feature
first,
and
then
people
can
automate
assigning
and
whatnot,
but
it's
very
hard
after
that,
to
do
anything
but
slice
it
horizontally.
D
On
the
other
hand,
like,
maybe
we
should
be
asking
ourselves
like
what
would
we
build
if
we
couldn't
write
any
code
at
all
and
then
what's
the
absolute
minimum,
we
could
do
so.
Another
example,
I
thought
of
was
quality
management
which
we
have
at
the
minute.
D
We
have
we're
producing
a
new
issue
type
for
test
cases,
usually
we'll
be
able
to
select
that
issue
type
view
list
of
test
cases
and
so
on,
but
maybe
if
we
couldn't
write
any
code
at
all,
what
would
be
the
thing
we
would
do
in
that
case,
and
I
would
imagine
that
we
would
produce
some
kind
of
issue
template
that
automatically
applied
a
label
test
case
and
we
get
all
the
functionality
all
based
with
some
downsides,
but
you
would
be
able
to
view
test
cases
as
regular
issues
and
so
on,
and
so
you
might
say
like
well,
what's
the
if
we
could
just
write
one
piece
of
code?
D
What
would
we?
How
would
we
iterate
from
that,
and
I
don't
know
what
the
answer
is,
but
maybe
you
know
a
select
that
automatically.
You
know
you
can
select
test
case
and
it
automatically
applies
that
label
so
we're
still
using.
You
know
what
I
mean:
we're
reusing
things
that
we
already
have
in
the
first
iteration
and
that
could
be
done
extremely
quickly.
So
those
are
the
two
examples
I
kind
of
thought
of.
I
was
wondering,
though,
like
that
requires
us
to.
D
In
my
opinion,
change
the
way
that
we
either
where
in
the
workflow
we
do
iteration
or
just
simply
change
the
way
we
approach
things
when
we
break
them
down,
because
I
think
we
tend
to
get
to
the
the
the
smallest
vertical
feature:
slice
and
then
immediately
we
just
horizontally
slice
it,
and
maybe
we
need
to
be
more
radical
about
what
the
smallest
feature.
Slice
actually
is
and
ask
questions
like
that.
What
would
we
write
if
we
couldn't
write
any
code
at
all
and
then
take
the
next
step?
Up
from
that?
So
yeah?
D
That's,
that's.
My
whole
ted
talk.
Basically,
I
was
kind
of
interested
to
see
what
other
people
thought
of
this.
Mr,
what
you
think
of
that
kind
of
approach
to
iteration
and
how
does
it
fit
with
you
know,
ux,
where
you
might
design
you
do
all
the
customer
research
you
design
the
feature
and
then
somebody
comes
in
and
says:
hey
we
maybe,
as
a
first
duration.
We
do
this
complete
other
thing.
You
know.
What's
that
experience
like.
E
I
think
it's
like
what
is
that
complete
other
thing
right
and
does
it
lead
towards
the
larger
vision
of
what
we
had
in
mind
and
if
you
already
kind
of
like,
I
think
what
gabe
and
I
are
saying
here,
is
if
you
kind
of
understand
the
flow
and
the
edge
cases
that
doesn't
necessarily
mean
anything
is
designed
out.
It's
just
like
you
kind
of
understand
how
you
want
this
to
go.
You
understand
the
edge
cases
you
understand
where
there
could
be
pitfalls
for
the
user
right.
E
So
if
it's
a
step
towards
that
happy
path,
even
if
it's
really
really
small,
that's
okay,
because
then,
like
a
designer
like
me,
might
understand
my
small
step
right
and
maybe
to
jon
or
donald,
that's
not
quite
the
smallest
step,
but
if
it's
getting
towards
that,
that's
fine!
I
think,
if
it's
completely
in
a
different
direction,
maybe
that's
where
we're
going
to
talk
a
little
bit
more.
I
think
you
and
I
john
even
with
epic
assignees.
There
was
an
example
in
there
where
you
know
we
didn't
have
to
do
anything.
E
There
was
just
like
a
little
code
element
that
you
had
there
that
there's
nothing
in
the
ui.
It
was
just
a
quick
action
or
something
like
that
and
that's
fine,
so
yeah
and
I
think
maybe
it's
about
planning
a
little
earlier.
E
So
we
already
kind
of
do
this,
but
maybe
it's
we
all
ideate
on
a
problem
before,
as
like.
First
step,
get
a
little
bit
better
about
that.
I
know
gabe,
you
wrote
a
bunch
here.
What
do
you
think.
F
I
kind
of
just
said
like
using
iterations
as
an
example
holly,
and
I
worked
on
some
ux
and
thinking
through
like
the
bigger
vision
for
things,
but
then,
when
we
thought
about
implementing
it
to
make
it
easy,
we
broke
it
down
into
like
specific
user
actions
like
each
click
or
each
thing
that
they
would
see
in
very
small
things
that
way.
If,
if
the
engineers
wanted,
they
could
open
up
an
mr
like
a
vertical
mr
for
each
thing,
even
though
it
wasn't
technically
complete
and
the
user
couldn't
use
iterations
the
entire
way.
F
It
still
was
like
one
step
in
the
user
path
like
the
critical
path
or
whatever
you
call
it,
and
I
found
that
that
was
sort
of
helpful
too,
and
I
think
along
the
same
lines.
My
next
point
was
at
my
last
company.
We
worked
on
this
rapid
rapid
prototyping
process
called
ux
triage
and
one
of
the
things
that
was
interesting
and
like
kind
of
I'll
just
share
my
screen,
real
quick
and
how
we
sort
of
approached
that
was
instead
of
like
even
working
on
wireframes
or
anything
like
that.
F
F
You
can
submit
invalid
what
happens
like
what
does
the
user
see
and
what
do
they
do
whenever
that
happens,
or
whenever
they
forget
their
password
and
kind
of
mapping
out,
but
basically
like
the
critical
path
the
user
takes
to
accomplish
the
thing
of
locking
in
and
where
they
go
when
it
is
valid,
and
so
without
getting
into
designing
what
the
thing
looks
like
you
can
start
to
have
a
conversation
with
engineers
in
ux
and
product
about
okay.
F
Well,
what
are
the
fields
that
would
be
on
the
login
form
that
are
valid,
so
you
can
start
talking
about
data
and
some
of
those
things
and
then
you
layer
on
sort
of
like
we
use
atomic
design
or
atomic
ux.
You
can
start
layering
on
different
components.
It's
almost
like,
let's
the
back
end
of
the
front,
end
work
in
parallel
and
also
allows
the
ux
to
work
in
parallel
on
like
improving
what
the
actual
ux
will
be
and
what
the
interface
looks
like.
F
C
I
yes,
I
think
that
does
make
sense.
I
was
just
going
to
link
to
something
similar
to
what
gabe
was
talking
about
in
user
story,
mapping,
which
I
think
is
similar
to
the
early
planning
session
that
mike
led
from
that
he
brought
from
pivotal.
I
forget
what
it
was
called,
but
yeah
just
having
something
some
process
like
that
beforehand.
C
I
think
is
super
helpful
to
answer
john's
question
that
he
had
in
there
around
yeah
inception
there
you
go
but
on
like
when
we
should,
because
I
definitely
agree
that
it
would
be
good
for
us
to
go
in
like
as
we're
planning
a
large
feature
and
think
through
think
a
little
bit
more
thoroughly
on
how
we
can
iterate
at
different
levels.
C
C
So
maybe,
if
we
could
use
this
meeting
to
do
something
like
say,
it
does
with
iteration
office
hours
because
from
those
I've
gotten
a
lot
of
value,
and
I
think
the
people
that
have
proposed.
C
Iteration
ideas
in
that
office
hours
have
have
found
value
in
that,
so
if
we
did
something
similar
to
that
either
in
a
separate
meeting
or
in
this
meeting,
I
think
that
would
be
helpful.
I
know
what
you
all
think.
D
Yeah
like
actually,
I
find
a
lot
of
value
in
those
as
well,
and
also
the
iteration
training
that
we
did
maybe
six
months
ago,
the
videos
that
came
with
that
were
quite
interesting.
I
find
really
useful
and
it's
actually
quite
liberating
as
well
like,
because
you
realize
that
at
that
point,
you're
free
to
make
these
decisions
like
I'm
mike.
D
You
can
correct
me
if
I'm
wrong
right,
but
if
you
look
at
where
we
ended
up
with
test
cases,
is
that
in
the
first
iteration
you'll
be
able
to
create
a
test
case
list
test
cases
and
view
them
right
and
you
get
like
90
of
the
way
they're
using
labels
and
issue
templates
right.
You,
you
have
some
weird
quirks
where
okay,
it's
still
an
issue,
so
it'll
still
appear
in
the
issue
list,
but
that
issue
list
can
be
filtered
by
this
test
case
label.
D
So
you
are
giving
the
user
the
ability
to
see
a
list
of
test
cases.
Next
iteration
you
could
put
that
in
the
sidebar
and
automatically
direct
them
to
a
list,
that's
pre-filtered
and
so
you're,
really
building
very,
very
little.
The
question
is,
I
guess,
like
did.
We
know
that
when
we
started
this,
you
know,
like
we
kind
of
iterated,
to
the
point
where
this
was
the
first
iteration
right
with
this
we
decided
what
we
were
going
to
deliver
and
and
that's
and
it
has
been
successful.
D
D
The
last
thing
that
I'd
have
some
concern
about-
or
maybe
I
don't
actually
have
any
concern
about,
but
some
other
people
might
is
that
you
are
going
to
have
some
duplication
of
effort
like
without
a
doubt.
You
know
you
might
have
to
design
an
interim
state
as
we
go
through
this
iteration
or
we
might
have
to
like.
G
Well,
it's
hard
because
some
of
these
features
like
test
cases
is
a
great
example
and
thank
you
for
bringing
it
up
yeah.
No,
I
completely
agree
we
iterated
back
to
a
very
simplistic
situation.
The
difficulty
is
the
feature
only
is
really
appealing
to
regulated
industries
who
have
to
be
very,
very
rigid
with
their
structure.
So
again
you
have
to
kind
of
understand
your
buyer
as
well,
in
this
case
having
a
an
issue
and
then
telling
them
they're
gonna
have
to
migrate
all
their
stuff
across
breaks
their
regulated
model.
G
So
it's
harder
for
those
types
of
customers
to
swallow.
Some
of
these
changes
than
it
would
be
for
other
customers,
so
it
you
kind
of
have
to
try
to
balance
customer
need
versus
features
and
rolling
them
out.
I
I
do
agree,
though
I
think
we
we
ended
up.
I
was
actually
really
proud
of
the
team,
probably
iterated
on
that,
and
I'm
not
sure
if
it
would
have
been
if
there's
a
better
way
to
kind
of
get
to
where
we
got,
but
I
think
in
the
end
we
got
there,
which
is
really
encouraging.
F
I
also
think
with
test
cases
interesting,
just
because
I
was
talking
with
a
customer
and
they
gave
me
a
list
of
all
the
different
issue
types
they
used
in
jira
and
test
cases
are
like
one
of
those
and
so
and
then
I
also
came
across
another
customer
who
generates
test
cases
as
issues,
so
they
can
like
watch
a
release
on
a
board
and
and
like
double
check
that
everything's
there
so,
like
I
don't
know
like
it's
sort
of
where
we
could
iterate
to
like.
F
F
You
know,
because
we
don't
really
know
all
the
ways
that
the
customers
use
everything
and
that's
at
least
what
I've
learned
is
that
there's
so
many
weird
things
that
customers
do
with
issues
and
boards
that
haven't
very
little
to
do
with
planning
so
which
tells
me
that
they've
gotten
creative
about
solving
their
problems
with
the
things
that
already
do
exist,
and
so
how
can
we
like
build?
On
top
of
that,
in
small
ways
I
don't
know,
but.
G
F
G
G
G
F
Well,
that's
also
where
we
should
talk
about,
because
it's
not
just
for
test
cases.
Every
company,
larger
company
I've
talked
to
wants
to
tie
budget
back
to
issues
and
merge
requests
right.
So
you
can
have
one
project
where,
like
it's
like
an
inner
source
thing
where
you
have
a
ton
of
different
teams
working
on
it,
but
things
have
to
get
like
budgeted
and
allocated
somewhere
and
somehow
and
tied
back
to
it
and
that's
sort
of
where
that's
like
a
universal
job
to
be
done.
F
That's
not
just
test
cases
which,
like
how
do
we
solve
that
job
to
be
done
with
tying
an
object
back
to
some
sort
of
cost
center
right
and
the
way
that
that's
solved
and
a
lot
of
other
tools
is,
you
know,
a
custom
field
so.
G
Familiar
if
you
do
a
government
contract,
you
must
every
piece
of
work
to
the
cost
center.
That
is
a
stipulation
of
winning
a
government
contract.
So
they
have
to
be
able
to
say
that
this
mro
was
done
under
what
cost
center
or
what
billing
code?
That's
a
us
government
restriction
and
they're
the
biggest
purchaser
of
software
united
states.
So
it's
something
that
a
lot
of
these
companies
are
running
into
and
I
don't
know
how
it
works
in
other
government
agencies.
But
that's
where
a
lot
of
this
is
coming
from.
G
D
Situation
all
right,
gabe
you
mentioned
there
like.
Could
we
assign
a
dri
from
each
function?
We
kind
of
do.
Do
that?
That's
the
thing.
So
I
wonder
if
it's
like,
if
it's
a
question,
we
need
to
ask
as
part
of
as
part
of
the
breakdown
as
part
of
the
iteration,
when
when
the
dri
is
assigned
like
what's
the
minimum,
you
would
do.
D
I
wonder
if,
like
I
wonder,
if
an
engineer
like
or
a
ux
or
whoever
like
coming
to
to
an
issue
is
asking
like
the
same
question,
you
know
or
if
it's
that
the
pm
understands
the
customer
need,
but
that
we
don't
and
that
the
customer
needs
might
be.
You
know,
in
the
case
of
test
cases
like
to
be
able
to
program
that
programmatically
work
with
test
cases
and
we
could
fulfill
that
need
without
building
too
much,
but
the
engineer
needs
to
understand
that
to
suggest
an
iteration
on
that
basis.
F
Yeah,
I
I
think
that
that's
part
of
it
and
also
think
part
of
part
of
it
just
goes
back
to
how
we
built
the
product.
This
far
and
thinking
about
solving,
like
a
customer
need
with
with
a
specific
thing
right.
So
the
first
thought
is:
we
need
test
cases.
Let's
build
test
cases,
the
first
thought
with
epics.
F
There's
other
there's,
like
other
other
issue
type
things
that
also
need
to
be
nested
in
the
same
hierarchical
way
like
requirements
and-
and
so
it's
almost
like,
instead
of
shifting
a
mindset,
instead
of
creating
a
new
thing,
how
can
you
build
the
a
widget,
for
example,
that
lets
you,
have
that
sort
of
relationship
and
holds
that
relationship
which
you
could
put
in
the
paid
tier?
You
know,
instead
of
creating
an
entirely
new
thing,
so
I
I'm
not
sure
wh
why?
F
I
think
async
does
make
it
hard,
but
especially
as
we're
like
kind
of
constrained
for
budget
and
resources
moving
forward
as
a
team,
I
think
it's
it's
paramount
that
we
start
to
think
about
the
smallest
change,
using
what
we
have,
and
I
think
that
that
sort
of
constraint
will
be
really
valuable
because
it'll
lead
to
more
innovative
solutions
in
the
long
run.
I
think.
E
I
mean
I
like
the
idea
of
everyone
ideating
on:
what's
the
smallest
change
or
like
what's
the
smallest
solution,
not
that
we
have
to
go
that
way,
but
just
having
that
in
mind,
especially
as
I've
designed
from
y'all's
perspective,
would
be
awesome
so
like
if
we
have
the
job,
the
user
story,
we've
broken
them
down
into
small
stories
within
the
issues
and
then
we
ideate
on
those.
I
think
that
could
make
sense
and
capture
that
within
the
issue
and
that's
like
first
step,
what
do
y'all
think
pms.
F
G
A
H
Back
to
the
mr,
which
seems
to
have
more
of
be
focused
on
the
the
mars
and
on
developers
or
engineers,
so
I
was
just
wondering
like
do
we
well,
it's
not
merged
yet,
but
it
seems
to
be
going
that
way.
So
I
was
wondering:
do
we
do
we
go?
Are
we
going
to
go
with
to
the
with
the
path
of
having
both
frontier
and
backhand
on
the
same
amar,
sort
of
to
provide
that
visibility
and
context
for
the
reviewers
or
how's
that
going
to
work,
or
is
it
a
decision
to
make
per
team?
D
Sorry
I
misread
your
name.
I
thought
I
was
alexis
who
wrote
that
point
yeah.
So
that's
a
good
question
and
everyone
stole
discussing
it
right.
I'd
prefer
not
to
see
that
I'd
prefer
that
we
went
down
the
route
where
we
simply
come
up
with
iterations
that
required
fewer
disciplines
to
be
involved
in
the
changes,
because
I
think,
once
you
introduce
more
levels
to
the
review
process
and
you
couple
things
more
things
slow
down,
that's
my
opinion,
others,
others
may
disagree,
but
also
like
sid
made.
D
This
comment
about
like
the
minimum
change,
is
the
one
that
requires
a
documentation
update
which,
like
so
you
could
like
in
in
that
context
like,
if
you
add
something
to
the
graphql
api
that
allows
the
user
to
do
something
that
they
didn't
do
before,
or
they
couldn't
do
before.
D
That's
something
that
requires
a
docs
update,
that's
something
that
you've
delivered
to
a
customer
and
that's
something
that
would
be
you
know
back
ends
only
on
the
other
hand
like
if
we
were
to
think
even
more
radically
about
it,
and
you
were
to
say
you
know
we
can
deliver
this
feature.
D
The
customer
can
do
this
thing
if
we
could
just
speed
up
just
speed
up
this
one
end
point:
the
customer
could
repurpose
it
for
x
feature,
but
they
can't
at
the
minute,
because
it's
too
slow
and
that
result
is
that
you
do
a
database
improvement
like
that
to
me
is
a
perfectly
fine
thing.
D
You
know
like
at
the
minute.
You
go
to
a
new
issue
and
you
type
in
the
title
of
the
issue
and
as
you
type
along,
it
suggests
new
issues
to
you
and
like
last
year
that
didn't
work,
because
the
suggestion
took
five
or
ten
seconds
and
it's
simply
time
died.
So
that
feature
didn't
work
at
all.
D
I
think
it
was
felipe
who
sped
up
that
feature
and
that
feature
like
that.
Endpoint
could
not
possibly
be
used
to
suggest
issues
in
any
context
in
real
time,
and
so
simply
by
speeding
up
that
feature.
You
could
provide
that
as
a
feature
to
a
customer
in
different
contexts,
different
like
separate
from
just
when
they're
creating
a
new
issue.
You
could
use
it.
For
I
don't
know
anything
anytime.
You
want
to
do
a
real,
real-time
search
by
title.
D
So
I
think
it's
it's
interesting
from
that
point
of
view
like
if
we
were
to
ship
a
brand
new
feature
with
back-end
front-end
database
design,
docs
quality,
all
in
one,
mr
yeah
from
that
mark.
That.
H
Seems
to
be
that
seems
to
be
the
idea
that
you
provide
as
much
context
for
the
maintainer
as
you
can,
so
that
a
maintainer
could
provide
you
with
better
feedback
and
so
on,
which
I
can
see
the
the
value
on
the
point
there.
But
that
does
to
me.
I
think
that
does
add
to
the
response
time,
service
and
and
review
time
on
the
mr,
especially
giving
their
stream
and
given
that
there
will
be.
H
You
know,
multiple
people
having
to
do
review
and
maintain
a
review
which
have
different
time
zones
so
that
kind
of
spans
across
more
time.
I
don't
know
if
in
total
it
will
be
more
time
if
you
split
that
mars
into
horizontal
slices
like
front
end
backhand
and
even
backhand
changes
into
multiple
smaller
marks.
Maybe
the
way
to
go
is
to
have
these
smaller
mars
reviewed
by
the
reviewers
and
then
combine
all
of
them
into
a
like
a
branch
that
gathers
everything
for
the
maintainers.
I
don't
know
what
the
solution
would
be,
but
yeah.
D
I
really
think
they
just
want
context
like
if
you're
creating
a
brand
new.
What
do
they
call
it.
C
D
A
non-recommended
term
for
it,
so
I'm
going
to
shrink
it
away
from,
but
if
you're
creating
a
brand
new
feature-
and
you
need
a
new
table
in
the
database,
they
don't
want
to
receive
the
mr
with
just
the
new
table
in
the
database,
because
we
know
it
takes
a
database
review.
It's
going
to
take
longer.
They
want
to
see
it
in
context,
so
they
want
to
see
it
used.
D
But
I
don't
think
that
means
like
we
have
to
do
the
front
end
and
do
the
interface
and
like
everything,
but
rather
just
if
we're
creating
this,
you
know
new
table.
They
want
to
see
it
in
use
through
the
api
or
something.
But
if
we're
just
speeding
up
a
query
or
something
that
makes
total
sense
on
its
own
and
it
doesn't
need
any
other
context.
That's
what
I'm
taking
from
the
mr
anyway.
H
Yeah
well
yeah,
I've
read
through
the
commands,
and
there
is
debate
back
and
forth
that
at
least
dillon
who's.
The
author
of
the
umar
seems
to
be
wanting
as
much
context
as
as
there
is
and
he's
arguing
that
combining
frontier
and
back-end
is
not
a
problem
so
to
say,
because
then
having
the
whole
context
will
help
you
rather
than
having
to
switch
through
multiple,
mrs
or
or
just
a
kind
of
a
brief
description
of
the
context
might
not
be
as
useful
so
yeah.
H
It's
not
like
at
some
point.
I
feel
like
this
turns
into
a
personal
preference
as
well
as
there
was
some
some
mentions
as
well,
but
I
don't
know
I'm
just
like
curious
and
I
want
you.
I
would
like
to
know
if
we
are
going
to
do
that.
How
are
we
going
is
there
is
something
that
we
can
decide
at
the
team
level,
at
least.
Maybe
we
can
try,
I'm
not
against
trying
it,
but,
like
my
personal
feeling
is
that
will
not
help
speed
up
things.
H
Maybe
that
will
help
certain
maintainers
to
get
more
context,
and
maybe
we
can
do
a
better
job,
providing
a
better
description
in
their
mars,
which
totally
makes
sense
providing
more
context
and
I'm
giving
a
a
better
understanding
on
what
that
specific
mark
does
and
why
it
does
it
this
way,
not
the
other
way,
which
is
totally
questions
that
can
be
asked
by
the
maintainers
as
well,
while
reviewing
stuff
so
yeah
mixed
feelings.
C
Yeah,
I
think,
the
hard
part
with
that
anytime,
we
have
a
combined
front
and
back
end
work
in
a
single,
mr,
just
throughout
the
review
process.
That's
at
minimum
six
contributors
working
on
the
one
mr,
which
is
going
to
just
add
overhead
to
the
just
the
collaboration
aspect
of
it
is
going
to
add
overhead.
C
C
The
front
end
is
essentially
just
another
just
another
consumer,
so
for
back-end
reviews
on
api
changes,
I
mean
we
should
have
enough
context
within
the
mr
or
within
the
issue
that
they're
not
really
going
to
that
we're
not
really
going
to
need
to
combine
the
front
end
work
there,
but
I
mean
I,
I
think,
we're
still
a
ways
from
there
and
I
think
it
was
dylan.
That
was
the
author
of
the
mr
I'm
not
sure.
C
If
on
his
group,
they
are
using
like
a
lot
of
the
back
end,
they
are
building
according
to
design
and
front-end
requests.
C
Okay,
we
want
to
move
on
to
the
next
topic
next.
F
Point
sure
I'll
skip
the
one
about
the
high
level
question,
just
something
to
think
about,
as
we
look
to
sort
of
simplify
things
and
make
them,
I
think
a
little
bit
more
extensible.
F
I
was
thinking
about
what
does
it
look
like
if
you
were
to
convert
an
epic
into
an
issue
type
and
have
like
eventually
we'll
walk
to
allow
people
to
name
each
level
of
the
epic
is
something
which
is
sort
of
the
same
thing
as
type.
So
we
can
talk
about
later.
It's
not
pressing.
The
next
one
was
we're
about
eighty
percent
of
the
way
done
with
consolidate,
update
for
simplified
groups
and
projects.
F
F
So
I
created
an
update
issue
that
we're
going
to
be
once
I
get
done
with
the
videos
and
and
alex
pulley
who's.
The
engineering
lead
helping
out
with
this,
provides
a
bit
more
input.
We
are
going
to
present
this
to
product
leadership,
to
see
if
we
can
get
it
approved,
but
would
love
any
feedback
or
input
from
y'all,
because
it
does
heavily
impact
a
lot
of
stuff
within
our
stage.
So
that's
there.
F
F
Okay,
cool
next
thing:
the
real-time
working
group
has
been
amazing
and
we
now
have
websockets
live
on
canary
and
assignees
are
updating
in
real
time,
and
I
think
we're
close
to
being
done
with
working
group,
which
is
also
amazing,
heinrich
also
got
subscriptions
working
and
just
given
like.
F
I
wanted
to
raise
this
in
this
group
meeting,
because
there
are
a
lot
of
moving
parts
right
now,
a
lot
of
things
being
refactored
and
kind
of
working
towards
consolidating
sidebars
and
all
that
good
stuff,
but
like
bringing
it
for
front
like
long-term
goals.
So
everyone's
aware,
real-time
boards,
real-time
issues,
epic,
mrs
and
the
ability
to
open
an
issue
with
a
board
and
interact
with
it
and
then
hopefully,
eventually
collaborative
issue,
descriptions
and
whatnot,
but
that's
getting
into
much
more
complicated
things
where
we'll
have
to
rewrite
the
editor.
F
D
I
have
a
question:
it's
currently
enabled
feature
flags
enabled
for
gitlab
org
and
a
couple
of
other
projects.
Are
we
aiming
to
enable
it
on.com
by
the
end
of
this
milestone.
F
I
I
am
not
the
dri
for
making
that
decision,
because
I
think
it's
based
on
performance
impact,
so
I
want
to
see
it
defaulted
on
as
quickly
as
possible,
and
then
you
can.
The
folks
in
the
engineers
in
the
working
group
can
tell
me
at
the
rate
at
which
we
can
do
so.
Is
that
fair
yeah?
That's
where.
I
There's
one
front-end
bug:
we
might
also
be
waiting
to
fix
before
doing
that.
I
don't
know
johnny
you're,
probably
familiar
with
what
that
is.
F
C
Yeah
yeah
and
it's
sorry-
it's
currently
being
worked
on
for
boards
assignees,
so
it's
in
the
process,
and
it
should
be
done
by
this
milestone.
C
Till
defaulting
it
on,
but
personally
I
think
we
can
comment
on,
as
is
it's
better
than
what's
there
now.
D
C
Awesome
all
right:
let's,
let's
do
some
demos
carl,
are
you
on.
A
Yep
I'll
just
start
by
sharing
my
screen.
A
So
it's,
although
it
looks
like
a
small
change,
it's
taken
a
bit
of
time
to
get
here
because
first
I
had
to
migrate
the
label
sidebar
from
handle
to
view,
and
then
there
were
some
issues
with
the
labels
themselves
with
the
close
button
which
I
managed
to
fix,
and
then
I
had
to
wait
for
that
to
get
propagated
to
get
lab.
But
now
I'm
happy
that
this
is
now
in
maintainer
review
and
will
be
on.com
relatively
soon.
A
Hopefully
so,
and
you
can
hover
over
the
buttons
and
you
get
an
indication
that
you
can
interact
with
them,
click
on
any
and
then
it
clicks
off
and
they're
also
tab
accessible
as
well.
So
you
can
tab
to
a
close
button
hit
enter
and
then
it
removes
that
button
to
that
label
and
that's
it
and
let
me
know
if
you
have
any
comments
or
questions.
I
G
I
Yeah,
I
think
somebody
mentioned
that
in
the
in
the
issue
or
somewhere.
I
saw
a
conversation
about
that,
so
I
think
that'll
be
the
next
next
iteration
we'll
figure
out
what
to
do
there.
D
I
remember
brett
had
this
idea
that
scoped
labels
should
also
have
like
a
drop
down
so
that
you
can
just
kind
of
click
that
and
select
a
different
sculpt
label.
So
that
was
really
cool.
C
I
think
there's
an
issue
for
that,
because
yeah
I've
heard
that
that
not
mentioned
a
couple
times
cool
any
other
questions
on
that.
C
All
right,
I
will
demo
the
next
one,
because
I
don't
think
we're
just
on.
C
One
all
right-
this
is
the
add,
open,
close
configuration
two
boards
and
it's
actually
not
just
on
swim
lanes.
It's
on
both
swim
lanes
and
old
boards,
which
is
great.
Let
me.
C
C
All
right,
nice
job
team
where's,
my
screen,
I
think
it's
the
marching
next.
B
Yo,
so
this
is
less
less
a
demo
more
of
issue
specific
discussion.
I'm
still
trying
to
understand
the
the
change
that
simon
is
introducing
to
burn
up
charts
that
you're
going
to
be
able
to
press
a
button.
B
I'm
going
to
share
my
screen
just
so.
It's
kind
of
a
demo.
B
There
so
that's
his
screenshot,
so
we're
thinking
about
the
copy
for
the
notification
and
for
the
buttons
and
I'm
definitely
I
definitely
don't
like
old
and
new.
I
like
calling
it
like
that,
but,
like
I'm
trying
to
you,
know,
understand
this.
F
I
can,
I
can
explain
the
difference
between
two
if
you
leave
your
screen
up
so
because
we're
using
like
state
events
now
to
render
the
plot
points,
if
you
were
to
close
close
the
milestone
and
move
all
the
issues
that
are
currently
in
it
out
your
burn
down
chart
in
the
old
way
which
we
can
find
out
a
different
word
for
that
the
burn
the
blue
line
would
basically
go
diagonal
straight
to
the
date
that
is
closed
on
and
show
that,
like
all
of
the
all
of
the
issues
that
were
part
of
that,
milestone
were
burned
down
because
they
were
removed,
and
so
what
we're
showing
here
now
is
like,
if
you
were
to
close
it
and
move
all
the
issues
out.
F
Your
your
burn
down
chart
line
will
not
change,
because
that's
what
it
was
at
the
time
that
the
milestone
closed
so
like,
instead
of
changing
the
chart
based
on
the
relationships.
After
it's
been
closed,
it
will
always
stay
the
same
and
never
like
be
altered.
Depending
on
what
issues
you
you
point
into
the
next
milestone,
or
something
like
that,
so
I've
been
using
the
term
historically
accurate.
F
F
Inaccurate
yeah,
so
because,
if
the
milestone
ends
on
september
20th-
and
I
have
three
issues
that
are
that
are
in
that
milestone-
that
that
it
like
freezes
at
that
point
in
time,
instead
of
changing
it
after,
like
once
the
milestone's
been
expired,
the
data
that's
in
the
chart
should
never
change,
but
right
now
or
previously
it
did
change
which
led
to
people
believing
that
the
burn
down
they
actually
hit
their
burned
on
target
when
they
didn't.
B
Okay,
so
so
it
always
updates
unless
I
press
new
burn
down
chart
that
it
becomes
immutable,
meaning
it
will
never
change
unless.
F
Yeah,
that
is
only
shown
when
for
old
milestones
that
were
created
before
we
had
the
state
events.
So
for
new,
my
if
you
like
once
this
goes
live
you
create
a
new
milestone
that
old
and
new
thing
will
never
show
up.
It
will
only
show
up
if
I
go
to
because,
like
milestones
created
three
months
ago,
that
didn't
have
the
state
events
won't
render
burn
up,
charts
and
won't
really
render
burn
down
charts
the
way
that
they
do
today.
F
So
we
almost
need
a
way
to
give
them,
instead
of
like
globally,
changing
and
making
it
so,
the
the,
even
though
it
was
incorrect,
the
old
way
we
rendered
bird
out
charts,
we
wanted
to
still
make
that
accessible,
because
it
is
some
form
of
data.
So,
instead
of
like
making
a
feature
regression
and
their
data
disappearing,
we
need
a
way
to
let
them
switch
between
the
old
version
that
didn't
use
data
events
in
the
new
version.