►
From YouTube: CI/CD Section Deep Dive
Description
A
Well,
hello,
everybody
and
thanks
for
joining
the
CIC
D
strategy
overview
glad
you're
able
to
make
it.
We
wanted
to
schedule
this
meeting
to
have
another
chance
to
present
this
content
and
talk
about
it.
The
product
managers
and
me
had
produced
all
of
this,
maybe
a
month
and
a
half
ago,
maybe
even
two
months
ago
now,
and
then
we
went
through
an
exercise
where
we
presented
to
the
leadership
group,
got
a
bunch
of
feedback
and
then
have
integrated
that
all
for
the
most
part
here
into
this
document.
So
it's
it's
pretty
accurate.
A
It's
pretty
it's
pretty
forward-looking
in
terms
of
where
we're
headed
and
it's
got
a
lot
of
great
information
today.
Hopefully,
everybody's
had
a
chance
to
review
it
who's
participating
in
this
meeting,
but
for
anybody
who's
going
to
watch
this
on
unfiltered
later
I'm
just
going
to
share
my
screen
and
walk
us
through
the
page
and
of
course
my
trackpad
just
died
at
this
moment.
But
that's
okay
I
got
a
back
up.
A
So
what
this
page
is
is
it
actually
has
the
content
integrated
from
all
of
the
individual
stages
and
everything
as
well,
and
it
just
gives
one
really
really
nice
overview
of
CI
CD.
Not
all
of
the
section
pages
are
going
to
be
organized
in
this
way,
but
within
CI
CD
we
sort
of
have
a
unique,
a
unique
positioning
where
CI
CD
is
really
tightly
integrated
and
people
in
the
market
tend
to
think
about
it
as
CI
CD
and
talk
and
talk
about
it
in
that
way.
A
So
for
us,
it
makes
sense
to
have
everything
sort
of
it
well
integrated.
Here
we
kick
things
off
in
the
document
by
showing
this
infographic.
That
shows
how
the
different
stages
and
categories
relate
to
each
other
within
CI
CD
we've
got
verify,
which
covers
build
pipelines,
release
which
covers
delivery
pipelines
and
then
package
which
stores
the
intermediary
artifacts.
A
Anything
from
like
actually
binaries
that
are
built
to
container
to
container
images,
and
things
like
that
and
that's
sort
of
is
the
glue
between
these
two.
We
talked
a
little
bit
about
the
market
size
here,
our
competitive
space
overall
in
the
market
and
how
we're
seeing
ourselves
there
and
then
the
themes
are
what
we
go
into
next
I'm.
Sorry,
they
make
a
continuous
delivery.
A
A
That
actually
has
all
of
the
the
data
that
you
need
and
whatever
role
you're
in
in
that
are
engaging
with
the
CI
CD
process,
all
in
one
place,
and
all
this
is
more
for
anybody.
Who's
just
gonna
be
watching
this
online
I
know
you've
all
read
this,
but
so
I'm
trying
to
go
relatively
quick
while
still
getting
the
content
across
the
next
most
important
section.
Here
is
the
plan
and
theme
section,
and
what
we've
done
here
is
broken
out.
A
So
this
is
all
about
pipeline
performance
and
how
like
how
long
it
takes
to
get
a
to
get
a
runner
how
quickly
that
runner
can
set
itself
up?
How
fast
the
registry
is
these
sorts
of
things
doing
powerful
things
easily
and
quickly
is
probably
a
another
word
that
could
be
added
to
this
is:
is
all
about
onboarding
and
just
being
able
to
do
powerful
things
using
gitlab
in
a
really
clear
way.
C
A
A
This
is
a
really
exciting
area
as
well
talk
about
things
that
we're
not
doing,
and
then
the
stages
and
categories
within
within
this
area.
So
we've
got
verify
which
has
its
own
strategy
and
is
gonna,
be
all
about
yeah.
Well,
they
I,
guess
there's
a
ton
of
thing
in
each
of
these
that
I
really
I'm
not
gonna
dive
into,
but
within
testing
I've
got
like
AI
in
ml.
There's
just
a
lot
of
really
really
interesting
things.
Child
child
parent
pipelines
is
another
one
to
check
out.
A
That's
coming
up
very
soon,
that's
really
going
to
make
get
that
much
more
powerful.
Each
of
these
categories
under
here
has
its
own
strategy
page,
and
then
we
go
into
package,
has
its
own
strategy
and
then
the
individual
categories
have
strategy
pages
as
well.
Release
has
the
same
thing
and
then
finally,
we
have
what's
next
in
you
can
browse
in
here
to
see
what's
coming
up
in
all
of
the
different
releases
that
we
have
out
through
the
beginning
of
next
year.
So
that's
the
page.
Hopefully
everybody
had
a
chance
to
read
it.
A
D
A
C
And
Jason
I
can
I
can
chime
in
from
one
other
a
lot
of
times,
we'll
pull
tam
data,
total
addressable
market
from
analyst
reports
or
analyst
research
and
the
package
space
is
a
not
not
covered
as
thoroughly
so
kind
of
like
Jason
was
saying,
I
think
we
could
derive
some
numbers
by
reading
the
tea
leaves
or
pulling
some
numbers
together.
We
might
be
able
to
do
that
as
a
project
and
I'll
all
up
in
an
issue.
D
Thanks
for
that,
sorry,
I'm
just
trying
to
take
notes
in
here
as
well
for
the
a
good
representation
of
our
conversation.
Oh
yeah
I
was
this
thing
I
sort
of
tried
to
catch
up
on
this
last
night.
There's
a
lot
to
taking
at
once,
I'm
wondering
if
we'll
focus
conversations
around
our
strategy
could
be
useful
and
what
are
your
thoughts
on
that
yeah.
A
I
saw
your
question
earlier
and
I
think
that
that's
a
great
idea,
I
think
probably
having
each
of
the
product
managers
for
each
of
the
stages
per
that
present,
something
that
people
have
come
in
and
and
really
do
a
deep
dive
in
would
be
great.
It's
a
really
really
great
idea
and
I'll
take
an
action
to
to
talk
to
the
product
managers
about
getting
that
set
up.
Yeah.
D
I
think
we
I
would
sort
of
attribute
a
little
bit
of
this
to
think
big
meetings
that
the
package
is
doing
that
Tim
and
Deanna
put
together.
I
don't
know
if
that
would
be
helpful
for
other
people,
but
I
could
certainly
see
this
type
of
thing
coming
up.
So
maybe
that
would
be
a
suggestion
too.
I
guess
I
front-loaded,
all
my
questions.
Sorry
Hank
I
go
to
them
last
night
when
I
was
reading.
E
D
So
I'm
seeing
potential
for
integration
across
our
various
stages.
Should
we
look
at
these
opportunities?
Circumstantially
ie,
you
know
when
they
come
up
and
I
did
have
an
example
in
there
as
well
or
sort
of
proactively
start
looking
for
opportunities
to
actually
share
effort
across
our
stages.
I
did
sort
of
follow
up
with
some
more
information,
but
I
don't
know
if
you
want
to
just
answer
that
before
I
start
talking
more
sure,.
A
Yeah,
so
so
we're
starting
next
year's
planning
for
how
or
the
organizations
did
we
structure
one
of
the
things
that
I'm
looking
at
that's
my
highest
priority
is
building
out
a
team
that
can
look
at
workflows
and
tie
these
things
together.
So
I'm
not
exactly
sure
how
this
will
work.
It's
not
been
approved
yet,
but
I
I'm,
hopeful
and
I'm,
pretty
confident
that
we
had
any
instruction
that
that
we
will
have
a
team.
A
That's
not
working
on
package
features
or
verify
features
or
release
features,
but
like
how
do
you
go
to
import
a
project,
get
it
deployed
to
the
container
registry
and
then
on
to
you,
AWS
and
they'll,
be
looking
at
that
well
in
its
entirety
and
I
think
that
that
will
be
huge
for
us,
because
some
of
those
things
there
are
I
mean
we're
all
in
one
product
and
it's
all
a
single
application.
But
sometimes
there
are
these
little
gaps
in
stepping
points.
A
Auto
DevOps
does
a
great
job
in
a
lot
of
cases,
for
tying
them
together,
like
I
did
a
walkthrough
recently
when
you
know
I
imported
a
project
made
a
little
container
and
it
automatically
deployed
it
to
the
Container
register
for
me,
so
it
was
like
a
little
magic
in
that
way.
But
yeah
doing
more
of
that
is,
is
a
super
high
priority.
Yeah.
D
A
There
is
an
issue:
that's
titled,
something
like
you
know,
onboarding.
What
was
difficult
when
you
first
joined
I,
can't
what
it's
called
I
shared
it
in
company.
You
know,
since
recently
that
would
be
great
to
talk
about
those
kind
of
first
user
flows
and
there
and
definitely
ones
that
bridge
the
gap
between
different
stages
and
CIC
or
even
beyond.
F
Sure
so,
on
the
integration
side,
we
have
at
least
three
different
efforts
were
sent
before
you
write
strategy
for
tonight.
City
surfers
in
these
very
high
impacted,
so
that
definitely
are
concerned
for
us
designers
and
thought
of
designers
to
understand
the
overlap
of
nationalities
in
let's
see
how
we
can
better
integrate,
what
we're
building,
what
we're
designing
and
also
while
they're
researching
so
success
as
a
suggestion
and
I
think
then
also
touch
base
on
that
for
us
to
look
into
the
u.s.
vision
as
a
group
as
a
whole
or
not
separately.
G
D
Cool
and
I
think
I
have
the
next
question.
If
no
one
has
any
other
comments,
there
get.
How
denotes
recently
made
a
couple
of
large
announcements
in
our
section?
It
seems
this
is
like
github
change
of
strategy
to
start
like
being
more
of
a
single,
a
single
point
for
people's
DevOps
needs.
I
mean
they're
copying
us
that's:
okay,
but
I,
guess
what
I'm
a
question
is
that
was
in
packaged
in
CI
and
I'm,
wondering
like
how
how
we
look
at
trying
to
compete
with
some
competitor,
like
that?
D
That's
well-funded
and
has
assumably
a
heap
of
people
working
on
these
specific
things
and
I
could
call
out
just
particularly
where
the
package
managers
on
the
package
stage.
It's
it's
difficult
to
keep
up
with
that
pace,
I'm
wondering
what
your
thoughts
are
on
that
in
terms
of
that
a
bigger
competitor,
yeah.
A
I'll
top
my
head,
those
two
I
think
main
areas
there
that
that
we
need
to
focus
on
one
is
hiring
so
for
next
year.
I
think
we
need
to
grow,
probably
another
package
team
and
just
be
able
to
to
do
more
ourselves.
But
the
other
really
really
important
part
for
a
package
is
to
get
to
the
point
where
the
package
innovations
can
be
contributed
and
having
a
really
strong
set
of
guidance.
Having
a
really
strong
base
functionality.
A
D
I
think
we
do
have
a
number
of
community
contributions
and
we
are
working
through
with
those
people,
and
we
do
have
an
existing
effort
to
provide
some
clear
documentation
on
how
to
do
that
better
and
that's
something
that
Steve
Steve's
already
been
working
on
as
part
of
his
effort
to
build
out
those
first
new
ones
that
we
started
together.
So
yeah
I
feel
like
that's
good
value
in
that
particular
area,
and
as
far
as
hiring
and
splitting
teams
and
to
you
know
more
focused
around
certain
categories.
Certainly
we're
gonna
keep
hiring.
So
that's
super
important.
G
I
think
I'm
the
next
one,
so
I'm
curious.
How
are
we
making
sure
that
or
that
we
are
building
the
right
or
the
solutions
that
our
customers
want
today,
I'm
curious
like
what
are
the
efforts
that
we
are
doing,
how
user
research
is
involved?
Maybe
we
do
market
analysis?
You
know
what
are
the
frameworks
that
we're
using
today
yeah.
A
The
I
think
there's
a
today
today
version
and
a
tomorrow
version.
What
we're
doing
today
is
sort
of
relying
on
the
expertise
of
the
team
that
we
have
today
working
together
to
work
on
the
issues,
and
you
know
kind
of
make
smart
decisions
and
what
I
like
to
consider
our
superpower,
which
is
that
all
of
our
issues
are
public
and
customers.
A
Users
can
all
participate
and
we
can
get
these
really
great
active
conversations
going
where
we
come
up
with
really
really
brilliant
ideas,
because
we're
including
customers
directly
in
the
planning
process
and
everything,
is
transparent
and
nothing
is
hidden.
There's.
No.
We
never
end
up
in
that
situation,
where
we've
worked
on
something
for
three
months
that
we
kind
of
internally
thought
was
a
good
idea,
but
then
the
kind
of
falls
flat
when
it
hits
the
market.
So
that's
how
we're
doing
it
today
in
the
future,
we've
got
this
yeah
a
sort.
A
The
issue
but
in
pieces,
they're,
super
super
active
and
the
issues
that
we're
working
on
are
the
kinds
of
issues
that
have
a
lot
of
traffic.
So
it's
really
in
the
implementation
issue
is
where
this
is.
How
do
you
so
like
in
12.6
12.7
right
now,
I'm
covering
in
on
an
interim
basis,
the
role
for
CI,
the
PM
role
for
CI,
so
I'm
in
conversations
with
customers
and
Dimitri
who's?
My
designer
and
a
couple
key
engineers
like
in
some
cases,
Camille
in
some
cases
Fabio?
A
These
are
the
folks
that
I
tend
to
work
with
on
my
team
and
we're
having
early
discussions
that
involve
customers
in
those
issues,
and
so
by
the
time
we
get
to
talk
about
sex,
we
we
will
are
by
the
time
we
get
to
actually
delivering
that
release.
We
will
have
had
some
of
these
conversations
and
come
up
with
at
least
something
that's
a
little
bit
battle
tested
and
is
more
than
you're
able
to
do
it
at
other
companies,
I
think
and
then
in
the
future.
A
We've
got
this
product
development
flow
process
which
we
were
rolling
out,
which
has
the
opportunity,
canvas
and
has
formal
customer
conversations
and
UX
research
built
into
it,
which
I
think
is
a
whole
exciting
new
way
of
working
I'm
actually
going
through
my
first
one
right
now
and
super
impressed
with
how
it's
going
so
far,
but
I'm
not
quite
got
through
the
complete
one.
I
think
that
this
is
going
to.
Let
us
still
be
able
to
take
advantage
of
the
the
process
that
we
have
today
on
smaller
items
and
things
like
that.
A
G
Awesome
so
I
guess
with
this
you're
kind
of
touching
on
my
next
question,
which
is
about
how
do
we
see
user
research
as
partially
as
well
as
user
experience
and
product
designers,
that
contributing
to
the
strategy
to
the
C
ICG,
particularly
in
this
case,
and
so
I
think
today
is
different
from
what
we
see.
What
we
try
to
do
tomorrow,
right
like
how
you
also
describing
that
I
guess
I
can
see
a
lot
described
in
the
product
development
flow
I
will
check
that.
That's
something
already
see
but
like.
A
But
it's
not
quite
perfect
in
the
future.
It's
much
more
formal
for
these
bigger
items
and
definitely
check
out
that
product
development
flow
thing.
It
is
totally
new,
so
everybody's
learning
it
right
now,
but
UX
there's
very
clear
steps
where
the
product
manager
goes
to
the
UX
designer
and
asked
for
advice
based
on
the
opportunity,
canvas
that
we
produce
and
we
review
it
together.
A
And
then
the
UX
researcher
creates
questions
and
we
go
research,
those
together
and
have
customer
conversations,
and
then
that
comes
back
and
then
we
work
with
the
designer
to
break
it
down
into
like
prototypes,
and
then
we
present
those
to
the
product
and
UX
leadership.
So
this
is
all
super
formal.
That's
all
done
in
the
exact
same
way
every
time
and
that's
the
vision
for
how
we're
all
going
to
be
getting
in
better
habits
of
working
together.
I.
G
Checked
this
and
actually
I've
come
across
this
page
already
yeah,
but
yeah
I
guess
like
watching
it.
You
can
also
comment
in
here
and
Ian
as
well
that
yeah
I
understand
that
that's
a
new
process,
but
it's
not
that
we
can
get
better
there
as
well
into
earlier
involvement
of
the
product,
designers
and
yeah
getting
a
little
bit
on
the
same
page
two
bit
earlier.
So
we
can
work
closer
together,
but
yeah.
So
I
think
this
is
something
for
us
to
discuss,
also
in
the
future
corporation,
how
we
can
get
better
in
this.
G
A
So
I'll
quickly
answer
this
question.
Dan
made
a
note
that
we
may
have
skipped
over
something
so
I'm
going
to
come
back
to
that
in
just
a
second.
But
we
do
do
trend
analysis
and
we
have
a
loss
report.
You
may
have
seen
that
posted
and
I
think
goes
in
the
product
Channel
today
we
this
actually
isn't
our
main
area
of
focus.
Though
acquisition
is
much
more
so
we
have
loss
reports.
G
A
D
F
D
F
My
comments
only
kind
of
I
didn't
already
such
bacon,
that
that
we
need
to
get
better
also
in
communicating
the
UX
research
results
and
also
decisions
across
the
audience,
but
also
I
work
more
closely
with
the
engineering
team
for
that.
So
when
things
are
really
creating,
this
translational
serious,
where
we
are
adapting
adopting
the
resident
more
slow
is
that
it's
been
kind
of
an
isolated
effort,
sometimes
from
us
or
from
engineering
standpoint,
and
also
once
we
start
collecting
this
data.
F
We
have
an
issue
open
to
talk
about
how
we
want
to
collaborate
with
product
manager
and
counterparty
relief.
So
a
suggestion
is
to
have
like
not
a
working
session,
but
release
or
expi
Sydney
called
had
like
this
conversation.
That
can
invite
people
to
you
know
here
or
findings
so
that
we
can
share
more
knowledge
that
we
collected
splitting
the
margins.
So
that's
actually
super
helpful.
H
Oh,
my
follow-up
was
package,
I've
experienced
may
be
uniquely
or
maybe
not
a
lot
of
what
they're
looking
for
is
not
to
come
to
package
and
for
just
it
to
work,
and
a
lot
of
the
things
are
asking
for
is,
for
example,
show
a
pipeline
show
in
the
pipeline
screen
when
a
package
gets
built.
That
would
be
really
helpful
and
I'm
just
kind
of
experienced.
It's
really
a
hard
lift
to
try
to
get
that
cross
team
idea
up
and
moving
anywhere
cuz.
H
A
That
can
be
super
super
tricky.
A
general
rule
of
thumb,
though,
is
that
if
it's
helping
your
users,
then
you
should
feel
free
to
implement
it.
There
isn't
a
you
know
a
hard
hard
line
where
like.
If
you
need
something
from
verify,
then
you
need
to
come
to
verify
and
then
ask
us
for
resources,
and
we
will
get
it
to
you
and
then
we
will
ship
it.
And
then
you
can.
You
know
you
really
have
the
freedom
within
package
to
to
implement
it
yourself.
I
do
recognize,
of
course,
that
sometimes
there's
expertise
challenges.
A
Sometimes
there's
you
know
capacity
problems,
because
maybe
it's
a
little
bit
of
a
smaller
thing.
It
would
be
nice
if
somebody
else
did
it,
but
you
wouldn't
necessarily
prioritize
it
yourself
and
it
can
be
get
quite
complicated
but
I.
Think
in
those
cases,
especially,
you
know
what
you're
describing
is
sounds
like
a
pretty
quick
win,
just
showing
an
activity
in
a
new
place,
reach
out
to
us
for
help
or
I,
say
us,
but
reach
out
to
the
the
verify
team
for
help
and
let's
find
a
way
to
get
it
done.
A
D
It's
yes,
I
was
just
gonna,
say,
they're,
doing
powerful
things
easily
as
a
great
way
to
summarize
our
way
to
to
make
our
solutions
in
get
Lobby
way,
and
certainly
something
that's
been
coming
up
for
us
and
the
think
big
conversations
of
like
ok.
But
yes,
we
could
just
replicate
what
the
system
does,
but
how
I
actually
use
it
actually
going
to
be
able
to
interact
with
this
in
a
way
that's
engaging
and
useful
to
them
without
exposing
a
bunch
of
detail,
I'm,
so
I'm,
just
my
thought
here.
D
Maybe
it's
not
a
question
is
just
sort
of
how
do
we
sort
of
procedural
eyes
that
a
little
bit
so
that
we
can
sort
of
say
well?
This
is
this
is
how
we
draw
that
line
through
this
functionality
to
make
it
really
sort
of
an
experience
which
is
consistent
across
the
board
and
that
I
think
maybe
Ian's
example
was
a
great
one
of
you
know.
We
just
showed
that
the
package
got
built
in
the
pipelines
didn't
go
to
they're
sort
of
native
overview
of
what
happened
in
the
build
then
see
how
the
package
got
built.
D
A
For
that
a
great
point,
oh
yeah,
and
to
add
to
that
I
think
the
UX
folks
can
really
help
us
a
time
in
identifying
those
things.
But
there's
lots
of
things
that
we
can
do
on
the
engineering
side.
You
know,
as
for
implementing
things
like
keywords
in
the
gate
lab
see.
I
am
Oh
making
sure
that
we're
not
kind
of
turning
that
into
a
programming
language
or
making
it
so
that
you
need
to
read
the
entire
page,
which
is
already
getting
quite
long.
A
There's
a
really
nice
video
that
maybe
was
six
months
ago,
I
recorded
with
Mark
and
a
couple
other
folks
mark
one
sec,
and
it's
about
small
primitives
and
we're
talking
about
the
idea
that
there's
these,
like
small
keywords,
that
if
you
tuned
them
right,
they
let
you
do
really
really
powerful
things
and
don't
get
in
your
way.
And
that
really
really
does
feel
like
the
get
lab
way
like
having
a
bunch
of
wizards.
That
automatically
do
things
for
you
and
put
you
on
Rails
and
as
long
as
you're.
A
On
the
happy
past
and
everything
works
great,
it's
kind
of
not
our
way
doing
things.
We
want
to
make
things
easy
and
discoverable,
but
we
want
to
do
it
in
terms
of
powerful
primitives
that
people
can
use
to
do
cool
things,
and
so
there's
a
lot
of
subtlety
that
comes
into
that
theme.
That
is
I
think
it's
good
to
engage
with
and
good
to
ask
questions
about,
and,
and
we
can
all
kind
of
come
to
a
shared
understanding
of
retirement.
What
exactly
that
means.
G
You
me
next
I
guess
so:
you've
been
going
about
the
page,
and
actually
this
is
something
that
I've
seen
earlier.
There
is
a
mobile
support
section
to
that.
So
I'm
curious
with
my
fault,
never
checked
curious.
What
support
do
we
offer
for
mobile
today
and
I'm
curious?
Like
do
we
know?
What
are
there
that
the
use
cases
that
people
who
use
mobile,
forgive
that
yeah.
A
Arts,
where
we
did
something
like
you
know,
hundred
hundreds
of
mobile
builds
in
publishing
every
single
day,
so
I
sort
of
know.
The
problems
and
I
published
a
blog
post
again.
I
think
it
was
about
six
months
ago
for
using
fast
lane,
which
is
a
nice
little
tool
that
can
integrate
with
get
labs
CI
and
you
can
get
builds
preview
environments
and
then
publishing
all
set
up
and
work.
A
Mac
runners
is
going
to
help
that,
because
for
OS
X
builds,
you
can
only
build
them
on
a
Mac,
but
I
think
that
the
reality
is,
for
the
most
part,
we're
really
not
on
people's
radar
as
being
a
like
mobile
build
solution,
because
we're
missing
some
of
the
key
pieces,
you
can
pull
it
all
together,
you
can
make
it
work,
but
we
don't
make
it
easy.
One
of
the
other
things
that
I
want
to
focus
on
in
the
hiring
plan
for
next
year,
at
least
like
this
is
potentially
building
a
team.
A
That's
focused
on
that
mobile
use
case,
and
it's
just
thinking
about
the
things
that
mobile
developer
needs
and
delivering
those,
because
it's
a
it's
a
really
great
market
and
it's
a
really
interesting
one,
because
you're
building
kind
of
unique
things
you're
publishing
to
app
stores
instead
of
to
like
a
you,
know,
kubernetes
environment.
So
they
have
their
own
challenges
and
problems.
It's
really
really
interesting
and
we
can
bring
all
of
the
greatness
of
the
overall
gitlab
out
to
those
users
as
well,
which
I
think
would
be
awesome.
Cool.
E
Sorry
I
was
being
asked
something
here.
Let
me
see,
I
was
I
was
wondering
in
terms
of
theme
prioritization.
If
we
have
thought
about
introducing
a
hierarchy
of
sorts
to
say,
hey,
you
know
in
case
we
had
multiple
competing
items.
We
can
clearly
say,
because
we've
dedicated
ourselves
to
a
certain
hierarchy
that
you
know
this
issue.
Shouldn
t
be
prioritized
over
here.
A
Yeah
that
that's
interesting,
I
think
that
at
least
the
way
we've
been
thinking
about
it
too
now
is
that
these
themes
are
such
high
level.
Things
delivered
across
multiple
stages
that
there
aren't
really
prioritization
conflicts
between
them
per
se
or
they're,
like
isn't
a
plan
to
deliver
X
on
this
theme
by
this
date,
in
the
same
way
that
we
manage
that
for
maturity
or
categories.
A
It's
more
that
the
things
that
we're
that
we
are
delivering
are
relevant
to
those
themes
and
then,
in
things
like
the
kickoff,
we
can
talk
about
those
themes
and
how
we're
contributing
to
them.
If
you're,
probably
right,
though
I
think
you're,
probably
predicting
what
we
need
to
do
in
the
future,
because
there
will
come
a
point
where
we
want
to
have
a
more
clear
target
for
for
some
of
these
themes
and
maybe
have
like
a.
A
F
Yeah
and
I
have
a
comment
from
that.
It's
understood
the
question
question
for
actually
a
fish,
the
first
time
that
we're
trying
to
look
into
it
with
in
relief
or
autism
I
had
a
conversation
is
my
point
about
that
and
and
if
I
got
a
good
sense
for
the
me
to
assay.
So,
for
example,
we
are
releasing
that
releases,
Lucian
ality.
So
now
we
have
per
sample
the
the
ability
to
edit
a
release,
but
we
don't
have
the
ability
to
create
it
from
the
UI.
F
So
when
I
think
about
the
scene
with
the
feature
functionality,
I'm
thinking
our
you
know
what
type
of
functionalities
and
what
type
of
fixtures
that
we
want
to
deliver.
First
and
we'll
bring
more
about
it
to
the
users.
But
it's
been
quite
a
challenge
to
have
this
conversation
because
need
to
go
so
higher
level
and
looking
to
the
future
as
a
whole
and
see
what
what
makes
more
sense
to
go
first
and
improve
upon
the
restoration
efforts,
etc.
But
they'll
be
super
valuable.
F
A
Yeah,
nice,
that's
great
to
hear
the
epics
can
and
probably
should
already
be
aligning
to
themes
and
that's
kind
of
how
it
goes
in
the
other
direction.
So
if
you
look
at
the
themes
it
links
down
into
epics,
so
you
know
the
next
logical
step.
Is
you
know
having
issues
in
there
and
then
being
thinking
about
those
themes
just
like
we
think
about
you
know
personas
as
we're
designing
features.
F
A
B
Hey
Jason
and
someone
else
is
heading
in
well.
I'll.
Add
this
to
the
list
later,
when
I
look
at
what's
under.
What's
next
grouped
under
each
of
the
upcoming
releases,
are
these
in
rank
order,
and
so
the
confidence
level
of
the
lower
ones
are
less
as
far
as
they
may
be,
pushed
out
to
a
future
release
release.
A
No
they're
in
I
think
they're,
grouped
by
project
and
then
by
number.
So
it's
just
sort
of
arbitrary
and
not
really
useful
in
that
context,
and
this
actually
is
a
problem
that
we've
been
thinking
about
lately
within
the
product
team,
so
you
could
probably
kind
of
saw
it
in
the
kickoff,
but
all
of
these
pages
that
there's
actually
one
generator.
That's
behind
all
of
these
pages
that
have
lists
of
issues
like
this
on
our
website.
A
So
like
they
kick
off
the
upcoming
releases
page,
they
give
up
releases
page
the
direction
pages
like
the
one
that
we're
talking
about
in
this
meeting.
All
of
them
are
using
the
same
generator,
that's
issue-oriented,
but
more
and
more
issues.
Issues
are
nice
to
talk
about
and
a
lot
of
times,
there's
valuable
issues,
and
that
is
important,
but
it's
the
epics
that
are
really
interesting
and
epics
don't
appear
on
that
page
at
all.
So
you
can
have
a
problem
like,
for
example,
where
you
have
four
or
five
little
issues
that
make
up
an
interesting
epic.
A
None
of
them
are
really
necessarily
that
interesting
to
talk
about
on
their
own,
but
then
nothing
shows
up
on
that
page
because
it's
really
what
they
add
up
to
in
the
epic
that
makes
sense,
and
then
the
next
click
up.
We
also
sort
of
have
the
same
problem
where
those
epics
are
aligning
to
themes,
and
we
want
to
talk,
be
talking
about
themes
publicly
and
giving
people
that
context
so
and
then
themes
don't
show
up
on
that
page.
A
So
I
think
there's
some
work
to
do
in
how
that
page
is
being
generated,
and
maybe
reconsidering
you
know,
including
epics,
including
themes,
somehow
finding
a
way
to
make
all
of
that
well
integrated,
preferably
even
in
the
gitlab
product
itself,
rather
than
in
an
external
web
page.
Those
are
problems
that
folks
in
the
plan
team
are
thinking
about,
and
but
we
don't
have
a
solution
quite
yet,
so
so
those
those
those
pages
tends
to
be
long
lists
of
issue.
Unfortunately,
you
have
to
be
a
little
bit
the
context
together
yourself,
at
least
for
the
moment.
A
A
Cool
well
ready
for
the
time.
Hopefully,
this
was
valuable.
I'll
put
the
recording
up
right
after
this
meeting,
so
you
should
see
it
on
unfiltered
in
the
next.
Probably
30
minutes
yeah.
Maybe
we
can
do
this
on
some
cadence
I'd
love
to
hear
your
feedback.
So
let
me
know
you
know
what
I
could
improve
what
well,
what
could
do
better
and
I?
Don't
try
it
again
in
another
month.
Maybe
thank
you.
Thanks.