►
From YouTube: Learning Sync: 2021-02-23
Description
Meeting notes: https://bit.ly/38pal2Z
A
All
right,
so
we're
done
with
the
first
item,
we'll
go
on
to
status
updates.
Does
anybody
have
any
status
updates
relevant
to
the
learning
team.
A
I
can
give
a
maybe
a
forward,
looking
statement
that
I've
been
working
on
tecton
quite
significantly
and
there's
going
to
be
a
new
tecton
pipeline
as
opposed
to
a
task
that
can
be
a
little
bit
more
sophisticated,
and
my
hope,
after
it's
released,
which
should
be
here
at
the
end
of
february,
is
to
create
a
blog
post.
A
So
I
think
that's
something
that
I
guess
we
can
look
forward
to
is
having
a
blog
post,
that
more
or
less
explains
the
tech
town
integration,
how
to
use
it
and
hopefully
drive
us
a
little
bit
there
more.
B
A
A
Okay,
next,
we
have
unlabeled
issues.
You
go
through
this
real
quick.
I
believe
we
have
two.
I
don't
know
I
believe
yeah
you
were
the
one
that
added
tagging
issues.
Is
that
related
to
what
we're
about
to
do
right
now,.
B
B
A
A
D
I
have
a
question:
should
there
be
like
a
special
label
for
documentation,
editions
that
are
probably
going
to
be
seen
by
people
that
are
beginners,
or
maybe
it's
their
first
time
on
the.
A
All
right
registry
nav
button.
C
Yeah,
so
this
is
a
pull
request
that
adds
the
registry,
a
registry
link
to
the
nav
bar,
and
I
think
I'm
going
to
merge
it
today,
even
though
we're
probably
not
going
to
do
the
registry
launch
today
we're
just
waiting
for
some
people
to
update
their
build
packs
with
more
metadata,
so
that
all
the
build
packs
actually
look
good
when
we
launch
it.
A
Right
that
makes
sense
yeah,
as
I
was
looking
at
this
pr,
I
mean
I
definitely
didn't
stand
in
the
way
of
it,
but
I
think
in
the
future
we
might
want
to
look
at
either
collapsing.
Some
topics
or
or
the
search
functionality
might
also
help
in
some
of
that,
I
think
chocolaty
has
like
a
search
and
it
lets
you
search
docs
or
you
know,
in
this
case
the
registry
that
might
be
a
thing
but
just
different
things,
because
it
does
feel
like
it's
starting
to
get
a
little
cluttered
yeah.
I.
C
C
Oh
yeah,
that's
just
a
link.
If
you
have
a
chance
to
review
it,
please
take
a
look,
just
copy,
editing
or
whatever
still
not
100
sure
what
day
we'll
launch,
maybe
wednesday,
but
I
don't
think
it'll
be
today.
A
All
right
on
to
the
next
topic,
organ
organizing
concepts.
F
Yeah
hi
everyone,
I'm
I'm
samuel,
I
work
at
bloomberg
and
I'm
trying
to
introduce
build
packs
as
like
a
new
container
building
mechanism
inside
the
company.
F
So
just
to
give
you
some
background,
like
so
far,
it's
been
like
just
me
mainly
trying
to
get
some
infrastructure
up
and
running
internally
and
like
one
of
the
problems
we
face
is
because
it's
it's
internal
and
there's
nothing
connected
to
the
internet.
There
are
some
settings
or
things
that
you
have
to
do,
which
are
way
different
from
the
typical
buildback
author's
guide
or
the
operator's
guide.
F
So
when
I
was
first
looking
through
all
of
this
and
like
looking
at
concepts
to
figure
out
which
parts
are
interacting
with
what
it,
it
took
me
quite
a
while
to
understand
each
of
the
concepts
that
are
listed
there
in
in
sort
of
a
dag
fashion
so
like
which
one
do
I
start
with
first
to
understand
what
comes
next,
because
currently,
if
you
look
at
the
documentation,
they
all
sort
of
refer
to
each
other.
So
it's
it's
difficult
to
pick
a
starting
point
where
you
begin
your
comprehension
of
buildbacks.
F
So
I
was
just
wondering
if
anyone
has
any
thoughts
on
how
to
introduce
like
these
concepts
to
someone
who's
never
heard
of
buildbacks,
because
now
I
like
now
that
I've
worked
with
this
and
I
know
about
it.
I
can
try
and
explain
it
to
other
people,
but
they
still
get
confused
because
of
the
fact
that
most
of
the
folks
here
are
used
to
like
using
docker
files
to
build
their
container
applications.
F
So
they
have
like
it
it's
very
hard
for
them
to
fathom
that
a
container
image
can
possibly
use
other
container
images
to
build
yet
another
container
image
and
then
how
all
of
these
things
come
together
and
the
different
like
container
images
that
come
into
play.
That's
that's
very
difficult
for
them
to
understand
and
like
concepts
like
build
packs,
builders,
etc,
regularly
get
confused
internally
like
when
I
tried
presenting
it
to
people.
F
They
were
getting
confused
between.
What's
a
build
back,
what's
a
build
package
what's
a
builder
and
how
how
they
interact
with
each
other.
So
that
was
sort
of
my
some
some
background
information
on.
Why
I
I
put
that
topic
in
the
agenda,
like
has:
has
that
been
a
common
issue
for
new
users
like
or
is
it
something
that
I'm
facing
only
because
it's
internal
and
then
have
to?
I
had
to
implement
a
lot
of
these
things
from
scratch
and
understand
these
concepts
in
details,
or
is
it
just
like
a
common
thing.
C
It's
it's
definitely
not
just
you
I'll
say
that
much,
I
think,
but
I
think
you
articulated
pretty
well
in
terms
of
like
things
referencing
other
things
like.
I
can
imagine
like.
What's
a
builder,
I
click
through
and
it
talks
about.
What's
a
build
pack
and
then
you
see
a
link
to
a
builder
kind
of
feel
like
you're,
not
getting
anywhere.
C
I
wonder
like
like.
We
do
have
a
bunch
of
things
that
people
need
to
learn
about,
and
I
think,
as
the
project
matures
some
of
those
things
will.
I
think
our
hope
was
that
some
of
those
things
would
like
go
behind
the
scenes.
Like
you
know,
we
definitely
hope
that
builder
image
would
be
just
an
implementation
detail
at
some
point.
C
We're
not
there
yet,
though,
similarly
with
build
packages,
but
I
wonder
if,
like
one
approach
to
reduce
some
of
like
the
things
you
have
to
learn
would
be
to
really
lean
into
the
like.
So
I
know
docker
file
and
then
here's
the
progression
you
know
which
is
like.
I
think
we've
steered
away
from
that
because
we
we
don't
want
to
do.
We
don't
want
to
put
too
much
emphasis
on
like
a
one-to-one
comparison
with
docker
file
because,
like
at
the
end
of
the
day,
I
think
people
would
be
left
like
well.
C
So
why
do
I
need
build
packs?
And
it's
like?
Oh
well,
it's
all
the
things
that
you
can't
compare
to.
Docker
file
that
make
build
packs
have
like
more
advantages,
but
maybe
that's
something
that
we
need,
if
only
to
start
people
off.
A
So
I
have
two
thoughts,
one
of
them.
You
know
in
relation
to
what
you
just
mentioned,
I
mean.
Is
it?
A
I
guess
one
question
I
have
whether
or
not
that
should
be
a
little
bit
more
of
bringing
you
know
again
kind
of
with
the
same
vein
of
maybe
acknowledging
that
people
most
people
already
have
a
doctor
file
or
docker.
You
know
experience
it's
like
okay,
so
this
is
how
you
do
it
here
and
provide
a
little
bit
more
context.
C
If
you
have
someone
like
sam
in
your
organization,
who's
figuring
all
this
stuff
out
for
you
and
all
you
have
to
do-
is
run
pack
build,
but
I
think
for
the
majority
of
people
like
that's,
like
they're,
probably
coming
in
learning
about
build
packs
and
I'm
trying
to
understand
the
whole
picture,
so
they
can
figure
out
how
it
fits
into
their
organization
or
whatever
so
yeah.
Maybe.
A
E
A
Very
specific
use
cases,
so
that
could
be
a
route.
The
other
thing
I
was
thinking
about
was
like,
at
least
for
me,
I'm
very
visual
right
and
if
I
look
to
the
components
section
under
concepts
like
yeah,
it's
like
just
a
whole
bunch
of
stuff
right,
like
literally
descriptions
of
things,
whereas
at
least
for,
like
the
build
operation
right
I'll
share
the
screen.
Real,
quick.
D
A
F
A
F
Diagram
there,
that's
actually
what
helped
me
understand
the
whole
thing
so,
when
you're
coming
from
like
outside
the
buildbacks
world,
like
it's
still,
you
understand
buildbacks
and
builders,
but
as
soon
as
you
get
to
something
like
lifecycle
or
platform,
you
you
start
like
platform
is
not
something
people
associate
with
the
ci
or
so
cli
to,
for
example.
So
when
I
tell
them
that
okay
pac
is
a
platform
they're
like
what
it's
it's,
it's
just
a
it's
just
a
command
line
tool.
How
is
that
a
platform?
F
So
maybe
in
that
build
like
in
that
build
diagram?
If
we
just
introduce
that
the
platform
is
the
one
that
uses
all
of
this
and
orchestrates
it
into
the
image,
like
that's
the
only
thing
missing
from
the
concepts
and
then
put
that
in
the
original
components
page,
I
think
that
would
that
could
be
a
good
introduction
that,
in
in
the
buildback
world,
the
platform
is
simply
the
underlying
orchestrate,
like
the
tool
that
orchestrates
the
lifecycle
to
do
xyz.
A
F
Yeah,
the
the
other
thing
which
is
like
in
in
builders,
you
you
talk
about
build
images
and
run
images
but
like
like,
although
run
image,
is
there
certainly
on
the
right
side,
the
run
image
is
suddenly
gone
like
so
so
on
the
left,
there's
the
run
image
and
and
then
on
the
right
side.
That's
not
there.
So
maybe
some
way
to
say
that
it's
not
part
of
the
builder
image,
but
that's
what
it
uses
to
create
the
final
app
image
or
some.
F
E
All
right
just
to
offer
my
couple
cents
in
here.
You
know
I'm
also
peruse
these
docs
and
I
just
wanted
to
highlight
a
point
where,
like
you
know,
I
feel
like
all
these
components
you
should
have
given
that
all
right
away-
and
I
know
for
me-
it'd-
be
really
nice
to
have
like
a
bird's
eye
view
when,
when
you
do
have
these
kind
of
things
listed
out
just
to
see
you
know,
maybe
what
the
most
important
things
to
know
right
away
are
before
you
know,
maybe
a
month
later.
E
I
don't
know
three
weeks
later,
when
I
want
to
get
into
a
more
granular
level,
then
I
can
investigate
you
know.
Then
I
can
know
what
the
life
cycle
is
doing
and
things
like
that.
I
feel
like
that
would
have
helped
me,
which,
which
again
it's
only
because
of
bill
packs,
because
there's
these
different
abstractions
that
you
sort
of
are
being
made
aware
of
right
away
right.
C
B
B
I
want
to
add
that
there
is
just
so
much
information
that
maybe
we
should
just
create
like
an
introduction.
B
F
They
need
a
high
level
overview,
but
they
don't
need
to
know
everything.
Then
the
next
stage
is
the
buildback
authors
who
need
to
know
how
to
create
health
packs.
And
finally,
it's
like
some
infrastructure
owners
who
need
to
know
who
need
to
provide
like
certain
stacks
for
you
or
who
need
to
provide
a
platform
like
who
recommend
a
platform
for
you
to
use,
whether
it's
pack
or
techdon
or
kpac
or
anything
else.
So
for
someone
creating
a
new
platform,
their
understanding
of
concepts
have
to
be
very
different.
F
They
probably
need
to
know
about
how
the
life
cycle
is
working
for
someone
creating
a
builder.
They
probably
will
just
use
the
life
cycle
binary
or
image
houses,
they'll,
never
investigate.
What's
going
underneath.
So
that's
what
an
operator's
guide
would
be
and
then
for
the
buildback
author,
they
they
don't
really
care
about
stacks.
They
just
care
about,
like
here's,
the
here's,
the
stack
that
my
operators
provided
me
and
I'll
just
write
bill
parks
on
top
of
it.
A
It's
it's
all
pretty
nebulous
in
my
mind,
but
let
me
try
to
see
if
I
can
explain
it.
So
I
think,
like
the
the
general
getting
started
here
should
be
like,
maybe
something
that
we
would
have
done
at
a
presentation
right
like
a
what
is
it
cube
con
presentation?
Look
but
like
not
the
deep
dive,
but
the
like
very
high
level
overview
with
some
like
diagrams
or
something
that
really
shows
like
hey.
This
is
what
this
is
all
about
right
and
then
from
there.
A
A
C
I
think
this
would
be
like
there's
there's
a
lot
of
things
in
this,
and,
and
some
of
them
are
small,
like
I
almost
wonder
just
some
minor
changes
would
improve
this,
but
then
I
think
there's
some
like
big
revisit
the
docs
kind
of
things,
and
I
wonder
if
we
should
include
that
in
the
roadmap
for
for
this
year,
because
one
of
our
goals-
and
I
think
we
already
talked
about
having
some
document
documentation,
stuff
and
like
actually
blocking
releases
on
documentation
and
stuff
like
that
but
independently
and
especially
based
on
the
user
research.
A
Yeah,
I
definitely
think
so.
I
think
it
would
align
very
well
with
everything
else
that
we're
trying
to
do
as
far
as
growth
of
the
community
and
you
know
being
able
now
that
we
have
a
little
bit
more
of
a
a
solid
ground
versus
before.
I
think
we
were
just
still
trying
to
build
everything
now.
I
think
it's
the
time
to
maybe
focus
on
this.
B
A
So
definitely
some
action
items
that
I'll
take
from
this
is
add
it
to
the
road
map
right
or
at
least
discuss
it
further
in
the
roadmap
discussions
and
then
the
ultimate
action
item
would
be
to
have
some
issues
that
come
out
of
it
to
further
improve
it.
So
I'll
re
I'll,
listen
to
the
recording
again
and
try
to
jot
down
notes
for
everything
and
kind
of
throw
them
into
the
slack
channel,
and
then
maybe
we
could
proceed
from
there.
Some
issues
to
take.
D
Yeah,
I
don't
really
have
that
much
to
say,
except.
I
think
that
some
of
the
the
work
that
we're
doing
on
docs
that
are
probably
going
to
be
more
visible
to
people
that
are
first-time,
maybe
first-time,
build
pack,
authors
or
first
time
developers
might
need
special
attention
or
they
might
need
to
be
in
a
more
visible
spot
in
the
docs
or
maybe.
D
Yeah,
they
might
be
need
to
be
somewhere
where
they
are
it's
kind
of
easily
easy
to
sift
through
them
and
then
also
kind
of
somewhere
else
where
they
might
be
closer
to.
I
guess
their
specific
concern.
C
Yeah
that
makes
sense.
This
came
up
just
I
think.
Yesterday,
when
I
was,
we
were
finalizing,
or
you
know
putting
some
finishing
touches
on
the
group
editions
to
the
project
tamil
rfc,
that's
where
you
have
like
the
pre
and
post
build
packs,
and
I
think
I
did
create
an
issue
for
it.
C
So
it
left
me
like
thinking.
Where
does
this
even
belong,
because
I
don't
want
to
put
it
in
our
like
the
app
developers
guide,
necessarily
maybe
the
using
project
tamil
but
yeah.
I
think
that's
the
kind
of
thing
you're
talking
about.
D
A
Topic
if
we
were
to
think
of
like
just
that
example,
that
you
just
brought
up
joe
if
we
look
at
using
project
tamil,
like
I
think,
a
lot
of
our
current
documentation
is
geared
towards.
You
know
a
a
page
in
regards
to
a
you,
know,
context
or
subject
right
and
then
I
don't.
C
C
Yeah,
I'm
gonna
have
to
drop
off.
I
think
we
should
sort
of
fold
what
danielle
brought
up
into
that
larger
discussion
about
what
we
put
on
the
road
map
for
rethinking
the
docks.
I
think
I
think
they're,
I
think
it's
very
much
related
to
what
sam
was
bringing
up
and
that
it's
just
like
in
that
we
should
be
cognizant
of
being
hostile
towards
people
that
are
just
getting
started,
but
then
also
try
to
accommodate
people
that
are
looking
for
like
oh.
How
do
I
do
this
more
advanced
thing,
but
not
necessarily
entangle
them.