►
From YouTube: Learning Sync: 2021-03-02
Description
Meeting notes: https://bit.ly/38pal2Z
A
All
right,
let's
see,
moving
on
to
the
first
item
on
the
agenda,
is
status
updates,
since
I'm
talking
I'll
go
ahead
and
throw
mine
out
there.
So
I
know
from
last
meeting
I
promised
that
I
would
take
notes
or
write
down
some
notes
based
on
some
of
the
input
or
feedback
that
was
given
on
the
docs.
A
Also,
that
meeting
is,
is
being
uploaded
to
youtube,
as
you
know,
per
usual,
so
my
train
of
thought
is
more
or
less
tied
to
the
last
item
that
I
added
on
the
agenda,
which
has
to
do
with
the
roadmap.
There's
a
mention
about
docs
and
how
all
that
could
tie
in,
but
we
could
discuss
it
a
little
bit
more
in
that
agenda.
Item
cool
any
other
status
updates.
B
I
tried
to
add
a
couple
of
new
pages
on
docs
there's,
a
new
stack
like
creating
a
custom
stack
guide
and
under
the
operator's
guide
now
and
yeah.
That's
it.
I
think.
One
thing
you've
noticed
in
the
past
is:
whenever
people
make
changes
to
some
subsection.
B
The
subsequent,
like
sections,
are
not
updated
with
the
same
piece
of
code
that
leads
to
inconsistencies.
That
has
happened
a
couple
of
times
where
we
pushed
something
onto
the
main
branch,
which
was
then
inconsistent
with
the
rest
of
the
docs.
A
Do
you
have
any
thoughts
on
that?
Do
you
want
to
maybe
explore
it
as
an
agenda
item?
We
could
talk
about
it
more.
B
Sure
I
can
look
into
some
tools
that,
like
I
think
last
time,
you
suggested
something
like
kaka
code
or
something
similar.
Maybe
we
can
look
into
tools
that
help
write
these
sort
of
step-by-step
tutorials
in
an
easier
fashion.
A
Cool
yeah
it'd
be
great
yeah.
If
we
could
look
around,
I
I
again
personally
didn't
find
anything
too
concrete,
but
yeah,
I'm
sure
more
eyes
could
probably
do.
A
All
right,
moving
on
to
user
research,
we
don't
have
anybody
here
to
represent
that
topic,
but
I
I
will
kind
of
relay
some
information
that
I
got
yesterday,
so
it
sounds
like
natalie
and
sam
are
kind
of
towards
the
completion
of.
A
I
guess,
ultimately,
what
the
the
initial
ask
was,
which
was
a
sort
of
report
as
the
outcome
for
other
user
research.
I
know
that
there's
one
workshop
that
they
were
still
trying
to
to
finalize.
I'm
not
entirely
sure
you
know
whether
or
not
that's
going
to
actually
happen,
but
I
believe
sam
is
going
to
be
joining
us
at
one
of
the
working
group
meetings
or
at
least
speaking
with
the
core
team
members
in
trying
to
figure
out
exactly
how
to
either
finalize
that
or
pass
it
along
to
somebody
else.
A
I
think
he's
running
into
some
conflicts
with
availability
so
more
to
come
there,
but
there's
definitely
some
traction
and
some
outcomes
coming
up
very
soon.
Any
questions
on
user
research
cool
all
right.
Moving
on
next
one
unlabeled
issues.
I
looked
right
before
this
meeting.
I
believe
we
don't
have
any.
So
that's
good.
A
Let's
keep
skip
that
tagging
issues.
This
is
a
holdover
from
the
previous
meeting.
Do
we
know
who
added
this
issue
and
or
sorry
this
item
and
what
we'd
like
to
discuss
here.
C
Is
this
in
reference
to
tagging
them
for
new
contributors,
or
I
can't
remember
because
I
I
think
that
came
up,
but
I
don't
remember
if
we
actually
talked
about
it
a
little
bit
or
if
it
just
kept
getting
moved
down
in
the
agenda.
C
C
Yeah
we
already
have
that
label,
so
maybe
just
people
that
are
kind
of
combing
through
issues
just
labeling
things.
Accordingly,.
A
Yeah,
I
don't
think
we
have
a
process
for
that
right,
but
I
believe
I've
heard
recently
that,
like
we
just
kind
of,
I
guess,
maybe
an
acknowledgement
that
we
haven't
been
doing
so
good.
C
A
Just
need
to
figure
out
exactly
and
not
just
within
the
docs,
but
throughout
the
entire
project,
a
lot
we
don't
have
enough
getting
or
sorry
good
first
issues
for
the
community.
So
that's
probably
something
that
the
maintainers
should
focus
on
which
is
kind
of
pointing
the
finger
back
at
me.
But
whatever.
A
Right
cool
next
migrating
missing,
specs
to
docs.
B
That
was
something
I
added
in
the
last
meeting,
so
I
think
it
also
has
to
do
with
tagging
issues,
but
we
have
a
lot
of
issues
or
like
whenever
there's
some
new
rfc
or
spec,
or
some
some
updates
to
pack.
Someone
creates
an
issue
in
docs.
I
think
it
would
be
nice
to
add
them
to
like
a
milestone
or
some
sort
of
a
checklist
so
that
we
can
track
and
work
on
it
as
a
chunk.
B
So
I
like,
as
of
right
now,
I
don't
know
which
like
which
build
sorry
which
buildback
api
version
we
have
documented
everywhere
or
like.
Is
it
consistent
across
all
the
different
guides?
B
Similarly,
like
there
are
like
just
some
way
to
like
collect
all
of
the
issues
that
we
have
in
docks
into
some
milestones
so
that
we
can
iterate
on
them
one
by
one
rather
than
like
picking
them
at
random
would
be
good,
and
it
would
also
help
us
identify
if
there
are
any
missing
issues
from
or
missing
documentation
from
specs
that
were
put
in.
But
a
subsequent
issue,
for
it
was
not
created
in
the
docs
repository.
A
Yeah
that
definitely
sounds
like
a
good
idea
if
it's
okay,
I'd
like
to
maybe
spend
a
little
bit
of
time,
to
provide
some
context
based
on,
I
believe
the
first
meeting
we
had
in
one
of
these
things,
which
was
around
how
this
sub
team
operates
right
and
one
of
the
things
I
just
want
to
point
out-
is
like
this
sub
team
right
like
whether
it
be
the
contributors
or
maintainers.
A
I
guess
we
really
are
more
like
just
simply
facilitators
for
the
docs
or
for
yeah
for
basically
the
docs
repo
the
website.
Anything
in
relation
to
that
are
our
kind
of
working
model
is
that
we
don't
feel
like.
We
have
all
the
knowledge
and
context
from
each
individual
like
sub
sub
team
right,
so
whether
it
be
the
platform
sub
team,
the
implementation,
sub
team
or
the
distribution
sub
team.
A
We
we
just
wouldn't
have
enough
knowledge
to
be
able
to
provide
the
document
or
yeah
to
write
the
documents
right,
the
guides
and
all
that
stuff
for
each
one
of
those
other
individual
teams,
so
we're
kind
of
leaning
on
them
to
be
able
to
provide
those
stocks.
So
it
really
would
be
up
to
the
you
know.
If
we're
talking
about
the
build
pack
api
right
and
whether
the
specs
up
to
date,
it
would
be
up
to
the
implementation,
maintainers
or
sub
team.
A
I
should
say
to
really
make
sure
that
that
is
well
documented
and
this
team
is
really
just
more
facilitating.
You
know
the
tools
that
we
use
for
publishing
the
website
and
maybe
any
like
very
general
high
level.
You
know
getting
started
type
of
guides.
A
Cool
so
again
like
I,
I
definitely
agree
that
we
should
add
milestones
and
maybe
that's
something
for
tracking,
but
I
think
we
should
relay
that
information
and
that
feedback
back
to
each
individual
sub
team.
C
A
B
I
I
think
it
was
just
like,
like
I
think,
currently
I'm
sort
of
divided
between
when
to
look
at
docs
versus
when
to
look
at
the
spec
itself.
So
at
which
point
should
the
users
look
at
the
api
reference
inside
buildback.io
versus
when?
Should
they
go
to
the
spec
repository
and
read
that
document
there?
B
A
For
better
for
worse
right-
and
I
think
if
we
want
to
change
that,
I
think
we
really
need
to
look
at
how
to
actually
do
that.
B
A
I
I
don't
know
what
your
your
take
on.
It
is,
but
I
think
it's
been
improved
over
time,
but
I
don't
know
that.
I
think
it's
something
that
you
could
just
put,
and
you
know
like
a
a
newcomers.
You
know
face
and
be
like.
Oh
do
you
understand
this
right
like
there's,
it's
very
terse
language.
It's
like
legal
stuff,
legal
terminology,
then
I'm
not
sure
again.
A
I
think
it
goes
back
to
last
week's
conversation,
but
it
really
depends
on
the
audience
right
if
it's
somebody,
that's
like
very
deep
in
the
weeds
and
needs
to
know
like
precisely
how
everything
operates
then
yeah
they
should
be
looking
at
the
spec.
But
if
we're
trying
to
like,
maybe
even
just
entice
people
to
try
it
out
like
we
don't
want
to
throw
the
spec
at
them
right
like
that,
would
be
kind
of
detrimental
there
yeah.
A
So
I
think
we
should
render
it
potentially,
but
it
wouldn't
be
the
first
thing
that
they
see
right.
It
would
be
something
that
maybe
as
we're
running
through
the
through
or
sorry
as
they're
reading,
through
the
dock,
we
could
say
for
more
information
click
here
and
then
it
takes
them
to
that.
A
Maybe
section
of
the
of
the
spec
yeah,
that's
at
least
how
I
could
foresee
it
cool,
but
again
good
feedback
so
appreciate
it
all
and
it
seems
like
docs
is
a
pretty
big
focus,
which
I
think
kind
of
leads
us
to
the
next
agenda
item
I'll
share
my
screen,
real,
quick.
A
Yes,
last
week's
topic
or
conversation,
what
I
want
to
do
is
maybe
expand
on
this
better
documentation
idea
and
throw
it
as
a
whole
different
discussion
topic
inside
of
yeah,
like
the
community
discussions,
where
we
could
really
pick
apart
everything
and
align
it
with
the
roadmap.
Since
it
seems
like
it's
it's
you
know,
it's
got
a
decent
amount
of
votes
and
it
seems
like
there's
a
lot
of
thought
behind
it.
A
So,
ultimately,
my
pic
my
thought
would
be
that
we
add
it
onto
the
roadmap
where
it
gets
added
to
the
roadmap,
and
then
we
have
a
place,
which
is
a
discussion
board
that
would
link
to
the
meeting
that
we
had
last
week.
This
meetings
recording
and
then
some
notes,
and
we
could
just
start
throwing
everything
on
there
and
hopefully
the
outcome
would
be
a
much
better
presentation
of
our
documentation.
A
C
A
So
I
guess
my
only
thing,
my
only
ask
would
be
obviously
add
your
comment
here
and
add
them
to
the
new
discussion
that
should
be
up
there,
maybe
in
about
30
minutes
or
an
hour
just
to
keep
the
traction.