►
From YouTube: CNB Core Team Sync - 25 May 2022
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).
B
A
B
Review
outstanding,
spec
peers.
I
made
a
couple
of
meta
spectators,
one
that
just
tries
to
map
all
the
team
leads
to
the
various
parts
of
the
spec.
B
I
also
don't
know
if
that
mapping
makes
sense,
but
that
was
the
original
mapping
that
was
previously
discussed.
So
we
can.
We
can
probably
discuss
whether
we
need
to
change
that
mapping
or
that
should
stay
as
it
is,
and
I
also
made
another
pull
request
to
remove
the
service
binding
spec
because,
oh
sorry,
the
cnb
binding
spec,
because
we,
I
think
at
some
point,
decided
we
should
remove
it
and
put
a
deprecation
notice
on
top
of
it.
B
But
we
didn't
actually
do
that
and
also
since
no
team
was
mapped
to
that
part
of
the
spec.
I
thought
now
is
a
great
time
to
remove
it.
A
How
do
we
go
about
meta
once?
Do
those
have
to
be
toc
right.
B
Now
I
just
have
it
everything
major
is
just
team
leads,
so
just
super
majority
of
team
leads
everything
else
is
just
assigned
to
one
specific
team
lead,
but
that's
again
like
what
I've
proposed.
I
don't
know.
If
that's
what
we
want
to
enforce
the
the
first
meta
one,
I've
set
it
to
toc
super
approval.
Once
that's
approved,
we
can
just
if
those
set
of
responsibilities
make
sense.
We
can
just
rely
on
that.
B
B
A
Yeah,
I
I
find
it
interesting
as
well.
I'm
not
sure
that
it's
as
well
defined
in
my
head,
based
on
what
you
you
just
stated
sam,
but
that
being
said,
I
have
no
real
opposition
to
the
platform
spec
being
part
of
the
implementation
team,
because
I
do
agree
that
you
know
effectively.
A
They
are
the
producers
of
the
platform
interface
and
then
we
are
more
or
less
the
consumers
that
leverage
that
with
that
being
said,
I
feel
like
that
could
also
apply
for
the
build
pack
spec.
A
B
B
A
But
the
lives
the
life
cycle
or
the
implementation
team
is
who
more
or
less
dictates
what
the
buildback
api
should
look
like
right,
similar
to
the
platform
api,
like
everything
like.
If
the
build
pack
author
team
wanted
to
change,
something
they
would
have
to
get
more
or
less
buy-in
from
the
implementation
team.
B
Wouldn't
it
be
the
other
way
around
like
the
back
team
is
proposing
features
and
the
implementation
team
would
implement
them
and,
as
a
course
of
that
implementation,
they
would
expose
certain
flags
to
the
platform,
or
at
least
that's
how
I've
typically
seen
it
work
like
we
propose
we
never
go
about
proposing
here's.
What
the
platform
spec
should
look
like
and
then
have
the
life
cycle
implemented.
We
typically
go
here's
what
the
buildback
api
changes
should
look
like
the
implementation.
B
A
Yeah,
I
guess
you
could
see
it
the
other
way
too
right
like
I
could
bring
up
maybe
logging
as
another
example
where
the
platform
team
did
make
the
request
like
hey.
We
need
to
be
able
to
toggle
the
verbosity
like
we
wanted
structured
logging
right,
but
we
didn't
get
to
that
point
and-
and
it
was
like
you
know,
hey,
we
need
this
additional
flag
or
this
feature
right,
and
so
that
was
a
platform
feature
at
the
end
of
the
day.
It
just
means
that
there's
collaboration
from
both
sides
of
the
the
coin.
A
B
A
B
It's
not
set
in
stone,
so
that's
why
it
was
just
like
a
request
for
the
like
the
doc
to
review
and
suggest
changes.
So
I
think,
like
we
should
probably
record
these
changes
on
the
pull
request
along
with
the
arguments,
and
if
you
want
to
figure
out
a
way
that,
like
we
want
to
co-share
specs
between
teams,
so
that
both
the
team
leads
need
to
approve
it.
We
might
want
to
add
that
or
not,
I
would
say
just
add
those
as
comments
on
the
request.
C
A
Yeah,
I
think
that
the
problem
is
twofold.
Right,
like
one
of
them
is
what
does
ownership
really
mean,
because
in
a
lot
of
these
cases,
we're
effectively
crossing
a
bridge
or
trying
to
connect
two
dots?
That's
the
whole
point
of
an
interface
right,
so
it
typically
means
that
two
people
should
work
very
closely
together
to
ensure
that
both
sides
know
what
the
end
result
is
and
agree
to
that
end
result.
A
So
I
don't
know
effectively
what
it
sounds
like
to
me
is
that
maybe
we
should
have
you
know
two.
I
don't
know
two
code
owners
per
each
one
of
these.
The
people
that
are
collaborating
on
such
thing.
A
B
It's
the
first
time
that
this
is
happening,
and
previously
it
was
owned
by
the
core
team.
That's
why
it's
still
a
pull
request
and
there
are
still
three
code
reviews
required
from
someone
in
the
core
team.
You
check
the.
If
you
check
the
review
requirements,
it
still
says
three
code
reviews
required.
A
B
C
I
think
it'd
just
be
reflective
of,
like
you
know
how
the
actual
governance
model
before
didn't
require
unanimous
consent
from
the
core
team,
but
in
practice
we
would
always
just
chase
everyone
down,
because
we
wanted
to
make
sure
that
there
was
consensus
and
I
think
in
practice
you
know
you're
always
going
to
want
like
if
you
have
as
a
platform
change.
You
know,
you're
always
going
to
want
to
make
sure
that
the
life
cycle
implemented
like
whoever's,
implementing
the
life
cycle
and
whoever's
owning
the
platform.
Part
of
things
like
that
they
agree.
A
I
don't
know
I
don't
know,
there's
been
scenarios
where
a
individual
may
take.
I
don't
want
to
use
the
word
advantage,
but
we'll
definitely
leverage
right
the
ability
to
move
things
forward.
If,
and
so
I
think
that's
the
thing
really.
A
Ultimately,
that's
what
we're
trying
to
do
here
right
is
to
some
extent
notify
and
have
the
right
people
involved
in
certain
conversations,
and
so
if,
in
this
particular
case,
let's
say
platform
right,
because
I
could
speak
to
that
one
there's
a
platform
change
coming
right,
I'm
pretty
sure
I
would
want
to
know
and
and
have
some
sort
of
you
know
at
least
up
or
down,
vote
on
that,
and
if
I
choose
not
to
vote
on
it
right
based
on
our
governance
rules,
then
it's
a
given
approval
right.
B
A
B
Yep,
because,
like
currently,
everyone
on
the
team
leads,
is
going
to
get
a
notification
anyway.
It's
just
that
this
specific
person
needs
to
approve
it
for
it
to
go
through
it's
the
same
thing
as
our
rfc
is
like
for
every
team
that
owns
it,
like
the
team.
Lead
needs
to
start
the
voting
period,
but
after
that
anyone
can
object.
A
B
B
It
will
require
that
any
change
to
those
specific
files
is
approved
by
that
specific
team,
but
at
the
same
time
it
also
requests
a
review
from
everyone
there
so
like
in
this
case.
It
will
request
a
review
from
everyone
in
the
team
leads,
which
is
a
super
set
of
all
the
individual
team
leads.
So
if
there's
a
platform
change,
all
the
team
leads
will
be
notified,
but
the
implementation
team
lead
has
to
review
it
and
approve
it.
A
Comfortable
with
that,
because
again,
I
think
that
aligns
with
our
sort
of
overall
model
of.
A
B
A
Have
we
discussed
windows
or
time
frames
for
those?
I
know
that
the
governance
team
just
kind
of
left
it
up
in
the
air.
Have
we
determined
what
we
feel
to
be
appropriate.
C
B
We've
been
following
that
for
a
while,
and
I
think
once
the
team
lead
for
that
rfc
determines
that
it's
time
to
start
voting,
they
can
give
a
one
week
period
and
then,
if
everyone
agrees,
it
goes
to
final
comment.
I
guess
so
one
week
prior
to
final
comment
for
all
the
team
leads
to
say
yes
or
no,
and
then
final
thing
for
like
final
one
week
for
final
comment
forever
from
everyone
who
wants
to
make
any
comments
to
it.
Oh
so
effectively,
it
would
be
two
weeks.
A
That's
not
only
puts
it
in
practice
right
we're
work
either.
I
guess,
is
there
an
opposition
to
just
having
the
fcp
without
the
pre-voting
period
like
in
my
mind,
that
seems
easier
and
more
easier
to
consume?
It's
like
this
is
your
final
comment
period.
Aka
voting
period.
C
Well,
because
it
would
make
sense
to
me
that
the
final
common
period
comes
before
voting
right
because
it's
like,
I
think
it
said
that
you
can't
make
any
changes
in
the
voting
period
right.
So
it's
you
do
need
some
notice.
It's
like
okay,
last
chance
to
make
any
changes,
go
through
and
add
all
your
your
knits
and
you
know
anything
you
want
to
see,
make
it
into
the
final
thing
that
gets
merged
right
and
then
there's
that
period
of
like
okay.
A
Right,
I
I
am
curious
how
this
is
going
to
you
know,
play
out
especially
the
first
few
couple
times
right,
because
before
anybody
gets
notified,
it's
supposed
to
be
like
finalized
right,
like
you
were
supposed
to
have
already
had
conversations
with
individuals.
Maybe
had
him
look
at
stuff
or
whatever
right,
but
as
as
an
owner
or
champion,
whatever
team
lead
of
the
rfc
like
when
you
say
hey.
This
is
now
up
for
voting,
it
should
be
kind
of
crystallized
and-
and
so
then
the
only
you
know,
outcomes
are
accepted
or
rejected.
A
C
B
Right,
I
would
assume
that
where
was
it,
whoever
is
shepherding,
it
would
start
the
voting
period
once
they've
had
consensus
from
all
the
team
leads
that
are
active
if
they
notice
that,
like
there
are
folks
that
are
not
active
like
they're
on
vacation
or
they're,
not
replying,
and
they
probably
wouldn't
have
interest
in
it.
They
can
start
to.
B
So
it's
like,
for
example,
we'll
let's
take
the
signer
binary
as
an
example
like
at
this
stage
we
think
it's
close
to
completion
the
only
folks
that,
like
we
probably
need
to
figure
out
some
things
between
the
the
team
lead
and
the
author,
but
once
those
are
figured
out,
we
can
put
it
to
a
vote
and
have
it
finished
in
a
week.
I
don't,
I
think,
everyone
who
wanted
to
say
something
at
this
point
has
had
a
chance
to
say
something.
A
And-
and
I
don't
know
if
you
all
have
seen
it,
but
it's
funny
that
we're
talking
about
this,
where
emily,
I
think,
has
an
rfc
for
the
rfc
process
on
the
right.
And
if
you
haven't
seen
that
that's
where
I
kind
of
take
this
mentality
of
when
we
get
to
a
voting
stage,
we
should
have
already
done
a
lot
of
the
due
diligence.
Yeah.
B
I
think
they're
close
to
ending
this
meeting
anyway,
and
we
just
discussed
this.
I
think
everyone
I
want
to
set
the
items
for
tomorrow
before
we
close
off.
Yes,.
B
All
right
got
it:
we
have
how
to
handle
the.
A
B
I
mean
if
we
have
a
conclusion
we
can
just
like
conform
with
aiden
and
stop
the
voting
period.
Then.
A
B
It's
the
signer
one.
I
don't
know
what
we
want
to
do
with
that.
A
A
More
accurate,
so
I
think
we
have
two
thus
far.
Is
there
another
one.
C
You
think
it
would
make
sense
to
talk
about
stack
removal
just
like
we
keep
saying
we
need
maybe
a
dedicated
meeting
for
it,
but
I
think
that
just
having
a
brief
conversation
would
be
helpful,
because
I
don't
even
know
the
scope
of
what
it
is.
We
need
to
talk
about
right.
A
B
I
think
we
it's
not
an
immediate
pressing
concern,
and
I
think
last
time
we
decided
jesse
was
gonna
drive
a
bunch
of
this
and
terence
is
interested
in
it
and
both
of
them
are
busy,
and
I
think
emily
is
also
not
going
to
be
able
to
make
it
tomorrow.
I
don't
know
so
most
of
the
folks
who
might
have
had
interest
in
it
will
probably
not
be
able
to
make
it
tomorrow.
At
the
very
least.
B
A
C
To
be
specific,
the
thing
is
the
spec
as
it's
written
right
now,
it's
not
reflective
of
reality.
It's
it
says
that
the
life
cycle
will
validate
mix-ins,
but
we,
but
the
life
cycle
does
not
right
like
we
leave
that
up
to
the
platform,
and
so
it's
sort
of
I
don't
know,
I
don't
think
it
should
block.
I
don't
think
that
the
stock
removal
should
be
blocking
phase
one
of
docker
files,
but.
C
B
I
mean
we
can
probably
discuss
that
in
the
spec
pr
for
the
dockerfiles
phase,
one
removal-
I
don't
know
if,
like
at
least
that
specific
bit
on
where
to
do,
mix
and
validation.
If
we
keep
stocks
around.
A
Okay,
I
I'll
keep
that
on
the
agenda,
then
so
docker
file,
plus
a
stack
removal
strategy.