►
From YouTube: [OCI-WG] Reference Types - 2022-02-08
B
C
C
D
I
just
ever
since
jason
started
the
second
place
award
there.
I
had
to
keep
it
going.
B
B
Silence
my
other
windows
and
yeah
josh
has
most
of
the
agenda
items.
I
sound
like
my
other
windows
and
then
I
lost
all
the
tabs
where
I
was
there.
We
go.
Josh
has
all
the
the
first
items
I'll.
Let
him
start
with
the
smattering
of
baby
prs.
E
Yes,
I
have
a
smattering
of
baby
pr's
that
I
opened
last
week
and
I
think
they're
relatively
harmless.
I
can
walk
I'll
just
walk
through
some
of
these
changes.
Really
quick.
We
had
opened
up
a
about
the
ice
cream
stuff
and
I
think
steve
had
made
a
bunch
of
points
that,
like.
E
Were
actually
concerning
ourselves
with
the
sort
of
like
trucking
company
and
there
he
is
we're
concerning
ourselves
with
like
the
trucking
company,
and
so
I
just
added
a
little
bit
of
language
in
here
that
talks
about
that
and
how
we're
kind
of
focused
on
the
transportation
of
the
ice
cream
from
the
factory
to
the
consumer.
E
And
so
this
this
one's
like
relatively
harmless,
considering
it's
ice
cream
related.
This
is
a
placeholder
for
changes
that
we
will
have
to
graft
into
the
specs
if,
if
it's
necessary,
given
the
outcome
of
the
group
so
nisha-
I
don't
know
if
you're
here,
but
there
was
a
comment
about
like
these
categories.
E
These
four
are
specifically
what
we
broke
down:
conformance
and
distribution
specs.
So
perhaps
it
is
that
we
need
to
add
more
categories
to
registry
api,
but
I'm
imagining
most
will
fall
under
discovery
and
management.
E
It
could
be
that
these,
just
we
don't
need
any
updates,
but
perhaps
pool
we
need
to
pull
things
in
in
a
different
way
image
spec.
This
is
kind
of
out
of
a
conversation
with
brandon
and
slack,
but
it
could
be
the
case
that
we
need
to
introduce
a
new,
manifest
format,
steve
or
nisha.
Do
you
want
to
talk
about
this?
One
specifically,
your
I
see
hands.
F
Okay,
thank
you.
This
is
related
to
my
point
in
the
agenda,
which
is
the
process
of
migrating
decisions
into
these
mini
baby
prs
for
baby
documents
or
skeleton
documents.
Nice
work
by
the
way
josh
most
of
it
looks
good,
including
the
division
of
the
categories.
F
F
G
E
E
The
stuff
in
the
google
doc
is
what
I'm
considering
requirements
when
we
were
talking
last
week
and
the
week
before
we're
talking
about
like
the
user
stories
and
hopefully
from
that
we
can
actually
come
up
with
the
requirements
of
the
working
group.
The
changes
doc
is
more
like
we
have
our
requirements.
E
We've
come
up
with
our
like
strawman
api
or
our
design,
and
these
are
the
these
are
the
things
that
we're
going
to
need
to
propose
into
the
other
pieces
of
oci,
and
I
actually
included
a
part
for
tob,
because
perhaps
there
could
be
that
we're
blocked,
because
we
can't
make
administrative
decisions
there.
So
that's.
What
number
five
is
about?
F
Yeah
I
mean
I
understand
the
intent
totally
you're
you're
making
placeholders
to
put
decisions
that
we
make
about
requirements
about
what
changes
need
to
happen.
All
of
that
sounds
great.
I
I
was
for
that
particular
section.
I
was
thinking
you
know
you
may
have
jumped
the
gun
a
little
bit.
Maybe
just
you
know,
remove
the
categorization
together
and
we
can
add
categorizations
later.
E
H
Sorry
yeah
always
I
just
I
like
the
way
you.
I
also
think
it's
interesting
just
on
the
transition
from
the
google
doc
to
a
pr,
because
there's
some
good
conversation
happening
in
the
google
doc,
which
is
easier
to
iterate
on
than
a
pr.
This
is
kind
of
the
hack,
md
kind
of
things
before
it
goes
into
a
pr
the,
but
I
do
like
the
categories
because
it
maps
back
to
what
you
were
doing
in
the
conformance
tests
on
push
pull
discover.
H
I
agree
in
general,
there
shouldn't
be
much
the
only
thing
on
poll
that's
been
interesting,
we've
been
doing
within
with
the
auras
artifact
stuff
is,
and
I
know
we
don't
get
into
often
permissions
in
the
in
the
specs,
but
we
do
make
sure
the
specs
support
registries
to
do
author
permissions,
because
of
course
we
all
do
is
when
you
pull
something
the
ability
to
pull
the
references
as
well
like
the
permission
to
pull
the
net
monitor.
V1
image
has,
even,
though,
that
we
separate
permissions
on
discover
the
list
of
tags
and
so
forth.
H
If
you
can
pull
the
net
monorail
image,
you
should
be
able
to
pull
reference
types.
So
I
think,
there's
there
is
some
subtleties
there
to
just
keep
those
categories
because
it
maps
back
to
your
conformance
tests
and
there
it
makes
it
easy
for
subtleties
of
the
diff
the
requirements
to
feed
into
those
categories.
E
That,
yes-
and
that
was
like
100
percent
my
goal,
so
it
sounds
like
misha
we're
kind
of
in
disagreement
on
that.
I
I.
H
E
Maybe
that's
the
conversation
we
should
have
is
like
what
is
our
process
here
and
that's
kind
of
my.
My
second
point,
like
I'm,
seeing
a
lot
of
the
you
know,
these
pr
is
like
I
jason,
has
a
gray
check
and
I'm
getting
a
great
check
from
brandon
and
gray
checks
from
nisha,
and
I
just
I'm
curious
like
how
are
we
to
progress
here?
E
E
Is
there
a
way
that,
like
the
four
people
I
listed,
could
like
get
merged
rights
on
this,
and
I
don't
mean
like
I
don't
mean
for
this
to
be
a
call
out
like
lockheed,
especially
has
been
here
besides,
I
think
last
week,
but
like
are
these
the
people
that
are
supposed
to
have
plus
one
plus
one
here
or
is
it
the
members
that
are
coming
to
the
coming
to
the
call?
Because
I
don't
feel
like
there's
any
meaning
in
me.
Opening
these
or
anyone
trying.
C
B
Yeah,
I
think,
that's
yeah.
I
think
that's
an
interesting
parallel,
also
to
the
problems
that
oci
has
had
in
even
in
image
spec
and
distribution,
spec
that,
like
the
folks
actively
discussing
some
issue
or
question
or
proposal,
may
all
agree.
But
if
the
people
with
the
power
to
hit
the
big
green
button
aren't
in
the
room,
then
it
doesn't
mean
a
lot.
B
I
would
like
to
change
that
for
this
group
both
because
I
think
we
have
a
specific
charter
to
make
a
change,
whereas
the
other
specs,
I
don't
think,
have
a
charter
to
make
a
change.
They
have
a
charter
to
maintain
and
at
the
end
of
the
day,
like
whatever
we
write
in
our
github
repo
is
not
law
right.
Whatever
we
write
in
our
github
repo
is
our
proposal
to
the
law
upstream
into
into
image,
track
and
distribution
spec.
B
So
I
think
there
should
be
a
much
lower
barrier
to
entry
to
get
stuff
merged
in
there.
As
to
the
question
of
like
what
is
our
process,
we're
we're
the
only
adults
in
the
room,
so
the
process
is
whatever
we
all
collectively
agree
on.
I,
if
people
think
that
stuff
is
getting
put
into
prs
too
fast,
then
putting
them
into
pr's
faster,
isn't
going
to
make
anybody
happy.
B
B
C
Yeah
so
it
you
know,
I
just
went
through
the
agenda
and
I
think
all
these
things
are,
you
know
basically
the
the
agenda
for
today,
so
we're
not
putting
the
cap
before
the
horse.
All
these
things
need
to
naturally
happen.
It
sounds
like
that.
We're
at
that
point
now,
so
I
just
wanted
to
address
them
top
down.
C
First
thing:
thanks
josh
for
putting
this
scaffold
out
and
starting
to
put
in
putting
a
place
where
we
can
start
to
put
decisions
into
place,
and
you
know
I'm
for
you
know,
merging
fast
and
merging,
often
and
like
let's
iterate,
because,
as
you
said,
you
know,
getting
things
in
here
doesn't
mean
anything's
changed
and
we
can
continue
to
iterate.
So
I'm
I'm
happy
to
do
that.
So
you
know
whether
the
the
scaffolding
fields
are
there
or
not.
C
Based
on
what
nisha
said,
I
don't
mind
because
I
know
we
can
reserve
the
right
to
change
that
down.
You
know
whether
you've
got
push
paul
discover.
We
can
figure
out
how
that
looks
the
process
of
how
we
do
the
decision
making.
I
think
it
would
be
worth
having
a
conversation
now
and
see
if
we
can
swizzle
on
it
and
make
a
decision
and
and
some
loose
agreement
here
and
then
maybe
just
document
how
we're
going
to
work
and
then
the
other
thing
is.
C
You
know
I've
spoken
to
chris
when
it
chris
anna
checked
from
oci
on
who
has
repo
access,
and
no
nobody
does
because
I
was
like
well,
let's
just
figure
out
how
we
get
repo
access.
So
whatever
we
suggest
chris
and
amy
are
waiting
for
us
to
say
you
know
we
can
put
in
a
maintainers
file.
However,
we
want
to
do
this,
but
the
intent
is
that
we
set
up
and
get
this
place
working,
but
I
didn't
want
to
go
and
jump
out
in
front
of
everybody
and
those
names
of
the
organizers
was
just
to
show.
C
There
was
some
commitment
to
the
proposal
that
people
were
going
to
get
show
up,
and
I
don't
think
you
know
john
john's
here
as
well.
He
can
chime
in
and
whoever
else
it
was.
Basically,
we
had
a
group
of
people
who
are
invested
in
making
sure
that
this
working
group
was
stood
up,
but
as
to
people
who
can
merge,
I'm
less
worried
about
that.
You
know
I
want
to
make
it
lower
barrier
to
entry
and
make
sure
we
have
accountability
between
all
of
us
to
check
each
other's
checks
and
balances.
C
Here
I
don't
think
merge
access
is
something
we
need
to
gate,
but
we
should
just
try
for
the
end
of
this
meeting
to
come
up
with
an
agreement,
and
then
I
can
I
or
any
one
of
us
can
take
back
to
chris
and
say:
can
you
implement
these
access
rights,
so
we
can
start
to
make
some
movement
in
the
repositories.
So
I'm
all
for
these
things
again.
I
didn't
want
to
go
to
chris
and
say:
hey
put
all
these
things
in
place
and
amy.
C
It
was
kind
of
like
let's
get
to
the
let's
get
to
that
place,
and
it
looks
like
we're
getting
to
that
place
now,
so
I
didn't
want
to
kind
of
push
process
on
us
until
what
was
needed.
So
you
know
what
I'd
ask
for
the
remaining
time.
Just
my
suggestions
are:
how
do
we
go
from
process
from
where
we
I'd
ideate
things
to
where
we
bring
them
into
issues
prs?
And
one
of
the
hopes
when
chris,
when
I
spoke
to
chris
about
this,
was
using
github
discussions?
C
I
don't
know
if
anybody's
used
that
for
more
longer
running
things,
it
doesn't
have
to
be
that
it
can
be
a
google
doc.
But
how
do
we
take
what's
in
the
google
doc
and
then
start
to
transpose
that
into
the
structure
you're
laying
out
josh
and
the
other
thing
is
who
should
have
access
to
approve
and
what
kind
of
merge
access
do
we
want
to
set
up
on
this
repo
I'd
like
to
get
those
things
answered,
and
then
you
know
we
can
run
them
down.
C
B
Yeah
thanks
josh
for
for
taking
that
on
and
both
both
the
initial
sort
of
buck
cutting
into
stuff,
which
was
super
helpful
and
then
moving
it
over
into
prs.
I
thank
you
lucky
also
for
for
being
open
to
you
know
giving
people
access
as
much
as
we
want.
I.
I
appreciate
that.
I
still
think
there
is
a
potential
issue
on
the
horizon
that
the
working
group
leads
that
have
final
sort
of
approval
over
what
we
produce
again.
What
we're
producing
is
not
the
law.
B
What
we're
producing
is
a
proposal
to
the
law
or
proposal
to
the
specs.
I
have
a
slight
concern
that
the
people
in
this
discussion
are
coming
going
to
come
together
and
hash
out
a
lot,
a
lot
of
requirements.
A
lot
of
proposals
come
to
something
we
like
and
have
to
get
through
the
gatekeepers
of
the
approvers
that
haven't
been
in
that
discussion
for
the
last
few
months
and
then,
when
we
get.
B
Hurdle
we
have
to
take
it
to
the
oci
tob
as
another
group
of
gatekeepers
that
have
not
been
involved
in
the
discussion
and
I
just
don't
think
it's
a
setup
that
warrant
like
a
setup
that
that
facilitates
actual
merging
of
changes
and
it
will
be
very
frustrating
for
the
josh's
and
niches
and
brandon's
and
jason's
and
steve's
of
the
world
that
have
been
spending
months.
Talking
about
this,
if
we
have
to
get
over
first,
the
hurdle
of
the
working
group
leads
that
weren't
involved
and
then
the
tob
leads
that
were
involved.
B
F
So
let
me
start
off
by
making
some
suggestions
and
see
where
we
go.
So
obviously
everyone
wants
to
get
this
resolved
and
get
back
to
the
meat
of
the
stuff.
Oh
there
lucky
said:
let's
make
suggestions.
Okay,
so
my
suggestion
would
be
lean
on
the
note
taker
a
little
more
than
it
being
a
passive.
You
know
just
write
down
notes
about
what
everyone
is
doing
and
kind
of
leverage
the
note
taker
to
write
down
consensus
and
action
items.
F
So
the
consensus
is
a
record
of
what
we
as
a
group
decide
and
the
actions
are
what
needs
to
go
into
the
proposal
and
someone
can
follow
up
on
those
actions.
F
Josh
has
been
very
proactive
about
this,
but
I
would
suggest
that
we
spread
that
work
around
and
as
far
as
the
folks
with
the
merge
rights
are
concerned,
I
am,
I
would
just
say,
let's
just
vote
now
and
someone
take
the
action
to
tell
people
to
tell
whoever's
or
the
t.o.b
or
whoever
chris
and
amy.
You
know
we.
We,
as
a
working
group,
have
decided
that
these
folks
have
merged
rights.
Can
you
please
give
them
murder
rights.
E
I
think
I've
had
something
else
to
say,
but
I
like
one
of
the
comments
between
like
the
four
pr's
I
have
on
there,
that
I
said
I
think
nisha
was
asking
like
why.
Let's
resolve
this
in
google
doc,
I
think
one
of
the
things
I
think
we
should
keep
in
mind
is
that
if
we
do
well
here,
then
we
could
hopefully
archive
this
repo
right
like
if
the
working
group
comes
up
with
a
proposal
and
the
proposal
lands
into
distribution,
spec,
image,
spec
and
we
all
have
champagne
like
let's
archive
it.
E
The
next
discussion
will
be
in
another
working
group,
so
I
don't
think
we
need
to
treat
what's
in
that
repo
is
like
so
sacred
almost
to
like
nisha,
like
what
you're
saying,
maybe
the
note
taker
submits
the
pr
of
the
notes
into
the
repo,
and
that
becomes
the
record
google
docs.
I
can
come
in
and
just
like
wipe
the
whole
thing
and
it's
gone.
E
I
don't
know.
Maybe
google
has
backup
but
like
if
you
look
at
what
I'm
doing
in
these
pr's
there's.
Actually,
a
new
section
in
the
read
me
that's
called
in
progress
and
so
perhaps
like
what,
if
I
wanted
to
come
up
with
a
straw,
man
for
the
api
or
like
the
aura
stuff,
gets
put
into
an
official
like
working
group
proposal
like.
Why
is
that
even
something
that
needs
review
to
be
in
a
temporary
space
as
like
josh's
proposal
right?
I
think.
E
Maybe
we
look
at
like
the
way
we
structure
the
repo
as
like,
there's
a
temporary
folder
and
then
there's
like
a
more
permanent
folder
that
we
agree
on
and
then
my
other.
My
last
comment
is
like
on
consensus.
I
think
we
need
to
figure
out
what
consensus
means
because,
like
I
think,
that's
like
a
feeling
like
that's
not
really,
you
can
walk
away
from
a
call
and
be
like.
Oh
yeah,
there
was
consensus
about
ice
cream
right
and
like
so.
E
C
Yeah,
I
was
just
gonna
say:
let's
start
making
suggestions
and
see,
see
how
they
they
go.
You
know
I
I
advocate
for
keeping
the
the
process
as
lean
as
possible,
and
you
know
if,
if
any
been
on
other
boards
and
things
like
that,
basically
it's
somebody
proposes
a
motion
to
make
a
change
in
people
hands
up
hands
down,
and
you
know
we
could
extend
that
to
virtual
forums
as
well.
But
you
know
I
don't
want
to
go
wrap
this
in
some
big
voting.
C
You
know
it
kind
of
defeats
the
I
would
let's
keep
it
lightweight
and
use
the
accountability
between
us.
As
steve
said,
you
know,
there's
some
level
of
trust
that
we're
all
working
towards
the
same
thing
here
and
what
what
what
thing
you
know
as
jace
jason?
How
do
we,
hedge
on
the?
How
do
we
get
ahead
of
the
the
worries
you
have
like
what
process
we
could
put
in
in
place?
If
any,
but
you
know,
do
we
need
to
start
just
throwing
throwing
down
some
different
suggestions
here,
because.
C
C
They
can
liaise
us
so
hopefully
they're
not
coming
in
cold
to
the
point
that
you
know
when
we're
making
the
proposal
to
the
tob
there's
enough
representation
of
the
top,
that
they've
got
a
semblance
of
what's
coming
down
the
gauntlet,
but
for
working
groups
you
know
we're
setting
the
stage
here.
We
have
the
responsibility
to
set
the
stage
for
how
subsequent
working
groups,
whether
we
care
or
not,
I
think,
setting
something
up
and
a
process
up.
C
C
So
I'm
going
to
stop
throwing
questions
out
here.
Let's
just
start
making
suggestions
and
let's
see
what
what
we
can
land
on.
I
think
there's
enough
experience
collectively
here
on
us
to
create
a
list
of
maintainers
that
we
could
propose
to
to
chris
and
amy
and
define
a
lightweight
process
to
taking
things
from
suggestion,
iterated
stage
and
and
figuring
out
where
we
want
to
do
that.
Discussion.
B
Yeah,
I
think
my
my
concrete
suggestion
would
be
to
give
as
many
people
merge
rates
as
possible
have
that
repo
be
as
fast
moving
as
we
can
get
it
and
for
everyone
to
have
a
mindset
change
to
not
care.
If
some,
if
you
disagree
with
something
currently
in
the
repo,
that's
fine
send
an
issue
send
a
pr
to
change
it.
It
is
it
is.
It
exists
to
be
maximally
editable
and
modifiable,
which
might
feel
unusual
if
you
are
coming
from
the
broader
oci
ecosystem.
B
But
the
point
of
the
repo,
I
think,
is
a
like:
I
want
to
have
the
mindset
that
the
point
of
the
repo
should
be
fast
moving
constantly
moving
until
it
settles
naturally
over
time
to
some
like.
Oh,
we
no
longer
have
anything
to
argue
about.
This
must
be
the
thing
we
all
agree
on.
Let's
propose
it
does
that.
Does
anyone
want
to
disagree
with
my
suggestion.
F
I
disagree
yeah
mostly
because
we're
working
in
a
group-
and
you
know
having
one
person
stomp
over
somebody
else's
stuff
just
willingly
without
any
kind
of
you
know,
discussion
about
why
one
person
has
written
like
over
somebody
else's
stuff
will
cause
a
lot
of
hurt.
F
Now.
Having
said
that,
if
there
is
a,
if
there
is
an
agreement
among
the
group
that
we
take
everybody's
changes
in
good
faith,
then
I
don't
have
any
problems
with
that.
So
I
guess
the
vote
is
like
everybody
gets
merged
rights,
and
everybody
agrees
that
you
know
we're
having
open
and
honest
discussions
about
why
we're
making
changes.
D
C
Okay-
let's
just
I
think,
we're
coalescing
here
to
some
decision,
which
is
good
and
let's,
let's
get
it
documented
in
the
notes.
I'll
come
back
in
a
second.
Can
we
just
kind
of
think
about
how
this
would
work
functionally
like?
Let's
just
game
it
out,
everybody
gets
merge
access.
I
think
the
interesting
thing
to
consider
what
nisha
was
saying
is:
do
we
create?
C
Are
we
expecting
a
whole
bunch
of
proposals
that
people
scaffold
into
directories
and
then
we
start
to
consider
and
they're
kind
of
the
the
working
place
for
this
discussion
and
ideas
to
be
put,
you
know
put
into
play
and
if
that's
the
case,
does
it
make
sense
just
to
say:
if
that's
the
case,
then
we
probably
just
need
a
gating
consensus
barrier
that
you
get
over
that
once
we've
made
a
decision,
we
move
that
thing
into
some
other
place
like
josh's
top
level
structures
and
say
that
we've
had
agreement
on
this
particular
piece
of
this
working
group,
and
then
we
can
start
to
bring
it
up
into
those.
C
So
we're
just
getting
the
the
final
thing
that
goes
into
the
proposal
and
having
just
open
space
to,
let's
just
say,
a
wip
directory
where
people
can
start
to
scaffold
out
ideas
and
iterate
quickly,
because
I
do
want
to
consider
what
niche
is
saying
and
in
that,
let's
try
not
to
stomp
over
each
other.
Is
that
creating
just
a
that's
kind
of
a
sandbox
where
people
can
scaffold
out
documents
that
they
can
present
during
an
agenda
for
feedback
and
we
capture
all
their
you
know.
The
good
thing
is
about
that
method.
C
C
What
are
we
functionally
proposing
is
that
anybody
can
do
anything
anywhere,
or
are
we
all
going
to
have
an
agreement
that
we
carve
out
a
space
within
this
repo
that
we
start
to
scaffold
our
ideas
and
then
get
agreement
with
the
group
as
to
how
we
bring
them
up
into
them?
The
top
level
set
of
directories
as
a
this
is
the
actual
working
thing
that
we
have
agreement
on.
B
I
don't
think
I
would.
I
don't
think
I
would
recommend
like
a
wip,
slash,
josh
directory,
where
he
can
do
whatever
he
wants
in
a
wip
flashlocky
directory,
where
he
can
do
whatever
he
wants.
I
think
I
think
the
the
solution
to
the
problem
of
stomping
over
each
other's
changes
is
trust
and
humanity
and
don't
you
know,
don't
write
a
bot
that
deletes
every
word.
That
josh
writes.
That's
that
that
that's
wrong.
I
think
I
think,
having
a
shared
history.
B
Preserving
scratch
pad
is
useful
for
discussion
and
is
useful
for
progress
going
forward,
and
if
you
use
it
to
delete
everything
nisha
writes,
then
you
get
your
keys
revoked.
I'm
sorry,
like
I
don't
know.
I
just
think
I
just
think
we
have
to
trust
each
other
not
to
make
malicious
changes
or
mess
with
each
other.
F
Yeah
thanks,
I
do
want
to
point
out
just
because
I'm
a
parent
that
google
docs
has
version
control
like
you
can
go
back
to
a
previous
revision
to
see
what
has
changed
in.
F
As
far
as
like
a
process
is
concerned,
I
think
you
know
the
the
the
artifact
of
the
discussions
that
we're
having
over
here
is
the
google
doc
and
if
we
can
document
what
we
have
decided
to
do
in
the
google
doc,
then
what
happens
in
the
repo
is
the
result
of
the
google
doc
and,
as
such,
people
will
be
able
to.
You
know,
figure
out.
Okay,
this
the
changes
that
are
happening.
Like
suppose
I
go
on
vacation
and
come
back
to
see
what
decisions
people
have
made.
F
F
Yeah,
so
it
as
long
as
there
is
a
place
to
record
consensus
or
agreements
or
actions
that
have
happened.
That
are
the
result
of
us
speaking
in
the
meeting,
whether
it's
in
the
google
doc
or
whether
it's
on
github
repos,
as
as
issues.
F
Everything
else
is
kind
of
like
voluntary
people
pick
up
an
issue
or
pick
up
an
action
and
start
working
on
it
and
asking
for
feedback.
I
I
wanted
to
kind
of
like
disagree
with
that
sentiment,
primarily
because,
as
an
author,
I
typically
come
to
github
to
see
specs
and
consensus.
I
personally
am
not
kind
of
like
fond
of
writing
something
into
google
docs,
primarily
because
it
cannot
keep
history
like
the
current
extension
pr
in
oci.
It
took
two
years
to
get
through,
but
the
comments
are
all
tracked
and
there's
very,
very
good
record
of
everybody.
Who's
actually
spoken
on
it.
I
When
you
ask
somebody
from
the
community
to
come
and
maybe
open
an
issue,
it'll
happen
in
the
github
repo
asking
them
to
go
and
enter
this
into
a
google
doc
might
be
challenging
so
indian.
For
me,
github
is
currently
the
place
where
a
lot
of
the
discussions
are
captured
and
there's
identity
there.
There
is
history
there.
So
that's
why
I
was
kind
of
like
hoping
that
we
keep
github
as
a
source
of
truth
and
show
progress.
I
The
google
doc
is
great
for
the
meeting
and
I
think
there
are
other
communities
like
helm
and
folks
that
move
the
meeting
notes
into
maybe
a
repo
or
a
mock
town,
or
something
like
that
to
kind
of
show
progress.
So
consider
folks,
who
are
not
on
the
call
as
well,
because
they
need
to
come
and
open
an
issue
somewhere
and
a
doc
seems
like
a
very
hard
place
to
kind
of
ask
them
to
follow
a
train
of
thought
in
some
way.
Anyway.
That's
all.
F
And
there
is
a
need
to
create,
like
a
meetings
folder
in
that
repo
to
put
meeting
notes
in
there.
B
Sure
I
think
that
I
think
the
the
the
actual
sticking
point
question
is
not
when
we
have
consensus
on
something:
where
do
we
put
it?
I
think
that
I
think
everyone
agrees
that
belongs
in
in
the
github
repo,
for
you
know
in
perpetuity
in
perpetuity
for
forever.
The
question
is:
where
do
we
put
not
yet
reached
consensus
ideas
for
discussion
for
feedback
for
typo
fixes
for
comments,
for
you
know
anything
when.
F
Yeah
that
that
at
least
that's
what
it
is
right
now
now,
whether
that's
going
whether
we
want
to
move
that
to
github
discussion
or
something
I
am,
I
do
not
have
any
opinion
on
that
that
can,
in
my
opinion,
that
can
go
anywhere
as
long
as
we
know
as
a
group
where
it
is
how.
B
About
how
about
the
as
as
a
as
a
shirking
of
making
a
rule
for
this
as
you
as
the
author
of
the
proposal,
gets
to
decide
whether
that
proposal
is
a
pr
or
a
github
discussion
or
a
doc
or
a
hackmd
or
papyrus
or
you
know,
smoke
signals
you
as
the
author
get
to
decide
what
what
that
arena
for
discussion
is
so
long
as
whenever
we
come
to
a
consensus
on
that
discussion.
We
all
agree.
It
goes
into
github.
So
if
you
prefer
github
discussions
or
prs
for
your
discussion,
you
can
do
that.
B
If
you
prefer
docs,
you
can
do
that
and
then,
when
consensus
is
when
we're
done,
we
put
it
in
the
pr
or
put
it
in
the
repo.
How
do
you
feel.
C
That's
fine
with
me.
I
just
think
maybe
the
the
the
top
artifact
maybe
just
be.
We
should
just
agree
on
that
being
a
github
issue
to
say
that
I'm
you
know,
we've
had
this
discussion
in
the
meeting.
Here's
the
action
item,
github
issue,
I'm
going
to
go
work
on
this
in
a
doc,
I'm
going
to
go
work
on
this
in
discussion,
I'm
going
to
add
at
least
then
we've
got
the
top
level.
C
There
was
an
action
and
it
was
in
this
meeting
and
now
we've
got
a
github
issue.
So
if
we-
and
maybe
that's
just
the
start
of
the
process-
nobody
needs-
you
know,
merge
rights
to
raise
an
issue,
and
then
you
know
how
it
yields
down
to
what
you
were
saying.
Jason.
I
think
that's
reasonable.
C
So
then,
as
a
note
taker
as
we're
doing
actions
whoever's
assigned
to
them.
The
first
step
is:
does
this
have
an
issue
if
no
go
create
one?
If,
yes,
you
know
amend
where
you're
keeping
the
running
the
running
work
and
then.
H
I'm
just
going
to
having
an
issue:
we've
had
the
same
problem
with
hack
talks.
You
know
they're
kind
of
like
out
there
in
the
ether,
and
maybe
you
have
a
hackdoc
profile
that
helps
find
it.
Others
can't
find
it
so
having
an
issue
in
the
project
that
links
to
where
that
discussion
is
then
everybody's
collaborative
on
that
discussion,
and
then
you
take
chunks
of
that
output
and
create
prs,
but
hack
or
google.
Docs
is
a
great
way
for
iterative
discussions,
but
yeah.
Absolutely.
I
totally
support
getting
stuff
into
the
repo
as
fast
as
possible.
B
Great,
I
think
we
have
come
to
an
agreement
on
how
we
want
the
process
to
be.
If
anyone
disagrees
that
we
have
come
and
come
to
agreement.
This
is
your
opportunity
to
challenge
me.
B
As
the
chair
of
our
agreeing
to
when
in
a
meeting
we
come
up
with
an
issue
that
needs
to
be
discussed
it
an
issue
is
opened
and
assigned
to
someone
that
person
can
choose
whatever
format
they
want
for
that
discussion
to
take
place.
Github
issue,
doc,
hack
and
d,
et
cetera
when
consensus
is
reached.
Whatever
format
that
discussion
was
when
consensus
is
reached,
that
result
is
committed
to
the
github
repo.
Is
that
a
correct
summary.
D
C
Make
sure
that
gets
in
there
yeah?
So
if
we
were
to
just
run
this
through
the
ringer
with
what
josh
has
done
in
the
last
week,
you
know
we
would
have
had
at
the
meeting
last
week.
Josh
is
going
to
go
and
scaffold
out
some
top
level.
You
know
placeholder
docs
that
are
going
to
land
as
pr
and
he
would
have
an
issue
for
that,
and
these
would
be
four
linked
and
we'd
all
go.
Oh,
we
know
about
this.
B
That's
your
idea,
I
mean
yeah.
I
I
wanted
to
bring
up
a
thing
that
thank
you
brandon
for
the
green
check.
I
wanted
to
bring
up
a
thing.
I
want
to
make
sure
that
we
don't
only
assign
issues
and
start
discussions
at
this
meeting.
I
think
one
of
josh's
points
was
also
that
we,
we
shouldn't
only
work
on
this
an
hour
a
week.
We
should
think
about
this
as
much
as
we
can
as
much
as
we
want
as
much
as
time
allows.
C
Slack
channel
and
just
say:
hey,
I'm
dedicating
time
to
work
on
this
yeah
and
I
expect
set
some
expectation
with
people
that
you're
going
to
set
aside
time
in
some
amount
of
time
period
that
I'm
thinking
about
this
and
I
have
time
dedicated
between
meetings
and
then
you
know
everybody
can
kind
of
thumbs
up
or
ask
questions
and
then
that
can
either
yield
a
go,
throw
an
issue
in
and
start
working
on
it.
But
we
definitely.
C
E
Basically,
yes,
like
we
were
saying:
let's
you
want
in
you're
in
so
I
opened
a
issue.
That's
like
the
latest
issue
in
the
repo
I
linked
it
in
the
chat
in
zoom.
C
Yeah,
we'll
just
aggregate
that
with
the
list
and
when
you
say
integrate
here.
Sorry,
I
like
making
sure
I'm
not
gonna
go,
do
the
wrong
thing.
Are
we
just
going
to
do
owners
and
then
set
up
branch
protection
to
say
that
hey
ask
for
you
know
optional
required
people
and
approvers
so
using
the
github
tooling,
just
to
say
that
anybody
in
that
list
of
owners?
I
think
it's
called
the
owners
file.
So
we
add
all
the
github
handles
to
that.
C
We
set
up
branch
protections
on
main
and
we
just
say
that
you
know
two
optional
approvers
or
you
know
what
what
do
we
want
there
or
nothing?
We
just
say
as
long
as.
G
C
E
Yeah,
I
think
so.
I
think,
though,
there's
a
bigger
issue
in
oci,
which
is,
I
think,
I
think
it's
coming
from
organizations,
so
we
may
need
to
make
a
team
and
I
think
that's
like
pretty
much
just
chris.
I
I'm
I'm
t.o.b
now
and
I
don't
have
that
access.
I
don't
know,
maybe
like
steve
or
john
or
someone,
but
I
I
can't
like
make
a
team,
so
I
think
we
need
to
make
a
team
with
the
people
on
the
team.
C
I'll
make
it
I'll
make
a
team,
you
can
use
owners,
you
reference
the
team
name
and
owners,
and
then
you
regex
I'll
just
star
it.
They
have
access
to
everything
and
then,
in
the
branch
protections
on
the
main
branch
we
can
say
hey,
optional
or
required,
and
how
many
people
in
that
list
need
to
look
at
something
before
it's
mergeable.
C
J
I
was
just
gonna
say
just
for
the
sake
of
formality.
At
some
point,
gonna
want
to
shift
from
like
we're.
Gonna
need
to
actually
be
able
to
have
votes
and
say,
okay.
Well,
we
need
to
get
everybody
who
is
a
maintainer
on
board
to
this
change
or
like
90,
some
super
majority
of
the
maintainers
or
whatever,
on
board
to
a
particular
change,
but
totally
like
for
the
working
progress
stuff.
It
totally
makes
sense
to
just
do
whatever
in
terms
of
those
branch
protections
yeah.
E
I
I
like
100
with
you
on
that,
and
I
don't
know
I
don't
think
branching
is.
I
think
we
should
keep
things
on
main,
but
maybe
we
have
a
folder,
that's
like
official
output
of
the
group,
and
that
requires
some
percentage
of
things,
and
maybe
we
can
do
like
it
can't
be
this
many
people
from
the
same
company
and
stuff
like
that,
like.
I
think
we
need
to
protect
it,
but
make
it
in
a
way
that
you
can
vote.
B
Again,
I
think
just
to
just
to
remind
us
that
what
we're
doing
is
not
that
important
and
doesn't
need
that
much
bureaucracy.
It
won't
like
immediately
get
proposed
to
tob
as
soon
as
there
is
a
work
like
as
soon
as
the
proposal
directory
gets
merged
to
we're
all
adults
we're
all
just
going
to
talk
to
each
other
before
we
send
anything.
So
all
the
talk
about
like
needing
five
votes
from
three
different
companies
or
whatever
really
fills
me
with
chills-
I
was
just
gonna
say
this-
I
mean
this
isn't
working
these
aren't
specs.
B
J
E
Yeah,
I'm
sorry,
I
gave
you
the
chills,
I
I
think
one
thing
that
you
mentioned
jason
or
20
something
minutes
ago.
That
I
think
is
actually
a
huge
concern
is
how
is
the
work
that
we're
doing
going
to
land
and
we
have
like
several
of
the
tob
people
on
the
call
right
now.
E
I
still
have
not
been
indoctrinated
in
the
robes
ceremony,
but
like
what
do
we
need
to
do
like?
How
can
we
make
this?
So
it's
a
successful
thing
and
I
think
we
can
propose
changes
in
the
charter.
Maybe
I
don't
I
don't
know.
I
know
that's
a
long
process
too.
So.
H
We
did
outline
that
in
the
reference
type
working
with
you
know
like
the
pr
that
initiated
this
progress,
it
was,
it
was
clearly
called
out.
This
group
will
make
recommendations,
we're
not
starting
it
with
the
assumption
of
what
those
recommendations
are,
you
know
could
be
a
new
spec
could
be
modifications
to
existing
specs.
It
could
be
use
what's
there
to
reduce.
Like
we
don't
know
what
the
outcome
is.
So
this
group
is
the
recommendation.
C
I
would
just
say
like
from
the
tobs
having
them
in
this
meeting:
let's
figure
out
what
the
output
that
would
be
most
useful
to
the
tob,
to
make
a
decision
based
on
a
proposal,
but
we
I'd
say
we
formulate
a
proposal
which
is
a
set
of
artifacts
or
different
artifacts,
as
maybe
a
bad
word
documents,
and
that's
that
sub
constitutes
the
proposal.
Then
we
say
to
you
know
everybody
in
this
working
group.
Are
we
all
in
agreement
at
some
level,
some
super
majority,
that
this
is
the
proposal?
C
We
want
to
go
to
the
tob
with
everybody
says
their
piece
and
then
we
go
and
make
that
process,
which
is
you
know,
raising
an
issue
or
a
pr
that
we
have
a
proposal
from
this
working
group
ready
and
we
start
the
discussions.
You
know
either
everybody's
part
of
it
or
whoever
wants
to
be
part
of
it.
C
But
there's
going.
C
Where
we
formulate
everything
into
a
proposal,
we
all
agree
on
that
as
part
of
the
working
group,
and
then
we
agree
on
taking
that
to
the
tob
and
I
think,
as
tob
members.
Just
what
do
you
need
to
see
in
the
proposal
in
order
to
facilitate
a
discussion
where
you
can
make
a
decision
is
without
what
I'd
want
to
have
the
tob's
eye
on.
B
Yeah,
I
think
I
think
I
I
agree
that
having
tob
folks
involved
in
the
discussion
will
be
very
helpful.
I
think
tanisha's
point
I
I
agree
that
we
may
be.
You
know
one
mile
into
the
marathon
talking
about
where
we're
gonna
go
for
burgers.
Afterwards,
we
should
probably
focus
on
the
next
25
22
miles.
How
long
is
a
marathon?
Clearly
I'm
very
active?
B
Cream
ice
cream
anyway,
yeah
josh,
you
still
have
your
hand
up
and
then.
K
I'm
confused.
Why
we're
talking
about
a
proposal
to
the
tob?
The
tob
is
the
oversight
body,
not
the
tdc,
which
is
where
the
proposal
is
actually
going
to
go
specifically
for
image
back
and
distribution
specs.
So
there's
two
separate
maintainer
bodies
that
we're
probably
going
to
propose
something
to.
B
Yeah,
thank
you,
for
that
is
a
very
helpful
fact
check
before
we
get
too
far
down
the
road
of
who
is
going
to
be
actually
approving
any
of
this.
I
think
that
fills
me
with
even
more
dread
about
where
we're
going
to
get
burgers
at
after
this,
because
we
need
to
have
two
separate
somewhat
overlapping
groups.
B
They
will
also
see
all
of
our
haggard
faces
from
all
of
the
discussions
that
we
have
had
and
if
we
all
agree
to
it,
then
it
must
be
good
right,
but
yeah
I
I
agree.
I
we
only
have
seven
minutes
left,
but
I
would
I
think
this
has
been
a
productive
discussion
in
terms
of
what
we
think
we
are
going
to
produce,
how
we
think
we
are
going
to
produce
it.
B
F
Before
I
do
that,
just
one
more
thing,
I
filed
an
issue
to
create
a
governance
or
process
operations
document
to
just
document
how
we're
going
to
do
this
process.
It's
just
a
cap
on
everything
that
we've
had
all
the
discussion
we
had
today
and
moving
forward
I'd
like
to
tackle
the
user
stories
cleaning
up
next
time.
B
Great,
can
you
can
someone
add
that
to
the
agenda
for
next
week,
so
that
we
remember
that
that's
what
we
wanted
to
do
and
we'll
take
a
look
at
it
over
this
week
and
then
talk
about
it
next
week,
yeah
go
ahead.
K
One
one
idea
I
just
had
is:
maybe
the
the
maintainers
we
come
up
with,
for
this
working
group
become
essentially
the
the
stewards.
I
don't
know
what
a
good
word
is
for
that
to
to
actually
explain
our
position
to
the
downstream
maintainers,
like
they're
they're,
the
ones
who
are
responsible
for
ensuring
that
the
working
group
actually
lands
where
it's
supposed
to.
B
I
think
that
will
be
helpful
and,
in
fact
so
helpful
that,
whether
it's
a
formal
position
and
job
that
will
be
all
of
our
practical
positions
and
jobs
is
to
to
help
make
sure
that
this
lands
yeah
just
going
through
the
chat
and
everyone's
making
me
so
hungry
should
not
have
made
a
food
metaphor.
B
B
Delicious
ice
cream
sliders
the
best
of
both
worlds,
all
right.
Everyone
have
a
lovely
week
and
we'll
talk
to
you
later
on
the
internet.