►
From YouTube: CNB Weekly Working Group - 28 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).
A
Looks
like
we
have
a
small
group
to
them
familiar
faces,
so
I'm
going
to
skip
over
introductions
and
we
can
move
right
into
release,
planning
and
updates,
maybe
starting
with
the
implementation
finality
of
release,
planning
or
updates.
C
A
Sounds
good,
do
you
have
anyone
from
platform
here.
D
A
Thanks
for
the
update
to
everybody,
moving
on
to
our
first
planned
topic
for
today,
I
think
this
was
one
that
you
suggested
sam
sort
of
continuing
our
discussion
around
in
container
phases
that
are
not
part
of
the
lifecycle
because
they
don't
interact
with
buildpacks
platform
helpers.
Basically,.
D
I
wanted
one
of
the
maintainers
to
be
here,
so
I
don't
know
if.
D
Yeah
and
and
david,
if
he
I
think
he
also
had
some
opinions,
but
I
think
we
discussed
a
bit
of
this
in
the
core
team
saying
yesterday
that
we
were
fine
with
making
like.
I
think
javier
was
supposed
to
make
some
changes
to
the
governance.
D
D
A
D
A
Some
background
to
folks
who
weren't
part
of
this
conversation
on
the
motivation,
and
so
we
can
do
more
rapid
prototyping
around
some
of
these
things.
If
there's
a
contributor,
that's
interested
in
kicking
off
a
stream
of
work
in
a
separate
repository
that
we're
not
pulling
all
the
way
into
the
critical
workflow.
Yet
we
want
to
be
able
to
allow
a
broader
set
of
people
to
review
and
merge.
D
Yeah,
these
components
would
still
require
an
rfc
for
a
new
repository
to
be
created,
but
once
a
repository
exists,
the
whoever,
whichever
team,
maintains
that
repository
the
maintainers
of
that
team
can
then
delegate
github
permissions
accordingly
on
a
per
repository
basis,
rather
than
on
a
team
wide
basis.
D
So,
right
now
what
we
have
is
like.
We
have
two
types
of
roles
in
the
project.
We
have
contributors
which
have
right
access
to
all
the
repositories
that
the
team
owns,
but
they
can't
merge
things.
They
can
approve
things
and
they
can
create
branches,
but
they
can't
merge
things
to
main
or
release
branches,
and
we
have
maintainers
who
have
effectively
admin
access
to
all
the
github
repositories
within
that
team's
purview.
A
I
think
one
restriction
we
wanted
to
put
on
it
was
definitely
to
make
sure
we're
using
teams
or
sub
teams
in
the
github
sense
in
order
to
express
these
new
roles.
So
I
don't
think
we
want
the
wild
west.
Where
we're
you
know,
giving
individuals
permissions
in
code
owners
files.
We
want
all
of
this
to
be
expressed
through.
You
know
our
back
rather
than
individual
access.
A
It'll
obviously
need
broader
approval
from
the
core
team
to
change
the
governance,
but
hopefully
it
shouldn't
be
too
controversial.
D
I
think
the
other
sort
of
use
case
for
this
was
like
project
level
donations
or
repository
level
donations
into
the
project
itself.
So
if
someone
wants
to
make
donate
a
repository
to
the
project,
but
they
have
maintained
it
for
a
while
through
this
model,
they
can
still
retain
right
or
administrative
access
within
that
repository,
but
they
don't
necessarily
need
to
be
maintainers
of
that
team
or
have
to
deal
with
any
of
the
other
repositories
that
that
team
owns.
They
can
be
contributors
to
that
team
with
elevated
permissions
on
the
repository
that
they
contributed.
But.
B
D
So
you
just,
however,
background
you're
walking
through
like
the
proposal
we
discussed
yesterday
with
the
rest
of
the
working
group
and.
E
Cool,
I
know
we
talked
about
this
briefly
yesterday.
I
know
we
left
with
some
sort
of
action
items.
What
is
more
or
less
the
the
current
status
or
really
the
question
at
hand
right
now,.
D
I
think
we
put
this
there
yesterday
in
the
agenda
before
we'd
gone
through
the
discussion
around
the
top
level,
permissions
and
stuff,
but
I
think,
apart
from
that,
the
current
rfcs
are
still
blocked
and
I
think
they're
subtly
rfc,
so
I'm
waiting
for
one
of
the
platform
maintainers
to
approve.
Do
we
want
to
wait
for
the
governance
changes
to
happen
for
the
rfc
to
be
approved,
or
are
we
comfortable
approving
it.
E
I
know
the
the
sort
of
permissions
part
of
it
is
really
sort
of
something
that,
if
I'm
not
mistaken
emily,
you
may
mention
that
it
may
be
good
to
get
some
sort
of
buy-in
from
from
everybody,
and
I
think
so
because
of
that,
I
think
we
probably
want
to
make
sure
that
that
gets
accepted
before
we
finalize
and
approve
the
rfcs,
so
sort
of
a
chain
of
events
right
would
be
kind
of
that.
E
D
Yeah,
would
it
make
sense
to
for
now,
just
of
course,
the
rfc?
The
rfc
doesn't
actually
have
any
like
specific
contents.
In
terms
of
who
contributes
that
specific
feature
or
like
what
permissions
they
have,
I
think
that's
independent.
We
can
just
start
with
the
current
model
where
you
can
start
off
with
the
pull
request,
some
of
the
maintainers.
If
they
want
they
can.
I
can
just
block
the
review
until
some
maintainer
reviews
it,
but
I
guess
we
can
at
least
create
the
repository
right.
There's
no
blocker
on
creating
the
repository.
E
Right
and
who
owns
the
repositories,
but
I
think
at
this
point
the
platform
team
would
be
comfortable.
I
mean
speaking
for
everybody,
there
would
be
comfortable
taking
on
those
repositories,
at
least
in
the
interim.
E
D
E
Yeah
seem
a
little
surprised
that
they're
on
so
we
we
have
been
talking
about
the
publisher
kind
of
in
the
same
context.
E
You
know
where
the
publisher
is
another
sort
of
utility
for
platforms,
right
or
or
platform,
tooling,
is
what
we're
kind
of
calling
it
and
publisher
is
one
of
the
things
that
sort
of
came
to
our
mind
as
well,
when
we're
having
conversations
about
the
preparer
and
the
cosigner
or
signer
functionality.
E
I
think
part
of
the
rfc
was
the
idea
of,
and
and
this
was
all
kind
of
in
that
track
of
work
of
trying
to
remove
the
dog.
The
doctor
damon
support
right,
and
so
it
was
where
the
exporter
would
essentially
export
to
only
two
mechanisms
which
would
be
the
registry
and
oca
layout.
E
And
then
you
would
have
a
another
mechanism
called
a
publisher
that
would
more
or
less
be
things
that
pac
would
do
and
other
platforms
would
do
as
well,
which
could
then
put
him
into
dr
damon
and
or
any
other
sort
of
areas
or
locations
that
we
might
deem
necessary
in
the
future.
D
B
E
F
F
F
Was
left
and
but
yeah,
I
know
all
these
stuff
are
related.
We
have
the
rfc
to
export
to
oci
format.
That's
one
that
it's
there.
It's
still
on
draft,
but
I
can
remember
also
is
what
things
were
pending
based
on
that
one
exporting
to
oci.
We
have
that
option
that
javier
is
mentioning
that
will
help
to
remove
the
daemon,
because
lifecycle
will
only
export
to
oci
layout
and
then
pack
or
any
other
platform
can
do
something
with
it
and
deal
with
the
demon.
F
If,
if
it's
that
what
we
want
and
then
we
have
the
other
option,
that
sam
is
mentioning,
we
keep
the
demon,
we
save
the
metadata
somehow
some
other
way,
and
then
we
offer
the
the
features
to
platform
to
put
things
together
and
push
to
a
registry.
If
the
user
save
it,
I'm
not
sure
which
one
are
we
gonna
do
if
we're
gonna
we
if
we
can
do
both
or
which
were
the
cons
or
or
the
things
open,
I
will
take
a
look
on
the
roc
and
comments
and
see.
E
E
But
I
do
recall
that
at
some
point,
if
I'm
not
mistaken
from
the
implementation
team,
the
lifecycle
wanted
to
remove
the
the
docker
demon
right
like
that
was
a
a
goal
or
hope.
I
think
a
lot
of
this
comes
with
juan
right
and
the
platform
team
trying
to
figure
out
whether
or
not
we
could
alleviate
some
of
that
or
help
in
that
regard
by
shifting
that
responsibility
over
the
platform
side
of
things.
E
So,
ultimately,
I
think
it
really
depends
on
the
answer
of
or
the
request
of
the
implementation
team
right,
so
the
implementation
team-
I
don't
know
if
they've
changed
their
mind
on
whether
they
want
to
keep
the
doctor
damon
support
or
not.
But
if,
if
we
build
this
right
and
then
there's
still
dr
damon
supporting
the
life
cycle,
then
that
just
kind
of
creates
some
sort
of
misalignment
there.
So
maybe
it's
really
up
to
the
implementation
team
to
give
us
a
little
guidance.
A
E
Would
we
consider
it
a
platform
or
an
implementation,
rfc
right,
because
no
matter
what
we
still
have
sort
of
that
designation.
A
E
Yeah,
and
and
to
some
degree,
I
want
to
understand
what
the
goal
is
right.
It
seems
like
there's
various
goals.
One
of
the
goals
is
to
align
the
daemon
functionality
or
set
of
features
with
registry
right.
We
talk
about
annotations,
we
talk
about
some
attributions
and
so
forth
that
are
at,
I
believe,
a
manifest
level
and
that's
something
missing.
Obviously,
from
the
doctor
daemon
then
there's
another
goal,
which
is
basically
removing
the
complexity.
That's
built
into
the
life
cycle,
for
the
daemon
support
are,
are
those
the
the
two
goals?
E
Okay,
so
those
are
the
two
goals
of
the
rfc
that
we're
trying
to
satisfy,
so
the
implementation
team
does
want
to
remove
the
complexity
of
the
dr
daemon
support
that
I
feel
like
that
one's
not
like
a
straight
answer
right.
I
feel
like
there's
a
little
bit
of
waffling
right
as
to
whether
or
not
we
want
to
do
that.
A
I
mean
I
can't
speak
on
behalf
of
all
the
other
implementation
maintainers.
I
personally
feel
like
getting
rid
of
the
demon.
Complexity
would
be
good
for
the
project,
making
things
simpler
in
the
spec
having
fewer.
If
cases
and
special
features,
I
think
is,
brings
the
functionality
of
the
life
cycle
in
the
direction
we
want
to
go,
which
is
more
straightforward.
B
E
E
E
Are
there
any
specific
features
that
the
life
cycle
needs
from
the
daemon
either
currently
or
going
forward?
Because
I
know
that
we
were
talking
about
the
dockerfile
stuff
at
some
point,
whether
that
would
use
conoco
or
execute
them
against
the
daemon
itself.
I
don't
know
again
too
much
of
the
details
there,
but
is
that
something
we
foresee
being
a
requirement.
B
C
Logic
to
facilitate
the
platform,
just
invoking
the
docker
daemon
with
the
docker
files
that
it
wants
to
use
to
you
know
it
like
kind
of
cost,
not
involved.
You
know,
even
like
the
life
cycle
shouldn't
be
involved
at
that
point
right.
It's
just
here
platform
here
are
some
docker
files
run
them
right.
A
I
feel
like
we
can't
have
a
hard
dependency
on
the
docker
demon
like
the
life
cycle.
Cannot
pack
can
have
a
hard
dependency
on
the
docker
demon,
because
that's
the
tool
it
chooses
to
orchestrate
its
containers
right.
That's
where
it
runs
the
life
cycle
phases,
but
there
are
other
platforms
that
run
kubernetes
or
don't
have
a
dependency
on
the
daemon.
So
I
feel
like
the
life
cycle,
because
the
life
cycle
can't
depend
on
the
demon.
E
E
About
it,
the
creator
workflow
with
files
that
still
not
knowing
a
lot
of
the
intimate
details
between
the
dockerfile
implementation
or
in
the
dockerfile
implementation.
How?
How
would
that
work.
A
E
Cool
all
right,
then
yeah
that
that
makes
me
feel
more
comfortable,
then
so
the
only
downsides
and
again
what
we'll
kind
of
play
with
this
through
the
rfc
process,
but
would
be
probably
any
performance
implications
or
inconveniences
right,
so
performance
implications
of
exporting
to
something
like
oci
layout
and
then
having
to
take
that
and
load
it
into
the
daemon
or
having
to
spin
up
ephemeral
registry
proxy
or
something
like
that.
That
could
be
another
sort
of
challenge.
E
I
know
there
there's
been
discussion
of
things
like
the
the
spring
boot
plug-in
right
and
sort
of
the
inconvenience
there.
If
we
were
to
remove
the
dam
and
support
from
the
life
cycle,
that
one
seems
a
little
bit
more
challenging,
but
I
don't
know
that
we
should
sort
of
take
responsibility,
responsibility
for
for
the
spring
boot
implementation.
E
B
A
I
feel
like,
as
we
design
this
solution
for
pack,
we
should
reach
out
to
the
maintainers
of
that
plug-in
to
make
sure
whatever
we're
working
on
works
for
that
platform
as
well.
A
B
H
It's
very
similar.
Yes,
it's
a
java
implementation
and
it's
still
in
use
by
a
few
different
places,
and
you
know
when,
when
the
dockerfile
stuff
comes
along,
I've
been
looking
forward
to
what
I'm
gonna
have
to
do,
to
tweak
it
to
make
it
work
but
yeah.
H
I
don't
think
it's
gonna
be
any
any
difficulty
there,
because
whatever
happens
at
the
end
of
the
day,
without
I'm
still
just
it's
still
just
basically
launching
containers
and
telling
them
to
run
so
at
the
moment,
it's
using
the
creator
life
cycle,
mainly
because
that's
quicker,
because
that
way
I
don't
have
the
overhead
of
having
to
daisy
chain
like
seven
different
container
launches
together
one
after
the
other,
and
that's
my
fear.
When
we
start
talking
about
things
with
the
docker
files
like
we
can
make
it
the
responsibility
of
the
platform
to
apply
the
docker
file.
H
H
But
you
know
it's
it's
costly
to
have
to
spin
up
these
containers
and
what
you're
saying
here
is
I'll
need
to
spin
up
all
of
the
phases
to
the
point
where
the
docker
files
are
generated
and
now
I'll
need
to
basically
run
docker
stuff
to
apply
each
generated,
dockerfile
of
which
they
could
be
n,
which
is
a
bad
thing
at
this
point
and
then,
after
those
are
done
now,
I
can
get
back
to
actually
doing
the
build.
But
again,
I'm
still
not
on
the
creator
path.
H
At
this
point,
so
by
the
time
we're
done,
we
could
have
spun
up
and
launched.
Like
you
know,
a
couple
of
hundred
containers.
If
you're
unlucky
with
the
number
of
dockerfiles
that
got
generated,
I
mean
I'm
counting
the
application
of
a
dockerfile
as
sort
of
the
spinning
up
of
a
container.
It's
not
really,
but
it's
in
the
same
vein
right,
because
you're
going
to
have
to
run
all
the
different
instructions
within
it
and
if
you're
driving
that
via
docker,
it's
still
not
going
to
be
quick.
H
So
that's
that's
my
thought
there,
whereas
the
canico
stuff
we've
got
at
the
moment
at
least
internalizes.
All
of
that
and
hides
it
from
the
platform
so
that
I
just
give
it
a
poke
and
it
comes
out
and
it's
done
the
business
and
I'm
happy
and
I
step
away
at
the
end,
and
that
makes
me
as
a
platform
you
know
person
a
lot
happier
with
my
implementation.
It
also,
I
hope,
would
mean
that
there
will
be
less
variation
between
implementations
between
platforms,
because
you
know
once.
I
H
E
And
to
get
your
take
on
the
other
part
of
the
conversation
or
change
that
we're
thinking
about
is
what
implications
would
you
run
into
if
we,
the
lifecycle,
were
to
remove
daemon
support
right
and
the
only
ways
that
you
could
export
or
your
for
your
processor
plug-in,
would
be
oci
layout
or
osa
registry.
H
I
can't
really
speak
to
that
much
because
the
usage
info
that
I've
got
back
at
the
moment
doesn't
really
speak
either
way
as
to
which
one
people
are
using.
I
mean
it's,
it's
demon
is
the
default
just
because
it's
quick
and
it
gets
the
job
done,
but
I
think
at
the
end
of
the
day
providing
it
works
if
it
was
something
that
was
affecting
all
of
bill
pack's
moving
forwards.
It's
not
something
I
would
fight
against.
You
know
I
mean
because
it's
like
this
is
a
direction.
E
So
so
I
think
I
know
sam
gave
us
a
time
check,
but
I
just
want
to
make
clear
ozzy
that
what
this
ultimately
would
mean
would
be
that
newer
builders
with
newer
life
cycles
wouldn't
have
well.
I
guess
newer
platform
apis
as
well,
wouldn't
have
daemon
support,
so
you
would
output
to
let's
say
oci
layout
and
then
you
would
have
a
secondary
process
to
essentially
feed
that
into
the
daemon.
E
H
Yeah
I
mean
that's
doable.
You
could
almost
see
that
as
an
extra
I
mean
if
it
was
an
extra
life
cycle
binary.
That
was
tagged
on
the
end
that
was
sort
of
like
that
took
the
argument
of
the
demon,
and
then
it
could
take
the
image
and
put
it
in.
So
it's
still
a
provided
thing
and
it
wouldn't
be
something
as
a
platform
creator.
I'd
have
to
write
much
to
do.
It'd
just
be
another
documented
invocation
of
a
a
given
executable
with
arguments
that
I
can
derive
from
the
existing
platform
invocation.
A
H
I
mean,
if
that's
the
fact
that
I
can
go
that
way:
yeah
yeah,
whichever
is
easiest
at
that
point.
Doesn't
it
but
it's
I
I
mean
I
wouldn't
want
to
call
down
to
the
cli
and
invoke
the
equivalent.
D
B
H
H
D
Yeah,
I
think
that's
why
the
publisher
was
supposed
to
do
the
things
the
other
way
around.
It
was
life
cycle
still
just
published
to
the
damon,
and
if
you
wanted
to
publish
back
to
the
registry
with
all
the
required
information
you
had
that
publisher,
because
then
it's
a
complex
thing,
then
just
talk
a
load.
A
D
The
life
cycle
exists
as
it
does
today.
It's
just
to
get
it's
just
so
that
features
like
annotations
or
signatures
are
not
blocked.
When
you
use
the
daemon,
that's
that's
the
part
that
the
publisher
covers.
So
if
you
export
an
image
with
annotations
that
information
is
currently
lost
when
you
export
to
the
daemon,
if
you
still
want
that
information,
when
you
publish
to
the
registry,
you
just
use
the
publisher
binary.
So,
instead
of
doing
publish,
you'll
do
back,
publish.
A
G
Hey,
I
suppose
I
should
just
summarize
where
we
are
wrote
the
rfc
I
haven't
updated
the
rfc,
obviously
in
a
few
weeks,
but
we
presented
some
options
from
the
rfc
to
to
folk
and
there
was
one
particular
route
that
people
wanted
to
go
down,
which
was
to
better
look
at
having
some
kind
of
third-party
scaffolding
tool
that
we
could
plug
into
to
pack
in
order
to
generate
these
things,
so
I've
been
playing
around
with
with
that
playing
around
I've,
been
developing
a
third-party
tool
which
is
designed
to
plug
into
pack.
G
So
I
mean
right
now
where
it
is
right
now
is
sambhav
was
kind
enough
to
do
a
design
and
code
review
earlier
on
this
week.
I
now
have
a
list
of
11
different
things
to
fix.
G
He
was
being
kind
of
me
and
once
I've
got
those
11
things
done
I'll
consider
at
least
the
interface
good
enough
to
be
able
to
revisit
the
document
effectively
describe
the
interface
in
the
document
and
and
we're
still
in
a
position
where,
if
this
is
not
the
route
that
we
want
to
go
down,
then
there
are.
There
are
the
the
other
options
in
the
document.
Are,
are
reasonable
things
to
choose.
G
So
I
suppose
that's
where
we
are
with
this.
At
the
moment,
I've
got
a
few
hours
tomorrow
to
hopefully
address
some
of
those
11
things
and
update
the
document,
but
yeah.
G
There
is
some
progress
being
made
on
it,
and
please
shout
at
me
and
tell
me
if
there's
anything
you
want
to
see
in
particular,
I
should
say,
as
I've
gone
along,
I've
been
trying
to
make
sure
that
I
keep
the
documentation
reasonably
clean,
because
there's
absolutely
no
point
in
us
having
a
an
onboarding
tool
that
doesn't
have
good
documentation.
G
A
This
is
a
trustworthy
third
party
for
us
to
take
a
dependency
on.
G
I
mean
there's,
I
think,
that's
a
reasonable
question
more
than
reasonable
question
to
ask.
I
mean
we
don't
want
to
take
on
the
dependency
ourselves.
Then
the
question
is:
who
do
we
trust?
I
know
there
are
a
bunch
of
organizations
that
might
be
interested
in
taking
something
like
this.
E
I
am
curious
just
for
sort
of
make
sure
I
I
paint
the
right
picture,
so
this
is
sort
of
like
a
standalone
utility
like
cli
and
library
and
how
we
envision
how
to
leverage.
This
would
be
through
a
sort
of
like
library,
functionality
where
it
would
just
inherit
the
functionality
that
it
provides,
but
within
pack
itself
is
that
right.
G
Yes,
so
that
the
pax
cli
would
invoke
the
library
in
some
way
to
create
new
projects,
so
the
way
you're
currently
doing
pack
build
pack
new
instead
of
invoking
the
code,
that's
currently
with
impact,
it
might
call
out
to
such
a
library
and
and
get
it
to
just
generate
the
project.
For
us.
G
So
yeah,
if
you
look
at
the
documentation,
there's
some
talk
about
overrides
in
it,
and
these
are
things
that
would
be
passed
from
pac
into
this
library.
So
if
you
want
a
specific
api
version
in
in
the
something
or
if
you
want
a
specific
string
somewhere,
then
the
it's
designed
so
that
you
can
pass
things
in
this
is
one
of
the
things
that
interface
is
something
that
is
going
to
change
over
the
next
few
days,
because
there
are
nicer
ways
of
doing
it.
G
Yeah
I,
unless
there
are
other
comments
I
I
mean
I
don't
we
can
return
to
the
previous
arguments.
A
I
guess
if
we
have
some
extra
time,
maybe
I'll,
throw
it
another
topic
out
at
us,
which
is,
I
think,
like
a
meta
topic
about
this
meeting.
I
feel
like
one
of
our
goals
recently
has
been
to
enable
the
teams
more
to
make
progress
without
running
everything
through
the
top
level
of
the
project
and
that's
exciting,
and
I
want
to
support
that.
But
I
wonder
if
more
action
is
happening,
sort
of
in
teams
and
at
team
sinks,
whether
we
want
to
move
I'm
curious
about,
maybe
like
setting
up
a
rotation
where
teams
then
present.
E
Could
you
give
us
an
example
of
what
that
may
look
like
that's
different
than
just
you
know
very
similar
to
the
release
updates
that
we
do
on
other
meetings.
A
I'm
thinking
more
around
sub-team,
rfcs
and
stuff,
like
that,
just
sort
of
like
giving
a
highlight
like
here's
the
problems,
this
team
has
been
wrangling
with
and
we're
thinking
about,
moving
these
rc's
to
a
vote
soon.
A
You're
the
priorities
for
the
sub
team,
like
it
doesn't
have
to
be
every
week
like
every
team
is
more
like
you
know,
would
each
team
want
to
go
once
a
month
and
be
like
just
for
those
who
aren't
deeply
involved
in
platform?
Here's
like
what's
going
on
here.
E
Maybe
I'll
just
I'll
speak
for
myself
somewhat
selfishly,
but
I
think
that
if
I
care
about
what's
going
on
in
a
particular
sub
team,
I
would
go
to
their
sub
team.
You
know
sync,
I
guess
for
me-
and
maybe
I'm
just
asking
like
for
everybody's
time,
to
be
sort
of
respected,
like
I
find
more
value
in
these
meetings,
be
more
like
high-level
or
very
cross-cutting,
as
opposed
to
being
team
specific.
B
D
If
you've
tried
doing
this
for
some
of
the
bad
topics,
we
often
discuss
at
first
in
this
obtain
meetings
and
then,
if
we
think
that
this
impacts
the
community
at
large
or
if
you
want
to
get
a
wide
opinion,
we
try
to
bring
it
up
here
in
the
working
group
again
like
to
give
you
some
examples.
We've
talked
about
structured
logging
first
in
the
back
sync
and
then
in
the
working
group.
The
reason
builder
can
fix
stuff
first
in
the
back
sync
and
then
the
working
group.
D
A
summary
of
those
discussions
in
the
working
group
to
get
people
to
join
back
in
or
provide
feedback,
but
I
don't
know
if
every
team
would
have
things
like
that.
Like
hey,
I
don't
know
what
like
distribution
team,
for
example.
I
don't
even
know
what
what
kind
of.
D
E
Yeah,
I
think,
definitely
for
conversation
pieces
right.
I
think
that
seems
like
the
right
approach.
I
do
want
to
maybe
ask
forrest
to
your
to
your
point
like
if
there's
a
better
way
of
bubbling
those
things
up
or
providing
that
sort
of
visibility.
E
I
guess
is
the
right
term
without
having
to
be
somewhat
what
sounds
to
be
almost
like
forceful
of,
like
hey
you're
gonna
present
this
month,
right,
like
your
team's
gonna
present
this
month
like
come
with
something
to
to
say
because
again,
a
lot
of
things
and
a
lot
of
conversations
happen
right
within
that
month,
like
maybe
force
cared
about
something
that
happened
on
the
first
week,
but
it
was
so
fast
that
you
know
it's
no
longer
relevant
by
the
time
your
your
month
comes
up.
I
I
can
obviously
see
previous
week's
discussion
topics
and,
like
the
sub
team
document,
that
there
is,
but
I
don't
necessarily
know
if
there's
a
great
way
of
me,
seeing
that,
like
in
an
asynchronous
fashion
like
you're
talking
about
and
if
there
is
I'm
just
ignorant
to
it,
and
so
maybe
having
some
device
like
putting
a
link
on
your
community
page
to
where
that
would
be,
would
be
sufficient.
I
Unless
so,
I
guess
that's
what
I
would
say,
having
a
direct
link
to
the
agendas
of
various
sub
teams
in
some
place
that
can
be
like
you
know.
If
I
drop
in
on
slack
and
say,
hey
I'm
looking
at
this,
then
you
could
say
oh
great
well,
the
sub
team
is
talk.
Is
thinking
about
talking
about
that
here.
Here's
a
link
to
that
agenda.
That
could
be
something
nice.
E
Yeah
and
what
I'm
hearing
as
well
is
something
that
I
think
we've
been
pretty
poor
of
doing
in
other
sub
team
meetings,
but
I
think
we
do
fairly
well
in
working
group
is
setting
the
agenda
beforehand
right.
I
think
that's
something
that
would
bring
a
lot
of
value.
It
is
hard
to
do
right
like
we.
We
even
find
it
hard
to
do
on
the
working
group
sometimes,
but
it
seems
like
that
would
bring
about
a
lot
more
value
so
that
that
way
you
can
choose
ahead
of
time.
I
I
think
that
that's
the
biggest
piece
of
feedback
that
I
get
from
my
team
currently
is
that
they
they
already
have
a
lot
of
commitments
to
meetings,
and
they
don't
necessarily
want
to
make
another
one.
If
it's
not
going
to
be
relevant
to
them.
So
being
able
to
find
the
relevance
would
be
perfect.
E
Yeah,
I
would
be
in
favor
at
least
for
some
of
the
meetings
that
I
either
facilitate
or
partake
in
to
say
that
if
we
don't
have
an
agenda
item,
we
should
just
cancel
that
meeting
ahead
of
time.
I
know
some
other
communities
sort
of
take
that
pretty
strong
stance
as
well,
and
I
find
that
to
be
somewhat
successful
in
their
communities.
A
Well,
maybe
that's
something
that
we
can
maybe
the
first
version
of
this
is
just
a
request
to
all
the
sub
teams,
to
think
about
how
we're
bubbling
up
information
and
be
organically
conscious
of
that
and
then
and
setting
agendas,
and
then
see
how
that
goes.
E
Yeah,
I
think,
being
a
little
bit
more
loud
about
upcoming
meetings
and
being
a
little
bit
more
forceful
of
requesting
agenda
items
before
the
meetings
is
something
that
at
least
I
would
take
as
an
action
item
and
try
for
at
least
the
platform.
Sync,
I
think
learning
is
something
I
no
longer
am
responsible
for.
D
E
Yeah
and
then
I
I
want
to
also
maybe
talk
about
something-
we've
recently
been
pushing
a
little
bit
more-
is
for
like
autonomy
of
independent
teams
right,
so
I
think
it's
good
to
maybe
have
the
soon
to
be
leads.
Maybe
take
ownership
of
that
sort
of
the
ask
being
hey.
How
do
we
bubble
stuff
up
and
then
the
leads
could
try,
whatever
feels
more
appropriate
for
their
teams.