►
From YouTube: GitOps Principles Committee Weekly Meeting 20210714
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Fair
enough,
all
right,
I
will
we'll
just
do
it
ad
hoc.
Then,
let's
see
in
terms
of
last
week,
I
know
there
was
quite
a
bit
discussion
around
just
revamping
some
of
the
the
principles
and
getting
them
simplified.
A
Maybe
since
a
lot
of
people
are
missing
today,
but
we
do
have
a
new
one,
daniel
warner,
do
you
want
to
introduce
yourself.
A
Well,
when
you
work
that
out,
let
me
know
so,
I
think
just
to
kind
of
reset-
and
please
go
add
your
name
to
the
attendees
if
you
haven't
put
in
yet
the
we
were
talking
about,
having
kind
of
a
goal
in
mind
of
trying
to
have
maybe
a
1.0
version
by
kubecon.
A
We've
got
git
ops
con
coming
up
at
that
time,
so
it
would
be
really
awesome
if
we
could
get
there
now.
Obviously,
you
know
we
either
get
there.
We
don't,
but
to
have
that
in
mind
as
as
a
north
star
here
to
be
shooting
for
that.
I
think
that's
something
that
we
can
all
work
towards
and
hopefully
achieve.
A
The
other
thing
is
just
level
of
participation.
I
think
we've
slowed
down
just
a
little
bit.
Last
week
we
had
quite
a
few
people
this
week.
Maybe
people
aren't
able
to
join,
I'm
wondering
actually,
if
maybe
we're
doing
this
too
often,
maybe
we
should
be
doing
it
every
other
week.
Let
it
build
up
a
little
bit
more
make
make
it
more
of
an
event
for
people
to
join
any
thoughts
about
that.
B
B
We
should
probably
don't
need
to
meet
as
often
I
don't.
I
don't
know
what
anyone
else's
opinion
on.
I
think
maybe
we
can
at
least
start
a
discussion
on
git,
but
I
agree
then
I
think
maybe
we
should
have
it
every
other
week
and
if
we
are
maybe
time
box,
it
may
be
for
a
little
longer.
I'm
not
sure
we
can
hash
that
out,
but
just
in
short
yeah.
I
think
I
agree
with
that.
Having
it
maybe
every
other
week.
C
A
Well,
then,
I
think
it's
motion
will
probably
carry
I'll.
I'm
gonna
follow
up
just
quickly
with
the
other
co-chairs
over
slack
so
I'll.
Take
that
as
an
action
item
to
look
at
moving
to
like
an
every
other
week,
cadence.
A
A
Let's
see
and
then
in
terms
of
work
that
we
want
to
get
get
it
get
done
today,
anybody
have
any
items
they
want
to
bring
up.
D
I
do
have
a
question
on
in
in
previous
meetings.
We
have
been
talking
about
this
list
of
pending
items
to
go
and
start
and
continue
so,
but
it
has
not
been
clear
if
that's
going
to
be
done
under
this
umbrella,
working
group
or
in
a
different
work
stream.
So
has
there
been
any
communications
or
decisions
or
discussion
around
that.
A
D
No,
it
was
more
on
the
started
to
work
on,
for
example,
documenting
patterns
or
documenting.
I
don't
want
to
call
it
best
practices,
but
at
least
like
reference
way
to
do.
E
A
Yeah:
okay
comment
from
rob
earth.
C
D
C
And
we're
we,
we
need
to
establish
a
road
map
and
I
kind
of
got
that
as
an
action
item.
So
I
will
try
to
gather
all
these
things
that
we
said
that
we
kind
of
wanted
to
do
and
try
to
put
it
into
some
sort
of
list
that
we
can
kind
of
like
look
at
and
organize
from.
C
So
I'm
not
really
sure
how
that's
gonna
look,
but
I'm
gonna
give
it
a
go
see
if
we
can
get
it
more
organized
than
what's
now
good
fantastic.
But
but
if
there
is
things
we
we're
talking
about
the
the
patterns
and-
and
you
know
all
these
different
sources
of
information
that
we
kind
of
want
to
gather-
we
were
talking
about
a
a
radar
or
landscape
map
or
whatever
of
get
ops.
Everything
like
that.
C
It
would
be
great
if
we
had
some
sort
of
a
list
to
work
out
of
from
so
at
least
when,
when
I
start
getting
like
a
structure
at
least
I
have
something
to
put
into
it:
I'm
not
really
sure
and-
and
that's
probably
not
a
principles.
Meeting
thing:
that's
probably
a
git
ops,
working
group,
monthly
yeah
topic.
I
guess.
A
I
think
I
think
you
would
agree,
though,
if
william
is
ready
to
start
working
on
one
of
these
next
items
by
all
means
like
go
scope
if
they
open
the
issue
or
open
the
pr
and
let's
move
it
forward.
I
mean
we're
going
to
move
a
lot
faster
if
people
are
bringing
work
forward,
that
they'd
like
to
get
done,
then
waiting
for
like
a
committee
decision
or
something.
So
I
don't
know
that,
like
william,
if
you're
ready
to
get
going
on
starting
to
create
the
pattern,
I
think
we'd
say
high
five.
A
Let's
just
do
it
in,
but
in
that
case
where
so
I
would
put
them.
I
would
put
the
pr
on
the
website
because
I
think
that's
where
we'd
probably
store
it
and
we
could
you.
You
could
create
a
branch
there
that
that
we
could
create
like
a
navigation
item
for
the
website
and
then
just
have
something
kind
of
similar
to
the
blog
format
for
patterns.
We
can
create
like
a
little
metadata
around
it
and
I
haven't
really
spent
a
lot
of
time.
Thinking
about
it.
A
But
you
know
the
that's
the
there's
the
website
repo
and
we
could
probably
create
a
new
content
item
under
there
for
like
patterns
or
best
practices,
or
something
like
that.
And
if
you
wanted
to
take
a
crack
at
the
metadata
and
start
making.
One
christian.
B
Sorry
that
was,
I
was
on
youtube,
would
is
the
website
the
place
for
it
or
what
would
the
with
the
principal's
document
the
open
get
ups?
You
know
we
have
the
the
documents
section.
A
Yeah,
so
I
think
the
original
idea
for
the
patterns
was
this
would
be
basically
directory
where,
like
I
want
to
find,
how
do
you
do
get
ups
if
I'm
using
aws
and
github,
and
this
that
and
the
other
thing,
and
you
could
kind
of
look
through
a
catalog
of
practice,
best
practices
or
patterns
that
people
had
posted
and
shared
to
say:
hey,
here's,
how
we
here's,
how
we
built
our
process,
here's
how
we
did
it!
You
can
share
this,
you
can,
I
don't
know
upload
it
or
something.
I
think
that
was
the
idea.
C
A
A
D
Yeah
that
that
that
will
be
one,
so
I
work
in
the
telco
space
telco
industry
and
I
work
a
lot
with
git
ups
on
telco
environments,
so,
for
example,
start
flushing
out
some
of
these
patterns
for
telco,
for
example,
for
5g
how
they
look
and
start
documenting
those
tunes
again
put
something
out.
That
is
at
least
provide
some
guidance
or
some
ideas
on
what
to
consider
how
to
structure
some
concept,
such
as
a
map
to
what
a
telecon
it
things
like
that.
So
it's
it's
in
that
extreme.
In
my
case,.
A
No
gotcha,
okay,
yeah,
I
mean
it
when
it
comes
to
like
where
you
want
to
put
submissions
and
stuff.
I
mean
we've
got
the
open,
git,
ops,
org
and
I
think
maybe
scott,
do
you
want
to
give
just
a
quick
share
for
those
that
don't
know
that
what
we're
doing
there.
E
Absolutely
and
again
and
sorry-
I'm
sorry,
I
was
late,
but
I'm
glad
that
you
I
knew
you
had
this
dan
and
I
had
to
take
a
quick
break.
E
Yes,
so
the
I'm
trying
to
look
at
the
camera
here,
I'm
in
a
new
space
today,
but
yeah,
so
so,
william,
let
me
I
mean,
maybe
it
would
just
be
good
to
share
my
screen.
E
I
don't
know
yeah.
Let's
do
let's
go
ahead
and
do
it
for
one
sec
here
is
the
okay.
So
here
is
the
upping
it
ups
project,
basically
that
the
top
level
these
repositories
all
have
some
description
of
what
they're
for
at
this
point,
except
for
events,
which
is
just
bare
bones,
and
I
we're
gonna
set
that
up
asap
github
prevents
you
from
unless
you
use
the
api,
which
I've
just
I've
been
too
lazy
to
do
that
so
far
or
too
many
other
things
in
the
agenda.
E
Github
ui
prevents
you
from
adding
a
description
until
you
actually
create
your
first
commit.
So
we'll
do
that
soon,
but
but
basically,
the
point
of
that
is
this
is
the
only
one
that
doesn't
tell
you.
The
point
of
this
is
that
we're
going
to
have
a
separate
space
for
the
idea
is
we'll
have
a
separate
space
for
events
that
will
stand
on
its
own
and
could
be
used
for
various
things
and
what
the
most
the
most
pressing
need.
We
know
right
now
is
for
the
website,
and
so
that
is
in
this
repo.
E
The
project.
Repo
is
the
top
level
kind
of
entry
point
for
the
open
gaps
project.
So
it
should
give
you
all
the
information
about
the
things
that
I
just
mentioned
and
and
what
dan
had
just.
I
guess,
if
I
sort
of
heard
right
at
the
very
end,
I
think,
of
what
you
were
saying,
but
if
you
wanted
to
work
on
best
practices
or
patterns,
or,
let's
just
say
use
cases,
case
studies,
even
user
user
roles
or
whatever
other
other
supporting
documents
that
we
really
should
have.
E
E
Well,
yeah,
ultimately,
ultimately,
though,
if
dan
correct
me,
if
I'm
wrong,
but
I
think
the
website
will
in
a
a
minute
yeah
a
fast
follow
near
hopefully
near
future.
Iteration
yeah
we'll
consume
these
documents
from
these
other
places
where
they
live
so
so
the
goal
of
them
will
be,
they
will
live
on
their
own
and
they
will
be
available.
E
The
only
value
for
them
won't
just
be
for
the
website.
People,
for
example,
can
can
download
these
packages
themselves.
You
know
what
I
mean:
they're,
versioned
and
so
on,
but
but
by
probably
the
most
visible
place
for
the
foreseeable
future
will
be
on
the
website.
E
But
yeah,
actually
dan
you're
right
until
we
get
that
done,
we're
going
to
be
duplicating
some
stuff
in
the
website
repo
for
now,
okay,.
A
D
Let's
see
so,
I
think
yeah
william,
go
ahead
so
question
in.
In
that
sense,
let's
say
the
published
version
is
going
to
be
in
the
website
following
the
idea
that
robert
presented
there.
So
what?
If
we
do,
the
iteration
on
a
pattern
of
repo
do
the
iteration
and
then
the
published
version
goes
into
the
website.
E
One
thing
I
did
that
makes
sense,
and
one
thing
I
didn't
mention:
I
just
wanted
to
kind
of
put
a
period
on
the
on
what
our
punctuate,
what
I
introduced
for
a
second
ago,
so
the
documents
repo
is,
is
versioned
and
it's
intended
to
be
versioned
so
yeah.
That
makes
perfect
sense
right
now.
We
we
currently
have
we're
at
a
pre-release
version,
we're
working
toward
a
v
1.0.0.
E
We
have
a
milestone
for
that
right.
Now,
we've
only
identified
two
things
that
are
that
we
know
we
want
to
do
before.
We
have,
you
know
a
first
version
and
our
and
we
set
our
stated
goal-
was
to
have
a
version
at
least
before
kubecon
n
a
ideally
before
then
so
we
can
publicize
it
to
folks
and
get
people
excited
that
things
are
actually
happening
and
there's
a
real
kind
of
standard
out
there
that
this
working
group
is
decided
on
but
yeah,
that's,
that's
primarily
the
principles
but
the
other
supporting
documents.
E
They're
meant
to
be
versioned
together,
because
the
principles
can
excuse
me
for
now.
The
principles
do
will
be
linked
to
glossary
items,
and
that
is
the
goal.
E
But
that
glossary
may
potentially
want
to
connect
to
other
supporting
documents
you
know.
So,
if
there's
something
in
there,
that's
really
relevant
to
a
specific
you
know,
set
of
use
cases
or
or
whatever
else
it
would
be,
or
some
other
place
in
the
supporting
document.
It
would
be
really
nice
if
a
if
a
glossary
item
could
could
do
that,
so
we
wanted
to
version
them
all
together.
So
someone
could
just
download
that
package
at
a
specific
version.
So
that
makes
sense.
That's
my
long
way
of
saying
that
makes
sense
to
me
anyway.
C
So
the
reason
why
I
brought
up
the
idea
of
having
the
patterns
best
practices,
whatever
you
want
to
call
it
and
a
separate
repo
is.
I
I
believe
that
that's
going
to
be
a
a
lot
of
documents,
there's
going
to
be
a
lot
of
text,
there's
going
to
be
a
lot,
it
kind
of
needs
its
own
space,
there's
going
to
be
too
much
to
cram
that
into
with
everything
else.
I
would
rather
see
that
being
in
its
own
repo,
and
then
you
know
with
the
the
you
know,
the.
C
Reaper
would
then
you
know
point
to
that
as
place
to
look
at
patterns.
We
can
do
follow
up
things.
We
could
do
with
blog
posts.
We
could
even
complete
videos,
just
you
know,
showing
examples
from
that
repo.
E
Quick
quick
comment
is
that
I
don't
have
a
strong
opinion
on
that.
I
was
just
sort
of
outlining
what
or
trying
to
recall
what
we
what
we
had
said
previously.
That's
it
all
that's
subject
to
change,
so
whatever
is
best
for
end
users,
robert,
you
know
what
I
mean
like
whatever's
best
for
the
project
whatever's
best
for
end
users.
We
can
reorganize
as
needed.
E
If
we
do
not
intend
to
do
that,
which
maybe
we
don't,
maybe
that
maybe
it's
not
necessary
to
link
to
to
specific
patterns
through
there,
then
it
really
isn't
necessary
to
be
in
that
repo.
It
can
be
on
its
own.
A
Yeah
and
and
and
let's
not
like
scott-
and
I
were
talking
about
getting
the
website
up
and
we're
we're
gonna
push
it
up
manually
right
now,
we're
gonna
move
hopefully
rapidly
and
set
up
the
automation,
so
it's
done
in
a
gadopsy
way,
but
let's
not
let
the
perfect
be
the
enemy
of
the
good.
Here
I
mean,
let's,
let's
you
know
if,
if,
if
you
guys
feel
more
comfortable
just
trying
to
push
it
through
something
simple,
let's
do
it
that
way
and
then
we'll
evolve
it.
A
You
know
I
mean,
let's
not
over
engineer
these
problems
and
on
a
second
note
like
when
it
comes
to
work
on
this
project.
This
is
this:
is
a
total
open
source
project.
There's
no
someone
else
out
there.
That's
like
doing
all
the
things
and
we're
just
trying
to
give
them
like
the
tasks
to
take
care
of
you
know
between
the
co-chairs
and
then
the
committees
which
are
all
volunteer
engagements.
We
all
have
full-time
jobs.
We
all
have
got
a
little.
A
You
know
a
little
bit
of
time
here
and
there
to
contribute,
but
if
you've
got
something
that
you're
excited
about,
you
want
to
engage
on
it,
dude
shoot
ahead.
Let
us
give
you
some
support.
You
know,
let's
give
you
a
high
five
and
and
we'll
try
to
look
at
the
pull
requests
and
and
look
at
the
issues
and
participate,
but
the
the
only
way
we're
really
ever
going
to
be
successful
is
if
more
people
are
contributing
more
right.
E
Totally
my
only
robert
I'm
just
going
to
send
you
a
link
to
this,
but
just
would
you
mind
doing
me
a
favor
like
just
maybe
think
think
over
it
and
see
if
you
think
that
it
needs
a
separate
repo
to
even
start,
like
maybe
take
a
look
at
there's
a
section
in
the
project.
E
Read
me
now
that
describes
the
repos,
as
is
that
came
from
a
discussion
in
the
get
ops
working
group
which
I
could
be
wrong,
but
I
seem
to
remember
you
being
like
one
of
the
two
people
that
were
into
that
that
discussion
item
about
repost
structure,
but
this
can
continue
to
change.
So
maybe
just
look
over
and
think
about
it
and
see
how
you
feel
and
if
you
think
it
it
really
requires
its
own,
then
maybe
make
a
pull
request
to
that
readme
too,
and
we
can
set
that
up.
E
C
I
think
we
could
either
do
it
so
like
our
own
repo
for
patterns
or
best
practices
or
whatever
people
suggest,
then
we
all
agree
on
or
probably
have
it
under
documents.
But
at
that
point
you
know,
depending
on
the
amount
of
things
going
into
that
documents,
repo,
it
can
get
a
little.
You
know
a
lot
of
history
mixed
up
in
between
should.
E
We
wait
it
outgrows
its
pot.
If
it's
you
know.
C
Well,
if,
if
we
start
doing
like
best
practices,
slash
patterns,
good
bad
anti-patterns,
whatever
you
know,
and
and
for
some
reason
we
start
doing
a
white
paper
or
something
something
something
you
know
that
doesn't
mean
that
the
documents
repo
is
going
to
be
too
convoluted.
I
think
so.
It's
probably
you
know
just
as
well
to
just
start
by
putting
stuff
into
the
documents
repo.
C
B
So
yeah,
I
I
had
my
hand
raised
in
systems.
A
That
I'm
watching
super
super
cool.
B
Okay,
cool
yeah.
No,
I
I
think
this
is
a
case
of
if
you,
if
you
build
it,
they
will
come
right,
so
I
don't
think
so.
I'm
actually
like
william,
like
I'm,
actually
willing
to
contribute,
like
I
I'm
opinionated
right
for
those
who
worked
with
me
so
like
I
actually
have
strong
opinions,
and
I
think
things
should
go
a
certain
way
and
I'm
willing
to
contribute.
It's
just
like
point
me
where
and
then
I'll
start
printing
the
the
heck
out
of
it
right.
B
So
I
think
I
think,
the
if
there's
a
consensus
of
where,
like
where
the
entry
point
is
at
least
we
can
then
move
it
around
later
right,
at
least,
if
we
tell
people,
hey
put
it
here
as
the
entry
point
and
then
I
think
people
will
start
contributing
more.
I
think
a
lot
of
it
is
like
people
don't
know
where
to
contribute
like
for
me,
like
william's
talking
about
like
telco
patterns
right
with
get
ops.
I,
like
I,
would
put
that
maybe
under
documents,
but
then
some
people
think
well.
B
Maybe
that
should
go
on
their
website,
but
I
think,
as
long
as
we
have
like
a
place
where
it
lands,
we
can
then
decide
where,
where
it
best
goes.
So
I
don't
know
yeah.
So
that's
just
my
my
two
cents
on
that.
I
think
if,
at
least,
if
we
have
a
place
where
it
lands
deciding
where
it
goes,
you
know
that
that
could
come
later
like
like
dan.
Like
you
said,
don't
let
the
the
the
perfect
video
I
mean
the
good
right.
Let's
just
put
it
somewhere.
A
Yeah
documentary
repo
is
always
safe,
it
doesn't
just
show
up
somewhere
and
then
the
website
doesn't
automatically
slurp
anything.
Yet,
as
scott
is
saying
in
the
in
the
comments
here,
so
if
you
want
to
put
in
the
website,
I
think
I'm
fine
with
that
too,
and
then
william
is
asking
for
the
work
on
the
patterns.
Should
we
create
a
separate
repo
right
now
for
patterns,
so
it
doesn't
affect
break
it
from
the
beginning
without
affecting
anything
quote-unquote
stable,
which
has?
A
I
don't
think
there
is
anything
stable
at
this
point,
so
I'm
not
super
worried
about
it.
Yeah.
I
I
honestly
for
for
that,
like
I'd,
be
thrilled
to
just
under
the
content
directory
of
the
website,
make
a
new
folder
for
patterns
and
then
just
work
there,
because
that
will,
by
doing
it
that
way,
you're
going
to
automatically
create
an
mdx
file
and
any
other
files
for
each
entry,
and
you
have
a
pattern
just
like
the
blog
that
we
do
and
then
you
can.
A
C
To
get
started,
and
you
know
what
kind
of
patterns
do
you
want
to
do
and
et
cetera,
et
cetera,
and
I'm
you
know
just
for
the
record,
I
I'm
I'm,
I'm
not
going
to
be
a
consultant
anymore
at
my
job,
I'm
going
to
be
like
an
in-house
guy.
That
makes
a
platform,
so
everything
I
do
these
days
are
actually
looking
at
patterns
like
what
can
we
do
with
this
and
et
cetera,
et
cetera,
et
cetera
so,
and
that
and
being
part
of
the
corporate
delivery
working
group
as
well.
C
Everything
I
do
right
now
is
kind
of
pattern
and
looking
at
how
to
do
stuff
with
different
stuff.
So
that
would
be
great
if
we
could
actually
just
you
know,
come
together
and
figure
out
what
we
how
we
want
this
presented,
and
when
you
know
what
can
we
start
with?
Where
do
we?
Where
do
we
start?
Because
I'm
also,
you
know
just
you
know
pointing
in
the
right
direction.
C
I
also
do
prs,
but
you
know
we
need
a
little
bit
structure
or
someone
needs
to
clean
up
everything
afterwards,
but
documents
repo
with
a
pattern
director
or
something
that
would
work
for
now,
at
least
until
someone
figures
out
on
the
voice.
I
think.
E
I'm
excited
just
here's.
The
discussion
link
for
what
we
had
before
might
be
valuable
to
revisit
that
and
yeah.
I
guess
my
memory
was
correct
on
that
robber.
You,
you
and
lother
were
the
people
that
commented
there.
C
Do
we
want
to
organize
something
besides,
I
guess
principles
and
events,
and
you
know
the
monthly
thing
do
we
want
to
talk
a
little
bit
of
what
we
think
patterns
should
look
like
or
best
practices
or
whatever
we
even
what
to
call
it.
Yeah.
A
Yeah,
let's,
let's
take
a
few
minutes
right
now
to
talk
through
it
and
I
think
what
we
had
originally
kind
of
envisioned
was
a
directory
that
anybody
could
submit
to,
and
I
was
interested
to
think
I
was
thinking
like.
Oh,
I
want
to
show
like,
if
somebody
searches
for
how
to
do
aws
with
eks
and
github.
A
I
want
to
have
a
code
fresh
pattern
there
and
let's
have
a
flux
pattern
there
and
let's
have
an
argo
pattern
there
and,
let's
have
you
know,
and
then,
if
you're,
you
know
so
I
kind
of
imagined
that
there
would
be
like
a
tech
stack
metadata
thing
that
was
like
I'm
looking
for
things
with
this
stack
in
it
like.
I
want
to
do
open
shift,
okay.
Well,
if
I
want
to
do
openshift
and
I'm
doing
get
ups,
what
it
you
know,
okay,
here's
the
patterns
I
should
follow
and
for
format.
A
I
imagine
them
essentially
as
a
diagram
with
kind
of
a
blog
post
and
discussion
and
explaining
it
and
why
it's
done
this
way
and
what
works
well
and
what
doesn't
work
well,
but
then
leaving
it
fairly,
free
flow.
You
know
let
people
kind
of
if
you
want
to
make
it
really
long
you
can,
if
you
want
to
make
it
short
you
can,
that
was
that
was
kind
of
my
original
thinking
with
this
and
happy
to
you
know,
go
in
a
different
direction
and
do
different
stuff
too.
D
C
Categories
or
you
know,
delivery
tool,
you
know
ci
and
cd
tools
whatever
and
if
we
that
would
be
a
good
thing
to
kind
of
use
as
something
you
can
point
from,
for
instance,
the
website,
if
you
had
a
place
where
you
can
filter
based
on
you
know,
github
actions
and
argo
yeah,
you
know
you'll
get
something
back.
That
would
say
all
right.
You
could
do
this.
A
Yeah
any
other
ideas
stuff
that
we
should
support.
You
know
baseline
requirements.
A
Maybe
we
should
mention
just
process
for
getting
these
up.
Do
we
I
I
didn't,
I
didn't
think
about
like
let's
have
a
review
committee
or
anything
like
that.
I
felt
like
it
was
like
someone
can
post
this
and
we
can
have
you
know
a
label
on
it
that
says
community
and
maybe
there's
some
mechanism
by
which
people
can
add
like
a
plus
one
or
like
yeah.
I
used
this
and
it
worked
for
me,
but
I
don't
think
that
we,
as
a
committee
necessarily
want
to
take
a
stand
on
like
like.
A
If
somebody
submits
something
and
it
has
it
meets
it's,
it
purports
to
be
conformant,
and
it's
not
blatantly
not
conformant.
With
the
standard
with
the
principles
then
just
merge
it
and
move
on.
B
Yeah,
I
think
if
the
only
checking
should
be
done
is
as
long
as
it
doesn't
contradict
the
principles
right.
So
as
long
as
we're
not
contradicting
ourselves
right
like
we're
posting
something
that
contradicts
the
principles,
but
I
think
other
than
that
yeah
I
mean
it's
just
as
long
as
it's
conformant
to
those
principles
I
mean
it
maybe
should
have
a
review
of
maybe
like
one
or
two.
B
You
know
people
from
the
from
the
working
group
just
to
make
sure,
but
it
doesn't
have
to
it
doesn't
have
to
like
you
said
that
has
to
be
like
an
official
process
or
like
a
like
a
whole,
like
code
review,
sort
of
thing,
but
maybe
just
kind
of
looking
like
all
right.
As
long
as
you're
you
meet
the
four,
the
four
principles
yeah,
you
merge
it
and
go.
D
Yeah
and
okay,
so
can
we
do
something
like,
for
example,
to
to
make
sure
that
it's
following
the
principle
to
I
don't
know,
add
some
structure
like
okay,
it
should
include
a
mapping
to
which
principles
are
covered
or
or
or
I
I
don't
know
something
that
could
be
used
as
an
easier
translation
of
okay.
This
is
the
pattern,
and
this
pattern
is:
it's
probably
only
on
one
of
the
principles
where
you're,
covering
in
in
that
sort
of
blog
post
as
what
I
understood
from
them
is
like
it
can
be
individual
pose.
E
Yeah
it
all,
I
think,
we've
already
covered
a
lot
of
the
stuff
in
the
sense
that
you
know
we're
really.
You
know:
we've
gotta
we've
got
a
a
a
working
group
for
as
long
as
it's
needed
to
help
with
the
open
get
ups
project.
We
now
are
transferring
relevant
things
over
to
this
through
the
sandbox
project
itself.
The
open
get
ops
project.
E
We
have
these
committees,
these
kind
of
ad
hoc
committees
of
people
who
are
interested
in
focusing
on
different
parts
of
different
important
things,
including
these
principles,
including
those
foundational
principles.
It
seems
that
the
people
in
this
group
are
much
are
interested
not
only
in
the
principles,
but
also
in
really
just
the
lasting
documents
for
this
for
this
for
this
project
for
the
open,
git
ops
project,
because
they
do
they
are
either
supporting
documents
or
supported
and
or
supported
by
those
foundational
principles.
E
So
that's
how
we
have
it
set
up
right
now,
anyway,
as
you
as
dan
said,
pull
request
discussion.
We
have
a
github
discussion
set
up
now,
so
we
can
have
you
know
conversations
about
this.
You
know
I
imagine.
Polar
requests
might
take
a
little
while,
but
we
could
probably
get
them
going
relatively
quickly.
What
what
I
think
isn't
is
is
something
we
should
all
acknowledge
is
that
we
have
all
it's
an
open
source
project.
We
all
work
at
different
places.
E
We
all
have
different
interests,
and
so,
in
order
to
ensure
that
this
project
is
really
it's
a
fair
and
balanced
project,
we
want
to
at
least
think
about
what
we,
what
we
publish,
what
we
publish
together
and
when
you
know,
for
example,
just
because
I
co-maintain
the
flux
project,
I
I
don't.
I
wouldn't
want
to
create
a
pull
request.
That
has
you
know
a
page
of
patterns
and
it's
only
patterns
related
to
flux.
You
know
it
wouldn't
really
be
very
well
rounded,
and
it
would
give
the
wrong
impression
of
the
opengetops
project
I
think
like.
E
If
we
do
things
like
this,
we
should
think
about
you
know.
Of
course
we
can't
be
comprehensive
to
start,
but
if
we
start
a
new
section,
I
think
it
would
be
good
to
try
to
be
well-rounded
to
to
really
show
the
community
what
this
git
ops
thing
is
all
about
from
the
highest
level
perspective.
Of
course
we
can
promote
various
tools
tools
and
we
should
you
know
it's
important
to
let
people
know
what's
out
there,
but
we
really
need
to.
I
think,
try
to
keep
that
in
mind
as
we
as
we
do
this.
E
I
just
wanted
to
make
that
note,
but
I
have
no
objection
personally
with
any
of
this
kind
of
stuff.
This
all
sounds
good
use
cases,
patterns,
user
roles,
etc.
You
know
we
really.
We
wanted
to
flush
those
out
in
this
pr.
Let
me
just
send
it
to
you
real,
quick,
the
the
older
pr
that
was
closed
in
favor
of
of
us,
focusing
just
on
those
like
initial
principles,
and
our
plan
is
to
get
back
to
this
and
go
back
and
mine
some
of
this.
E
For
for
information
for
this
prior
art,
you
know
and
take
a
prior
work,
rather
that
went
into
this
that
was
drawn
from
different
places,
including
collaboration
with
other
people,
on
this
call
so
that
I
don't
think
has
a
full
section
on
patterns
yet,
but
it
has
the
intention
of
that
and
it
has
some
other
other
supporting
documents
in
it.
So,
let's
work
on
them.
C
I
would
just
just
like
to
expand
on
the
thing
that
I
that
I
wrote
in
the
chat.
If
we
one
thing
is
the
patterns,
documents
and
you
know
possible,
leave
something
else
in
related
to
that
sort
of
like
white
paper,
things
and
stuff
like
that,
but
also
uses
stories,
or
you
know
how
things
are
what's
happening
in
the
field
from
the
field
field
notes,
whatever
you
want
to
call
it.
C
I
think
that
having
someone
that
actually
is
more
interested
in
the
documents
should
be
involved,
at
least
to
just
look
over
and
kind
of
help
if
things
are
stalling
at
a
certain
point
on
a
pattern
or
a
something
that
someone's
written
from
you
know
a
use
case,
user
use
use
case
standpoint,
someone
would
actually
just
kind
of
pick
it
up
after
a
while
and
and
push
it
through,
because
you
know
they
are
involved
in
in
the
documents
process.
A
I
I
feel,
like
that's
part,
of
the
job
of
the
principles
committee
right,
at
least
at
this
point.
No,
is
it
too
divergent.
E
I
propose
that
we
rename
the
principles
committee
to
a
documents
committee
at
some
point
and
I
think
the
principles
and
documents
committee
yeah
and
then
I
think
you
know
chris
sanders
suggested
that
we,
you
know
that
these
committees
are
really
just
here.
It
really
is
just
a
way
to
have
some
organization
to
this
working
group.
The
working
group
itself
is
is
not
meant
to
be
forever.
E
We
should
just
organize,
however,
we
think
makes
the
most
sense
for
us
as
long
as
the
the
the
process
of
organizing
doesn't
get
doesn't
actually
detract
from
our
goal.
You
know
if
it
helps
things
and
makes
us
go,
you
know
get
to
our
goal
of
of
working
on
this
content
together
and-
and
you
know,
really
building
this
community
and
building
the
movement
then
great,
if
they,
when
they
start
to
not
do
that,
we
should
probably
just
let
them
let
them
go.
E
I
think
chris
suggested
that
we
just
make
a
documents
committee,
and
maybe
it's
all
the
same
people.
Maybe
we
stop
this
one,
and
maybe
we
move
it
over.
I
don't
know
it's
really.
It's
really
up
to
you
all,
or
it's
really
up
to
the
group.
I
think,
but
really
that's
what
we
did
with
the
events
committee
we
had
it
was.
E
I'd
be
down
for
that
really.
I
honestly
I
can
be
extremely
opinionated.
Maybe
it's
just
my
attitude
today,
but
I
really
don't
care
how
exactly
how
we
do
it
as
long
as
we
just
you
know,
pick
one
of
them
and
go
with
it
and
don't
get
super
attached
to
exactly
how
these
little
these
committees
are
organized
as
long
as
we
respect
each
other
and
as
long
as
we
you
know,
respect
and
make
sure
that
it's
a
welcoming
space
for
everyone
involved
and
like
have
a
goal.
E
I
I'm
happy
and
I
can
make
suggestions
on
which
we
do
like
the
one.
One
suggestion
is:
let's
just
rename
it
to
to
documents
committee
I
don't
know,
but
in
terms
of
like
an
actual
sorry
one
one
more
quick
point
in
terms.
I
think
I
might
be
to
my
two
minutes
now
almost
but
like
in
terms
of
an
actual
process
for
reviewing
pull
requests.
E
Yeah,
let's
I
I
think
we
we
we
said
that
that
people
on
each
committee
we
would
make
separate
teams
for
just
like
we
did
in
the
get
ups
working
working
group,
repo
or
org,
rather
will
make
separate
teams
for
in
github
invite
you
to
invite
each
person
to
the
organization
so
that,
like
a
you,
can
put
this
on
your
github
page
and
say
I'm
part
of
this
organization.
I
actually
do
in
fact
participate.
I'm
not
just
you
know.
Trying
to.
I
don't
know
like
be
part
of
things
I
don't
participate
in.
E
I
really
do
participate
in
this
and
secondly,
that's
it's
a
very
common
practice
in
in
organizations
to
have
a
finite
set
of
maintainers
a
set
of
maybe
another
level
from
there.
In
this
case,
perhaps
the
chairs,
that's
that's.
E
At
least
we
have
with
the
get
ops
working
group
and
the
project
right
now,
and
then
it
should
have
many
more
organization,
members
and
many
of
whom
are
very
involved
in
the
project
who
have
different
responsibilities
and
if
we
need
to
make
a
separate
responsibility
like
a
role
like
a
triage
role,
someone
who
can
help
with
issues
and
so
on
and
pull
requests.
We
could
do
that
too.
But
I
would
personally
like
to
recommend
that
we
follow
things
that
work
for
other
cncf
and
open
source
projects.
D
E
E
We
just
set
that
up
from
the
last
meeting
right
before
I
had
to
take
my
break,
but
in
I'll
link
I'll
just
link
to
it
I'll
send
a
link
to
it.
They're
inside
of
opengetup's
project,
there's
a
discussions
section
here
we
go
and
you
know
the
first
post
I
just
kind
of
used
to
get
the
github
template
and
added
a
few
extra
little
frills,
basically
saying
yeah.
This
is
for
this
project,
make
sure
to
read
our
you
know.
E
E
E
One
of
the
reasons
that
we
are
had
been
focused
again
on
simplifying
those
first
sentences
is
because,
once
that,
once
we
actually
started
using
them
in
a
real,
a
real
world
scenario
like,
for
example,
in
the
website
preview
and
and
and
got
feedback
from
other
people,
it
became
clear
that
there
were
some
things
that
we
might
want
to
adjust.
Just
style-wise.
E
You
know
like
making
them
shorter,
and
so
so
on.
You
know
things
like
that,
but
one
way
or
the
other
once
we
get
that
there
it
will
be
ready
to,
then
I
think
move.
I
don't
know
to
really
use.
Excuse
me
to
really
flesh
out
the
other
parts
of
this
project.
C
B
B
A
Agreed
well,
I
actually
feel
like
that's.
That's,
maybe
a
good
stopping
point.
I
I
have
to
apologize.
I
am
really
burned
out
today.
I'm
like
really
just
losing
the
threat
over
here
and
I'm
I
don't
know
if
I
just
need
to
go,
take
a
walk
around
the
block
or
what
but
it's
been
a
long
day.
So
I
think
I'm
ready
to
call
it.
A
So
one
of
the
action
items
we
had
scott
from
when
before
you
came
in
was
to
look
at
maybe
moving
this
meeting
to
be
every
other
week
because
we're
we've
kind
of
rounded
the
corner
on
some
of
the
big
stuff,
and
I
think
some
of
us
were
feeling
like
well,
maybe
we're
losing
a
little
participation
because
people
feel
like
they
can't
come
every
week
and
we're
kind
of
rotating
through
people
so
I'll
bring
that
up
with
you
and
and
and
we'll
talk
on
co-chairs
and
get
that
scheduled.
E
B
E
E
Yeah,
let's
plan
on
it
being
next
week
and
if
I
can
make
a
suggestion,
I'd
love
us
to
to
work
between
now
and
then
on
really
forming
our
feelings,
or
you
know
not
necessarily
taking
a
position
but
just
getting
getting
kind
of
measuring
our
feelings
about
some
of
the
different
proposals
that
have
come
up
so
far
about
about
really
sort
of
getting
that
v1
of
the
principles
out
there
you
know,
and
if
that
means
you
know,
I
will
definitely
be
participating
in
github
discussions.
E
I
think
dan
has
a
plan
to
to
to
help
with
website
preview
so
that
we
can
kind
of
see
what
they
even
look
like
in
a
designed
format.
Maybe
we
can
just
try
to
be
async
about
a
little
bit
of
that
stuff
and
if-
and
I
think
that
might
actually
help
us
understand
whether
or
not
we
want
to
have
a
bi-weekly
or
sorry
fortnightly
or
weekly
meeting
or
whether
we
actually
feel
like,
we
don't
need
to
meet
synchronously
anymore,
and
we
can
just
do
this
asynchronously
from
from
this
point
onward.
A
Yeah
I
agree.
Okay
sounds
good.
Well,
let's
close
there
before,
I
pass
out
sorry
folks
I'll
bring
more
energy
next
week
thanks.
Everybody
appreciate
the
discussion
appreciate
the
help.
Let's,
let's
keep
it
going,
let's
get
into
get
get
in
the
game.
Let's
get
get
in
to
get
that.
A
C
A
Next
week
we'll
talk
about
starting
our
t-shirt.
Company
guys
sounds.