►
From YouTube: GitOps Principles Committee - April 28, 2021
Description
Meeting notes: https://docs.google.com/document/d/1hxifmCdOV5_FbKloDJRWZQHq0ge-trXJKF-BgV4wHVk/edit#heading=h.fka0qz5oay6e
A
Okay
yeah,
so
we
are
recording
now
welcome
to
the
get
ups
working
group
principles.
Committee
april,
28th,
3,
p.m,
eastern
I
forget
utc,
but
yeah
1900,
gmt,
hi
everyone,
so
we're
going
to
just
quick
housekeeping.
I
pasted
a
link
in
slack.
We
have
a
few
a
few
topics
that
the
first
few
were
just
the
normal
topics
that
we've
been
using
each
time,
just
that
we
the
one
changes
that
we
now
have
a
a
set
weekly
day
and
time.
A
So
that's
nice
for
everyone
who
can
make
it,
which
was
almost
everyone,
but
we'll
use
the
same
hacking
d,
doc
that
I
will
unlock
now.
If
you
haven't
already
greece
and
and
just
to
be
clear,
I
think
the
agenda
is.
We
are
working
toward
broad
consensus
for
principle.
Four,
we
are
not
going
to
get
hung
up
on
principle
three
for
the
moment
it
has
broad
consensus
in
hackenbee
as
it
is,
there
will
still
be
a
pr,
but
the
one
content.
A
We
we
are
going
to
move
ahead
with
the
broad
consensus
and
we
will
continue
the
discussion
on
github
and,
if
there's
any
other
main
point
of
contention,
we'll
do
the
same
thing
so
that,
but
but
if
another
contention
comes
up
from
anyone,
we'll
definitely
hear
it.
We
will
all
hear
it
as
a
group
because
everyone's
voice
matters
and
we'll
do
the
same
thing
if
we
can't
reach
consensus
within
a
reasonable
period
of
time.
A
A
C
A
Sounds
good
yeah
that
is
true
yeah
and
the
the
the
the
github
discussion
is
linked
in
the
notes,
I'll
paste
it
here
into
the
into
the
meeting
chat
too
just
for
convenience
for
everyone,
but
the
decision
unless
everyone
on
this
call
disagrees
that
we
should
continue
to
move
ahead.
So
we
didn't
feel
like
in
person.
We
were
making
a
lot
of
headway
and
we
don't
want
to
spend
another
week
doing
that.
So
we
can
do
that.
Asynchronously.
C
A
Okay,
so
just
quick
housekeeping
before
we
jump
into
let's,
let's,
let's
put
topics
on
the
I
mean
the
topic
is
principle:
four,
which
you're
right
about.
Let's
go
ahead
and
start
I
mean
that's
cool.
You
can
continue
now,
since
no
one
else
jumped
in,
but
let's
get
back
to
the
hand
raising,
just
because
just
so
that
we
can
everyone
agreed
on
it
in
every
last
meeting.
So
unless
there's
objection,
I
think
we
should
do
that
now.
Does
that
sound
good
okay,
cool.
A
A
D
E
D
Yeah,
so
I
think
so
someone
posted
here
that
quote
change
is
ambiguous,
inconsistent
with
previous
wording,
and
I
think
I
agree
with
that.
I
think
also.
We
need
to
step,
I
think,
maybe
step
back
in
that
and
that's
how
someone
and
think
about
using
something
like
interfacing
like
how
someone
interfaces
with
the
controlled
cluster.
However,
you
want
to
call
it
controls.
D
The
operation
is
done
via
a
declarative,
I'm
trying
to
I'm
trying
to
make
it
easier
by
getting
rid
of
change,
and
I
think
I'm
I'm
making
it
more
complex,
but
I
think
how
someone
interfaces
with
the
the
cluster
or
how
someone
interacts
with
the
cluster.
I
think
we
should
maybe
approach
it
from
that
standpoint,
so
the
so
the
proposal
is
the
the
mechanism
through
which
an
operator
I
don't
know
what
that
would
be.
A
good
word.
Interfaces
with
the
cluster
is
through
a
new
declaration
or
deck
declaration.
F
How
about
the
mechanism
through
which
the
system's
actual
current
state
is
modified
is
through
a
change
in
the
desired
state
right,
something
like
that,
showing
that
the
link
that
you're
you're
you're
changing
the
system's
running
state
and
you're
doing
that
on
the
basis
of
changing
the
desired
state
and
that
that's
the
only
mechanism
of
operations
is
changing.
The
desired
state,
which
I
think
is
is
the
core
here.
F
F
A
C
A
G
For
instance,
you
might
be
declaring
the
the
composition
of
a
solution
running
on
top
of
a
cluster,
but
there's
going
to
be
changes
to
the
underlying
cluster.
For
instance,
node
scaling
there's
going
to
be
changes
to
the
underlying
state
of
the
cluster,
in
terms
of
where
your
pods
are
running,
and
this
is
a
kubernetes
specific.
G
This
will
apply
that
should
apply
to
systems
that
are
not
kubernetes
in
general.
So
also
when
you
think
about
change,
there's
going
to
be
declarations
in
your
desired
state
that
allow
for
environment,
specific
change
so
think,
for
instance,
you're
declaring,
I
don't
know
a
certificate
to
be
generated.
That
certificate
is
going
to
change
over
time.
It's
going
to
be
automatically
renewed.
G
If
you
think
about
secrets
that
are
there's
this
concept
of
secrets
that
are
made
of
other
secrets,
I
forget
the
name.
All
those
are
changes
that
are
happening
in
the
system.
That
would
apply
to
the
concept
of
change.
I
think
dynamic
sequence,
which
makes
me
think
of
change
applicable
to
a
system
as
a
whole
ambiguous.
We
are
not
we're
not
talking
about
change,
we're
talking
about
desired
state
versus
running
state,
so
I
would.
I
would
prefer
to
see
consistency
across
that
terminology.
G
A
Okay,
cool
I'll,
be
really
sure
I
I
I
was
only
going
to
say
that
I
thought
perhaps
we
could
use
consistent
terminology
from
the
first
from
the
from
the
initial
principles
that
preceded
it,
and
that's,
that's
really
all
as
much
as
possible
since
they
are
in
order
and
numbered
what
I'm.
Seeing,
though,
is
that
the
I
don't
think
we
would
need
to
use
terminology
from
principle
three,
because
that's
mainly
speaking
about
the
agents
themselves,
we
may
just
it
sounds
like
we're
really
talking
about
the
declared
desired
state
and
the
version
of
that
declaration.
A
But
I
have
a
I've.
Only
one
question
is
the
spirit
of
this.
I
I
think
it
is
it's
a
spirit
of
this
that
we're
saying
the
only
thing
I
see
that
really
adds
to
the
first
three
principles
is
saying
to
to
to
fully
realize
this
get
ops
principle
you're,
really
only
using
the
first
three
principles,
right,
you're,
not
using
anything
else
or
if,
if
it
is,
then
those
are
not
considered
primary
or
something
like
that,
but
okay,
I
yield
that's.
F
That's
really
following
on
from
leonardo
I
I
would
actually
go
to
that
extreme
of
saying
that
that
is
the
system's
desired
state.
The
current
certificate
is
part
of
the
system's
desired
state,
and
it
should
be.
I
mean
it
could
be
by
reference,
but
at
least
it
should
be
stored
in
the
state
store.
All
of
the
things
that
you
say
are
dynamic.
F
The
value
might
be
referenced
elsewhere,
but
the
fact
that
it's
that
particular
value
at
that
particular
point
in
time
should
in
fact
be
part
of
the
system's
desired
state.
So
I
would
really
bring
those
into
the
desired
state
very
much
so
so
that
it's
a
lot
more,
encompassing
rather
than
narrow
as
to
what
the
desired
state
is,
and
I
I'm
keenly
aware
that
a
lot
of
our
practical
and
real
systems
don't
necessarily
implement
it.
F
Your
agent
software
agent,
that's
responsible
for
certificates,
is
going
to
make
a
commit
to
the
desired
state
and
add
a
new
certificate,
and
I
think
that's
that's
the
direction
that
we
probably
want
to
go
to
be
to
be
kind
of
more
restrictive
more
in
that
direction,
rather
than
less.
If
that
makes
sense,.
F
A
C
C
So
if
I
have
a
sealed
secret
as
a
desired
state-
and
I
want
that
to
be
unsealed,
do
I
now
just
commit
my
my
unsealed
secret
back
into
the
the
repository
that
that
doesn't
make
too
much
sense
to
me
and
the
same
with
the
deployment?
If
I,
if
I
have
a
deployment,
am
I
committing
all
the
pods
that
get
created
out
of
that
deployment
back
to
the
get
repository
and
and
the
same
applies
to
certificates?
C
So
I
think
I
think
the
desired
state
should
be
that
the
desired
state
that
and-
and
if
that
decides,
that
is-
is
making
changes
of
a
larger
scope.
That's
fine,
as
long
as
that
larger
scope
implements
the
desired
state.
So
if
I
have
an
auto
scaling
rule
that
says,
I
can
be
from
1
to
100
nodes,
whether
I'm
at
20
or
50
or
99.
C
H
H
What's
what's
the
purpose
of
number
four
here
I
feel
like
and
I'm
I'm
gonna,
I'm
gonna
sidestep
all
of
the
the
the
word
soup.
We
want
to
say
really.
The
only
way
you
make
changes
in
this
system
is
through
the
system.
Right,
you
don't
log
into
the
system.
There's
no
ssh
and
there's
no
cube
cuddle
apply
like
you're
coming
in
through
a
pull
request.
H
H
You
know,
for
example,
cluster,
auto
scaler
and
kubernetes
or
or
we're
defining
recipes
for
automation
to
bake
right
like
dynamic
secrets,
it's
all
still
in
the
desired
state
repo.
So
I
I
feel
like
we
may
maybe
just
want
to
talk
a
little
bit
about
the
intent
and
the
wording
might
come
to
us.
I
am
not
opposed
to
the
word
change.
H
A
I
see
moshe's
thumbs
up
and
then
a
few
more
hands
thanks
jesse
I
was
next
and
I'll,
be
again
I'll,
be
very
short
because
I'm
tempted
to
agree
with
jesse.
But,
although
I'm
not
saying
I'm
100
convinced
that
we
don't
need
a
principal
for,
I
just
wanted
to
say
that
the
notes
that
we
discussed
about
the
point-
I
think
mosh
crystallize,
a
very
good.
I'm
sorry
moshe
right,
you
know:
okay,
okay,
I
want
to
pronounce
everyone's
name
correctly.
If
I
can
so
okay
yeah.
A
So
so
the
point
that
you
crystallized
from
the
discussion
that
came
up-
or
I
think
it
was
a
very
good
crystallization-
is
that
there
is
going
to
be.
There
are
inevitably
going
to
be
things
running
in
the
system
that
that
that
system
is
capable
of
handling
that
should
not
need
to
be
sent
back
to
the
to
the
initial
instructions
as
we're
calling
them
the
desired
state
stored
in
an
immutable
version.
A
Some
excuse
me,
some
git
ops
tools
do
have
the
ability
to
write
back
to
that
storage
system
dynamically
so
that,
for
example,
pinning
or
image
updating
or
whatever,
so
that,
if
a
new
instance
of
your
system,
it
just
absolutely
crashed
and
need
to
be
needed
to
be
remade
or,
let's
just
say,
you're,
duplicating
that
and
that's
why
you're
using
git
ops
that
that
new
system
would
have
all
the
instructions
it
needs.
It
doesn't
have
to
have
everything
else.
That's
that
happens
to
be
running
like
all
of
the
logging.
A
So
I
just
wanted
to
mention
that
if
we
we
may,
that
might
be
able
to
be.
However,
that's
worded
or,
however,
if
that's
an
important
point,
we
could
probably
do
that.
As
a
note
on
point,
one
is
my
thought,
because
okay
and
almost
done
here
is
because
that
is
the
principle
declarative
desired
state.
So
just
a
thought
and
I
yield
breezes
next.
F
I
think
it's
that
has
been
missed
in
previous
discussions.
So
the
idea
that
you
you
have
these
continuous
state
reconciliation,
immutable,
state
versions,
declarative
design,
state
all
great,
but
actually
in
in
real
practical
sense,
that
the
idea
that
you
should
not
be
operating
directly
on
the
system
has
been
missed.
F
F
Yep
and
it
I
mean,
like
there's
a
couple
of
finer
points
here
right
the
principle:
if
we
really
mean
it,
that's
that's
that's
lovely
but
like
things
like
a
human
operator
and
other
systems
should
both
act
in
that
way
right.
So
it's
not
sufficient
to
just
have
humans
acting
that
way,
but
other
systems
must
tagged
in
that
way
too.
That's
an
important
point,
so
I
wouldn't.
H
F
To
lose
that
creating
a
new
version
is
the
method
of
operation
you
can't
jumping
back
is
not
is
not
appropriate
right.
You
shouldn't,
be
you
shouldn't,
be
either
so
you're
if
you're
going
to
be
creating
a
new
version
that
you
should
be
reverting,
do
a
git
revert
or
do
get
reset
hard
and
then
commit
that
value
rather
well,
not
really,
but,
like
you
shouldn't
be
going
backwards
in
that
time.
I
F
A
F
A
J
H
Want
to
be
clear
and
I'll
yield
the
rest
of
the
time
back
to
conversation,
but
I
think
I
did
I
did
mean.
I
think
we
need
four.
I
just.
I
think
we
need
to
accept
that
it's
a
little
different
than
one
two
and
three
right
and-
and
I
and
the
reason
I
think
that
that
is
because
still-
and
I
know
you
all
are
having
the
same
experiences
as
advocates
for
get
ops,
we're
still
talking
to
folks
that
are
like
well,
I
I
use
git
and
I
use
vm,
so
I'm
doing
get
ops.
Well,
no!
Okay!
H
Now
now
I've
learned
I'm
using
declarative
configuration
and
get
now
I'm
doing
get
offs,
and
no
really
you
need
the
agents
in
place
and
you
need
to
stop
interfering
with
the
system
you
put
in
place.
That's
really
what
number
four
needs
to
say
right
and
I
do
think
yeah
we
could
add,
we
could
add
to
the
previous
ones,
but
I
really
feel
like
number
four
kind
of
hammers
at
home.
H
It's
just
you
know
we
we
have
to
maybe
accept
that
it
could
be
a
little
loosey-goosey,
but
I
will
also
say
these
four
are
taken
as
a
whole
right.
The
four
principles
must
be
taken
as
a
whole.
So
if
we
have
like
issues
with
maybe
change
again
feeling
arbitrary
in
the
context
of
the
first
three
principles,
I
don't
think
that
it
is.
D
Yeah,
so
just
basically
echoing
kind
of
what
what
jesse
was
saying,
I
do,
I
do
believe
we
need
four
there
and
I
do
believe
which
was
my
original
point
in
the
beginning.
I
think
interfacing
with
like
me,
interacting
with
the
cluster,
is
done,
isn't
done
directly
and
I
think
that's
that's.
I
think
the
point
we're
trying
to
drive
home
with
everyone
right
as
advocates
of
get
ops
is
I
I
I
tell
them.
Okay.
First
with
kubernetes,
I
took
your
ssh
away.
D
Go
through
your
get
process
right,
whether
it
be
github
or
gitlab
or
whatever
right
go
through
that
pro
process,
and
so
that,
which
is
why
I
brought
the
point
of
maybe
nothing,
let's
say
changing
it,
but
kind
of
calling
out
interacting
with
the
the
cluster
or
inner
like
how
you
interact
with
the
cluster
is
maybe
what
point
four
should
be
about,
because
I
think
number
one
I
think
is
is
self-explanatory
and
I
think
number
four
would
be
kind
of
like.
Yes,
we
really
mean
it
but
driving
that
home
saying.
D
A
K
I
I
would
like
to
come
back
to
bree's
point
about
communication.
I
liked
that
very
much
that
made
me
think
of
hands
off.
So
to
me,
number
four
is
about
is
about
being
hands
off
of
the
system
and
that's
I
felt
I
felt
the
same
when
I
when
I
saw
the
last
comment
about
interaction,
so
we
don't
wanna,
we
don't
wanna
go
cube,
ctl,
whatever
we
wanna,
we
wanna
say
this
is
the
new
declaration.
This
is
the
new
desired
state
gear
system.
Please
apply
I
would
like
to.
K
Maybe
it
could
be
just
hands-off
principle,
but
maybe
that's
too
much
of
a
change
and
there
was
already
a
lot
of
thoughts
put
into
that.
So
I
don't
want
to
to
propose
to
change
the
title,
but
the
chord
to
me
is
I
I
don't
have
a
better
word.
The
chord
to
me
is
really
being
hands
off
of
the
system,
but
apply
it
through
declarative
change
and
then
some
some
system
applies
to
change.
I
I
think
operations
through
declaration
is
is
pretty
straightforward
for
me
personally
and
what
jesse
put
in
as
a
taken
run
at
number
four,
I
like
what
you
said
there.
I
would
just
take
out
the
word
primary
just
say
the
interface,
so
so
the
folks
won't
think
there's
a
secondary
and,
and
just
take
that
I
think
that's
that's
good.
That
says
you
make
you
operate
with
your
system
through
declarations
and
that's
it
all
right.
I
think
that's
that's.
What
we're
trying
to
get
across
right.
A
L
That's
also
the
talk
I'm
going
to
give
at
the
get
ops
con,
so
the
storyline
is
that
we
want
to
achieve
hands-off
operations
as
like
the
main
goal
in
rit
strategy,
and
we
use
githubs
as
the
kind
of
practical
technical
level
milestone
and
lever
to
get
there.
That's
why
I
think
it's
better
to
talk
about
operations
for
declaration
here
and
not
about
hands-off,
even
though
hands-off
is
the
overarching
goal
that
obviously
get
ups
tends
to
achieve.
L
L
H
H
I
was
expecting
people
to
call
that
out
that
to
me
is
the
biggest
difference,
an
os
engineer
from
20
years
ago,
everything's
configuration
or
running
state.
So
I
feel
like
it's
all
configuration
we're
talking
about
it
might
clarify,
but
I
don't
know
if
it
confuses.
So
I
think
if
we
can
decide
that,
if
I'd
be
good
with
just
running
with
it,
sort
of
as
it
is
no,
it
can't
come
off
all
right.
That's
fine!
It's
fine!
We'll
we'll
enjoy
it,
while
it's
here
nice.
H
H
G
So,
just
I
I
like
jesse's
approach.
Why
don't
we?
So
I
guess
the
question
number
one
is:
do
we
think
mec
the
mechanism
by
which
configuration
changes
should
only
be
through
declaration
or
primarily
b3
declaration,
so
like
who
thinks
it
should
be
only
who
thinks
it
should
be
primarily
how
strict
do
we
want
to
be
as
strict
as
feasibly
possible.
G
K
C
G
Okay,
so,
let's
imagine
that
we
say
the
only
mechanism
through
which
a
system
can
be
operated
against
or
something
along
those
lines
like
keeping
it
within
operations.
The
only
way
that
the
only
way
that
a
system
can
be
managed
is
through
the
creation
of
a
new
declarative
state
that
would
basically
cut
it
right.
The
only
mechanism
through
which
a
system
can
be
managed
or
can
be
operated
on
or
whatever
is
through
declarative
through
a
new
version
of
the
parity
state.
I
think
that
basically
communicates
can
be
intentionally
man.
That
sounds
good.
G
G
G
G
F
Oh
sorry,
I
didn't
realize
it's
telling
my
end
up.
No,
it's!
Okay!
So
just
going
back
to
the
configuration
point
with
jesse
very
quickly,
we
had
the
discussion
around
configuration.
We
spent
a
significant
amount
of
time
actually
with
scott
we
spent,
and
we
realized
that
configuration
brings
in
a
lot
of
context.
F
A
A
L
L
G
H
J
L
H
I
H
I
don't
I'm
I
fee,
so
I
won't
do
this
again,
but
I
feel
like
I
keep
bringing
us
back
to
this
point
of
four,
so
this
is
the
last
time
I'll
do
it.
Officially,
I
feel,
like
four
is
the
thing
that
hammers
home
the
fact
that
this
is
how
the
system
works.
I
feel
that
there
isn't
without
number
four
really.
What
number
four
is?
Is
we
mean
it?
H
H
J
F
So,
just
just
a
kind
of
housekeeping
these
these
numbering
were
purely
for
our
use
to
discuss
each
individual
point
of
principle
for
separately.
I
don't
think
they're
intended
to
make
it
to
the
final
version.
These
are
just
purely
for
our
use
to
help
discussion
to
break
down
these
things
into
kind
of
separate
concepts.
M
A
Check
yeah
all
right
well
I'll,
raise
my
hand
now
for
myself
follow
myself,
so
so
yeah,
I
I
I
don't
totally
agree
with
that
last
point,
brace
only
because
if
you
were
to
take
one
and
two
out
of
order
you're
describing
one
into
you
know
whether
or
not
they
have
to
have
numbers
associated
with
them
or
roman
numerals
or
symbols,
I
mean.
I
don't
think
that
really
makes
any
difference.
I
think,
practically
speaking,
it's
very
it's
valuable
to
say,
principles.
F
I
don't
mean
the
principles
I
wait.
Let
me
be
very
clear
within
principle.
Number
four
are
numbered
clauses
sentences;
okay,
I
don't
mean
the
principles.
I
think
it's
very
useful
to
have
principle
one
two,
three
four
or
one,
two,
three,
whatever
we
end
up
with,
but
I
mean
within
principle
number
four:
there
are
some
individually
numbered
clauses.
These
are
not
intended
to
make
it
to
the
final
product.
They're
used
they're
just
intended
as
a
tool
locally.
That's
that's
that's
what
I
was
I
was
talking
about,
not
the.
G
Just
a
very
quick
comment,
I
think
the
principles
should
be
should
be
like
super
condensed
and
short
like
if
you,
if
you
touch
four
points
in
a
single
principle
it
it
might
get
deluded
like
if
you
look
at
all
all
the
rest,
they're
like
basically
one
sentence
short
sentence
that
clearly
compresses
the
whole
concept.
I
I
would
like
to
keep
four
as
condensed
and
as
punctual.
A
Okay,
so
just
in
summary
there
and
greece.
That
is,
that
you
writing
this.
Let's
see
the
proposals
below.
I
find
that
to
be
very
helpful.
I
don't
know
about
the
rest
of
you
about.
Baris
has
been
taking
notes
on
all
of
the
proposals
so
far,
and
what
I'm
seeing
is
there
is
an
attempt
to
edit
below
or
above
just
below,
number
four
and
then
proposal
a
b
c
and
d.
A
F
Yeah,
so
the
idea
behind
adding
names
to
those
is,
we
could
do
a
quick
round
and
like
we
can
just
start
comparing
them
right.
If
we
do
do,
we
prefer
a
ob,
it
doesn't
matter,
it
doesn't
matter
which,
like
it's,
we
can
do
a
relative
weighing
and
and
then
we'll
end
up
with
one
that's
better,
and
then
we
can
just
move
that
up.
That
seems
like
a
productive
way
of
doing
it.
F
F
A
It's
only
one
slight
difference
for
a
different
proposal
is
that
it's
essentially
the
same
thing
that
we're
saying
but
proposal
proposal
a
and
proposal,
a
and
b
both
basically
point
to
principles,
one
and
two
essentially
two,
the
version
of
that
state.
I
think
we
also
probably
mean
that
we
need
principle.
Three
two
and
the
pr
proposal
c
spells
it
all
out
in
kind
of
long
form.
A
A
K
D
F
Yep,
I
think
the
only
piece
of
information-
that's
really
missing
is
well
not
really
missing,
but
like
the
distinction
between
human
software
or
freighters
was
made
explicitly
from
feedback
from
conversations.
So
I
think
that's
worth.
I
don't
think
it
needs
to
be
in
the
principle,
but
I
think
that
we
probably
don't
want
to
lose
that
sorry.
I
kind
of
spoke
out
to
10,
but
we
probably
don't
want
to
lose
that
idea.
So
this
is
what
I
meant.
I've
always
mentioned
in
the
comment
right.
F
A
A
Intentionally
operated
on
because
really,
I
think
what
chris's
point
was
before,
if
I
remembered
correctly,
is
that
it
really
doesn't
matter
if
there's
a
human
or
a
robot
that
does
the
work
of
a
human
or
something
like
this,
we
have
other
systems
that
do
things
for
us,
so
it's
not
always
just
human.
What
we're
talking
about
is
intention.
F
A
What
is
is,
we
could
say
the
word
desired
again,
but
I
think
like
really
it's
just
it's
kind
of
like
an
awkward
sentence.
So
we're
really
talking
about
what
we
intend
to
operate
on
because
there
are
we
recognize
like
like
moshe
said
there
are
things
that
are
going
to
happen
on
the
system,
whether
we're
just
talking
about
timestamp.
A
H
H
A
L
L
H
A
A
J
Yeah,
I
was
just
going
to
say
that
I
think
that
a
human
or
machine
probably
don't
need
to
be
in
it,
because
we're
referencing
principles
that
already
states
that
it's
either
human
or
machine.
So
it's
kind
of
implied
by
doing
that,
and
the
fact
that
we're
saying
that
the
only
mechanism
through
which
a
system
can
be
intentionally
operated
on
is
through
these
principles.
J
Kinda
doesn't
leave
much
to
the
imagination,
but
we
want
the
short
versions
right.
We
want
the
the
the
this
is.
This
is
our
these.
These
are
the
principles
and
then
we're
gonna
have
a
more
explanatory
section
later
on
going
through
some
of
the
the
the
variance
here
and
maybe
there
we
can
say
that
if
there
is
an
emergency,
obviously
you
can
do
things
to
the
system,
but
you
should
then
try
to
correct
that
by
by
getting
your
your
your
state
back
in
order
right.
A
A
M
A
The
other
screen-
okay,
like
this,
I
could
share
the
screen
I
should
probably
have,
but
I
I
pasted
it
in
the
chat
instead.
So
I
think
what
we've
been
discussing
thus
far,
the
most
recent
iteration
we've
been
discussing
has
been
e,
but
let
me
just
ask
that
first:
does
anyone
think
that
any
of
these,
besides
e,
would
be
the
one
you
would
like
to
vote
on?
Please
raise
your
thumb.
I
D
A
A
F
A
I
A
A
So
can
can
we
do
this
because
this
is
exactly
what
we
asked
moshe
to
do
which
which
he
did
or
actually
rather
we
made
a
discussion
and
invited
mush
to
to
make
his
point
there
right.
Can
we
take
the
the
contentions
that
were
just
raised
and
bring
them
into
a
github
discussion,
so
we
can
have
this
asynchronously
and
then,
if
we
can
find
consensus
at
least
broad
consensus
through
that
consensus,
not
unanimity,
then
then
we
can
proceed
with
the
first
non-v1.