►
From YouTube: Office Hours: 2021-05-13
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
And
we
shall
record
this
week
so
that
anyone
who
misses
today
so
last
week
we
were
looking
at
quotes
things
that
we
we
heard
in
the
user
research
interviews
that
we
did
in
january
and
february.
A
So
last
week
we
reviewed
those
and
we
had
a
good
discussion
and
generated
some
insights
that
are
listed
in
a
chalkboard
to
the
right
today,
we'd
like
to
go
back
and
revisit
some
of
the
assumptions
that
we
had
at
the
beginning
of
this
process.
So
you
might
recall
back
in
january
there
were
a
couple
of
working
groups
where
we
sat
down
and
kind
of
listed
out
the
assumptions
that
we
had
or
things
that
we
thought
we
might
find.
A
And
so
we'll
be
going
over
those,
and
then
we'd
like
to
discuss
some
actions
that
we'd
like
to
take
and
what
else
we
might
like
to
learn.
A
So,
if
you'll
navigate
to
section
three,
these
assumptions
are
listed
out
here.
We're
gonna
have
sort
of
a
similar
format
to
last
week.
So
we'll
take
a
few
minutes
for
silent
reading
to
go
through
the
contents
of
this
section
and
then
we'll
have
a
discussion.
A
We'll
share
observations
that
we
have
when
the
time
is
up,
we'll
discuss
our
observations
as
a
group
and
then
we're
gonna,
pivot
and
sam
will
lead
us
into
a
more
focused
conversation
about
concrete
next
steps
that
we
can
take
as
a
project
based
on
what
we've
learned.
A
Okay,
if
not,
please
go
to
section
three:
I'm
gonna
set
the
timer
for
five
minutes.
B
Yeah
thanks
so
much
for
coming
everybody
wonderful
to
see
so
many
repeat
faces.
I
just
kind
of
wanted
to
open
it
up
and
ask
what
folks
found
particularly
interesting
what
they
had
questions
about
and
encourage
folks
as
we're
discussing
and
as
you're
reflecting
here
to
add
some
stickies
over
here
on
the
right.
C
Yes,
when
you
say
auto
generation
of
docker
files,
I
guess
I'm
wondering
you
know
how
did
that
investigation
go?
Does
that
mean
like
you,
you
pose
that
feature
to
them
and
then
they
give
a
response
or
you
give
them
a
concept
or
something.
B
Oh
actually,
it
kind
of
refers
relatively
specifically
up
here
to
in
this
behavior
with
dockerfile
section,
there's
this
homegrown
automation
section,
and
so
it's
just
sort
of
like
examples
of
how
folks
who
are
using
docker
files.
Some
teams
have
some
automation
for
that
day.
One
moment
and
sort
of
quite
a
similar
way
to
build
packs
do
where
they
they
have
like
a
make
file.
They
called
it
which
helps
them
to
sort
of
bootstrap
the
docker
file,
and
I
think
the
needs
and
opinions
of
the
team
that
they're
working
on.
D
Given
the
amount
of
people
that
had
fairly
complicated,
docker
workflows
or
using
docker
compose,
I'm
wondering
is
this
false
because
we've
bundled
it
with
oci
image
concepts
which
people
aren't
familiar
with
or
are
people
using
docker,
while
still
being
confused
by
the
cli
sort
of
like?
How
did
we
get
to
that
answer?.
B
Yeah,
thank
you
so
much
for
calling
that
one
out,
because
I
think
that's
super
unclear.
Let's
break
it
up
into
two
things.
I
think
and
there's
also
a
bit
of
confusion
here
about
like
what
does
oss
developer
mean.
I
interpreted
it
to
mean
not
like
oss
developers
who
are
working
on
oss
but
like
developers
who
are
use
oss
in
their
tool
chain.
So
basically.
B
Exactly
and
I
would
actually
yeah,
I
would
switch
that
to
say,
like
I
think
people
seem
pretty
comfortable
with
the
dark
cli,
but
not
not
with
like
the
oci
image
concepts.
Thank
you
for
clarifies
sam
yeah
for
his
hand,.
E
Yeah
just
had
a
few
observations.
I
mean
a
lot
of
these
feature.
Suggestions
seem
to
be
from
like
engineers,
which
I
assume
are
app
developers
and
not
like
managing
platforms
or
they're.
Not
operators,
and,
what's
interesting
to
me,
is
that,
as
an
operator
myself
like
there's
a
fine
line
between
having
the
ability
to
customize
the
images
you
make
versus
security.
E
So
as
an
operator,
I
don't
want
like
app
developers
who
don't
know
enough
to
make
changes
just
because
they
think,
like
okay,
something
is
not
working
I'll,
just
quickly
copy
paste.
This
stack
overflow,
snippet
and
now
suddenly,
my
app
is
working
versus
being
able
to
understand
what
it's
actually
doing
underneath
and
at
least
from
my
like
original
goal
as
to
why
I
got
into
buildbacks.
E
It
was
to
take
that,
like
I
guess,
power
away
from
app
developers
where
they
don't
have
to
think
about
this
and
they're
not
making
these
mistakes
and
a
lot
of
these
features
are,
I
guess,
trying
to
pull
us
back
into
that
same
space,
where
I
want
to
make
all
these
changes
and
to
my
image,
because
my
operator
didn't.
Let
me-
and
I
just
want
to
get
my
app
out.
E
D
Into
that
makes
a
lot
of
sense
to
me.
I
think
about
this.
A
lot
like,
as
you
come
up
with
features
like
inline,
build
packs
right
like
if
a
app
developer
can
do
anything
in
a
really
easy
way,
like
there's
a
low
chance
that
then
the
bomb
is
totally
accurate
or
that
everything
in
the
container
is
secure
right.
F
Used,
I
think,
that's
a
good
point,
but
it's
probably
also
good
to
serve
both
of
those
ecosystems,
because
I
think
people
who
use
those
escape
patches
have
a
higher
probability
of
that
should
be
like
writing,
build
packs
or
kind
of
doing
those
things
where,
when
you're
first
working
on
something,
you
just
want
it
to
work,
and
then
you
kind
of
deal
with
how
to
do
it
properly
afterwards,.
D
I
guess
to
me
the
existential
question
is
the
the
second
half
of
that
ecosystem.
The
people
who
just
wanted
to
work
and
don't
care
about
these
things
does
build.
Packs
have
enough
to
offer
to
them
that,
even
if
we
unblock
them,
they'd
be
interested
in
it,
like
maybe
the
the
killer
features
of
it
appeal
to
the
first
audience.
F
I
I
think,
paz
as
a
whole
proved
that
point
to
some
degree
right
like
the
fact
that
heroku
was
bought
at
all
or
was
a
business.
I
think
proves
the
point
that
I
mean
it
is
geared
towards.
It
was
not
originally
built
around
kind
of
the
security
stuff.
You
know
that
was
part
of
it,
but
it,
I
think,
what
made
it
popular
was
not
like.
Oh
sweet,
it's
secure
my
app
secure,
it's
like
oh
sweet.
I
can
deploy
a
thing
to
the
cloud
and
get
out
my
way.
F
I
think
there
is
a
part
of
that
even
for
containers.
That's
if
there
is
a
healthy
ecosystem
of
build
packs
and
things
that
is
curated
and
whatnot
like
being
able
to.
I
think,
like
the
spring
boot
example
right,
it's
like
being
able
to
do
a
thing
not
have
to
write
docker
file
and
have
a
container
that
is
my
spring
boot
app
is
still
highly
valuable.
E
I
guess:
should
we
focus
on
like
expanding
the
ecosystem
of
good
buildback
authors
versus
providing
escape
patches
to
app
developers
who
don't
know
what's
happening
underneath
because,
if
you're
removing
this
abstraction
layers
from
buildbacks
that
you've
built
upon
to
separate
responsibilities
and
giving
the
app
developer
like
the
control
of
buildbacks,
like
you
have
this,
you
end
up
with
this
really
complicated
api
that
the
app
developer
has
to
learn.
E
I
guess
you
can
you
can
obviously
make
them
simple
using
something
like
inline
buildbacks,
but
then
again
you
still
have
to
know
that
okay,
there's
something
called
the
launch
normal
there's.
Something
called
the
like
like.
This
is
how
I
said
processes.
This
is
how
I
set
environment
variables
and
you
add
all
that
craft
for
this
extensibility
versus
you.
Just
like
put
more
effort
into
expanding
the
ecosystem
of
good
buildback
authors,
creating
buildbacks
that
the
users
can
then
utilize.
F
All
right,
I
don't
disagree
with
what
well,
I
guess
I
think
you
need
to
do
both,
but
I
I
do
think
the
escape
patches
are
important
because
I,
at
least
for
my
experience,
with
kind
of
youtube,
build
packs
as
well
as
like,
if
they're
stuck
and
the
options
are
to
stop
using
it
and
not
continue
like.
F
I
think
there
has
to
be
a
path
for
those
people
to
kind
of
keep
going
and
on
the
complexity,
like
I
mean
I
feel
like
people
say,
docker
files
are
simple
but,
like
I
think
it's
because
people
have
learned
those
things
but,
like
you
know,
you
had
to
learn
the
difference
between
like
command
versus
entry
point
and
like
how
to
set
this
stuff,
and
I
do
think
build
packs
are
more
complex.
A
I
think
for
me
the
the
comment
about
platform
operators
and
app
developers
potentially
being
at
odds
in
their
their
desires.
It
kind
of
like
now
seems
obvious,
but,
like
I
really
get
that's
why
we
get.
We
tend
to
get
a
lot
of
feedback
that
our
documentation
is
confusing
right,
like
our
website's
hard
to
follow.
A
You
know
when
sorry,
when
maybe
we
just
like
the
the
language
that
we're
using
is
like,
maybe
it
should
be
different
for
each.
F
E
G
E
E
What
I
also
found
interesting
was
that,
like
this,
this
point
around
users
expect
reproducibility
on
local
versus
ci,
like
from
personal
experience.
I've
found
that
to
be
a
major
pain
point
of
app
developers
where
they
were
trying
to
do
something
locally
and
it
didn't
work
out
the
same
way
on
the
platform
once
they
deployed
it.
So
I'm
also
surprised
that
that
was
like
not
a
true
assumption.
B
B
A
B
A
B
Yeah
yeah,
so
so,
at
this
stage
of
the
process,
we've
kind
of
like
we've
gone
through
most
of
the
findings.
B
We've
gone
back
to
our
initial
assumptions,
which
actually
you
know,
came
out
of
a
session
quite
like
this,
where
we
were
brainstorming,
what
do
we
want
to
learn
and
one
of
the
things
that
is
really
important
for
me
and
the
reason
that
natalie
and
I
decided
to
do
this
session
this
way-
is
that
we
really
want
you
all
as
participants,
stakeholders,
maintainers
contributors
to
the
project,
to
really
define
the
next
steps
and
use
your
knowledge
of
the
code
base,
use
your
knowledge
of
our
users
and
then
and
to
to
really
decide
what
actions
should
we
take
based
on
what
we've
learned,
so
I
might
actually
pull
a
little
bit
of
an
audible
here
and
ask
for
maybe
a
quick
like
three
minute
brainstorming
session
and
ask
folks
to
write
down
like
what
action
do
you
believe
we
should
take
based
on
what
we've
learned
an
action
might
be
something
around
like.
B
What
do
we
want
to
explain
better
that
we
have
today,
or
it
might
be
something
new
that
we
want
to
build
or
explore
building
so
would
folks
be
up
for
that.
Does
that
sound
good.
B
All
right
so
I'll
set
a
little
timer
here
for
three
minutes,
and
oh,
do
you
know
how
to
do
it?
You
know
how
to
do
it
better
than
me
now.
Natalie.
Do
you
mind
setting
it
and
yeah
use
the
chalkboard
space
over
here
on
the
right?
That's
your
workspace
and
yeah,
throw
down
as
many
ideas
as
you
have
in
three
minutes
and
then
we'll
we'll
talk
more
about
what
we've
learned
and
what
we
actually
want
to
take
forward.
B
Okay,
great,
no,
I
think
I
want
to
I
want
to
ask:
maybe
let's
kind
of
go
around
in
a
in
a
circle
a
little
bit
here
and
I'll
sort
of
prompt
folks
to
share,
and
you
could
either
talk
a
little
bit
about
an
action
that
you
wrote
down,
that
you
think
is
interesting
or
something
that
someone
else
wrote
that
you
think
is
interesting
or
sort
of
going
back
up
to
the
top
here
around
some
of
the
topics
and
possibilities.
B
We
discussed
last
time
I'll
drag
those
down
here
so
yeah
and
if
you,
if
you
feel
so
bold
and
you
want
to
commit
to
an
action
and
say
I
will
take
this
forward,
I
would
love
to
hear
that
as
well.
So
why
don't?
We
start
with
javier
gotcha.
H
What
me
I
feel
like,
I
wasn't
paying
attention
in
class
all
right,
so
the
one
that
I
wrote
down.
Actually,
no
I'm
gonna
focus
on
the
one
that
I
found
really
interesting.
H
So
there's
this
one
right
here
where
it
says
better
error
messages,
debugging
for
app
devs
right
and
it
talks
about
error
messages
and
it
kind
of
like
points
to
rust's
examples
there,
and
I
think,
we've
talked
about
this
in
the
past,
and
we've
we've
acknowledged
that
this
can
be
improved,
but
we've
never
really
taken
any
action
on
it,
and
so
I
I
don't
know
like
I
just
want
to
kind
of
point
it
out
like
it
would
be
really
really
nice
if
people
didn't
have
to
go
elsewhere
to
search
for
information
right
like
it
would
be
nice.
H
If
you
know,
detection
failed
right
and
it
didn't
just
tell
you,
detection
failed
right,
like
it
told
you
like.
This
is
why
detection
failed
right.
It
gave
you
like
some
hints
to
like
either
where
to
go.
Look
for
documentaries
like
even
just
pointing
to
a
url
where
we
could
manage
and
explain
that
better
or
just
kind
of
give
as
much
more
detail
as
possible
to
try
to
troubleshoot
that
on
your
own.
E
If
we
could
somehow
expose
that
metadata
in
a
way
that
platforms
can
understand
that.
Okay,
this
buildback
looks
at
this
file
of
this
environment
variable
when
it's
detecting
things.
We
could
provide
better
error
messages
or
even
suggest
buildbacks
to
users
so
like.
If
you
find
this
file
in
the
application
directory,
you
can
say
hey.
We
found
this
buildback
that
looks
at
this
file,
maybe
you're
interested
in
this
buildback.
H
That's
really
interesting.
It
reminds
me
of
like
vs
code
right
when
you
open
up
a
file,
and
it
tells
you
like
hey.
Did
you
want
to
install
this
plugin
for
this
file
format
right
and
obviously
it's
it's
doable,
if
you
think
about
the
registry
having
additional
metadata
and
then
just
being
able
to
query
the
registry
in
in
some
form
or
fashion
and
then
just
be
like,
we
found
these
three
build
packs
that
might
might
help
or
something.
E
Yeah
and
it
doesn't
have
to
be
a
part
of
the
normal
detect
process,
maybe
like
if
the
detect
fails.
You
say
that
okay,
like
none
of
the
existing
builders
or
build
packs
you're
using,
are
detecting
your
application.
You
want
to
do
some
extensive
search
on
the
registry
that
for
buildbacks
that
may
detect
your
application.
Then
it
runs
through
so
it
suggests,
like
hey.
I
found
these
build
packs.
E
You
want
to
try
any
of
them
and
then
vice
versa.
If
it
finds
certain
environment
variables
or
file
set,
which
the
build
packs
in
your
existing
build
do
use.
It
can
say
that
hey
this
was
like
a
slight
typo
or
spelling
error,
or
it
expects
this
to
be
one
of
these
enum
strings
or
whatever
it
can
get
crazy.
I
imagine,
but
I
wonder
if
we
can
expose
some
like
more
metadata
from
the
buildback
to
the
platform,
so
that
I
can
do
these
sort
of
things.
A
This
is,
I
think,
maybe
only
slightly
related,
but
it
came
into
my
mind
as
we
were
talking,
which
I
think
a
while
back.
Someone
on
our
team
suggested
the
idea
of
a
dry
run
for
pack,
where
you
could
basically
just
see
the
build
pack
that
would
get
generated,
build
plan
that
would
get
generated.
You
know,
so
you
could
see
what
order
the
build
packs
are
running.
What
dependencies
they're
requiring.
I
feel
like.
Sometimes
it's
a
little
bit
of
a
mystery.
A
D
I
wonder
if
we
could
add
in
some
of
our
results
like
ways
to
for
buildbacks
be
more
self-documenting
like
if,
when
you
return
your
detect
result
from
your
build
pack,
there
was
like
a
optional
reason
field
where
you
could
describe
either
why
you
detected
or
why
you
didn't
detect.
B
There's
some
really
cool
ideas
here.
Just
for
the
second
time
I
want
to
move
us
on
a
little
bit.
I
I
I
So
how
why
we
can
make
that
problem
very
clear
to
the
people
that
comes
into
our
website
and
try
to
understand
what
we
are
doing
so
put
that
clear,
because
I
can
be
on
a
startup
and
I
want
to
do
it.
You
know
I
want
to
put
my
product
faster
in
the
market,
but
if
I'm,
if
I
don't
start
in
a
good
with
with
good
practices
and
try
to
avoid
problems
in
the
future,
probably
I
will
face
it.
I
can
say:
okay,
I'm
a
startup.
I
I
I
will
care
about
that
when
my
product
gets
success
but-
and
there
are
companies
that
already
have
the
problem-
and
I
don't
know
if
they
can
go
to
our
website
and
and
says
okay,
I
have
this
problem.
Yes,
I'm
running
many
applications
and
containers,
and
I
I
have
this
issue
when
I
want
to
patch
them
and
whatever
right,
and
we
are
not
saying
that.
So
that's
why
I
said
I
put
this
one.
I
If
we
can
make
that
explicit
right,
if
somehow
we
can
say
we
are
trying
to
face
and
solve
this
problem,
and
if
you
like
the
docker
file,
that's
okay
go
ahead,
but
you
can
have
this
problem
if
you
grow
and
I
want
to
help
you
so
why
do?
Why?
Don't
you
come
with
me
and
try
to
use
it
and
avoid
having
these
problems
or
if
they
don't
realize
that
they
have
it?
B
Yeah
yeah,
that's
great!
Thank
you.
So
much
did
anyone
else
have
a
comment
on
that
or
an
action
that
we
might.
B
B
Now
we
can
also
move
on
to
the
next
person.
Joe
did
you
want
to
share.
E
B
In
late
sure
thing,
how
about
terence.
F
Yeah,
I
put
the
note
in
about
escape
hatches,
I
think
when
we've
talked
about
them
in
the
past,
it's
always
been
about
the
app
devs,
but
I
think
it's
interesting
to
also
think
about
like
do
operators
and
kind
of
our
other
users
right
operators
and
build
pack.
F
Authors
also
kind
of
need
escape
patches
to
be
able
to
do
stuff
that
they
feel
restricted
by
kind
of
the
system
and
stuff
we've
built
in
place
today
and
kind
of
what
are
what
are
the
kind
of
the
easiest
things
we
can
do
to
enable
these
these
folks
to
get
what
they
need
to
get
done
without
feeling
like
they're
kind
of
trapped
in
the
system.
B
Yeah,
that
and
but
from
the
buildback
author
perspective,
is
that
right.
F
Or
operators
right
like
we,
we
talked
about
how
we
have
multiple
classes
of
users,
but
I
feel
like
a
lot
of
the
escape
hatch
conversation
last
week
is
really
was
centered
around
the
app
dev
right,
the
app
that
being
stuck
because
they
couldn't
do
this
thing
that
they
could
easily
do
a
dockerfile
right,
right
and
so
kind
of
want
to
turn
it
on
its
head.
A
little
bit.
B
Yeah,
what
what
really
interesting
suggestion
when
you
think
about
that
app
operator
persona?
What
are
where
are
you
imagining
some
of
those
situations
where
they
might
need
an
escape
hatch
might
be.
F
F
H
D
One
of
the
things
that
stood
out
to
me
is
just
how
much
of
the
value
prop
is
dependent
on
an
ecosystem
of
great
build
packs,
even
the
things
that
are
some
of
the
success
points
rather
than
the
pain
points
like
my
dependencies
are
always
up
to
date,
and
you
know
I
get
a
bill
of
materials
like
those
are.
We
provide
tools
where
build
packs
can
can
create
that,
but
it's
not
happening
unless
there's
an
ecosystem
of
good
build
packs
that
are
doing
it.
D
So
I
wonder
if
we
need
to
do
more
to
support
buildpack
authors
in
helping
them
write,
good,
build
packs
and
then
make
them
feel
like
they're
getting
something
out
of
it
like
if
they
write
good,
build
packs.
Well,
say
something
nice
about
them,
and
you
know
sort
of
we
depend
on
them,
but
we
could
help
them
as
well.
D
I
did
start
an
rfc
for
creating
a
build
pack
sub
team
that
could
be
like
a
good
place
where
folks
could
come
and
have
discussions
like
that
without
having
to
listen
to
us
like
like
chat
about
directory
names
and
terence
has
taken
it
over.
So
hopefully
we're
making
some
progress
around
along
those
lines,
and
then
that
would
be
a
place
where
we
could
adopt
tooling
into
the
project.
If
that
was
appropriate.
F
Yeah,
I
imagine
the
sub
team
sync
for
that
kind
of,
or
the
meeting
that
comes
out
of
the
subteam
sync.
There
would
be
a
good
place
for
people
who
aren't
even
necessarily
contributors
to
cnb,
like
I
don't
think
it
should
be
a
requirement
that,
like
if
you
work,
for
instance,
on
packet,
that
you
need
to
be
a
cmv
contributor
right
like
I
think
it
would
be
much
more
open.
F
In
that
sense,
there's
the
I
I
updated
emily's
draft
if
you're
interested
dan
on
there,
but
but
one
of
the
points
I
put
for
the
goals
was
this
kind
of
comes
out
of
the
heroku
playbook
for
language
owners,
but
like
advocating
for
bill
pack.
Authors,
I
think,
is
a
thing
that
is
a
responsibility
of
that
sub
team,
so
also
bring
up
concerns
that
you
know
that
would
come
out
of
that
group
of
people.
B
D
B
F
E
I
I
already
did
but
like
that,
that's
pretty
much
all
I
had
to
say
like
around
having
the
ability
to
find
buildbacks
that
your
application
needs
might
be
like
something
we
should
look
into.
It's
not
always
obvious
that.
Okay,
this
random
build
back
on
the
internet
would
work
for
my
application
being
able
to
surface.
That
would
be
great.
B
J
Yeah
sure
I
was
like
something
I
mean
we
talked
about
it
also,
both
today
and
last
week.
It's
about
documentation.
J
J
I'm
not
sure,
what's
the
best
way
to
to
improve
it,
I
mean
how
to
start
where
to
start,
because
there
are
so
many
things
that
we
can
improve.
It's
starting
from
the
fact
that
people
are
getting
errors
that
they're
not
sure
how
to
to
resolve
them,
and
if
we
would
have
like
a
page
of
common
errors
and
where
to
look,
what
to
do
our
even
the
error
message,
as
we
already
talked
about,
can
be
better
and
also
for
new
people
like
our
website.
J
I
feel
that
it's
not
good
enough
for
new
people
that
would
like
to
start
being
more
familiar
with
buildbacks,
so
I
mean
like
an
intro
page
where
to
start
what
should
I
read
if
I
care
about
this
or
that
because
like,
as
I
already
said
like,
the
website
is
like
for
everyone,
it's
like.
B
About
yeah,
when
you,
when
you
talk
about
improving
the
website,
is
there
a
particular
persona
or
scenario
where
you
feel
like
it?
It
has
some
room
to
grow.
J
I'm
not
sure
I
feel
that,
like
for
every
person
that
we
can
make
our
talks
better,
there
is
always
way
to
improve,
and
mostly
I
think
that,
like
for
new
people,
it's
it's
very
hard
to
to
know
where
to
start.
J
I
think
that
even
we,
if
we
can
like,
I
think
that
we
have
two
people
that
are
here
like
join
our
community
like
in
the
last
month.
We
can
ask
them
what
is
missing.
Maybe
you
will
help
us
understand
where
to.
B
Start
awesome
anthony.
Did
you
have
a
sticky
from
the
chalkboard
you
found
particularly
interesting
or
or
an
action
that
you
shared
that
you'd
like
to
like
just
talk
a
little
more
about.
C
C
I
think
there
are
a
lot
of
good
points
about
things
that
are
blockers
today,
right,
there's,
not
a
huge
ecosystem
for
build
packs,
and
maybe
it's
hard
to
write
one.
I
believe
that
I
believe
the
documentation
maybe
is
not
fully
comprehensive
and
accessible.
I
believe
that
as
well.
I
guess
my
trouble
is,
I
don't
think
people
are
complaining
enough
about
it.
C
I
I
think
you
know
it'd
be
it'd,
be
better
for
me
if
there
were
more
complaints
on
a
consistent
like
daily
basis
about
that
right
and
to
me
the
problem
is,
you
know:
does
this
inherent
like
user
experience
you
get
with
docker
files
when
you
can
write
something
and
try
it
out
and
it
fails
or
passes,
and
then
you
can
try
something
else.
C
You
sort
of
more
or
less
have
clues
for
where
you
go,
and
you
know
it'd
be
really
nice
to
see
that
in
the
bill
packs
ecosystem
and
it
has
to
be
different
enough
right
so
so
that
it
doesn't
just
feel
like
a
minor
improvement.
It
has
to
feel
like
a
paradigm
shift
and
user
experience
for
how
you
build
containers.
C
B
Pants
folks
want
to
jump
in
a
comment
more
or
if
not
I'll,
keep
moving
maritim
jay.
G
Hope
I
got
that
somebody
run
yeah,
I'm
a
new
person
to
the
community,
so
I
was
just
trying
to
learn
how
you
all
are
interacting
and
what
we
are
discussing
and
like
pl
said,
if
I
hope,
I'm
pronouncing
her
name.
Writer
like
it
can
like
even
I
felt
a
little
difficulty
in
the
beginning.
However,
now
I
have
started
practicing
the
tutorials
and
I
built
my
first
application
through
build
packs
running
that
maven
application
of
java.
That
was
mentioned
in
the
tutorial.
So
that
was
easy
for
me
and
one
of
my
friend.
G
G
It
is
a
little
difficult
for,
especially
for
students
who
are
still
in
college,
who
are
still
learning
the
things,
but
as
of
now
like
right
now,
while
I
was
going
through
miro,
so
nero
was
also
new
for
me
and
I
mistakenly
you
know,
touched
the
sticky
note
and
thank
god
definitely
fix
that
again
so
yeah
I
was
trying
to
actually
just
get
involved
and
just
observe
things
for
now,
because
understanding
most
of
the
things
were
little.
G
You
know
difficult
for
me
and
I
also
wanted
to
discuss
my
previous
work,
but
today
it
was
not
in
the
agenda,
so
I
will
discuss
in
dm
with
joe.
I
was
working
on
a
pull
request,
so
I
have
a
few
doubts
related
to
that,
so
I
will
discuss
that
later.
In
the
event,
thank
you
so
much.
D
B
Apologies
for
that
please,
please
bring
us
in
the
slack
as
well,
but
also
next
week,
we'll
be
back
to
our
regular
scheduled
programming,
so
it
would
be
a
great
place
to
come
and
talk
about
questions,
but
thank
you
for
joining
us.
B
Thank
you
so
much
I'm
getting
pretty
close
to
time
here
I
want
to
give
daniel
dan
a
chance
to
speak.
F
Yeah,
so
I
have
one
that
I
wrote
down,
which
is
focus
on
users
that
we
can
capture
right
now
right
and
I
think
after
looking
over
a
bunch
of
the
feedback
from
this,
it's
like
there
there's
a
lot
of
feedback
around
the
difficulties
or
adopting
this,
particularly
just
as
like
a
devon,
maybe
a
smaller
shop,
where
the
functionality
you
get
out
of
like
rebase,
etc.
It's
not
immediately
useful
or
like
can't
be
leveraged
to
the
same
extent
or
you
don't
have
like
a
dedicated
team,
just
managing
your
platform.
B
Them,
I
think,
that's
super
interesting.
It's.
How
do
we
potentially
make
you
know
some
some
startups,
for
example,
talk
about
like
a
beachhead
market.
I
know
we.
We
have
obviously
a
very
ambitious
project,
but
it
would
be.
It
would
be
cool
to
to
maybe
consider
that
in
certain
ways
natalie
you
want
to
round
us
out.
Do
you
have
something
you
want
to
mention
or
or
any
closing
words
office.
A
Sorry
very
quickly,
I
added
a
sticky
around
like
what
could
we
do
next?
You
know
I
mean
I.
I
personally
found
a
lot
of
value
out
of
just
talking
to
people.
You
know
even
outside
of
this
more
structured
user
interview
project.
You
know,
just
in
slack
someone's
having
a
problem
hopping
on
a
zoom
with
them
for
a
few
minutes
and
seeing
how
they
actually
use
our
product
and
some
of
the
things
that
they
are
thinking
about
that
wouldn't
have
ever
occurred
to
me.
A
A
I
think
user
research
has
a
home
there
and
we
can
hopefully
strategize
as
to
you
know
how
we
can
keep
these
kinds
of
conversations.
These
kinds
of
learnings
happening.
B
Yeah,
thank
you
so
much
for
bringing
that
up
and
with
with
that
to
close
us
out,
I
wanted
to
ask:
is
anybody
interested
in
helping
to
spearhead
or
to
participate
in
some
some
future
research,
whether
that's
usability,
test
or
or
some
sort
of
broader,
more
exploratory
thing
like
this.
J
F
J
F
B
Dan,
emily
all
turns
amazing,
great
well,
man.