►
From YouTube: CNB Core Team Sync - 27 April 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
B
C
This
yeah,
I
know
from
my
side
that
mikey
is
he
was
out
for
a
little
bit
as
well
and
he
just
came
back
and
so
he's
catching
up
on
a
lot
of
this
sort
of
work.
So
I
assume
we'll
see
some
progress
here
soon
as
well.
D
The
only
weird
thing
I
see
is
we
previously
had
direct
equals.
True
sorry,
direct
equals
false
is
the
default,
and
now
we
are
just
omitting
it
entirely,
which
means
direct
equals
false,
but
it
will
now
be
direct
equals
true
or
it's
just
oh
wait.
We
went
through
this
argument
and
the
argument
was
the
command
changed
to
an
array,
so
it's
incompatible,
anyways
yeah,
never
mind
yeah,.
B
A
A
B
B
From
mikey
merging
this,
I
mean
not
for
mikey
from
terence,
because
he
is
out-
and
this
has
been
in
final
comment
period
for
like
a
month
now
yeah.
I
can
try
to
just
merge
this
today,
I'll
take
that
one
which
leaves
us
with
images
table
doc
files
and
project
scaffolding.
B
I
guess
I'm
curious
about
how
close
we
are
to
being
done
on
docker
files.
Are
there.
A
D
I
mean
we,
we
already
have
the
poc
proven
networks
and
I
think
steven
just
wanted
to
block
this
on
whether
we'd
require
something
like
builder
or
can
we
do
like
no
special
gates
cluster
mechanical
build
which
we
can
so
I
think
it's
like
there
were
no
major
changes
here,
except
for
like
the
gen
packages,
but
that
needs
to
be
removed,
but
but
not
everything
else
is
good.
C
Maybe
that's
something
we
could
add
right
there
on
the
pr
itself
as
a
sort
of
request
from
natalie
or
steven
to
update
with
latest
status.
B
I
was
just
writing
you
a
message
in
github
asking
for
what
the
outstanding
questions
are
on
the
docker
files.
I
know
I
need
to
go
through
and
do
re-review
because
it's
been
a
while,
since
I've
read
through
it,
but
I
was
curious
just
to
get
like
a
digest
of
what
people
thought
were.
The
remaining
sticking
points.
A
Something
about
s
bomb
and
run
images,
maybe,
but
I
thought
we
resolved
that,
but,
like
I
wouldn't
be
surprised
if
we
didn't
resolve
but
yeah.
B
A
B
Is
this
supposed
to
be?
I
guess
this
affects
pac,
so
it's
not
just
a
bill
pack,
author,
tooling
rfc,
specifically
project
scaffolding,.
A
D
B
C
Yeah,
I
think
this
came
up
a
couple
times
already
whether
this
was
a
sub
team
rfc
or
not,
and
I
don't
know
that
there
was
any
opposition
or
questions
from
the
platform
sub
team.
It
was
more
that
this
was
a
bigger
sort
of
user
experience,
change
that,
I
believe,
maybe
joe
wanted
to
have
some
overview
about.
B
D
Did
we
resolve
our
the
the
state
of
those.
D
A
C
At
this
point,
not
even
the
beginning
or
start
line
yeah,
so
the
other
one
would
be
the
prepare
operation-
rfc,
that's
mine
and
then
was
it.
Was
there
a
publisher.
C
I'm
thinking
the
maybe
only
other
voice
we
want
to
hear
would
be
david
as
a
platform
maintainer
right,
I'm
I'm
pretty
sure
he
wouldn't
be
present
tomorrow.
C
So
is
it
worth
dragging
that
conversation
to
tomorrow,
because
I
can
tell
you
right
now
that
personally,
I
don't
think
I
have
any
opposition
to
it
being
part
of
the
platform
sub
team,
especially
based
on
some
of
the
later
conversations
that
sort
of
went
in
the
direction
of
individual
ownership
of
repositories
and
just
having
a
sub
team
as
sort
of
like
the
backup
right
and
not
so
much
as
the
primary,
and
so
I
think
the
idea
of
having
these
platform
helpers
as
sort
of
experimental,
independently
maintained
repositories
and
just
kind
of
being
in
this
area
of
platform
team
feels
good
and
sounds
good
to
me.
C
C
That
was
kind
of
our
our
question.
Yeah
there's
a
you
have
to
attack.
D
B
D
B
C
Well,
the
problem
is
like,
let's
say
sam,
I
don't
believe,
he's
a
platform
maintainer
right,
so
he
doesn't
have
the
the
right
permissions
for
a
repo
to
maintain
an
entire
repository.
I
think
those
sort
of
technicalities
are
or
maybe
what
we're
putting
ourselves
up
against.
C
Yeah,
so
the
the
stuff
that
I
essentially
just
proposed
was
something
super
trivial
and
simple.
Was
us
leveraging
code
owners
as
a
way
to
signify
ownership
of
individual
repositories,
and
it
doesn't,
and
it
has
like
a
very
big,
open
question
about
you-
know
the
stuff
that
has
to
do
with
whether
a
maintainer
of
an
individual
repository
has
to
be
a
maintainer
of
the
team
in
order
to
again
obtain
those
sort
of
permissions
and
responsibilities
that
we
give
on
the
governance
side
of
things.
B
I
feel
like
that's
sort
of
what
you're
doing
right
with
the
code
owner's
file.
It's
like
the
repo
belongs
to
the
team.
A
B
C
That
is,
you
know,
a
concern
right
or
a
risk
is,
if
we
kind
of
open
this
sort
of
avenue,
could
it
be
misused,
but
what
we're
trying
to
achieve
right
is
again
sam
being
able
to
become
a
maintainer
of
repository
or
owner
of
a
repository,
especially
something
that
is
more
or
less
experimental
right
that
we
kind
of
want
to
trial
before
we
fully
put
resources.
A
D
I
think
the
other
side
of
this
was
like
donations
so,
like
those
depositories
will
have
their
own
set
of
maintainers
and
they
might
be
quite
a
few
in
number.
So
let's
say
something
like
packet
has
like
five
or
six
maintainers.
D
B
D
C
You
know
sort
of
that
upcoming
leads
to
the
governance
structure.
I
do
wonder
if
it
makes
more
sense
to
be
more
open
about
maintainers
right
without
spreading
a
wide
set
of
responsibilities
for
the
maintainers,
like
the
maintainers,
obviously
get
the
permissions
of
all
the
team
repositories,
but
more
or
less
can
become
owners
of
just
independent
ones,
because
I
do
feel
like
a
lot
of
the
responsibilities.
D
I
think
it's
also
about
what
we're
comfortable
with
right.
Like
you
have
a
maintainer
on
one
specific
repository,
they
now
have
more
access
to
almost
everything.
Let's
say
they
approve
something
on
a
repository
they're
not
familiar
with
then
you're,
basically
creating
code
owners
for
each
repository,
which
is
a
subset
of
the
maintainers
within
each
team.
D
D
Rights
over
whatever
they
want
to
do
with
that
repository,
whatever
governance
structure,
they
want
to
sit
within
that
repository,
but
at
the
top
organization
level
they
don't
have
anything
and
then
there's
tags
which
is
like,
I
think,
our
equivalent
of
sub
teams,
which
own
a
bunch
of
repositories,
and
they
have
some
common
set
of
responsibilities
at
an
organization
level
and
then
within
the
diag.
You
can
do
whatever.
C
I
will
say
that
at
least
through
some
of
the
things
that
use
power
and
like
kate's,
they
do
have
like
in
similar
to
code
owners.
They
have
an
owner's
file
right
with
approvers
and
reviewers,
so
they
even
have
those
individuals
laid
out
per
repository.
So
for
this
repository,
these
are
the
approvers,
and
these
are
the
reviewers
right.
The
approvers
are
the
only
ones
that
are
able
to
merge
stuff.
In
so
again.
B
A
D
Not
done
something
like
this
and
see.
Why
not,
I
think,
makes
sense
we
can.
We
can
have
like
the
code
owners
of
the
idea
still
works.
The
maintainers
have
admin
access
on
the
repositories
they
own,
but
in
the
branch
protections
they
can
have
something
like
code
owners
are
required
to
merge
this
and
there's
also
a
github
setting
to
list
out
who
can
merge
the
people
request.
Apart
from
approving
it,
I
think
maintainers
are
set
up
appropriately
to
do
both
of
those
things
right
now.
D
But
all
of
these
things
have
to
be
rfcs
that
were
sponsored
by
that
team
right,
like
whichever
team
agrees
to
take
this
zone,
has
to
have
their
team
lead
and
maintainers
agree
to
it
before
it
gets
accepted
so
same
with
the
case
of
the
signer
preparer.
All
of
these
were
rfcs
that
the
platform
team
and
their
maintainers
had
to
approve.
C
C
A
B
A
B
B
A
B
C
B
I
guess
what
I'm
saying
is:
I
think
that
that
is
valuable,
but
like
maybe
just
having
one
blanket
concept
that
we're
defining
at
the
top
level
like
project
contributor,
is
the
wrong
place
to
do
it.
It's
like
maintainers
of
a
team
can
create
you
know.
Maybe
one
group
wants
treehousers
versus
some
other.
C
You
know
all
right,
so
what
you're
saying
is
that
the
governance
document
should
essentially
just
talk
about
maintainers
how
maintainers
function,
but
then
leave
any
sort
of
responsibilities
below
maintainers
to
kind
of
open
ended
to
the
individual
teams
to.
B
D
Be
fine
with
it
as
well.
I
think
we
just
need
to
make
things
clear
that,
like
any
of
these
privileges
that
we
delegated
strictly
conform
to
github
permissions
and
nothing
more
than
that
so
like
it
would
you'd
still
be
a
contributor
just
with
a
different
set
of
guitar
permissions
over
a
set
of
repositories
owned
by
our
team.
B
C
B
B
C
Well,
maybe
that
that
last
part
might
be
true,
but
I
know
that
for
teams
or
people
like
there's
members
and
you
and
and
that
sort
of
view
of
people
you,
you
could
actually
see
all
of
the
people
listed
out
on
that,
because
I
actually
find
it
more
difficult
to
go
the
other
way
around
to
have
to
go
into
teams
and
manage
it
that
way.
But
maybe
it's
just
not
something
like
to
deal
with
right
now,
just
right
and
that
way.
D
C
And
I
mean
I'm
not
gonna
put
a
huge,
you
know
kind
of
foot
down,
but
in
my
experience,
individual
team,
individual
member
teams
are
sort
of
not
very
easy
or
there's
a
lot
of
overhead
for
no
reason.