►
From YouTube: Plan Release Kickoff 12.3
Description
12.3 Release Planning Issue - https://gitlab.com/gitlab-org/plan/issues/5
B
B
I
still
think
there
might
be
some
things
area,
spillover
from
four
point,
two
to
twelve
point
three,
so
we'll
just
kind
of
see,
but
the
kind
of
plan
is
to
take
you
easy
in
terms
of
commitments
for
12.4,
assuming
we're
going
to
have
a
little
bit
of
spillover,
and
then
the
new
process
should
allow
us
to
pull
things
in
from
twelve
point
four
into
twelve
point:
three:
if
we
have
excess
capacity,
does
that
make
sense?
Yeah.
A
It
makes
sense,
I
mean
I,
think,
even
though
we
can
practically
push
through
the
old
code
freeze
of
the
seventh
that
we
used
to
have
now
that
we
have
the
new
process.
I
think
that
we
basically
still
have
that
same
freeze
anyways,
because
that's
when
we
should
start
working
on
twelve
point
three
issues
if
we
want
them
to
be
on
time,
otherwise
everything
is
pushed.
So
in
practice
it's
it's
still
the
same
cut
the
last
milestone
on
the
seven
core
or
less
yep.
B
In
terms
of
I
guess,
the
agenda
items
is
to
review
category
directions.
There
haven't
been
any
updates
recently,
but
I
do
have
an
open,
mr
for
one,
for
project
management
that
I'm
working
on
and
I
have
a
tentative
date
of
August
22nd
to
have
kind
of
incremental
improvements
across
each
category
that
reflect
where
we're
going
for
12.4
and
so
yeah
I'll
ping.
You
guys
on
that
and
we'll
be
posting
those
into
the
slack
Proctor
plan
channel
and
all
that
stuff,
but
so
I'm
not
going
to
review
this
with
some
things.
B
I'll
jump
right
into
the
planning
issue
that
we
put
together
for
12.3,
and
there
are
some
comments
if
you
want
to
follow
the
context
and
stuff
down
there,
but
we
ended
up
with
basically
four
kind
of
directional
issues
that
we're
going
to
focus
on
so
I'm,
going
to
jump
through
those
at
high
level,
its
weight
and
progress.
Information
in
epic
bars
creating
an
issue
from
an
epic
issue.
B
This
a
little
bit
talked
more
about
the
general
problem
specific
to
this
and
in
the
form
of
a
job
story,
which
is
your
situation,
your
motivation
and
then
your
expected
outcome.
And
then
these
kind
of
forces
are
like
things
that
you
know
me
is
the
user
might
be
thinking
about
or
like
is
kind
of
top
of
mine.
I
specifically
related
to
this
particular
like
job
and
I'm,
trying
to
get
completed.
B
So
it's
more
or
less
when
I'm
visiting
or
viewing
the
roadmap
right
now
we're
not
showing
any
progress
indicators
of
any
of
the
epics
so
like
how
far
along
are
we
it's
all
fixed,
either
the
milestone
or
to
a
fixed
date
or
dynamically
to
milestone
where
via
fixed
date?
But
you
don't
get
any
visual
indications
or
feedback
along
the
way
of
like?
Are
we
on
track
or
not
at
eye
level?
B
This
has
been
one
thing:
that
a
lot
of
customers
to
talk
to
us
about
one
thing
that
I
personally
like
been
a
little
bit
frustrated
that
there's
not
that
visibility
there
from
a
product
manager
standpoint,
but
we
really
want
to
be
able
to
provide
a
kind
of
some
more
feedback
and
I.
Looked
it
a
little
bit
open-ended
in
terms
of
like
how
we're
gonna
end
up
getting
there.
But
this
is
just
the
MVC
for
also
adding
that
same
progress.
Information
to
epic
level
views
so
kind
of
have
down
here.
B
Working
design
and
I
think
this
is
something
that
Annabelle
was
tracking,
but
we
and
we
suggested
that
this
also
gets
shipped
with
kind
of
displaying
the
tree
view
in
the
road
map
as
well,
but
I
kind
of
see
it
as
a
sink
separate
thing.
So
the
basic
idea
is
just
to
show
this
with
each
kind
of
epic
level
representation
on
the
road
map.
B
B
Yeah
so
there's
issue
count
open
versus
closed,
so
people
might
track
progress.
Just
be
an
issue
count.
They
might
also
I've
gotten
feedback
from
a
couple
customers
that
they
track
things
be
a
time
so
time
estimate
versus
time
spent
and
so
I
think
that's
where,
for
the
nbnbc,
the
first
thing
that
I
was
suggesting
or
proposing
that
we
do
is
focusing
on
just
the
the
wait
completed
versus
wait
outstanding
and
that
would
roll
up
all
the
way
through
from
the
issue
level.
B
All
the
issues
to
an
epic
and
then
all
the
epics
to
the
parent
epics
so
that
way
on
the
roadmap,
you
kind
of
get
like
the
holistic
kind
of
stance.
There's
some
other
data
I
want
to
collect
as
part
of
the
process
and
that's
why
I
kind
of
left
the
validation
solution
on
here?
It's
just
you
know
which
percentage
of
customers
are
currently
using
weight
or
users.
What
percentage
of
users
view
milestones
by
issue,
count
versus
weight
and
then
just
maybe,
hopefully
conducting
a
couple
usability
studies
and
multivariate
tests.
B
So,
if
you
want
to
read
anything,
there's
all
the
comments
there,
it's
good
to
go,
the
design,
I
hope
gets
flushed
out
as
we
go
along,
but
this
is
the
basic
concept.
There's
a
lot
of
suggestions
on
there:
how
to
do
it,
but
I'll
leave
it
up
to
the
UX
folks
to
kind
of
track
that
process
as
we
move
through
the
implementation
of
this,
the
next
one
is
creating
an
issue
from
an
epoch.
I
kind
of
you
know:
I
saw
the
basic
ideas
right
now.
B
There's
a
couple
proposals:
this
is
the
first
one
where
you
have
the
ability
to
more
or
less
create
a
new
issue
or
create
a
new
child.
Epic
and
you'd
select
sort
of
like
how
it
works
on
issue
boards.
You
select
your
issue
title
or
type
it
in
and
select
which
project
you
want
to
show
associated,
to
which
I
think
is
a
little
bit
clunky.
But
we
have
to
do
this
right
now,
unless
there's
a
better
workaround
sits
epics
across
the
projects
within
a
group.
B
This
is
that
kind
of
the
initially
proposed
design
and
then
I
kind
of
thought
that
it
might
make
sense
to
think
about
the
ability
to
edit
more
stuff
within
an
issue
instead
of
just
the
description
and
picking
a
project
and
kind
of
just
using
the
same,
create
issue
form
but
like
in
this
light
out
window.
This
would
also
lend
itself
well,
if
you
wanna,
we
want
to
eventually
expose
the
functionality
to
edit
issues
from
within
an
epoch
which
would
be
nice
right
now.
A
Uh-Huh,
you
know
how
would
you
separate
just
adding
titles
out
like
creating
issues
with
just
title
versus
actually
opening
that
modal
to
description
and
everything
else,
plus
we
in
that
mock-up
we're
losing
the
ability
to
just
add
an
issue
that
it
already
exists.
I
mean
that's
easy,
just
you
know,
add
a
little
extra
place,
but
but
that
yeah.
B
A
A
B
Of
the
acceptance
criteria
is
that
we
have
to
account
for
that,
but
we
have
to
still
be
able
to
associate
an
epic
or
an
issue
to
an
epic
in
a
manual
way.
I
think
that
we
can't
have
a
direction
on
feature
set
and
then
the
other
third
option,
if
you
want
to
open
it,
run
your
own
screen
and
look,
is
the
kind
of
hyper
approach
where
we
kind
of
allow
the
short.
B
A
B
If
that's,
if
that's
a
better
way
and
I,
think
that's
where
one
user
commented
or
liked
I
think
one
of
the
community
water
community
members
coming
to
that,
you
know
they
would
really
like
it
to
do
that,
because
they
don't
want
to
have
a
bunch
of
like
half-finished
issues
floating
around
and
never
get
revisited
or
flushed
out,
and
then
other
folks
have
said
that
they
really
want
to
be
able
to
do.
It
really
think
we
cleaning
on
the
fly
and
not
break
up
their
flow.
B
What
they're,
thinking
about
and
I
understand,
both
use
cases
I
think
that's
where
I'm
open
to
you
know.
However,
we
want
to
think
about
it.
The
smallest
iteration
would
probably
be
going
the
hyper
approach
where
we
do
the
one
and
then
provide
the
edit
view,
but
that's
also
a
slightly
heavier
workload.
It
seems
like
from
just
picking
one
of
the
other
there,
but
I
mean.
A
B
A
C
D
A
B
That's
one
of
the
things
that
I
would
like
to
see
is
to
work
towards,
just
as
somebody
like
I
would
like
it
to
be
a
more
integrated
workflow.
If
that
makes
sense,
because,
by
the
end
of
my
work
day,
I
have
eight
different
chrome
windows
open
each
with
about
30,
tabs
apiece
and
I
could
be
more
disciplined
about
closing
stuff,
but
just
because
of
everything
you
lose
your
context.
B
Whenever
you
go
somewhere
else
and
let's
use
the
back
button
all
the
time
it
just
like
it,
it
would
be
nice
to
they'll
deduce
a
few
more
things
online,
like
editing
issues
or
reviewing
them,
and
we
kind
of
teased
it
out
a
little
bit
on
the
issue
boards,
but
it's
still
not
sufficient.
Like
I
can't,
you
know,
go
and
look
at
everything.
Just
a
few
things.
B
A
B
C
B
B
A
A
A
B
A
B
The
count
looking
it
over
I
was
having
a
hard
time
justifying
the
business
problem.
I
talked
to
Eric
a
little
bit
just
about
context
and
the
overall
goals
of
making
the
app
more
aesthetically
pleasing
one
of
the
things
that
I
would
like
to
double
check,
as
we
move
forward
with
this
is
that
we
can
connect
with
the
original
designer
who
kind
of
proposed
the
new
layout,
which
hat
was
close
to
10
months
ago.
B
I
think,
which
is
a
long
time
when
it
was
put
in
New,
York's,
ready
and
then
get
some
of
the
research
in
context
for
why
some
of
the
specific
things
were
done.
The
way
they
were
I
know
for
one.
The
the
decision
was
made
not
to
have
things
hidden.
The
labels
hidden
by
default,
so
I
think
that
was
out
of
scope
and
that's
in
the
design
notes
there.
B
B
And
if
that
is
a
blocking
issue
and
it
does
get
shipped
in
full
12,
we
should
be
good
to
go
with
that
and
and
definitely
kind
of
you
know,
I
think
alexis
is
gonna
be
out
for
out
of
the
office
for
a
week
or
so
or
week
and
a
half
during
this
whole
three
release
cycle.
So
we're
gonna
have
to
figure
out
how
to
do
this
and
like
it
up
pretty
quick
and
efficient
way
to
get
the
feedback
we
need,
because
it
is
so
high.
B
Visibility
I
think
it's
important
to
understand
that
the
changes
we're
making
are
gonna
provide
the
kind
of
benefit
not
just
from
an
aesthetic
standpoint
but
from
a
usability
standpoint.
But
there's
not
any
functional
change
in
terms
of
behaviors
I
think
there
might
be
a
couple
new
data
points
that
we're
showing
and
the
issue
lists.
But
it's
more
or
less
reorganized
to
be
a
little
bit
more
efficient
to
consume.
You
guys
have
any
feedbacks
comment
on
suggestions
on
this.
One.
A
B
B
A
little
wonky
was
the
stacked
stuff
on
the
right
side,
especially
like.
If
we're
gonna
have
I,
don't
know
if
we're
gonna
have
the
the
row
headers
or
the
column
headers
there,
but
if
they're
not
there,
it
feels
a
little
bit
more
normal,
but
I
have
never
been
a
fan
of
stacked
column
headers
with
data
point
stacked
on
top
of
each
other.
You
know,
but
that's
just
so.
Yeah.
A
I
mean
I
do
think
that
pushing
everything
more
to
the
right
and
giving
more
space
where
the
title
is
nice,
plus
getting
everything
to
actually
show.
Even
if
there's
no
data,
it
makes
it
explicit
that
you
don't
have
this
data,
because
sometimes
we
just
don't
show
it.
So
it's
this
way
is
explicit
that
we
are
showing
it
there's.
Just
no
data
I.
B
All
right,
I
did
in
the
acceptance
criteria
for
this
call-out.
That
I
would
like
to
see.
If
we
can
measure
the
current
performance
versus
the
you
can
see
right
there.
The
success,
metrics
and
acceptance
is
measuring
the
current
issue,
list,
design,
performance
and
rendering
for
certain
activities
and
I
would
love
front
end
to
weigh
in
on
that
Donald.
C
B
B
Subject
is
like
not
having
that
embarrassing
control
and
not
tracking
that
is
kind
of
a
deal-breaker
for
a
lot
of
people,
especially
those
who
wanted
like
I
deal
with
more
compliance,
and
they
have
to
ensure
that
once
an
issue
starts
that
the
description
or
the
subject
does
not
change,
and
so
this
is
like
I
think
an
important
thing
to
do.
It's
going
to
be
pretty
straightforward.
B
The
notable
change
for
this
is
that
it
was
originally
slated
for
get
lab
premium,
but
after
reviewing
it
with
some
of
the
other
product
managers
and
with
Eric,
we
kind
of
decided
it
made
sense
start
and
get
lab
starter
and
then
eventually
consider
moving
it
down
into
core.
So
it
should
be
accessible
to
more
users
and
yeah.
The
is
part
of
a
larger
effort
just
to
make
sure
everything
is
in
version
control,
and
we
are
tracking
changes
and
recording
changes
in
a
change.
B
A
A
Because
this
is
more
of
a
logging
making
sure
that
you
have
a
history
of
what
changed
and
how
it
changed
and
not
sure
if
we've
talked
about
how
to
develop
this
specifically
I'm,
just
basically
just
wondering
if
we're
gonna
be
storing
gifts
on
this
like
we
currently
do,
for
you
know
mr
comments
and
makes
it
that
versus
actually
creating
a
note.
This
diffs
and
things
like
that
I'm
pretty
sure
we're
trying
to
move
them
out
of
the
database
and
instead
of
storing
them
as
files
Brett.
You
you
remember
what
was
the
idea
behind
that.
B
A
Right,
of
course,
like
we
have
to
show
it
as
a
system
note
yeah
I
mean
it's
just
basically,
where
the
actual
change
is
going
to
be
stored,
which
is
an
implementation
detail
that
we
can
talk
about
later.
I
mean
currently.
This
suggestion
is
basically
show
it
like.
You
currently
show
so
distance,
like
mr
suggestions,
so
we're
probably
would
use
the
same
backing
system
for
em
or
suggestions
as
we
do.
This
I
mean
if
we're
this,
as
we
do
em
our
suggestions,
yeah.
B
I
would
say
the
general
rule
of
thumb
that
I
always
apply
to
situations
like
this
and
like
implementation.
Details
is
when
given
like
two
options
that
produce
roughly
the
same
value,
in
which
case
like
if
you
can
achieve
the
same
outcome
with
two
different
paths,
pick
the
one
that's
easier
to
change
down
the
road.
So
that's
my
rule
of
thumb
and
I
trust
you
guys
to
sort
out
when,
when
it
kind
of
comes
up
but
yeah,
whichever.
A
I
mean
the
solution
here
is
really
going
to
be
just
passing
this
through
a
different
tool.
You
can
get
loved
if
I
get
this
and
then
figure
out
how
to
store
that
properly.
If
it
means
storing
it.
As
a
you
know,
that's
a
batch
file
might
work.
I
just
have
not
been
exposed
to
how
we're
doing
the
mr
suggestions
so
I'm
not
on
2%,
and
how
are
we
storing
it,
but
we'll
find
out
is.
B
B
C
B
That
I
think
those
are
the
four
things
that
we're
targeting
in
terms
deliverables,
the
three
of
which
align
with
I
guess
the
previous
I,
don't
know
who
put
it
in
place,
but
the
the
2019
product,
vision
or
fiscal
year,
20
product
vision
for
plan.
So
that's
a
good
thing
and
we
also
have
a
nice
spread
of
stuff
across
both
project
management
and
as
well
as
like
some
of
the
more
portfolio
planning
things
and
also
across
the
the
tiers.
B
A
One
less
thing
on
the
on
this
one:
for
the
view
history
of
changes
we're
going
to
want
to
make
it
clear
that
the
scope
does
not
include
reverting,
but
we
should
actually
talk
about
a
reversion
in
the
future
because
we're
probably
going
to
want
that,
and
so
that
might
change
the
way
we
store
things
just
because
if
we
do,
if
we
do
gifts
based
on
that
edit
in
the
moment
in
time,
we'll
have
to
go
through
all
the
dips
to
get
back
to
that
point
in
history.
So
that
would
be
it
could
be
expensive.
A
B
A
That
I
can
already
see
that
we're
gonna
want
that
feature.
Russell
and
Chad
is
saying
that
he
he
was
requiring
this
specific
thing
several
weeks
ago,
where
he
had
to
where
he
wanted
to
revert
back,
and
there
was
no
easy
way
because
nobody
had
the
data,
because
I
mean
we
could
just
get
people
to
copy
the
changes
and
face
them
and
do
it
manually.
But
you
know
just
adding
that
button.
This
is
pervert
would
be
pretty
nice
for
the
users.
I
agree.
B
I'll
add
a
follow
under
this
and
refactor
the
epic
a
little
bit
to
be
more
inclusive
of
like
longer
term
things
I'm
trying
to
get
to
where
our
epics
slick
or
kind
of
generic
to
attract
the
life
cycle
a
little
bit
more
of
a
feature.
So
we
can
look
at
everything
holistically
together
in
a
in
a
more
straightforward
insane
fashion,
so
just
flipping
through
the
issues
and
trying
to
find
things
that
relate
to
each
other.
So
yeah.
B
Should
I
swap
job
I'm
sure
that's
great,
if
that's
it
for
now,
that's
it
for
now.
Thank
you
for
sharing
my
computer
didn't
crash
once
you
did
that,
so
it's
at
least
narrowed
down
to
when
I
share
something
and
the
screen
is
being
recorded.
So
that's
cool
I.
Thank
you
for
time
and
if
you
have
any
other
questions,
talk
about
slack
around
the
issues.
Thank
you
for
being
gracious
with
my
first
kickoff
meeting
and
I'm
excited
about
12.3
yeah.