►
From YouTube: Working Group: 2020-12-03
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
A
So
for
those
of
you
who
weren't
there
yesterday,
I'm
working
on
a
a
couple
rounds
of
user
research
that
I'd
like
to
do
to
help
support
the
project
to
grow,
in
particular,
to
identify
some
of
the
challenges
that
app
developers
experience
when
trying
to
make
the
transition
to
build
packs
and
also
some
of
the
challenges
that
build
pack
authors
face
when
maybe
they
don't
actually
want
to
be
build.
A
Pack,
authors
they're
just
app
developers
who
want
to
add
some
file
to
their
app
or
do
something
really
simple
or
maybe
even
something
more
complicated.
But
we
know
that
build
pack.
Authorship
is
a
challenge
right
now
with
the
v3
spec
so,
but
before
we
kind
of
dive
into
that
topic,
that's
sort
of
the
second
half
of
the
brainstorm,
but
the
first
thing
I'd
like
to
just
talk
about
is
like
it
was
just
like
dream,
really
big
and,
like
think
very
blue
sky.
A
So
we
have
the
budget
to
talk
to
15,
to
25
users
to
help
advance
the
project.
If
we
could
learn
absolutely
anything
that
would
help
guide
us
in
making
cnbs
grow
and
become
like
the
dominant
containerization
tool.
What
we
want
to
learn
so
there's
no
wrong
answers.
I
encourage
you
to
go
for
volume
and
we'll
I'll
set
up
a
timer
for
like
five
minutes.
We
can
brainstorm
answers
to
this
question.
Please
just
feel
free
to
write
directly
in
here
and
yeah.
A
A
A
A
Okay
about
one
minute
left
so
keep
keep
pushing
get
all
your
thoughts.
A
A
A
A
A
A
All
right,
that's
the
timer.
This
is
awesome
that
we
have
so
many
folks
here
and
so
many
ideas.
The
discussion
might
take
a
little
bit
longer
than
10
minutes,
but
I
think
that's
kind
of
more
important
than
this
good
proxy
for
build
packs.
Authors
thing.
A
So
why
don't
we
go
around
and
do
a
a
popcorn
style
and
just
tell
us
sort
of
your
highlight
what
you
your
top
thing,
that
you
would
most
like
to
learn
out
of
the
things
that
you
wrote
and
as
we're
going
I'll,
do
some
organizing,
let's
start
with
sophie
it's
right
below.
B
Yeah,
so
the
one
I
put
up
there,
I
forget
exactly
where
it
is,
but
I
was
wondering
like
what
documents
or
reference
do
you
look
at
when
you're
using
build
packs,
and
what
do
you
find
helpful
when
you're
trying
to
use
the
build
packs
and
is
there
anything
that
could
be
improved
to
make
your
experience
a
little
bit
more
clear.
A
Cool
cool
yeah
and
if
anyone
has
like
similar
things
that
they
want
to
jump
in
and
add
on
with
or
want
to
ask
a
follow-up
question.
This
is
definitely
a
discussion
so
sophie
you
can
popcorn
someone
else.
C
I
asked
what
languages
do
you
want
supported
just
make
sure
that
we're
covering
all
the
cases
that
people
actually
want
and.
C
I
also
asked
like
oh
how
do
you
currently
build
your
images
just
to
see
what
their
current
workflow
is?
Because
I
think
a
lot
of
people
have
like
really
bespoke
image
building
like
situations
and
it's
interesting
to
see
like
how
different
corporations
or
different
like
organizations
like
build
their
images
and
then.
C
Do
developers
plan
on
it's
kind
of
the
same
thing,
but
do
developers
build
their
own
images
for
prod
or
does
a
separate
team
other
than
developers
build
the
images
just
to
kind
of
get
more
of
a
like
a
sense
of
like
what
they're
currently
doing
and
to
see
like
if
they
like
that
or
not
stuff
like
that,.
A
Yeah,
what
what
is
it
about
those
two
questions
that
like
might
help
inform
the
features
for
cmd
lifecycle.
C
I
guess
just
to
make
sure
I
I
mean
that's
a
good
question.
I
I
would
just
want
to
like
make
sure
that
we're
like
to
see
like
what
they
like
and
don't
like
about
their
current
process.
C
I
guess
and
to
see
that
like
what
we
should
keep
out
of
like
a
current
process
and
what
we
like
should
try
to
improve.
E
A
question
comes
up
like
should,
should
be
as
similar
as
possible
to
the
docker
cli
like
what
is
like
if
we
use
these
domain
concepts
or
similar
usage
with
that
help
of
people,
because
this
is
something
they're
very
familiar
with.
Or
is
that
confusing?
Because
a
lot
of
the
target
audience
like
these
would
be
new
concepts
that
have
to
learn
about.
So,
I
think
just
getting
a
sense
of
how
comfortable
people
are
with
these
tools
and
concepts
would
help
us
make
good
decisions
in
the
ux.
A
Awesome
yeah,
I
love
these.
These
super
detailed
ones
or
the
more
low
level
ones
are
actually
super
helpful.
Popcorn.
E
Yeah
joe.
F
Popcorn,
thank
you.
I
think
mine
would
be
very
similar
to
emily's,
except
I
would
expand
it
out
to
the
cloud
native
ecosystem,
like
I'm
I'd
like
to
know
for
the
typical
user
or
what
the
spectrum
is
with
of
their
familiarity
with
the
broader
ecosystem.
F
A
Yeah,
what
are
some
other
to
get
a
little
bit
more
specific
there
other
than
kubernetes
the
big
one?
What
are
some
of
the
other
things
in
the
ecosystem?
You'd
like
to
know
if
people
are
comfortable
with
or
aware
of.
F
Docker
generally
too,
like
what's
their
comfort
level
with
docker,
what's
their
comfort
and
I
think
that's
kind
of
what
what
emily
was
saying.
Is
there
anything
other
than
kubernetes?
It's
just
all
kubernetes.
F
I
mean
kubernetes
is
like
the.
I
think
that
would
indicate
a
lot
about
the
other
things
I
mean
we
could
ask
about
something
like
helm
or
probably
another
good
one.
A
F
I
think
all
of
it,
I
think,
I'd,
be
curious
to
know
you
know
on
the
spectrum
of,
I
know
how
to
use
kubernetes
or
deploy
an
app
or
whatever
to
I
know
how
to
operate.
Kubernetes,
I'm
just
curious
where
our
users
fall
in
that
spectrum
by
and
large.
D
D
G
All
right:
well,
I
didn't
actually
write
it,
but
I
was
thinking
about
it
and
mostly,
I
guess
it
kind
of
ties
into
some
of
like
the
pre-existing
pipelines
that
developers
might
have
and
then
how
those
would
be
migrated
into
or
start
incorporating,
cloud-native
build
packs.
G
More
specifically,
the
thing
that
I
have
in
mind
is
around
testing,
since
testing
is
not
something
that,
as
of
right
now,
is
encompassed
in
quantitative,
build
packs
as
a
you
know,
kind
of
very
direct
feature.
So
I
am
curious
if
anybody
set
up
a
pipeline,
whether
they've
figured
out
how
to
do
that
outside
of
cloud-native
build
packs
or
if
it's
a
feature
that
they
really
wish
it
had.
D
G
Obvious
or
somebody,
oh
sorry,
I
was
typing:
let's
go
with
natalie.
A
B
I
think
we
we
tend
to
make
a
lot
of
assumptions
around
what
someone
who,
when
they
learn
about
build
packs
like
what
their
maybe
objections
would
be
to
you
know.
Oh
you
know,
couldn't
I
just
use
a
docker
file
or
that
it
sounds
hard
to
customize.
I
mean
I
don't
know
like
we
hear
these
things
said
in
the
wild,
but,
like
I
just
like
to
know
what
comes
to
mind
for
people
who
haven't
who
just
like
haven't,
maybe
tried
it,
but
when
they
know
what
it
is,
what
opinions
they
form.
G
A
Cool
popcorn
somebody.
D
H
H
D
H
A
Awesome
shoot
someone
a
popcorn
just.
I
For
local
development,
that's
you
know,
sort
of
very
tight
inner
loop
development
where
you're
you're,
changing
a
line
of
source
code
and
seeing
the
app
update
you
know
are:
do
people
feel
like
their
existing
solutions
inside
of
their
you
know.
Ides
are
you
know
sufficient,
and
you
know
they
they
don't
want
to.
I
You
know
kind
of
containerize
their
workloads
as
they're
as
they're
developing
or
you
know,
should
cloud
into
build
packs,
invest
in
things
like
you
know,
tilt
and
development
orchestrators
that
that
keep
you
know,
maybe
one
micro
service
out
of
many
continually
up
to
date
with
your
local
source
code.
So
you
can,
you
can
kind
of
you
know
rapidly
develop
on
something
that's
more
complex.
I
I
think
there
are
a
lot
of
big
unanswered
questions
there
more
generally
and
it
could
be
a
place
where
we
could
provide
a
lot
of
value
because
we
have
so
much
control
over
the
development
process
or
the
build
process
for
the
containers
so,
like
I
guess
everything
jesse
said,
but
I'm
especially
interested
in
that
that
sort
of
tight
inner
loop,
rapid
update
kind
of
aspect
to
it.
D
I
And
then
popcorn
to
mcnew.
J
This
is
somewhat
related
to
what
a
lot
of
people
talked
about,
but
I
specifically
find
the
less
the
feature
angle,
but
the
communication
angle
really
interesting,
and
I
think
what
I
mean
by
that
is
for
us
to
get
new
users
to
use
or
even
investigate
cmbs.
They
need
to
understand
non-trivial
amounts
of
the
oci
docker
and
even
cmb
ecosystem.
So
when
we're
evangelizing
cmbs,
we
spend
a
lot
of
time
explaining
these
concepts
to
users,
either
via
blog
posts,
conference
talks
and
whatnot.
J
D
K
K
In
addition
to
that,
I
also
asked
like:
where
did
you
go
to
learn
more?
How
would
you
go
about
looking
for
specific,
build
packs,
searching
for
them
again
a
lot
of
lines
of
the
discovery
angle,
just
trying
to
really
gauge
from
a
customer
perspective,
how
they
learn
more,
how
what
expectations
they
might
have
or
behaviors
in
their
attempt
to
learn
more.
K
K
I'm
really
curious
that
would
that
be
valuable.
I
think
it
would
be
great
to
get
some
reassurance
on
just
you
know,
with
a
customer
by
default,
go
to
a
website
and
hope
to
find
a
easy
way
to
to
learn
more
about
specific,
build
packs
to
drill
in
more
about
specific
topics
in
general.
For
that
matter,.
A
Cool,
I
know
we're
coming
up
to
time
here.
We,
it
looks
like
we
have
one
other
thing
on
the
agenda.
L
Yeah,
so
I
had
a
lot
of
similar
thoughts
to
what
matt
and
travis
had
said.
I
mean
even
along
those
lines
of
for
discovery
like
how
do
they,
what
do
they
do
currently
for
their
current
if
they're
an
app
developer,
their
current
language
and
ecosystem,
because
I
feel,
like
you,
tend
to
follow
similar
patterns
across
like
how
you
do
development,
for
how
do
you
find
the
tools
and
things
you
like
when
you're
in
your
language
or
ecosystem
of
choice
like
for
those
things?
L
I
think
that
fits
in
line
with
that
and
again
like
the
when
you
learned
about
build
packs.
What
caused
you
to
want
to
learn
more
like
what
was
kind
of
the
at
that
tipping
point
and
then
kind
the
other
one
for
me
was
how
do
you
like?
Are
there
parts
of
if
you
were
using
build
packs
from
kind
of
the
v2
era
like?
Are
there
features,
or
things
from
that
time
period
that
when
you
kind
of
moved
over
that
are
hurdles
or
things
you're
missing?.
L
D
Experience
in
the
past,
but
yeah.
A
A
Okay,
cool
awesome:
is
there
anybody
else?
We.
D
Hi,
I
think
that
people
mostly
said
I
mean
already
talked
about
my
thoughts,
so
I
don't
have
anything
special
to
add.
I
mean
I'm
very
curious
about
the
first
time
experience
how
people
learn
about
build
packs.
What
do
they
do
in
order
to
learn
what
is
missing
for
them,
but
I
guess
you
already
wrote
about
it.
A
Okay,
awesome:
I
think
we
might
have
one
or
two
more
people
still.
D
A
Okay,
cool:
does
anybody
after
sort
of
what's
been
shared,
have
any
other
like
additional
ideas
or
things
that
this
sparks
for
them,
but
they
just
want
to
get
out
there.
D
D
One
random
question
I
had
was
whether
a
more
interactive
social
media
presence,
I.e
twitter.
C
D
Something
of
the
sort
I
don't
want
to
make
a
tic
tac
would
help
the
project
or
not,
or
is
it
something
that
they're
like?
No,
I
don't
really
object
with
us
at
all.
A
Okay
is
it
sounds
like
there's
sort
of
like
a
instinct
there
about
that.
That
might
be
a
a
entry
point
for
people
is
that
right.
D
Yeah,
just
kind
of
hanging
out
on
tech
twitter
seems
like
there
are
some
organizations
that
are
that
post
more
or
less,
and
I
just
wonder
whether
people
and
who
would
you
know,
potential
pack
or
potential
build
packs
users
would
whether
that
would
be
a
factor
for
them
or
not.
E
A
Cool
were
you
about
to
see
something
before
emily.
E
I
had
one
extra
one
I
threw
on
the
end
here,
which
is
which
of
these
statements
most
closely
match
your
attitude
towards
the
container
build
process.
It
should
just
work.
I
don't
care
how
or
I
want
to
understand
each
step
of
the
process,
because
I
know
we
have
users
on
both
ends
of
the
spectrum,
but
I'm
curious
like
we're
the
average
user
or
person
who's,
considering
using
the
tool.
A
lot.
A
L
G
G
A
Cool
awesome:
we
have
four
minutes
left.
Thank
you
for
your
patience.
One
of
the
things
I'm
pretty
confident
that
we
want
to
learn
about
is
the
buildpack
authorship
process,
because
we
need
people
to
be
able
to
write
new,
build
packs
as
easily
as
they
add
a
file
to
a
docker
image.
But
we
know
that's
not
the
case
today
and
at
the
same
time
it
may
be
kind
of
diff.
A
It's
a
little
bit
of
a
chicken
and
egg
problem
where
it's
hard
to
learn
about
people
writing
build
packs
because
there's
not
a
lot
of
people,
writing
build
packs,
and
so
it's
hard
to
make
it
easier
to
write
them.
So
who
might
be
a
good
proxy
for
build
pack,
authors
or
sort
of
more
generally
people
who
have
to
customize
or
alter
existing
build
packs
to
get
a
good
get
a
build
going?
A
So
we
could
do
a
shorter
brainstorm
here.
Let's
say
like
three
minutes
and
yeah.
Please
jam
out
your
ideas.
Who
would
who
do
we
feel
like
would
be
a
representative
person
to
talk
to
about.
D
A
Cool
this
one
is
not.
We
don't
really
need
to
discuss
this.
This
is
sort
of
relatively
straightforward.
The
last
thing
I
want
to
say
is
so
over
the
course
of
january
and
february.
There's
going
to
be
a
lot
of
interviews
to
be
done
so
for
folks
who
are
interested
in
joining
those
interviews.
A
We'll
probably
have
space
for
like
one
one
interviewer
one
note
taker
and
one
like
ride
along,
do
nothing,
but
probably
no
more
than
that
per
interview.
All
the
interviews
will
be
recorded
if
people
want
to
check
them
out
later
and
obviously
they'll
be
summarized,
and
maybe
even
like
key
tidbits
of
the
videos
will
be
brought
together
into
like
a
sizzle
reel
montage
kind
of
thing,
but
is
anybody
interested
in
being
an
interviewer
being
a
note,
taker
or
potentially
just
shadowing?
A
A
H
J
H
Sure
yeah
put
this
on
the
agenda
just
to
kind
of
have
a
maybe
a
quick
high-level
discussion,
but
yeah
so
to
level
set.
We've
got
build,
packs
that
contribute
processes,
but
there's
no
way
for
subsequent
build
packs
to
view
or
alter
those
processes,
except
for
just
pure
overriding
them,
and
I
guess
I'd
like
to
explore
how
we
think
we
could
solve
that
in
build
packs,
either
by
giving
downstream
buildbacks
the
ability
to
just
change
the
existing
launch
entries
so
that
they
can
modify
them.
H
I
think
one
of
the
canonical
examples
would
be
something
like
if
you
were
to
create
a
build
pack
for
foreman
or
something
like
that
right
and
there's
a
bunch
of
processes
that
exist
before
other
builds
packs
and
you
kind
of
want
to
like
cap
them
together
or
you
want
your
profile
to
be
executed
by
you,
know,
format,
sort
of
manager
or
something
like
something
that
manages
multiple
processes
that
run
in
a
single
container
or
something
that
ships
logs
out
somewhere.
I
I've
thought
a
lot
about
like
how
we
could
achieve
outcomes
that
allow
these
kind
of
interactions
between
you
know.
Build
packs
and
other
processes
contributed
by
other
build
packs,
and
I
think
a
hard
part
is
that
anytime,
you're
you're
talking
about
something
trying
to
modify
some
complicated.
You
know
shell
invocation
that
something
else
contributed.
I
It
gets
pretty
hairy
right,
like
you
really
can't
make
any
assumptions
about
what
that
that
string
that
got
contributed
by
the
other
build
pack
was,
you
know,
can
you
put
and
and
something
at
the
end
of
it
or
you
know?
Is
there
something
about
the
invocation
that
will
cause
that
to
mean
something
different
right
like?
Is
it
so
one
idea
I've
you
know
been
thinking
about
is
if,
in
a
later
process
you
could
reference
an
earlier
process
using
a
command
or
the
whole
previous
process.
I
It
isn't
the
string
isn't
exposed,
but
the
execution
of
it
is.
You
know,
wrapped
in
a
function
or
in
a
script
or
something
like
that
right,
but
it's
probably
not
how
we'd
implement
it
so
that,
when
you
like
imagine
imagine
a
build
tech
contributes
something
called
web
and
you're
right.
You
write
a
web
bash
script
to
path
right.
H
We
kind
of
already
do
that
with
launcher
right
sort
of
like
the
yeah
we've
already
sort
of
made
a
tiny
step
towards
making
this
easier,
because
you
can
reference
launcher
with
a
particular
process,
type
to
kind
of
wrap.
Some
of
the
the
nastiness
of
trying
to
combine
things
right.
I
H
Yeah,
I
still
think
there
might
be
room
for
build
packs
knowing
about
those
processes
and
being
able
to
explicitly
control
them
after
the
fact
like
like
right
now,
you've
got
rif
is
an
example
one
right
now
it
it
contributes
three
different
processes
and
it
contributes
a
default
process,
but
I
really
want
to
remove
those
other
two
processes
like.
I
really
only
want
one
as
the
application
developer.
H
I
Do
you
want
to
check
for
the
existence
of
other
processes
by
name
or
do
you
want
to
be
able
to
list
all
of
the
processes
you
know
from
your
process
like?
Is
it
because
I
think,
there's
a
there's,
a
big
difference
in
how
the
interface
is
exposed,
if
you
just
want
to
be
able
to
say,
delete,
web3
right
versus
okay?
What
are
the
processes
that
the
buildbacks
have
contributed
so
far,
and
then
let
me
iterate
through
those
and
do
something.
G
H
Right,
you
want
to
override
the
default,
but
you
need
to
know
which
one
is
currently
default
at
the
time
of
creation
so
that
you
can
wrap
it
appropriately
with
some
sort
of
you
know,
middleware
or
whatever
some
sort
of
proxy.
L
I
mean
maybe
this
is
a
crazy
idea,
but
what
is
the
danger
of
exposing
the
processes
between
buildbacks.
L
Well
like
so,
if
I
want
to
say
solve
jesse's
case
right
of
like
I
have,
I
riff
a
roof
bill
pack
runs
for
me
and
I
know
it
produces
some
number
of
processes,
but
I
only
care
about
one
of
them
or
something,
but
I
may
not
know
which
one
is,
except.
Maybe
it's
a
default
one
if
I'm
given,
basically
that
tamil
input
of
like
what
process
at
that
point,
when
my
bill
pack
runs,
is
like
what
is
being
set
for
launch.
I
I
think
that
there's
two
things
for
me:
one
is
if
you're
gonna,
I
don't
want
to
expose
the
command
itself
from
the
previous
build
packs.
Like
the
the
actual.
You
know,
shell
invocation,
that
they
said
this.
I
This
corresponds
to
this
process
because
I
think
it
could
encourage
somebody
to
try
to
wrap
it
right,
like
I've
seen
places
where
that
information
is
exposed
and
other
systems
get
know
used
in
unintended
ways,
if
that
makes
sense,
but
if
you
just
mean
the
names
of
the
processes
so
that
you
could
reference
them
and
like
delete
them
or
wrap
them,
or
things
like
that,
I'm
not
opposed
to
that.
If
we
need
it,
if
that
makes
sense,
but
if
we
it
does
add
complexity
right
now,
start
commands
have
to
loop
other.
I
L
I
Yeah,
just
the
contents
is
the
only
thing
I
care
about
holding
back
the.
I
worry
a
little
bit
about
creating
tightly
coupled
interfaces.
If
that
makes
sense
where,
if
you
can
expose
all
of
them,
then
you
can,
you
know,
do
things
that
depend
a
lot
more
on
very
specific
combinations
of
earlier
build
packs.
I
don't
think
there's
a
there's
not
like
a
critical
problem
in
a
particular
use
case
with
it
it
just
if
we
don't
need
it.
It
seems
safe
for
design
wise,
like
as
build
pack.
I
L
Yeah
I
I
guess
I
feel,
like
the
plan
already
feels
tightly
coupled
and
that's
like
you
already
need
to
know
the
names
for
provide
and
require,
like
the
exact
name
at
that
point.
So,
like
already,
is
some
coupling
whether
it's
like
it
came
from
the
same
company
or
like
you
know
like
we,
it's
basically
like
he
said
a
bill
packs
had
to
agree
what
that
string
was
right.
I
I
think
the
idea
behind
build
plan
is
that
it,
it
puts
all
of
the
places
where
that
coupling
exists
into
a
single
place
right,
which
is
like
everything
should
interact
through
this
particular
contract
of
arbitrary
name
strings,
and
it
does
introduce
coupling
when
you
have
very
specific
interdependencies,
but
it's
in
one
place
that
we,
where
we
can
eventually
standardize
on
those
names,
the
more
places
we
introduce
that
type
of
coupling
you
know
kind
of
like
that's.
Why?
I
I
have
the
concern,
if
that
makes
sense,
whereas
you
could
use
the
build
plan
in
order
to
communicate
about
those
process
types
through
the
through
that
one
generic
interface
and
not
have
to
deal
with
multiple
generic
interfaces,
if
that
makes
sense,
but
yeah,
it's
like,
I
think,
an
alternative
to
exposing
the
process.
Types
between
the
bill,
packs
at
all
is
using
the
bill
plan
to
communicate
information
about
the
process
types.
G
L
Yeah,
I
guess
some
of
the
some
of
the
stuff
there
I'm
thinking
about
of
like
can
we
move
this
into
the
build
plan?
Is
that
that
communications
happen
happens
during
detect?
Right
is
what
you're
referencing
stephen.
I
H
All
right:
well,
I
hey,
I
don't
mean
to
try
to
solve
it
here,
but
I
just
wanted
to
make
sure
there
wasn't
like
big
pushback
on
like
some
sort
of
interface
to
reference
other
processes
so
that
you
could
wrap
them
and
so
I'll
kind
of
I'll,
probably
loop,
javier
in
and
others
as
well
to
kind
of
start
a
start.
L
D
I
I
think
this
is
it
process,
modification
from
other
build
packs.
Last
thing:
oh
yeah,
sorry
that
you
said
what's
the
last
thing
all.