►
From YouTube: Cartographer community meeting - Oct. 27th 2021
Description
Community meetings happen each Wednesday at 8:00 AM PT/11:00EDT
See the agenda here (https://bit.ly/2Z67z08), add any topic you may want to discuss and join us live!
00:00 Intro
01:24 The TL;DR
03:47 Follow up on Action items from last week
05:07 Brief RFC discussion
09:15 (Open Mic) Introducing the Core Infrastructure Initiative and the Cartographer progress with that
17:08 (Open Mic) Discuss 'owner' references in templates
A
A
There
you
go:
okay,
well
again,
welcome
everyone
and
remember
that
the
agenda
is
open
for
you
to
edit
at
any
topic.
You
may
have
for
this
session.
A
Okay,
so
for
this
not
only
for
this
session,
but
for
the
gender
for
the
structure,
it
felt
the
agenda.
We
added
a
new
section,
replacing
another
section
that
we
didn't
use
last
time
and
I
call
it
the
tldr
the
the
purpose,
to
give
a
really
short
overview
on
what
the
team
is
doing
right
now,
how
what
change
in
the
project
during
this
week,
and
so
that
way
the
community
will
get
a
proper
starting
point
for
this
conversation.
B
Yeah
for
sure,
thanks
david,
so
the
most
exciting
thing
that
we
did
this
week
was
we
we
shipped
zero,
zero
seven.
So
our
latest
release
and
the
exciting
bits
from
that
release
are
that
we
added
a
delivery
mechanism
to
enable
git
ops
workflows.
B
So,
if
you're
more
information
about
what
that
looks
like
feel
free
to
check
out
the
rfc
which
I've
linked
in
the
docs
here-
and
this
are
this-
this
release
also
has
a
couple.
Breaking
changes
to
be
aware
of
so
the
big
ones
are
is
that
we
rename
the
the
components
block
to
resources
in
the
supply
chain
and
we're
making
the
run
template
in
pipeline
cluster
scoped,
and
that's
just
to
better
align
with
some
of
the
other
templates
from
supply
chain,
so
yeah.
B
If
you're
upgrading
just
be
wary
of
those
two
breaking
changes.
So
that's
what
we've
been
up
to.
B
Yeah
so
after
the
big
release,
yeah
we're
planning
some
new
features,
a
lot
of
what
we're
working
on
is
actually
available
in
our
roadmap
as
well,
which
I'll
link
to
but
yeah,
just
in
the
in
the
short
term,
we're
just
looking
at
adding
some
more
features
to
to
delivery,
which
will
let
you
promote
a
deployment
so
right
now,
you
can
basically
like
once
you
finish
your
deployment,
it's
just
about
like
enabling
additional
workflows
that,
like
I'll,
let
you
to
run
checks
against
that
deployment.
B
So
there's
another
story
related
to
that
which
I'll
link
to
in
the
notes
as
well,
I'm
still
taking
some
feedback
where
right
now
we're
pretty
much
settled
on
the
idea
of
renaming
pipeline
to
runnable,
but
yeah
nothing's
been
changed
yet
so,
if
there's
any
other
feedback
feel
free
to
make
some
comments
on
that
story.
B
So
yeah
those
are
the
two
big
things:
we've
got
coming
up:
yeah,
it's
pretty
exciting.
A
Awesome,
thank
you.
Yeshua.
That's
great.
Okay.
Also,
I
added
a
a
short
section
on
follow-up
on
action
items
from
previous
meeting,
so
we
had
a
couple
nicey
for
the
adding
logging
and
error
handling.
A
A
Okay,
thank
you.
Emily.
C
D
Well,
I
think
there
needs
to
be
I
still
I
I've
been
bouncing
around
internally.
So
it's
something
I
need
to
share
with
the
open
source
community
type,
using
stricter
typing
for
resources
in
a
supply
chain
same
within
the
delivery,
so
that
we
can
actually
have
a
source
versus
sources
and
have
it
be
sensibly
typed.
So,
if
there's
no
more
to
talk
about
on
that
right
now,
I'll
try
to
make
sure
that
we
do
have
a
proposal
for
that
in
an
rfc,
maybe
that
rfc
yeah.
E
The
other
rfc's
that
exist-
and
I
know
we've
we've
kind
of
talked
about
them
as
a
team,
but
I
think
you're
great
just
for
you
know,
conspiracy,
say
to
say:
okay,
these
are
the
things.
These
are
the
like
big
ideas
that
we're
we're
working
on.
These
are
kind
of
when
we
believe
that
they'll
land
etc.
E
So
well,
we're
talking
about
rfcs
here.
I
think
it'd
be
great
to
add
an
action
item
for
maybe
the
next
meeting
to
look
at
that.
E
D
I
think
there
was
a
new
rfc
this
week
that
we
probably
should
have
popped
in
here,
but
I
never
got
a
chance
to
look
at
it.
I
think
a
new
one
has
turned
up.
A
E
D
C
Cool
it
would
be
probably
great
to
ask
the
author
of
rfc
14
to
join
this
session
as
well.
D
E
A
There
you
go
that's
great
okay,
there
is
not
anything
else
for
rfcs,
you
can
move
the
open
knife
discussion.
Well,
it
seems
like
mine
is
the
first
one,
so
I
wanted
to
introduce
the
common
infrastructure
initiative.
I
believe,
yeah
core
infrastructure
initiative.
This
is
a
program
by
linux
foundation
and
the
goal
is
to
provide
a
standardized
way
to
certify
that
open
source
projects
out.
A
There
follow
a
baseline
of
best
practices
on
different
books
and,
depending
on
how
much
of
these
criteria
we
need,
we
meet,
we
earn
the
passing
level
or
silver
level
or
goal
level.
So
if
we
see
here,
for
example,
it's
in
the
gold
level
we
have,
we
have,
for
example,
node.js
only
has
passing
level,
but
they
have.
We
have,
for
example,
the
linux
kernel,
it's
in
the
gold
tier
obviously
and
pearl
in
many
other
packages
and
software
we
use
every
day.
A
A
section
that
I
started
you
know
this:
this
program
works
in
a
self.
It's
a
self
certifying
thing,
because
we
we
enter
the
information.
Some
of
the
information
is
automatically
retrieved
from
the
repo
and
the
remaining
is
is
entered
by
by
whoever
owns
this
page.
I
actually
owned
this
page,
so
I'm
I'm
getting
started,
I'm
adding
the
stuff
that
I
know
that
I'm
aware
of
that
there
are
some.
A
So
it
means
that
for
anyone
out
there
that
this
project
follows
a
common
baseline
of
best
practices,
so,
for
example,
one
of
the
unmet
criteria
right
now
is
we
cannot
find
release
notes
in
the
repo
right
there.
There
is
no
change
log.
A
Some
other
form
of
release,
notes
that
the
the
the
human
can
understand
out
there
what's
new
and
what's
important
from
this
release,
so
that's
something
we
will
need
to
discuss
how
to
handle
this
release
notes.
I
know
that
it
help
now.
It
has
some
features
to
automatically
generate
we'll
need
to
see
how
to
handle
this
and
well.
There
will
be
several
oral
domains
that
I
will
be
discussing
with
you
all
to
see.
How
can
we
meet
this
criteria?
A
E
A
A
It's
more
what
users
get
out
of
this,
for
example,
with
better
release
notes.
Well,
we
will
have
more
users
that
are
that
have
clear
information
on
what's
new
and
why
this
new
release
is
important
right.
So
at
least
getting
the
passing
legal
criteria
is
something
that
is
considered
necessary
for
open
source
projects
under
the
vmware
umbrella,
but
with
with
the
progress
of
you,
know,
silver
and
gold
level,
attorching
several
security
topics,
so
it
will
be
great.
E
D
In
all
seriousness,
though,
like
it's
nice
to
have
a
well
a
well
groomed
list
of
criteria
that
makes
your
project
more
attractive,
so
so
I'm
all
for
it.
I
just
like
to
put
my
hand
up
for
helping
with
the
analysis
section
of
this,
because
we
we
have
been
talking
about
static
and
dynamic
code
analysis
and
I'd
love
to
get
some
feedback
too
on
what
tooling
should
work.
D
We
were
thinking
of
using
sonarqube,
but
it
does
talk
about
using
floss,
and
so
I'd
like
to
know
what's
available
in
the
floss
domain,
for
us
to
ensure
that
we
meet
those
criteria
and
that
we
get
good
feedback
on
code
quality,
make
our
reviews
easier.
It
will
make
it
easier
for
us
to
be
consistent,
so
that
might
my
hands
up
for
that.
If
you
need
to
find
someone
to
talk
to
about
it,.
F
On
that
you
know,
I
know
we
have
done
some
nice
integration
with
something
sony
cube
cloud.
I
think
they
do
like
freeze
service
for
open
source
projects,
which
is
kind
of
nice,
but
there
is
a
little.
I
know
that
recent
other
tooling
services,
south
services,
the
code
curve,
I
think,
had
some
fairly
horrendous
security
issues
as
well.
So
it's
recent
of
last
year,
so
it's
probably
yeah
it's
one
of
those
how
they
got
implemented,
but
yeah
having
that
kind
of
stuff
analysis
and
also
like
it's
really
really
really
really.
Nice.
D
Yeah,
I
think
what
I've
what
I
struggled
with
was
knowing
that
these,
because
also
for
the
cncf
criteria.
They
want
us
to
use
common
open
source
tooling
for
these
things,
and
it's
just
hard
to
find
a
list
for
go
of
good
tooling.
That
isn't,
in
my
opinion,
weak
vet
tools
that
don't
seem
to
do
the
job
very
well.
D
So
the
only
thing
I
found
that
worked
with
cena
cube-
and
I
don't
know
whether
being
available
for
open
source
is
the
same
as
being
open
source
in
itself
and
if
it's
open
source
enough
for
it
to
satisfy
these.
So
I'd
like
to
dive
in
on
that,
make
sure
we're
using
a
tool
that
will
meet
this
thing's
criterias
and
the
cncf
ones.
A
E
A
A
D
And
I
just
want
to
start
the
discussion,
because
I
know
there's
going
to
be
some
some
tool
and
throwing
on
this,
but
it's
a
new
issue
and
I
think
it's
significant
enough
to
need
to
talk
about
an
architectural
choice
here,
but
there's
no
rush
for
it,
and
it's
just
that
in
our
templates
we
currently
we
can,
we
can
write
a
template
and
the
template
can
be
consumed
by
either
a
delivery
or
by
a
supply
chain.
D
D
D
Workloads
and
deliverables
do
have
different
specs
workload
has
end,
whereas
deliverable
does
not
at
this
point,
so
there
will
be
situations
where
you
will
only
want
to
use
a
workload,
for
example,
but
then
I
wonder,
I
think,
that's
probably
the
right
thing
for
those,
but
I
still
think
that
we
need
to
be
able
to
make
dynamically
reusable
templates,
because
there's
nothing
different
between
the
two.
D
Why
would
we
deploy
two
templates
in
a
system
if
we
can
avoid
it,
especially
if
you
just
want
to
be
out
of
carp
launch
it?
Yes,
the
deliveries
deliveries
templates
tend
to
live
on
a
different
cluster
than
on
a
then
on
where
the
supply
chain
sits,
but
if
you
want
them
on
the
same
one,
that
should
work.
C
Did
this
as
a
workaround
be
solved
by
some
fancy,
ytt
templating.
D
I
don't
know
if
we
can
check
whether
the
value
exists
or
not.
If
we
can,
we
could
do
that
and
choose
one
or
the
other.
I
think
the
easier
workaround
is
to
copy
pasta,
create
two
templates:
a
delivery
template
and
a
workload
template
that's
an
easier
work
around.
D
At
this
point,
I
would
rather
the
solution
not
to
personally
not
to
throw
even
more
ytt
imperative
content
in.
C
D
Yeah,
I'm
just
thinking
about
the
one
example
where
I'm
building
a
supply
chain
and
delivery
at
the
moment,
and
I
would
rather
have
the
two
templates,
because
there
is
another
small
issue
too,
which
is
that
that
template
just
uses
the
metadata
name
and
the
delivery
tends
to
also
have
the
same
name.
Sorry,
the
deliverable
has
the
same
name
as
the
workload,
so
we
get
a
name
collision.
B
I
guess
my
only
hesitation,
my
only
hesitation
here
is
that
we
have
like
it
would
be
interesting
to
see
some
more
use
cases
of
where
these
these
templates
collide
between
workload
and
delivery,
because,
right
now
we
have
one
instance-
and
it's
it'd
be
nice
to
dry
that
up,
but
it
might
be
worth
it
to
like
see
if
we
can
come
up
with
some
other
use
cases
before
we
start
considering
like
whether
or
not
this
is
something
we
need
to
solve.
D
D
E
Probably
images
as
well
right,
I
think,
there's
a
push
for
using
supply
chains
for
images,
and
I
could
see
that
being
used
for
both,
I
think
from
like
a
a
ux
perspective
or
like
a
user's
perspective
like
you
wouldn't
want
to
have
to
know
you
know
one
versus
the
other
right
like.
If
it's
the
same
template,
it's
going
to
only
work
the
same
way
between
both.
D
I
think
it's
important
as
an
alias,
because
I
think
there's
a
lot
of
times
where
you
just
want
to
be
very
explicit
and,
and
that
way
our
template
will
just
obviously
explode.
If
you
said,
if
you
said
you
know,
workload
workload.spec.nf
right
instead
of
telling
us
owner.spec.m
doesn't
exist,
it
would
just
simply
say
no
workload
here,
and
that
would
be
useful.
So
in
the
templates,
where
you
know
it's
specifically
for
a
particular
type
of
chain
for
one
of
a
better
word,
then
you
use
that
specifically
and
the
owner
is
a
reference.
D
That's
the
generic
version,
so
the
duct
type
or
the
most
common,
the
most
common
interface
between
the
two.
E
But
I
mean
that
that
brings
up
a
bigger
discussion
right
like
what
is
the
future
for
ytt
inside
of
supply
chains
and
deliveries.
Right
of
this,
like,
like
we're
not
I
mean,
in
the
context
of
delivering
things
in
a
certain
time
frame
right,
like
those
kinds
of
work
around
discussions
are
important,
but
if
we're,
if
we
want
to
make
something,
you
know
for,
if
we
have
our
eyes
on
the
longer
term,
which
I
think
like
these
discussions
should
be,
should
should
be
right
like
what
is
what
are
we
doing
long
term
with
ytt.
F
D
It's
very
light.
We
have
we,
we
have
enough
abstraction,
the
the
the
choice
between
like
like
ytt
and
the
plane,
templating,
that
we
have
are
two
little
implementations
that
are
called
from
the
same
base,
which
comes
basically
in
with
a
set
of
inputs,
known
inputs
that
you
can
get
values
for
your
get
values
for
for
your
interpolation
right,
yeah.
So.
D
D
E
E
Double
down,
or
is
this
something
that
we
want
to
like
bridge
the
functionality
gap
with
stuff
to
get
us
to
where
we're
at
with
ytt
and
then
go
from
there?
So,
like
from
my
perspective,
you
know
it's
not
it's
more
of
an
engineering
discussion
right
like
do.
We
want
to
continue
to
use
it
double
down
or
what?
What
do
you
all
think.
D
We
obviously
don't
have
enough
users,
but
the
current
percentage
of
users
using
template
versus
ytt,
it's
like
ytt,
and
then
this
is
people
using
our
templates.
I
use
our
templates
when
I
write
a
template
to
get
started
and
then
I
always
go
to
ytt
by
the
end
of
it.
F
Controversial
question:
what
about
other
templating.
D
That's
not
as
con
that's
not
as
controversial
as
name
it
name,
one
that
does
as
well
structurally
and
also
supports
the
important
things
very
important
is
conditional
logic,
looping
logic.
F
I
think
the
I
mean
I've.
I've
quite
used
the
go
template
from
charts
and
that's
what
I'm
most
familiar
with
it's
just
those.
I
think
I
mean
that's
just
that's
just
one
that
I
can
just.
D
F
One
other
maybe
thing
that
might
be
worth
considering.
That,
though,
is
adoption
of
how
familiar
people
are
using
it,
so
it
might
make
our
lives
easier,
but
is
there
a
barrier
to
entries
to
some?
Do
you
have
to
learn
ytt
somebody,
that's
not
familiar
with
ytt.
It's
I've
had
to
scratch
my
head,
a
little
I'll,
be
honest,
not
yeah.
That's
probably
just
because
I
haven't
had
the
time
to
you
know,
probably
look
at
it.
I
don't
mean
to
offend
it.
F
D
D
I
see
why
the
choices
exist,
because
this
gives
you
a
structural
template.
The
problem
with
go
templates
is
that
you
then
start
to
have
to
make
sure
your
white
space
makes
sense,
and
so
that
becomes
frustrating
more
so
than
I
would
just
wish.
I
could
get
some
yaml
in
here
and
have
it
injected
as
it
as
an
object,
rather
than
as
a
string
right
and
that's
where
most
of
us
land
on
that.
D
I
almost
think
that
our
templating
should
be
replaced
with
go
templating
and
then
we'd
have
a
comparison
that
actually
makes
more
sense
that
we
could
have
users
try
to
one
that's
a
very
common
idiom,
which
is
go
templates
and
one
that
is
designed
to
improve
the
structural
templating
pains
that
you
have
rather
than
the
templating
we
have
today,
which
is
entirely
unique.
I
mean
it's
json
path,
but
it's
still
entirely
unique
and
very
limited.
E
Yeah,
I
guess
I
guess,
like
that's
what
I
was
gonna
say
like
what
do
we
need
to
get
there
to
get
to
a
point
where
we
can
make
an
intelligent
decision,
one
way
or
the
other?
So
if
it's
like,
we
need
to
support,
go
templating
first,
to
be
able
to
say:
okay,
it's
this
versus
that,
then
you
know
like
it's
not
a
decision
we
need
to
make
today.
I'm
sure
we
could
talk
about
it
a
lot
but
like
what?
B
Are
we
just
going
to
rely
on
templating
for
all
these
different
features
that
we
want
to
support,
or
is
there
a
nicer
experience
that
we
can
provide
to
users
if
we
take
that
and
make
it
a
top-level
feature
in
cartographer
right,
and
I
think
that
that
top-level
feature
support
is
going
to
be
case
by
case
and
because
yeah,
if
we
can
offer
a
better
experience
in
cartographer,
I
think
we
should
do
that
because
you.
D
E
Should
we
be,
should
we
be
closing
that
functionality
gap
right
like
that's,
that's
the
that's!
The
question
is
like
yeah
should,
should
we
be
right
or
can
we
like,
I
was
saying
double
down
on
ytt
like
in
my
opinion,
ytt
is
pretty
ugly
in
there
but
and
like
offering
a
nicer
user
experience
would
be
better,
but
right.
H
So
I
I
don't
think
pivoting
to
to
going
to
blades
would
be
like
I
mean
it's
like
saying,
like
yeah,
we
get
apple's
apples
comparison
because
now
we're
just
using
two
different
templating
engines,
but,
like
you
know,
I
don't
think
we
want
to
go
to
something.
That's
text-based,
and
you
know
one
of
the
things
that
that
our
baked
approach
has
is
that
it
is.
C
H
C
The
amount
of
docks
that
would
be
required
for
writing
building
these
features
in
is
slightly
terrifying
and
like
maintaining
that,
or
else
like
shoveling,
that
off
to
ytt,
where
the
features
already
exist.
A
D
D
My
problem
is
that
everyone
who's
talked
about
it,
talks
about
it
like
lofty
ideals
and
has
absolutely
nothing
concrete
to
present,
which
is
why
we
have
ytt
templates
today,
if
that's
not
unreasonable
to
say
so,
I
think
the
lofty
ideals
are
things
we
can
approach
while
also
giving
people
an
out
when
they
need
to
get
their
product
to
work.
H
F
It
sounds
like
there's
quite
a
few,
a
few
different
parts
to
it.
What's
the
next
approach
is
it
is
this?
Is
there
an
issue
for
you
already?
Is
there
what
would
be
the
best
approach
to
kind
of
start
dumping,
some
thoughts
and
tracking
this,
because
it
sounds
like
it's
not
going
to
be
a
solve
overnight
kind
of
a
thing
and
there's
lots
of
thoughts
and
lots
of
maybe
looking
experimenting
or
research
needs
to
be
done.
D
I
think
that
we
have
to
identify
those
like
those
use
cases,
so
so
so
the
the
the
repeats
are
about
things
where
you
have
more
than
one
thing.
You
need
to
configure
I'm,
but
like
I'm,
just
going
to
jump
straight
to
my
solution
just
to
try
to
describe
what
I
I
think
should
happen
here
is
that
we
can
template
any
object
out
that
we
want
to
so
there
should
be
an
object.
That's
well
designed
for
dealing
with
this
problem,
which
is
hey.
I've
got
I've
got
a
bunch
of
resources.
D
I
need
to
write
config
for
so
we
have
a
config
template.
The
config
template
should
come
up
with
that
by
using
a
sub
resource.
That's
designed
to
omit
that
and
then
you
should
not
need
a
ytt
template
for
that.
So
that's
a
that's
being
able
to
do
a
looping
solution
of
some
kind,
all
right
it
should
be.
I
think
it
should
be
aware
of
the
input.
D
So
if
it's
for
a
like
a
service,
a
list
of
services
that
you
want
to
be
able
to
attach
to,
then
it
should
know
about
services
and
generate
some
result,
which
means
that
we
need
to
either
work
with
the
community
or
find
solutions.
That
already
do
that.
That
say,
take
a
list
of
services
and
create
some
config.
You
can
append
and
then
the
other
one
is
conditional
logic
and
that's
way
more
complicated.
And
I
haven't
got
any
clues
about
that
one.
But
the
conditionals
tend
to
be
based
on
the
fact
that.
D
H
But
yeah
it's
almost
like
you,
it
feels
like
you
want
to
have
something
like
you
know
that
recursive,
like
templating
nesting,
part
and
then
like.
I
don't
know
if
you
folks
remember
much
or
ever
want
to
remember
much
about
xslt,
but
the
way
you
could
say
well,
I
want
to
apply
those
templates,
and
this
is
the
selecting
filter
that
I
want
on
it
right
and
then,
if
you
could
have
those
filters,
then
that
kind
of
gets
you
away
from
having
like
conditionals,
because
you
know
you
can
just
say
this.
B
The
underlying
problem
is
that
there's
all
these
different
use
cases
we
need
to
tackle
them
individually,
and
it's
going
to
be
a
much
larger
discussion
to
see
if
we
can
come
up
with
something
that's
cohesive
and
that
makes
sense
for
each
individual
use
case.
But
until
that
happens
until
we
can
identify
all
those,
then
I
think
ytt
will
just
be
there
for
a
while
or
some
templating
will
be
there
for
a
while.
D
I
think
logical
templating
will
be
there
forever.
That
would
be.
My
recommendation
is
that
we
don't
ever
think
we're
going
to
lose
it,
because
I
think
people
will
always
need
a
new
solution
out
the
gate
that
hasn't
been
solved
with
a
crd
and
with
controllers,
and
I
think
it
behooves
us
to
support
that
in
perpetuity,
because
that,
although
ytt
is
complex,
that
is
immediately
a
lower
barrier
to
entry,
then
well,
you
need
your
own
controller
and
crd
to
support
this
problem
right,
but
one
thing
we
could
do
to
sort
of
like
separate
the
concerns.
D
A
little
bit
is
actually
something
that's
been
brought
up
before,
which
is
produce
a
crd
ytt
itself.
So
then
there's
no
longer
our
problem.
It's
just
that's
the
default,
one
that
you
can
use
in
a
like.
A
config
template
create
a
a
ytt,
and
that
could
be
a
an
easy
proposal
to
separate
the
concerns,
and
then
let
someone
who
wants
golang
templates
to
go
and
do
that
and
create
a
to
create
their
own
crd
for
that
as
well.
E
I've
added
an
item
to
the
action
item
there.
B
I
don't
even
know
if
we
want
to
make
this
one
rfc,
maybe
like,
like
one
free
choose
case
right.
C
E
I
think
I
think
that's
reasonable,
like
this
is.
This
is
clearly
a
longer
discussion
right
and,
like
I
think
in
my
mind,
this
is
like
a
this
is
like
a
like
a
medium
to
long
term
thing
that
we
need
to
figure
out
like
for
now.
Ytt
is
here
right,
and
so,
let's
you
know,
our
community
usage
is
obviously
minimal
right.
So,
as
we
grow
right
like
we
can,
these
are
things
that
we
can
can
rally
around
in
terms
of
like
like.
Should
we
address
the
functional
gap
to
what
ytp
can
do
natively
with
photographers?
H
D
I
still
want
to
address
something
that
james
has
said
there,
though,
about
adoption,
right
and
and
comfort.
I
think
at
the
very
least
we
could
explain
in
the
documentation
welcome
to
your
first
ytt
template.
It
doesn't
have
to
look
as
overwhelming
as
you
think
it
here.
Here's
the
boilerplate.
D
D
It
is
pretty
straightforward,
but
if
it's
a
little
hand-holdy
document
a
bit
of
documentation,
then
maybe
people
won't
be
worried
about
it
and
then
the
other
thing
is
is
in
our
example,
to
make
sure
that
we
over
explain,
because
I
believe
our
example
carries
ytt
in
it
and
and
certainly
will
soon,
because
I
believe
we're
putting
in
an
example
that
uses
choices
for
git
ops
behavior.
So
we
should
over
explain
in
that
to
a
user
who's.
Reading
the
example
just
what
the
ytt
is,
even
though
we
can
say
here's
your
ytt
documentation.
A
Yeah,
it
sounds
great,
so
the
the
action
item
will
be
for
now
to
create
the
issues
for
these
topics
right
so
make
sure
to
add
your
name.
If
you
want
to
volunteer
in
doing
so,
and
we
will
make
sure
that
the
users
out
there
people
from
the
community
are
will
provide
your
feedback
for
the
discussion.
A
It
looks
like
a
really
big
discussion,
so
it's
important
and
we
love
to
to
have
feedback
from
the
from
our
users
out
there.