►
From YouTube: 2023-08-09 WG Platforms - Maturity Model Deep Dive
Description
TAG web site: https://tag-app-delivery.cncf.io/
TAG Slack channel: https://cloud-native.slack.com/archives/CL3SL0CP5
TAG git repo: https://github.com/cncf/tag-app-delivery
TAG meeting notes: https://docs.google.com/document/d/1OykvqvhSG4AxEdmDMXilrupsX2n1qCSJUWwTc3I7AOs/edit
A
B
B
D
D
D
That's
what
I
want
to
share.
So
this
document
has
some
context
at
the
top,
and
it
has
an
additional
column
here
for
usefulness
for
review.
But
the
idea
is:
is
that
the
rest
of
this
table
other
than
this
oops
other
than
this
one
column
in
the
middle
here
will
replace
the
table
on
our
maturity
model
document
that
has
been
crossed
out.
So
if
we
get
comfortable
with
it
today
where,
where
we
feel
like
that's
a
good
idea,
that's
what
that's!
D
What
we're
marching
towards
with
the
added
bonus
goal
of,
if
we
get
comfortable
with
that
table
today,
it'd
be
great
to
find
people
who
wanted
to
sort
of
Corral
and
and
start
start
getting
the
descriptions
and
detailed
sections
going
for
the
different
rows
of
the
table
so
I'm.
My
my
gut
feel
is
that
we
should
divide
the
kind
of
leadership
or
or
writing
of
these
of
the
kind
of
detailed
section
by
row.
D
B
D
That
is
a
really
good
point.
I
think
that
that's
so
I
was
sort
of
waiting
for
when
we
got
to
like
the
more
formal
review
period,
that
kind
of
final
month
of
like
GitHub
review
but
I
think
you're
right
that
this
is
now
like
divide
and
conquer
kind
of
workloads,
and
we
can
possibly
start
getting
kind
of
smaller
groups
of
people
together
to
do
it.
So
I
will
make
a
note
to
myself
to
to
do.
C
A
D
Awesome
items:
okay,
then
I.
What
I
was
going
to
just
say
is
that
like
I'm,
really
happily
surprised
that
people
seem
like
this
is
in
the
right
direction,
that
doesn't
mean
that
it
doesn't
have
question
marks
on
it.
So
I
don't
have
any
indication
of
like
something
we
should
dive
into
every
as
I
say,
there's
been
little
questions
here
and
there,
but
nothing
where
I'm
like.
Oh,
this
is
a
big
problem.
D
We
need
to
talk
about
this
today,
so
I'm
going
to
just
do
like
open
facilitation
until
it
seems
like
we
need
more
active
anything
if
we
ever
need
more
active
anything
so
I
would
say
if
there's
anything
on
this
table,
that
you
either
want
to
add
edit
or
delete
for
any
reason
or
discuss.
Even
just
for
more
clarity.
F
So
one
of
the
question
that
I
have
as
in
at
least
as
a
row
not
as
a
column
but
maybe
which
is
platform
extensibility,
okay,
and
if
the,
if
the,
if
the
given
platforms
are
already
being
in
a
certain
maturity
State.
How
are
we
going
to
think
through
on
the
model
of
maturity
in
the
extension
aspects
of
it?
So
is
it
being
covered
in
any
of
these
columns
in
the
context.
D
I'm
gonna
one
thing:
I'm,
gonna,
try
and
do
is
not
try
and
answer
quickly.
Anything
because
what
I
have
in
my
head
may
not
be
shared
because
I
feel,
like
I've,
been
the
most
deeply
kind
of
reviewing
this
stuff,
so
I'm
going
to
leave
space
intentionally
for
other
people
to
try
and
answer
their
opinions
and
then
I
can
reconcile
if,
like
I,
have
a
different
opinion
or
if
I
see
us
going
a
different
way
or
whatever.
D
F
Definitely
I'm
going
to
if
I
tell
the
select
the
point
that
you
selected
right,
upgrades
and
end
of
the
live.
Those
two
are
valid
and
the
another
word
that
I
use
are
extra
under
extensibility,
because
that
is
also
I
will
add
in
there,
for
example,
right
and
assuming
that
we
are
using
logging
as
a
service
as
a
platform
that
we
built
and
integrated
with
an
IDP.
F
What
is
being
successful,
it
is
being
used,
and
then
now
industry
came
up
within
using
different
tooling
altogether,
but
the
same
same
concept.
So
what
happens
is
that
you
have
to
extend
the
platform
to
support
the
more
models
and
the
extensibility
comes
as
a
natural
progression
of
the
successful
maturity
model.
So
that's
where
I
see
one
that
word
should
be
there
to
in
the
in
the
section
of
enhancements
yeah.
Now
it
covers
everything
it
covering
extension.
It
also
covering
the
end
of
the
life
it
also
covering
the
upgrade
yeah
good.
Okay,.
F
A
B
D
So
I
think
an
interesting
thing.
I
hear
in
in
your
summary
of
that
Josh
is
like
and
and
I
think.
This
is
where
you're
going
with
this
VJ
as
well,
but
maybe
I,
hear
wrong
is
like
we've,
come
to
calling
upgrades
and
updates
uppies
in
my
team
because
it's
like
they
are
different
right,
you're,
upgrading,
a
version
but
you're
updating
how
something
works,
possibly
depending
on
like
there's
different
different
ways.
D
That
feels
slightly
tangential
to
me
to
like
the
word,
the
the
column
word
like
in
level
two
centrally
tracked
and
level
three
centralized
Fleet,
Management
I
think
both
of
those
speak
heavily
to
the
idea
of
like
upgrading
from
version
12
to
version
13
of
something
right
like
that.
That's
something
that
you
manage
the
fleet
on
or
that
you
track
the
progress
of
upgrades
on
versus,
like
we
need
to
introduce
a
capability
around
blah
right
like
that,
isn't
something
that
you
would
Fleet
manage
right.
That's
not
something!
That's
already!
D
D
It
leads
me
to
think
that
extensions
maybe
doesn't
fit
in
the
current
way.
This
column
this
this
Rose
written
with
level
two
and
level
three.
So
we
have
a
couple
options.
We
can
either
look
at
rewording,
levels
two
and
three
to
make
those
a
bit
more
like
able
to
manage
that
use
case
of
extent
of
like
new
capabilities
or
we
can
try
and
see.
D
D
F
Before
I
just
take
one
minute
and
I'll
I'll
pass
on
to
others
to
share
the
thoughts
and
if
at
all,
I
have
to
take
that
and
I
don't
want
to
change
anything.
The
naming
aspect
of
it,
maybe
in
maybe
I,
can
add
even
other
row
calling
as
extensibility,
not
like
extensions
I
call
this
an
extensibility,
and
that
becomes
a
model
that
any
of
the
platform
that
you
built
and
do
you
have
the
Capital
Graphics
extending
your
platforms
to
other
things,
Integrations,
and
maybe
that
that's
another
aspect
in
case.
F
If
you
don't
want,
if
we
feel
like
changing,
will
changing
few
words
and
the
middle
table
will
make
a
big
shift
in
the
meaning
having
the
new
row
by
itself.
That
gives
you
the
future
of
the
platform
extensibility,
because
that's
what
most
of
the
companies
and
in
general
in
the
real
world,
if
I,
have
to
do
this
maturity
model
and
adapt
to
my
teams.
The
thing
like
what
I
go
and
look
for
is
that
how
it
is
going
to
be
extendable
to
the
things
that
what
I'm
trying
to
do
in
future.
B
Yeah
I
I
also
I,
like
the
addition
of
accessibility
here,
what
Abby's
saying
that
that
row
kind
of
doesn't
at
the
current
moment
it's
a
little
extra
looking
at
kind
of
the
the
stuff
on
the
right
of
the
four
levels.
Is
it
almost
the
same
like
the
way
that
you
maintain
existing
features
and
the
way
that
you
allow
other
teams
to
influence
new
features
like
would
that
also
progress
to
the
same
thing
at
first?
They
request
it
from
you.
Maybe
then
you
have
a
list.
Maybe
then
they
can
contribute
to
it.
B
G
I
think
I
also
have
similar
thoughts
on
these
lines.
Sorry
I
told
you
I'm
joining
him
for
the
first
time.
However,
I've
looked
into
the
document
a
couple
of
times
left
a
few
comments,
so
I
think
this
extensibility
thing
you
know
again.
My
point
of
view
would
be.
You
know,
since
I
mentioned
that
you
know
there
could
be
some
way
where
we
could
track
how
the
platforms
are
built,
basically,
how
organizations
go
from
a
level
one
provisional
to
an
operationalize.
G
So
let's
say
a
platform
is
built
in
in
that
particular
way.
So
extensibility
could
probably
fit
in
let's
say
at
a
level
three
or
a
level
four,
where
you
know
that
you
know
where,
as
a
company
I
start
with
the
platform,
which
is
extremely
basic
and
just
does
some
functionality,
but
by
the
time
they
reach,
let's
say
the
operational
or
the
scale
level.
Then
it
has
options
to
extend
meaning.
G
You
know
it
could
probably
work
with
different
products
or
you
know
it
could
it
could
have
a
lot
more
plugins
or
people
internal
teams
could
as
well.
You
know
develop
and
extend
that
probably
so
that
could
be
away,
because
I
do
feel
that
if
we
have
a
separated,
separate
Row
for
this,
what
might
happen
is
that
we
will
have
to
figure
out
each
of
these
levels
as
to
how
how
a
company
would
progress
from
one
level
to
another,
especially
only
from
the
extensibility
point
of
view.
D
That's
really
interesting:
yeah
I,
just
added
coverage
just
I
just
want
to
make
it
visual
visual,
what
I'm
hearing
and
like
so,
therefore,
hopefully
other
people
can
validate
their
own
hearing
about
like
wait.
That's
not
what
I
heard
and
I
find
that
writing
things.
Visually
always
helps
with
that.
So
this
is
not
that
I'm
suggesting
this
is
like
what
we're
gonna
do.
That's
why
I'm
doing
in
suggestion
mode,
but
I
just
want
to
give
you
this
be
verbal
about.
D
Why
I'm
what
you're
seeing
on
your
screen,
but
yes,
I've
added
coverage,
because
we
talked
about
that
at
one
point:
I
think
Josh,
you
mentioned
like
I,
think
you
had
capability
coverage
or
capabilities
or
something
to
that
effect
and
I.
Think
that
that's
what
I'm
hearing
again
being
like
just
raised
as
hey
like
there
is
a
level
of
maturity
around.
How
much
can
you
do
with
this
platform
like
how
valuable
is
it
to
you?
How
extensive
is
it
to
you?
G
D
Yeah,
maybe
another
one
I
don't
know
so
I
just
wonder
like
raise
like
I,
think
there's
a
piece
of
this
that
is,
do
you
have
the
time
and
money
to
to
extend
this
thing
and
then
there's
another
piece
of
this,
which
is:
is
it
technically
built
in
a
way
that
can
be
extended
and
I'm
I?
Don't
think
that's
what
you're
you're
poking
at
but
I,
but
maybe
it
is,
and
if
it
is
then
I
don't
think
we
capture
it
and
if
it's
not
then
yeah
so
so,.
F
I
think
you
got
up
the
right
point
and
about
my
intention
behind.
Is
that
exactly
I
just
texted
there,
the
four
columns
if
I,
had
to
write
it
for
extensibility
yeah
I
said
okay,
it's
closed.
You
cannot
extend
it.
It's
limited
limited
extension
that
you
can
do
and
plugins
and
open
apis.
You
can
easily
integrate
and
then
fill
developer
ecosystem.
Anyone
can
adopt
it.
So
that's
why
I
was
visualizing
I'm
picking
for
the
right
words
actually.
H
Yeah
and
to
your
point,
a
B
I
think
the
extensibility
extensions
in
the
support
section
fit
better
in
the
interface
than
in
the
investment
is,
is
how
I
feel,
because
in
energy
interface,
kind
of
maps
with
what
Vijay
was
saying
about,
you
know
close
versus
API
versus
complete.
You
know:
developer
ecosystem
sort
of.
D
D
The
things
I
was
saying
out
loud
about
investment
and
interface.
I,
think
that
is
a
slightly
different
mechanism
and
it
is
like
closer
to
what
we're
talking
about
in
support,
but
it
still
might
be
independent
of
it
like
it
feels
like
it
might
be
independent.
What
about
other
people?
How
do
people
feel
about
this.
E
E
It
kind
of
goes
like
what
I've
liked
about
at
least
the
words
that
we
have
right
now
is
that
it
doesn't
like
force
like
if
you
like,
an
organization.
If
you
don't
have
like
all
of
you,
for
example,
like
user
wise
right,
it
may
not
be
useful
for
a
platform
to
have
everybody
in
the
company
or
every
engineer,
be
able
to
contribute
or
have
like
a
communication
with
the
platform
right
like
that.
That
level
of
communication
just
may
be
unnecessary
and
provide
more
confusion.
E
So
I
like
the
idea
of
like
there,
there
could
be
intentional
adoption
or
intentional
interfacing,
whatever
I
think
I
have
trouble
with
the
extensibility
concept
has
again
an
organization.
May
it
may
not
even
make
much
sense
for
it
to
like
be
some
like
the
platform
to
be
very
like
extensible,
so
you
kind
of
have
like
levels
to
the
extensibility
I
find
a
bit
tricky
I,
think
having
it
kind
of
compartmentalized
within
something
like
supports
or
interface
or
investment.
E
I
really
like
that
kind
of
train
of
thought,
even
though
you
don't
necessarily
hit
like
some
more
of
the
components
of
what
extensibility
could
look
like,
I.
Think
if
we're
thinking
about
just
like
levels
and
trying
to
keep
it
a
bit
more
broad,
so
that
it
doesn't
really
matter
what
kind
of
organization
or
what
the
intention
is
with
the
platform
you
can
kind
of
fit
somewhere
into
this
yeah.
Hopefully
those
that
concept
made
sense.
I
I
It
is
because
inner
Source
doesn't
necessarily
mean
anything
other
than
that
you're
actively
how
to
frame
it.
How
you
you
actively
ensure
that
people
are,
you
know,
have
the
capabilities
to
influence
across
different
teams
and
structures
and
product
lines
and
et
cetera,
et
cetera,
et
cetera.
Things
are
open
internally
and
I.
Guess
at
that
point.
So
if
you
know
not
with
these
words
but
close
limited,
inner
Source
open
source
kind
of
at
that
point,
make
sense
because
or
does
or
does
it
not.
D
D
I
I
I
That
is
what
I
mean
by
it's.
Sometimes
you
have
a
specific
thought.
For
instance,
extensibility
kind
of
is
a
little
bit
investment
a
little
bit
interface,
a
little
bit
of
the
option
and
a
little
bit
of
support
like
it
could
be
seen
as
something
that's
part
of
these
other
categories
is,
is
it
is
it
worth
having
that
as
a
separate
thing,
I
think
it
is
because
it
I
feel
that
if
I
think
it's
worth
cons,
you
know
considering
where
you
want
to
be
at
when
you're
creating
a
platform.
I
D
D
Wordsmithing
on
the
the
level
words
when
we
don't
have
like
a
concrete
thing,
we're
trying
to
achieve,
and
so
I'd
like
to
challenge
and
and
open
the
floor
for
anyone
to
suggest
a
like
question
that
this
row
is
trying
to
answer
so
that
First,
Column
I
think
can
really
ground
Us
in
like.
Why
are
we
here?
What
are
we
talking
about
and
that
way,
hopefully
the
words
will
start
to
like
be
able
to
be
compared
back
to
that
and
say
like
that.
K
K
Like
a
maturity
level
that
we
need
to
categorize,
it
totally
makes
sense
as
as
I
think
as
Robert
mentioned,
it
doesn't
make
sense
to
different
organization,
different
customers,
different
users
to
to
have
a
closed
platform
to
have
a
plug-in
driven
platform.
We
have
an
API
driven
developer,
whatever
we
call
it,
but
but,
and
even
even
though
you're
not
supposed
to
get
to
the
to
the
level
four
usually
maturity
models.
Are
you
know,
organization
that
reads
them
and,
and
especially
like
management
leadership
teams
are
targeting
like
the
the
fall
level
is
like.
K
I
Anything
and
that's
kind
of
where
you
get
into
the.
If
we
put
it
in
here
and
say
we
are,
we
are
ranking.
You
know
what
is
the
best
if
there's
a
category
where
there's
not
really
like
a
clear
like
there
might
be
some
discussions
on
certain
certain
topics,
but
if
it's
not
clear
that
you,
you
know
when
you're
starting
out
you're
kind
of
starting
out
at
level
one
and
you
want
to
get
to
level
four
as
much
as
possible.
I
Within
your
context,
if
you
can't
say
that
I
feel
I
feel
that
extensibility
is
really
important
in
a
platform,
but
it's
important
for
the
people
who
are
creating
the
platform
to
determine
in
what
capabilities
they
want
their
accessibility
to
be,
and
it's
not
necessarily
something
you
mature
into
exactly.
If
that
makes
sense
that.
D
So
I
definitely
can
see
an
argument
for
that
and
that's,
but
that's
where
I
find
that
the
words
that
Vijay
first
suggested
around
close,
limited,
plug-in
and
ecosystem
is
really
really
powerful
words,
because
I
think
plug-in
indicates
like
a
it's
almost
like
an
addition.
Unlimited,
though,
to
be
fair,
like
so,
I
can
basically
I'm
going
back
and
forth
in
my
own
head.
D
D
Whoever
added
the
the
the
question
I
think
that
helps
a
lot,
and
that
leaves
us
in
a
state
where
I
think
we
might
be
in
a
good
place
if
anyone
wants
to
throw
out
ramble
for
a
minute
about
their
use
case
and
where
they
would
see
it
fall
on
this
table
and
and
whether
or
not
it
works
for
them.
This
might
be
a
good
time
for
us
to
be
like
to
take
a
use
case.
Run
it
through
this
table
and
decide.
Does
adding
a
line?
D
Understanding
is
not
yet
wordsmiths,
but
adding
a
line
around
that
extensibility
idea
or
that.
How
do
you
add
features
idea,
would
help
or
hurt
your
evaluation
like
the
the
effectiveness
of
your
evaluation
with
the
model?
This
might
be
a
good
time
to
do
that.
So
I
don't
know.
If
anyone
had
one
in
mind
that
they
wanted
to
use
yeah.
K
K
D
I
A
G
I
I
also
agree
to
what
she
just
mentioned
mentioned.
You
know,
maybe
all
the
parameters
that
you
see
here
in
terms
of
closed,
limited,
plugin,
driven
developer
ecosystem
are
more
about
how
the
platform
should
be.
Maybe
like
we
discussed
earlier.
Maybe
you
know
it's
that's
the
characteristics
of
how
the
platform
should
be,
or
it
should
be
here
so
again,
I
feel
it.
It
fits
better
in
the
interface
row.
Maybe
we
might
have
to
brainstorm
a
little
probably
see
if
there
is
a
better
word
than
interface.
G
You
know
that
probably
defines
how
the
platform
should
be.
So
when
you,
when
any
organization
is
let's
say,
building
a
platform,
so
they
know
that
okay,
when
I'm
at
the
provisional
level,
this
is
what
or
how
my
platform
should
be,
and
then
they
can
eventually
progress
to
a
level
which
says
you
know
we
have
a
full
developer
ecosystem
or,
like
I
mentioned
in
the
document
as
well,
that
you
know
inner
sourcing
is
done
so
that
you
know
people
are
contributing
and
building
it.
D
D
We
were
sort
of
an
operationalized
investment
as
in
we
had
a
team,
but
it
was
not
a
large
proportion
of
our
organization.
We
didn't
have
any
product
oriented
people
on
the
team.
We
only
had
Engineers
and
the
engineers
tried
to
have
a
product
mindset,
but,
like
the
organization
wasn't
investing
in
the
product
side
of
things,
it
was
that
the
team
was
investing
in
that
not
the
not
the
org.
Wasn't
supporting
that
side
of
things
and
like
work
around
that
platform
really
got
prioritized
by
things
that
needed
to
get
done
for
the
org.
D
So
we
did
a
lot
of
things
around
like
PCI
compliance
and
and
things
along
those
lines.
So
I
would
again
I
think
those
are
reinforcing
to
me
that
it
was
like
a
cost
center
of
like
solve
this
problem,
that
the
business
has
like
prioritize
rather
than
like
think
about
the
the
larger
kind
of
experience
of
the
developers
and
and
those
kinds
of
things.
D
Things
like
that,
so
I
would
say
that
it
was
not
a
you
must
use
it.
Good
luck
have
fun
like
this.
Wasn't
a
like
that
kind
of
thing.
It
was
more
like
it
was
us
trying
to
say
here.
You
know
you
have
problems
we're
trying
to
solve
for
you
with
terraform
modules
or
a
CLI
tool
or
whatever
you
know.
Let's,
let's
collaborate
on
that,
but
most
of
the
solutions
were
quite
supported,
like
it
was
a
pull
request
system
where
people
had
to
make
a
change
in
a
terraform
repo
we
had
to
approve
them.
D
We
had
to
apply
them
so
self-service.
We
had
one
feature
that
was
self-service,
which
was
like
a
new
feature,
as
I
was
leaving
the
company
that
we
introduced
around
developer
environments
and
a
second
one
around
secret
version
updates,
but
like
basically
we
were
so
we
were
sort
of
between
operationalized
and
scaled,
but
if,
when
it
comes
to
the
interface,
but
it
was
mostly,
you
know-
supported
Solutions-
it
was
all
in
code,
but
it
was
also
our
code
like
we
had
to.
D
We
had
to
support
the
engineers
in
doing
it
when
it
came
to
supporting
things
that
were
running.
That
was
us.
We
did
all
the
upgrades
of
all
the
things
we
I
would
call
it
centrally
tracked.
We
didn't
have
automation
behind
all
these
things,
like
I
was
in
the
office
on
a
Saturday
doing
an
upgrade
of
the
database
like
you
know
things
like
that,
and
but
we
also
didn't
have
a
fleet
to
manage.
D
So
this
is
a
good
example
of
where,
like
I,
wouldn't
have
expected
to
get
to
scaled
at
the
scale
of
our
company.
We
had
a
database
upgrade
there's
no
point
in
doing
Fleet
managed
database
upgrades
when
you
have
a
database
like
or
two
because
we
had
staging
and
production
like
not
worth
it
right,
so
that
that's
okay,
like
we
were
at
level
two,
but
that's
the
right
level
for
us
at
the
time,
I
think
and
when
it
came
to
measurement.
D
We
were
quite
ad
hoc,
if
I'm
honest,
so
we
didn't
really
have
much
Telemetry
around
things.
We
had
Telemetry
around
the
security
oriented
things
so
like
when
people
were
messing
with
Secrets
or
something
like
that.
But
but
it
wasn't
about
platform.
It
was
about
security
and
we
tried
to
do
a
couple
of
surveys,
but
they
weren't
at
consistent
intervals
and
they
weren't
consistent
questions.
So
I
would
call
that
quite
ad
hoc
at
the
time.
So
then
the
question
is
is,
would
it
so?
D
A
question
would
be:
would
extensibility
change
my
kind
of
self-evaluation
of
that
platform
or
change
my
ability
to
to
evolve
that
platform
or
something
better
and
I?
Would
say
that
the
thing
that
I
am
most
drawn
to
wanting
to
talk
about
is
the
fact
that,
like
devs
had
to
rely
on
us
to
merge
their
PRS
and
review
their
PRS
in
terraform,
and
that
was
a
pretty
like
annoying
situation
on
both
sides
and
that
I
felt
like
came
out
quite
naturally
when
it
came
in
to
interface.
As
we've
been
talking
about.
D
D
I.
Don't
know
like
that.
That's
maybe
somewhere,
where
that
would
have
a
different
aspect
that
focuses
on
it.
Maybe
would
have
highlighted
that
not
sure
anyone
else
have
any
like
questions
about
what
I
just
spewed
or
did
they
and
did
you
find
that
process
useful?
Would
it
be
useful
for
someone
else
to
try
that
process
on
something
that
they're
working
on.
E
E
You
know
what
to
focus
on
like
it's
good
to
have
like
a
full
narrative,
yeah
I
think
I
had
a
hard
time
like
I,
remembering
like
how
to
kind
of
keep
disconnected
with
what
we're
doing
as
well,
and
so
that's
kind
of
at
least
the
challenge
I
ran
into,
but
I
do
see
the
benefits
of
like
it
was
cool
to
kind
of
see
like
wow,
like
the
way
that
it
does
fit
together.
So
I,
say,
kind
of
pros
and
cons
of
having
something
like
that.
B
D
Cool,
that's
it's
probably
a
strong
enough
like
sway
at
this
point
like
I,
think
as
I
say,
I
think
it
was
a
good
conversation
topic.
But
maybe
it
sounds
to
me
like
maybe
I
should
remove
the
suggestions
around
extensibility
rule
at
this
stage
and
and
return
us
back
to
the
return
us
to
the
the
table
in
the
state
that
we're
all
in
agreement
of
and
then
like
again
kind
of
raise
any
more
questions.
Maybe
it
comes
back
around
or
whatever
I.
I
I
I
And
and
there's
other
things
again,
where
we're
going
to
create
content
based
on
the
table
where
we
can
start
talking
about
some
of
the
extensibility
issues
and
kind
of
pinpoint
them
to
different.
You
know
various
cities
of
scale
between
the
different
aspects
and
so
on
and
so
forth.
So
you
know
it
is
something
to
keep
in
mind
when
we
continue
to
work
on
the
maturity
model,
but
but
I
I'm
happy
to
say
that
I
feel
that
extensibility
is
part
of
the
maturity
model
within
the
table
itself.
F
D
This
is
this
is
why
we
have
these
open
calls
right.
This
is
the
fun
part.
Everyone
else
just
gets
to
read
this
thing.
The
fun
part
is
building
it,
so
yeah
cool.
So
all
right,
so
anybody
else
have
something
that
they
feel
like
is
like
a
burning
thing.
They
want
to
talk
about.
I
I
have
a
couple
prompt
questions
in
my
head,
but
I
want
to
leave
the
floor
open
for
this
first.
In
that.
B
I
could
bring
up
something,
I've
been
thinking
about
it
and
I.
Think
I
have
an
answer,
but
somebody
had
prompted
me.
You
know
I
told
them.
We
were
working
on
this
paper
and
asked
if
they
had
any
ideas
and
you
know
wanted
to
participate
and
they
said
well,
I
looked
it
over
and
there's
where's
developer
productivity,
and
is
that,
like
is
increased
developer
productivity?
You
know.
B
Should
you
expect
that
to
increase
as
you
go
I,
don't
you
know
I'm
thinking
about
that
a
little
I'm
not
saying
it
should
be
in
there
I'm,
just
sharing
the
thought.
What
I've
been
thinking?
Actually
just
the
past
few
minutes
as
I
was
gonna.
Tell
you
all
about
this.
Is
that
I
think
it
is
included
in
measurements
like
as
you,
mature,
you're,
gonna
measure
things
and
probably
in
column,
three
or
four?
Hopefully
one
of
the
things
you'll
I
mean
if
there
is
a
way
to
measure
developer
productivity.
B
I
You
know
you
would
measure
stuff
for
to
to
find
that
out
and
by
measuring
it
you
might
discover
that
you
need
to
have
a
different
type
of
interface
Etc
and
that
kind
of
just
like
the
net
like
makes
it
like,
like
moves
everything
forward,
I
think
so,
yes,
I,
don't
think
that's
a
it's
a
separate
thing,
but
I
think
it's
in
there.
Unless
you
know,
okay,
people
are
nodding,
so
good.
D
I've
added
I've
added
that,
like
that
under
measurement,
we
talk
about
the
things
that
you
have
as
goals
for
your
platform.
Not
every
company
has
Dev
productivity
as
a
goal
right,
but
that
is
a
very
commonly
discussed
one
today,
but
security
compliance
like
cost
savings
like
these
are
things
that
are
actually
a
lot
of
times.
The
drivers
of
platforms
and
Dev
and
devs
like
are
like
productivity
and
they're
like
we
don't
care
we're
talking
about
the
millions
we're
saving
by
doing
this
right.
So
you
know
we
live
in
a
sometimes.
D
I
C
D
Worrying
you
in
your
life
you're
doing
pretty
okay
right
right.
Well,
then
April
for
doing
things
well
and
and
to
clear
off
some
comments.
We
talked
about
the
fact
that
this
there's
sort
of
a
a
point
that
platforms
are
inherently
socio-technical
where,
on
that
socio
and
technical
side
of
problem
solving,
should
this
model
sit?
How
balanced
should
it
be
and
whether
or
not
it
should
shift
towards
one
side
or
the
other
and
yeah?
So
do
we
feel
comfortable
with
the
balance
on
the
socio-technical
nature
of
building
platforms?
E
A
L
B
I
But
but
do
we
want
to
get
rid
of
things
that
specifically
go
one
way
or
the
other,
or
is
it
okay?
Because
it's
in
in
some
parts
the
some
of
the
aspects
are
more
or
less
just
technical,
and
so
many
of
it
is
more
or
less
just
about
the
people
and
the
processes.
So
you
know
we
I
think
we
can
allow
ourselves
to
be
more
on
the
technical
side
on
some
aspects
and
more
on
the
peoples
and
other
ones,
because
it
makes
more
sense
and.
D
J
D
D
I've
put
detail
about
why
I
was
use
the
word
shared
ownership.
That
doesn't
mean
it's
correct,
I'm,
not
trying
to
validate
it.
It's
just
that,
like
it
gives
context
in
case
people
can
think
of
a
better
way
of
describing
that
experience
in
that
comment
there.
But
does
anyone
else
feel
like
this
row?
Has
any
confusions
or
any
any
of
the
words
in
it?
They
feel,
like
could
be
more
clearly
articulated.
A
I
In
some
of
these
again,
it's
kind
of
hard
to
pinpoint
a
this
is
less
mature
than
the
other.
It's
it's
more,
it's
harder
for
me
to
see
how
you
cannot
have
shared
ownership,
while
also
have
centralized
Fleet
Management,
for
instance,
like
it
kind
of
starts
overlapping
and
depending
on
your
organization,
you
might
choose
a
different
path.
I
Then
then,
was
kind
of
reflected
here
which
again
kind
of
then
for
me,
if,
if
it's
not
a
very
clear-cut
wording
wise,
this
is
where
you
kind
of
start,
and
you
want
to
try
to
move
towards
the
the
right
it
gets
kind
of
confusing
like.
Why
would
you
want
to
be
more
mature
in
this
case?
In
some
cases-
and
this
is
one
of
the
ones
that
I
I
struggle
a
little
bit
with
myself.
B
Is
this?
Is
this
really
getting
at
like
so
the
right
now?
The
question
is
phrased
that
once
a
capability
is
in
use,
but
maybe
it's
this
we
kind
of
touched
on
this.
Is
it
really
about
the
entire
life
cycle
of
a
capability
like
what
causes
it
to
come
into
use?
You
know,
how
do
you
determine
if
it's
meeting
its
goals?
How
do
you
determine
if
it
needs
upgrades
or
it's
time
to
Sunset?
It
would
would
that
make
it.
You
know
if
we
included
the
entire
life
cycle.
Would
that
make
it
a
clearer.
H
I
also
feel
the
word
shared
ownership
is
a
little
problematic
as
they
say
in
books.
Right,
everybody's
responsibility
is
nobody's
responsibility,
so
to
speak
right,
so
shared
ownership
kind
of
gives
me
that
feeling
and
I
was
reading
this
article
on
Martin
Pollard's
blog
just
last
last
week,
I
guess
around
principle
watches,
and
you
know
what
kind
of
models
work
right,
I
think
the
measure
models
there
seemed
like
where
people
collaborate.
H
So
even
if
you
have
to
do
a
place,
upgrade
databases,
for
example,
the
dev
team
might
as
well
participate
in
the
upgrade
of
database,
although
it's
not
there
kind
of
key
activity
from
application
point
of
view
right
so
I
would
rather
use
the
collaboration
or
some
word
around
collaboration
than
ownership
Because.
Unless,
if
somebody
has
to
really
own
you
know,
you
can't
say
everybody
owns
and
then
nobody
owns
sort
of.
I
I
I
agree,
and-
and
it
becomes
one
of
those
things
where
just
saying
words
collaborations
collaboration-
is-
is
more
mature
in
my
head
than
shared
responsibility,
because,
honestly,
because
at
some
point
someone
just
decided
that
a
couple
of
people
are
supposed
to
own
this,
that
doesn't
mean
it's
gonna
be
well
managed.
Yeah.
A
I
Think
that
that
might
that
might
just
make
it
more
harder
than
having
one
person
owning
it
and
kind
of
staring
the
direction
a
little
bit.
You
know,
while
trying
to
get
to
something,
that's
collaborative
is
kind
of
what
we
want
we
want
to.
We
want
to
be.
We
want
to
collaborate
on
that.
Not
necessarily
have
a
lot
of
people
having
ownership
to
it.
D
I'd
be
curious
if
defined
responsibilities
helps
at
all
like
it
may
not,
but
the
so
a
the
difference
between
shared
and
defined
I'm.
Definitely
hearing
that
shared
is
problematic
and
I'm.
Agreeing
with
with
that
like
the
way
you're
describing
that,
like
yeah,
okay,
I
see
where
that
could
like
be
really
misinterpreted.
Yep,
okay
cool
so
definitely
want
to
get
rid
of
shared
and
when
it
comes
to
ownership
versus
responsibility,
right
I
think
that
again,
ownership
sort
of
you
talked
about
collaboration
right
and
that's
okay.
To
need
to
want
to
collaborate.
D
Who,
who
is
responsible
for
the
success
of
something
versus
like
owning
it
like
I,
have
to
do
it
by
myself
and
so
I
think
both
of
those
words
are
independently
problematic
and
even
more
together,
but
but
I'm
very
hesitant
to
go
towards
the
level
of
being
like
a
responsibility
Matrix,
because
a
matrix
is
one
implementation
of
this
concept,
and
so
yeah
so
does
defined
responsibility
start
to
absorb
some
of
the
the
like.
The
challenges
that
we
had
with
the
original
wording
like
I.
I
I,
for
me
at
least
it
does
look.
Just
example
was
like
a
lot
of
different
places,
including
the
place
that
I'm
at
right.
Now
the
ID
was
that
you
know
there.
We
don't
have
titles,
you
know
everyone
just
kind
of
chips
in
so
again,
it's
basically
shared
ownership.
Everyone's
involved.
You
know
everyone
can
vote.
What
happens,
then?
Is
you
know
it?
It's
stuff
barely
moves
forward,
but
the
students
kind
of
go
like
all
right.
I
This
person
is
these
persons
now
have
the
responsibility
to
take
this
project
and
kind
of
move
it
forward
and
and
while
everyone's
still
involved,
someone
has
the
responsibility
to
make
sure
that
stuff
is
moving
forward.
I,
it's
just
basically
like
unclogs
the
entire
system
and
starts
getting
stuff
done
right.
As
soon
as
you
go
like
you
know,
again,
share
ownership,
just
doesn't
make
sense
in
I
would
say
all
cases,
but
you
know
all
cases
I've
been
in
at
least
where
that
has
happened,
so
it
might
just
be
ptsdf.
J
Something
that's
just
been
occurring
to
me
is
probably
perhaps
the
concept
of
distributed
responsibility
as
well
and
and
I'm
thinking
about
this
in
some
ways,
because
pep
says
we
get
that
sort
of
more
decentralized.
Perhaps
if
this
is
the
direction
of
travel
within
the
within
the
platform,
there'll
also
be
things
like
additional
policy
that
will
might
be
in
place
where
there'll
be
an
ownership
of
policy
within
an
organization
that
might
then
be
reflected
in
the
platform
and
I'm.
J
Just
thinking
of
that,
they
can
often
be
more
sort
of
more
multiple,
multiple
stakeholders
within
a
platform
as
well,
and
maybe
accounting
for
that
may
help
as
well
and
distributed
rather
than
defined,
as
perhaps
for
me,
feels
Just
a
Touch,
looser
and
sometimes
a
little
more
for
reflective
of
of
what
I've
observed.
Yeah.
D
Yeah,
it's
a
really
good
point.
Simon
I
think
my
my
current
thinking.
My
current
preference
would
be
to
add
that
into
the
description
rather
than
the
table
and
the
reason
why
and
that
doesn't
need
to
stick
there
I've
just
typed
it
there
we
can
delete
it.
We
can
do
that.
All
the
things
is
that
I
think
one
of
the
things
I
was
trying
to
capture
from
previous
conversations
and
from
previous
experiences.
D
Is
this
idea
that,
like
the
platform,
creators
and
providers
are
in
charge
of
drawing
a
line
right,
they're
in
charge
of
defining
like
where
the
platform
ends,
how
to
use
the
platform?
What's
expected
of
the
users?
What's
expected
of
the
platform
and
so
forth
and
I?
Think
when
we
talk
about
maturity
and
Robert
was
Raising
it
one
of
the
hardest
parts
about
maturity
models.
We
want
it
to
actually
be
a
progression
and
not
just
a
you
know,
you
could
go
in
a
bunch
of
different
directions
on
this
thing.
D
J
B
Yeah
that
that's
that's
I
wanted
to
bring
up
something
else,
though,
would
you
see
I'm
just
trying
to
wrap
my
head
around
the
word
Fleet
in
the
third
column,
centralized
fleet
manager
is
throwing
me
off
slightly
because
is
it
really
just
about?
Are
we
talking
about
individual
capabilities
here?
Do
we
mean
capability
management
and,
like
should
I,
should
I
be
in
all
four
of
these
rows
should
I
be
thinking
about
when
I
want
a
new
capability
or
or
fix
up
a
current
capability.
B
I
have
to
make
a
request
that
will
be
the
first
column
and
the
second
one
would
be
somewhere
there's
a
sheet
that
says
here
they
are,
but
nobody
actually
does
anything
and
then
the
third
column,
Central
management
means,
but
is
it
about
capability?
That's
the
word.
Fleet
is
kind
of
throwing
me
off
so.
I
L
I
D
D
The
thing
I
wanted
to
capture
was
the
difference
between
a
sheet
that
is
like,
as
you
said,
Josh
like
a
spreadsheet
that
you
manage
like
kick
off
as
things
get
done
to
like
a
click,
button,
kind
of
experience
or
like
a
kind
of
like
when
you
want
to
go
through,
and
when
you
want
to
update
a
API
to
introduce
a
new
field
option
or
to
deprecate
a
field
option,
it's
no
longer
like
one
by
one.
You
have
to
do
the
thing
it's
more
like.
D
Creating
a
platform
because
you're
expecting
many
people
to
create
things
on
your
platform,
and
how
do
you
then
manage
those
many
things
and
I
wanted
that
to
evoke
a
sense
of
like
those,
many
can
be
managed
as
a
singular
Thing
versus
those.
Many
have
to
be
managed
as
like
each
individual
thing.
That
was
the
that
was
the
emotion
I
was
trying
for.
I
I
I
think
if
you
remove
Fleet,
that
still
means
what
you
think
it
means
again.
It's
it's
not
it's
not
necessarily
only
about
like
the
the
hours
structure,
but
also
as
as
someone
that's
not
a
native
English
speaker,
like
I,
can
kind
of
I
can
kind
of
see
how
someone
like
started.
Reading
this
and
and
takes
it
literally.
L
I
You
know:
are
we
supposed
to
manage
stuff
in
fleets
and
so
on
and
so
forth?
Centralized
management
makes
sense
if
you're
speaking
about
again
having
a
specific
platform
team
that
manages
the
resources
so
to
speak,
while
the
fine
responsibility
like
I'm,
not
totally
sure
about
the
wording
but
like
the
the
next
majority
part,
would
be
not
necessarily
having
the
platform
team
being
responsible
for
every
single
part,
but
share
the
responsibilities
with
the
other
people
through.
D
B
D
B
D
C
B
D
I
think
I
would
push
those
both
back
down
one
level
personally
so
grab
bag
is
sort
of
this
buy
request
requirement,
like
someone
runs
around
with
fire,
coming
out
their
head
being
like
Oh,
my
God
I
just
found
out.
We
have
something
running
that
is
end
of
life,
go
fix
it,
and
so,
therefore
it
has
to
be
fixed
and
doesn't
matter
nothing.
It's
actually
quite
intentional
here
that
we
don't
talk
about
who's
in
charge
of
fixing
it
until
the
most
mature
level.
It
might
be
a
software
team,
that's
in
charge
of
fixing
it.
D
D
Does
the
thing
get
done
and
like
at
the
provisional
level,
you're
sort
of
like
it
gets
done
when
someone
realizes
it
needs
to
get
done,
and
some
teams
might
be
it
was
some
teams
within
an
organization
might
be
more
quite
mature
with
that
process
they
might
have
like
patching
Fridays
where
every
Friday
they
look
for
things.
They
have
to
patch,
but
another
team
in
that
organization
is
like
what
do
you
mean
I
have
to
patch
this
thing?
That's
five
years
old,
like
you
know,
and
that
would
be
quite
provisional.
D
That's
what
I'm
hearing
from
you
Josh
on
that
idea
of
like
there
is
a
list
and
we're
working
our
way
down
it,
and
we
understand
what
we
need
to
do,
but
we're
working
our
way
down
in
a
fairly
like
Point
by
Point
kind
of
world
like
where
everything's
a
little
bit
special
and
then
you
get
to
manage
to
centralize
manage
and
now
all
of
a
sudden
you
can
say,
databases
are
all
the
same
to
me.
I
can
treat
all
my
databases
as
like.
D
They
all
need
to
be
patched
or
they
all
need
to
be
upgraded
and-
and
there
might
be
a
really
mature
rollout
system
and
there
might
be
health
checks
and,
like
again,
I'm
not
saying
like
what
and
what
good
looks
like
in
in
the
really
kind
of
minutia
of
like
how
someone
does
it.
But
it's
about
being,
like
databases,
are
a
thing
and
I
can
manage
them,
not
Joe
schmo's
database
and
Sarah
schmo's
database
over
there
and
whatever
I,
have
to
treat
as
different
things
on
a
checklist
to
to
validate
they've
been
done.
You
know.
B
C
K
K
The
way
I
got
it,
what
not
really
aligned
with
what
we
said
opportunity
now,
and
we
even
call
it
like
day
two
with
day
two
in
in
the
in
the
third
color.
We
call
it
like,
should
tackle
the
hard
problem
of
day
two
and
day
two
is
day
two
operations,
so
I
I
don't
know
if
operations
is
like,
because
operation
operationalized
would
be
kind
of
kind
of
tricky
to
to
cover.
D
So
I
think
there's
two
things
there
and
I
think
one
of
them.
We
can
knock
off
fairly
quickly
so
that
we
can
get
into
the
harder
one
which
is
naming
the
row.
So
the
first
thing,
I
heard
you
say,
was
shared
responsibility.
Was
the
original
your
original
suggestion,
like
two
weeks
ago,
I
bastardized
it
as
shared
ownership,
which
was
raised
as
a
concern
and
we've
now
landed
on
defined
responsibility.
D
So
what
I've
done
is
I
agree
with
you
that
the
the
term
you
used,
which
was
shared
responsibility,
came
from
your
background
as
a
cloud
provider
or
like
in
the
cloud
provider
world
where
there's
a
shared
responsibility.
Matrix,
that's
also
what
I
was
thinking
of
and
so
I
wanna,
so
I've
captured
here
for
the
detailed
section
that
we
want
to
make
sure
that
when
we
come
to
that
optimized
detail
section
that
we
talk
about
that
as
an
implementation
of
this
and
I.
D
Think
that
where
we
were,
was
that,
like
shared
a
vote
when,
when
written
as
only
two
words
using
the
word
shared,
gives
people
heebie-jeebies
around
like
but
who
owns
it?
If
no
one
owns
it,
if,
if
everyone
owns
it,
no
one
owns
it
and
so
by
using
defined.
That's
the
outcome
we
want
and
the
implementation
that
we
could
use
to
achieve
that
outcome
would
be
a
shared
responsibility,
Matrix,
which
we
can
write
in
more
words
in
the
detailed
section.
D
Does
that
capture
your
intention,
Okay
cool,
so
that
that
one
I
thought
I
thought
we
captured
well,
but
I
wanted
to
validate
so
then
the
second
Point
Let's
Open
that
floor,
which
is,
does
support
so,
first
of
all,
I'm
going
to
close
off
fleets
I
think
we've
agreed
that
Fleet
doesn't
make
sense.
There.
We've
talked
about
it.
D
B
I
I
Part
of
operations
might
not
be
necessary
maintenance,
but
everything
from
architecture-
and
you
know
taking
some
of
the
strategies
and
et
cetera,
et
cetera.
You
know
I
feel
that
operations
kind
of
is
easier
than
you
see
a
word
to
use
for
an
aspect
and
maintenance,
and
so
on
and
so
forth
is
also
part
of
the
maturity
as
you
go
along.
B
Oh
sorry,
that's
okay!
Now
I
gave
away
my
my
sales
gonna
be
delivery
is
another
word
that
comes
to
mind
for
me:
a
little
people
kind
of
conflate
delivery
with
operations
a
little
bit
like
after
phrase
the
name
of
the
attack
yeah.
Maybe
that's
too
obscure,
I'm
still
leading
to
operations
too.
Okay,
Simon
go.
J
Yeah
that
my
thought
on
operations
is
that
I
see
perhaps
my
with
my
background.
I
see
maintenance
as
being
a
part
of
of
operations.
It's
a
subset
of
the
activities
that
take
place
within
it
and
the
challenge
I
see
with
with
support,
is
that
support
is
when
something
breaks
is
probably
spending
too
much
time
around
diet,
Health
to
my
own
good
and
and
on
the
on
the
delivery
side
as
well
as
for
me.
J
That
feels
a
bit
like
part
of
almost
a
release
process
as
well,
and
it's
touching
on
a
really
on
a
process,
the
delivery
of
of
software
or
platforms
for,
for
example,
and
I
like
operations,
because
it
it
fits
absolutely
squarely
with
running,
maintaining
and
supporting
a
a
platform
at
at
any
point
in
time,
regardless
of
the
life
cycle
of
anything
within
it.
If
that
makes
sense,
yeah.
D
Cool,
so
I
I
think
it's
quite
a
strong
argument
for
operations
being
the
rate
word
for
the
row,
but
maintenance
being
an
important
aspect
of
what
we
talk
about
within
the
descriptions
like
that's
what
I'm
just
hearing
kind
of
across
the
board
really
so
I'm
gonna
go
with
that,
so
I've
captured
that
down
below
cool.
So
we
are
what
80
minutes
in
and
I
the
goal.
Just
to
reiterate,
the
goal
of
today
is
for
us
to
be
comfortable
that
this
is
a
fairly
stable
table.
D
Now
that
doesn't
mean
that
nobody
can
ever
question
it
again,
and
this
is
what
we're
publishing,
but
it
means
that
we're
comfortable
that
people
spend
time
and
energy
writing
longer
descriptions
and
that
we're
not
going
to
end
up
blowing
up.
You
know
hours
of
people's
time
with
these
longer
descriptions
by
completely
rewriting
the
table,
that's
sort
of
the
level
of
completeness.
D
We
want
to
be
at
right,
words
changing
here
and
there
may
or
may
not
happen
so
I'll
Revit
rehash
that
question
and
say
how
do
people
feel
do
people
feel
like
this
is
in
a
place
where
they
feel
like
it's
stable
and
they're
comfortable
with
people
spending
time
on
the
detailed
sections
which
of
course
are
going
to
need
their
own
review
sections
and
and
all
that
stuff,
but
yeah?
Are
we
comfortable
with
people
moving
on
to
details.
I
D
Right
because,
as
we're
writing
the
details,
we're
like
oh
man,
this
is
broken
like
I,
really
wanted
to
be
able
to
write
about
this
at
the
operationalized
level
and
like
it
just
doesn't
fit
it
needs
to.
So
we
need
to
rethink.
You
know
how
we
categorize
operations
or
an
operationalized
platform
at
this
level
or
whatever
right.
I
Just
wording
wise
I
think
it's
fair
to
have
it
to
be
a
little
bit
open
so
that
we
not
necessarily
like,
pin
it
and
say
that
these
are
the
names
but
I
think
they
make
sense.
And-
and
we
might
have
some
sort
of
genius
moment-
that's
at
some
point
and
and
change
something,
but
it
would
still
make
sense.
Yeah
I
think
so
at
least.
C
I
B
D
D
You
know
for
the
current
model,
the
one
that
we're
agreeing
on
here
and
create
GitHub
issues
for
each
of
those,
so
that
we
can
have
an
owner
who
can
hopefully
drive
through
the
language
within
those
and
obviously
the
owners
are
gonna-
have
to
have
some
level
of
collaboration
because
language
used,
you
know
style
of
writing.
Those
kind
of
things
are
going
to
have
to
get
kind
of
emergently
defined
as
we
go,
but
so
that's
my
current
kind
of
process
for
thinking
about
what
comes
next.
B
One
thing
that
comes
to
mind
for
me-
and
maybe
these
ones
in
the
column
that
you
have
highlighted
here,
will
help
with
that
is
that
it
can
be
nice
to
have
a
rudimentary
something
for
someone
to
start
with.
With
that,
the
the
deeper
dive
we
might
end
up
diverging
significantly,
if
we
don't
so
I
guess,
I
just
wanted
to
put
that
out.
Do
we
think
that
these
what's
in
the
columns,
now
is
enough
for
that
or
how
do
we
make
sure
we're
starting
from
kind
of
a
similar
place.
D
Is
that
sort
of
the
scale
we
want
to
go
with,
or
are
we
looking
at?
You
know
longer
than
that?
We
in
the
detailed
section
there
was
no
extra
color
written
about
the
aspect
itself.
It
was
only
written
about
each
level
of
the
aspect.
Is
that
the
general
format
that
we
want
to
go
with,
or
do
we
want
to
add
a
paragraph
of
detail
about
the
aspect
itself
like
in
the
value
behind
the
aspect
and
then
the
other
thing?
D
The
third
thing
I
thought
about
when
looking
at
these
is
around
basically
like
how
concrete
we
get
like.
Is
this
where
we
start
talking
about
specific
practices
like
the
the
responsibility,
Matrix
and
and
things
like
that,
and
how
specific
do
we
get
and
do
we
want
to
link
like
reference
blog
posts
or
or
case
studies
that
like
are
publicly
available
and
therefore
it
can
be
like
C
and
and,
for
example,
this
discussion
here
or
whatever
like
yeah?
How
detailed
how
specific
we
want
to
get
so
those
are
just
some
ideas.
B
Yeah
I,
really
like
I,
was
thinking
first
of
all,
I
really
I,
like
the
idea
of
having
at
least
a
paragraph
kind
of
describing
and
that
might
be
the
stuff
in
this
column.
That's
there
or
that's
the
at
least
the
start
of
it
and
then
maybe
like
a
sandwich
or
two
like.
Maybe
we
start
small,
like
you
kind
of
did
here
and
that
make
sure
we
have
relative
consensus
and
then
we
can
expand
from
there.
B
I
You
know,
but
we
had
four
principles
with
basically
a
sentence
each
and
we
spent
like
it's
probably
around
10
to
20
hours
per
principle.
Getting
it
to
that
point
where
it
kind
of
just
makes
sense
from
that
little
sentence
and
I
don't
want
us
to
do
that
necessarily
especially
since
this
is
a
different
scope.
This.
This
is
not
something
that,
yes,
you
want
the
maturity
model
to
be
it's
fit
to
fit
on
the
slide.
You
know
yes,
but
it
doesn't
have
to
be
those
like
really
concise,
guiding
principles
in
in
that
aspect.
I
L
I
C
D
I'm
hearing
a
little
bit
of
like
tension
there
on
like
it's
really
hard
to
be
concise.
There's
that
quote
it's
like
I
would
have
written
you
a
shorter
letter.
If
I
had
more
time,
you
know
like
kind
of
thing
and
then,
but
at
the
same
time
like
by
not
putting
in
the
time
to
be
concise,
you
can
potentially
lose
readers
and
lose
readability,
and,
and
that
kind
of
thing
so,
like
I,
think
there.
That
is
a
natural
tension.
A
A
I
I
think
and
I
think
from
that
perspective,
we
could
spend
a
little
bit
of
time
to
try
to
get
the
maturity
model
to
be
not
necessarily
to
Deep
dive
into
specific
topics,
but
but
make
it
easy
to
digest
and
understand
what
what
we
mean
with
these
levels
and
and
so
on
and
so
forth.
Well,
any
one
of
these
aspects
could
be.
You
know
something
that
feels
another
one
of
those
projects,
maybe
something
more
technical
about
how
to
create.
I
You
know
the
the
the
self-service
Solutions
and
so
on,
like
there's
stuff,
that
can
come
out
of
a
maturity
model
and
then
be
you
know,
referencing
back
to
maturity,
model
and
say
like
we're,
we're
exploring
this
aspect
if
you're
around
these
parts,
the
maturity
model.
You
know
this
thing
is
for
you
and
that's
where
we
can
kind
of
Deep
dive
into
more
specifics.
D
Yeah
I'm
gonna
write
a
statement
and
you
could
tell
me
if
you
agree
with
it.
The
statement
I'm
going
to
write
is
it's
okay
and
even
expected
that
some
of
the
things
discussed
will
will
be
only
mentioned
and
could
benefit
from
a
much
deeper
dive.
This
is
out
of
scope
for
this
paper
and
is
an
opportunity
opportunity
to
add
a
GitHub
issue
to
track
a
deep
dive
paper
on
the
subject.
I
I
I
would
I
I
feel
that
that's
right,
like
that
doesn't
mean
this
is
the
right,
but
I
I
feel
that's
right.
It's
the
same
as
where
someone
asks
you
know,
I'm.
Looking
into
this
thing,
can
you
help
me
a
little
bit
and
then
you
kind
of
go
into?
Oh,
let
me
explain
the
200
year
history
up
until
this
point,
so
you
understand
everything.
Yeah.
C
I
This,
while
you
just
kind
of
want
your
answer
to
your
question,
so
to
speak,
not
that
this
is
that,
but
that's
kind
of
similar
thing
where
the
mature
demo
well,
it's
gonna,
be
it's
not
an
easy
digestible
thing,
but
we
can
at
least
try
to
make
it
easy
to
understand
for
P,
for
you
know
stupid
people
like
me,
so
we
can
look
at
it
and
kind
of
go
like
oh
yeah
yeah.
This
makes
sense
and
you
don't
have
to
look.
A
C
I
D
Okay,
so
the
so
I'll
leave
a
little
bit
airspace
on
these
General
format.
Things
I,
I,
agree:
Josh,
giving
like
a
complete
Blank
Slate
is
just
setting
people
up
for
disappointment,
because
if
they
write
something
amazing,
but
it
diverges
significantly
from
how
someone
else
has
written
we're.
Gonna
have
to
converge,
and
people
might
be
disappointed
with
that.
So
by
getting
these
in
place
so
because
they
don't
have
anything
else
if
they
were
to
pick
up
a
aspect
not
saying
you
have
to.
D
Okay,
so
then
so
I
believe
we're
getting
to
the
point
of
wrapping
up
the
one
thing
that's
on
my
mind
or
on
I
have
a
curiosity
around,
and
maybe
you
all
can
help
me
with
it
before
we
get
off
the
phone
here.
Is
we
had
in
the
original
paper
a
very
loose
sort
of
timeline
as
an
idea
of
trying
to
get
to
publication
for
Chicago?
The
reason
being
is
that
we
had
I
think
great
success
at
publishing
before
Amsterdam
the
the
white
paper.
It
gave
us
a
platform
to
have
a
conversation.
D
D
C
D
Like
the
one
day
for
retail
here
right,
so
if
we
want
to
try
and
hit
that
deadline,
the
soft
timelines
mean
that
we
need
to
have
reasonably
confident
so
similar
level
of
confidence,
as
we
currently
have
for
the
table,
reasonable
confidence
in
the
descriptions
and
the
details
by
September
10th,
which
would
give
us
a
month
to
have
deeper
confidence
in
that
right.
We'd
still
have
a
month
of
review
at
that
point
in
order
to
gain
confident,
deep
confidence
in
that,
so
that
we
then
would
still
have
a
month
to
be
able
to
manage
images.
D
Publication
promotion
Etc
like
we
did
for
Amsterdam.
So
this
is
following
the
same
kind
of
timeline.
So
what
that
means
is
that
it
would
give
us
one
month
to
get
detailed
sections
for
one
two,
three,
four
five
aspects
in
a
stage
where
we
are
like
yeah.
This
feels
like
a
thing
we
could
put
in
GitHub
and
edit
only
via
pull
requests
from
now
on.
D
D
F
I
I
think
I
I
I
feel
that
having
that
as
a
deadline
is
good
at
the
same
time,
I
also
feel
that
we
don't
necessarily
have
to
you
know
fit.
You
know
we
have
to
finish
it,
but
doesn't
necessarily
have
to
be
all
the
final
wording
and
stuff
like
that
like.
If,
if
it
goes,
you
know
people
don't
have
time
or
or
something
happens,
or
something
like
that.
I
It's
not
the
end
of
the
world
but
I
think
I
would
agree
the
the
just
the
the
level
of
feedback
on
the
the
platforms
white
paper
and
everything
that
happened
around
that
and
you
know,
being
in
Amsterdam
talking
to
people
about
that,
and
and
and
literally
like
talking
to
people,
even
you
know
in
Norway
as
customers,
and
they
start
referencing
that
and
I
kind
of
go
okay.
Well
by
the
way
you
know
you
know
having
something
to
kind
of
like
point
to
that,
we
all
work
against
like
it's.
L
I
K
I
I
can
unfortunately
I'll
be
on
PTO
for
two
and
a
half
weeks
out
of
this
one
month,
but
starting
next
Thursday.
So
as
much
as
I
wanted
to
try
and
Lead
something
I,
don't
think
I'll,
it
will
be
fair,
but
I'll.
Try
as
much
as
I
can
to
contribute
but
end
of
next
Thursday.
One
one
question
for
the
audience
like
and
I'm
new
to,
like
this
community
or
any
other
sensitive
community.
D
I
think
I
think
you're
spot
odd,
I
think
my
my
intention
is
to
put
an
issue
in
and
Link
it
to
the
GitHub
dock,
so
yeah
yeah
big
thumbs
up
on
that
for
sure
yeah.
That's
been
working
really
well
for
us.
So
the
that's.
Why
I
said
that
our
goal
is
to
get
to
a
point
where
we're
comfortable
with
it
it
being
like
stable
enough.
D
D
D
Like
you
could
interface,
if
you
feel
like
you
could
get
a
draft
out
by
the
time
you
leave
on
vacation
and
that's
not
overly
pressing
on
you.
In
my
opinion,
that'd
be
a
huge
awesome
benefit
the
one
the
one
risk
it
has
is
that
people
read
it
and
aren't
sure
what
you
intended
so
like.
Obviously,
you'd
have
to
have
a
little
bit
of
flexibility
with
people
like
you
know
not
not
sometimes
tearing
apart
things
and
not
realizing.
D
Why,
while
you're
on
vacation,
but
we
wouldn't
be
finishing
until
at
least
a
week
or
two
after
you
came
back,
so
we
would
still
be
able
to
incorporate
your
vision
again
on
the
back
side.
So
cool
I'm
gonna
make
a
note
of
that
here
and
then
I'll
add
you
when
it
comes
to
GitHub
into
that
that
section
as
one
of
the
people
and
more
people
can
join
in
right.
This
isn't
a
one-person
show,
but
yeah.
F
D
D
I
But
going
back
to
the
getaway
like?
Is
it
a
I?
Again,
you
know,
Define
responsibility
is,
is
not
a
great
good
idea
just
to
have
an
investment
adoption
into
face
operations,
measurements
issues
and
then
kind
of
tagging.
These
people
that
doesn't
necessarily
mean
that
the
wording
has
to
be
done
in
GitHub.
D
D
D
D
Be
a
reviewer
more
than
a
writer,
that's
okay,
cool
yeah!
No,
that's
awesome
the
fact.
We
have
three
out
of
five
already
with
people
that
are
really
passionate
about
them,
like
we're,
we'll
get
the
other
two
and
we'll
have
reviewers.
As
Robert
said,
he'll
be
reviewing
stuff
and
like
yeah,
so
it's
it's
you're,
not
people
who
are
owning
things
are
responsible
for
things
are
not
owning
them.
They're,
not
the
only
person
who's
gonna!
Do
it
there
there'll
be
lots
of
collaboration
on
it.
Still
it's
just
it's
good.
D
C
D
I
F
I
felt
comfortable
come
prepared
for
today
and
I
started
with
that.
That's
where
I
came
the
whole
point
of
action.
All
the
points
came
in
because
of
the
the
smooth
transition
I
had,
and,
and
also
thanks
for
the
team,
the
great
work
that
have
been
done.
A
lot
of
this
is
the
stabilization
to
be
helpful
for
even
not
only
at
what
I'm
contributing
on,
but
for
me
also,
it's
a
good
learning
and
entire
broad
aspect
of
it
as
well.
F
A
B
D
Right
well,
as
you
know,
we're
always
in
slack
we'll
be
in
the
docks.
I'll
get
the
GitHub
issues
out
at
some
point
today
tomorrow
and
and
get
people
attached.
Thank
you,
Sai
for
adding
your
email.
I
want
to
get
you
on
ASAP,
because
you
have
things
to
do
places
to
be,
but
yeah
I,
we'll
we'll
get
that
going
and
I'll
I'll
put
it
into
slack
and
all
that.
So,
thank
you
all
for
your
time.