►
From YouTube: Weekly Sync 2021-10-12
Description
Meeting Minutes: https://docs.google.com/document/d/16u9Tev3O0CcUDe2nfikHmrO3Xnd4ASJ45myFgQLpvzM/edit#heading=h.yptm1cswd65i
B
B
A
What
I
said
and
and
then
I
think,
you'll
find
that,
like
a
github
actions,
workflow
will
probably
be
sufficient
because
you
could
go
and
you
could
make
it
on
a
cron
job.
For
always
like
a
you
know,
recurring
meeting
or
you
could
make
it
a
triggerable
workflow,
in
which
case,
then
it
would
just
run
in
github
actions.
You
know
on
demand
whenever
you
hit
hit
a
button
right
and
that
way
you
maintain
no
infrastructure,
which
is.
B
A
A
A
B
A
B
A
A
D
A
Don't
have
any
files
sitting
around
on
the
disk
and
it's
immediate,
and
so
you
you
basically
have
you
set
the
vnc
as
the
input
and
then
you
set
the
you
know,
youtube
upload
url.
They
have
a
thing
as
the
output
and
it
should
just
do
stream
to
stream.
Now
you
know
getting
fm
peg
to
do
things
is,
you
know
not
easy,
but
hopefully
you
know.
Yes,.
A
B
A
So
here's
what
I
wanted
to
do
today
I
wanted
to
talk
about.
You
know
I
wanted
to
do
some
pr
review
like
we
talked
about,
and
then
I
also
wanted
to
talk
so
I
didn't
get
to
the
I
wasn't
able
to
get
to
doing
the
issues
I
saw
that
hashem
had
commented
back.
I
thought
that
you
did
the
pr
and
then
okay
great
and
then
hashimoto
commented
back
in
the
one
on
the
list
stuff.
I
don't
know.
If
that's
enough
information,
though,
let's
see
where
did
it
go.
A
B
A
B
A
Oh
yeah,
I
mean
sure
I
mean
sure
I'm
I'm
I'm
open
to
whatever
right
I
mean.
Obviously
we
don't
have
any
like.
Like
I
mean
like,
are
you
gonna?
Ask
him
like
you
like
we're
thinking
about
paying
him
to
do
it
like
in
relation
to
the
funding
issue
or
to
see
if
he'll
do
a
pro
bono
or
like
what
are
you?
What
are
you
thinking,
because
I
know
you.
B
B
B
A
Yeah
yeah
yeah,
you
never
know
what
the
intel
stuff
right.
Thanks
for
checking
in
you
know,
I
don't
think.
I
think
that
I
think
that
I
knew
this
looked
familiar.
Okay,
wait
a
minute
yeah!
I
knew
I
was
like
looking
at
this
and
I
was
like
this
looks
vaguely
familiar
and
that's
where
it
looks
familiar
from
yeah
I
mean
I
would
say
yeah.
If
you
want
to
approach
them,
go
go
for
it.
You
know,
I
don't.
I
think
you
know
we
might
need
to
give.
A
A
A
So,
let's
see
so
yeah,
it
makes
it
easy
to
generate
data
sets
train
and
use
machine
learning
models
and
integrate
machine
learning
into
new
or
existing
applications,
provides
apis
for
data
set
generation,
storage
and
model
definition
yeah.
I
wonder
how
one
I
wonder
if
this
is
sort
of
enough
information
for
somebody
to
make.
B
A
B
A
A
A
A
A
A
A
A
A
A
D
C
A
A
D
A
D
A
A
A
A
A
A
D
A
D
A
A
A
D
A
A
Not
done
done,
okay,
pr
view,
not
done
done,
okay,
great
all
right,
so
I
need
to
talk
to
you
guys
a
little
bit
about
the
second
party
plug-in
stuff.
So
basically,
this
is
like
my
number
one
thing
that
I
have
to
do
right
now,
so
someone's
coming
around
and
auditing
things,
and
so
well,
we
may
or
may
not
be
in
compliance
for
an
audit.
So
basically
I
need
to
put
my
ass
in
high
gear
and
make
sure
that
this
second
party
plug-in
thing
is
is
is
happening.
B
A
Yes,
yes,
yes,
that
is
what
will
happen
yeah,
so
the
the
main
thing
it
really
has
to
do
with
more
of
the
issue
was
really
around
testing.
And
how
do
you
ensure
that
breaking
changes
that
you're
aware
of
breaking
changes
in
so
downstream
repos?
So,
basically
anything
that
sees,
for
example,
config
yaml?
A
B
I
am
not
able
to
grasp
the
complexity
here
like
what
what
what
is
that
we
have
issue
with,
because,
for
example,
let's
trade,
this
all
packages
as
standalone
packages
like
we
have,
so
we
don't
care
about
how
other
packages
work.
We
just
care
about
that.
The
version
we
have
in
our
system
works
with
our
system,
so
each
package,
each
plugin,
would
be
itself
an
independent
project
yeah
and
if
one
breaks
then
we'll
fix
it.
That.
A
How
do
we
figure
out
that
it's
broken
right
and
that's
where
the
complexity
gets
involved
here,
and
so
essentially
so,
essentially,
what
will
end
up
happening
is?
Okay,
so
you
say
you
have.
This
is
I'll
write
it
in
the
adr,
I'll
write
it
in
the
adr
and
we'll
talk
about
it
next
week,
but
that's
that's
exactly
where
the
complexity
comes
in
is
okay.
How
do
you?
How
do
you
know
that
things
are
broken?
Does
basically
the
ci?
You
know
how
do
we?
A
So
if
you
guys
see
any
holes
in
this
logic,
let
me
know
right
now,
so
if
we,
so
you
bring
up
a
pr
right,
so
you
bring
up
a
pr
to
say
the
config
yaml
library
right
now,
you
need
to
that.
That
pull
request
needs
to
be
validated
against
anything
that
uses
config
email
to
make
sure
that
you're,
not
you
know,
because
if
all
of
a
sudden,
you
actually
start
not
serializing
tm,
while
everything
else
is
going
to
break
right,
so
we
need
to
trigger
the
we
need
to
trigger
a
rerun
of
the
downstream
plug-in.
A
So,
for
example,
say
what
tutorial
say
like
the
nlp
tutorial,
which
resides
within
the
nlp,
you
know
operations
repo,
that
that
uses
config
yaml
right.
So
we
need
to
trigger
a
retest
of
that
tutorial
on
a
pr
change
to
config
yaml
right,
because
that
is
currently
so
that's
currently
how
what
happens
in
our
ci,
because
we
have
a
mono
repo
right.
So
we
need
to
this
figure
out
the.
What
I've
done
is
I've
sort
of
said.
A
We
any
every
plug-in,
needs
to
declare
all
of
its
dependencies
right.
Obviously,
and
if
those
one
of
those
dependencies
is
a
plug-in
then
and
you've
changed
that
plug-in,
you
know,
then
we
need
to
revalidate
anything.
You
know
that
might
be
using
that
change
plug-in.
So
what
it
amounts
to
is
basically
just
kicking
off
the
github
actions.
Workflow
run
on
demand
and
then
reporting
back
the
status
into
the
repo
where
the
pr
originally
occurred.
B
See
any
issues,
a
very,
very
simple
and
maybe
incorrect
solution
comes
to
mind
that
all
the
dependencies
we
have
that
are
internal
dependencies.
Like
the
deficient
package
itself
and
the
plugins
we
always
used
the
most
up-to-date
version
like
the
pip
install
dash
you
sort
of
stuff
and
run
the
test
periodically
on
like
12
am
something,
and
we
will
know
in
a
day
or
two.
If
you
make
break
something.
A
A
Well
now,
then,
this
is
what
it
gets
annoying.
So
now
we
have
we're
saying
basically
you're
testing
against
master
right,
okay.
Well
now
what?
If
I'm
going
to
need
to
make
a
pr
in
the
downstream
repo
to
address
the
new
like
the
to
address
the
breaking
api
change
right,
and
so
when
you
do
that,
when
you
do
that,
you're
going
to
need
to
sort
of
re
yeah,
is
this
the
github
actions
yeah?
A
So
when
you
do
that,
you're
going
to
need
to
say
okay,
so
so
say
you
made
you
made
a
breaking
api
change
right.
I
have
to
change
the
documentation
so
that
it
so
that
it,
you
know,
uses
the
new
command
line
flag.
Well
now
I
essentially
need
to
maintain
either.
I
need
to
maintain
two
versions
of
the
documentation
or
I
need
to
maintain
a
version
within
the
same
document.
I
need
to
maintain
different
commands
for
different
versions
of
the
of
the
the
dependency
right,
and
so
this
is.
A
A
You
see
what
I'm
saying
so
basically
and
then
okay,
so
then
here's
the
next
thing
that
happens
and
I'll
write
so
I'll
write
this
up,
but
I
just
wanted
to
explain
it
first,
so
you
specify
the
so
now.
You've
you've
broken
down
stream
right.
So
now
you
need
to
go
to
downstream
and
you
need
to
update
the
documentation
of
downstream
to
be.
You
know
what
what
it
should
be
for
the
new
or
no,
maybe
we
got
rid
of.
I
think
I
actually
maybe
I
got
rid
of
that
change
in
the
documentation
thing.
A
I
remember
what
that
was
related
to
okay,
so
you
update
the
documentation
right
so
now
the
documentation
is
that
pull
request
in
the
downstream
repo
is
valid
only
if
the
pull
request
in
the
upstream
repo
is
merged
right
or
in
in
the
dependency
rep
or
in
the
yeah.
You
know
what
I'm
saying
in
the
original
pr.
Only
if
the
original
is
pr
is
merged.
So
then,
essentially,
what
you
end
up
with
is:
okay
before
you
merge
that
pr
yeah,
no,
the
versions
of
the
things
that
was
a
different
thing.
A
A
So
if
you
have
so
all
the
ci
passes
on
these,
both
these
pr's
right,
so
you
have
the
one
in
the
the
you
know
in
the
dependency
and
then
you
have
the
one
farther
downstream.
You
know
the
dependent
repo
where
you've
changed
the
documentation
in
accordance
with
the
api
breaking
change.
So
now
your
job
is
valid.
Your
valid
your
java
upstream,
is
valid.
A
If
you
use
the
upstream
p,
if
you
apply
the
pr
upstream
pr
when
you're
doing
the
downstream
ci
validation
of
that
documentation,
then
you
need,
but
you
need
both
of
those
things
to
go
through
at
the
same
time
or
else
the
whole
thing,
or
else
you
end
up
in
a
broken
state
right.
So
this
is
where
the
locking
comes
in.
So
essentially
you
end
up.
You
could
have
a
bot
that
sits
there
and
says:
okay
status
checks
pass
right
and
approvers.
You
know,
and
the
approvers
have
given
their
approval
right.
A
So
now
merge
almost
like
a
domino
merged
from
downstream
back
to
upstream
so
trigger
the
the
merge
in
the
in
the
downstream
repo.
So
the
one
where
we
made
the
documentation,
train
change
so
do
do
the
merge
and
then
that
ci.
So
when
that
ci
job
kicks
off,
it's
gonna
need
in
it.
Some
information
that
says
don't
run
until
the
upstream
has
hit
you
know
has
has
merged
that
plug-in,
so
just
in
the
event
of
a
race
condition
there
so
that
you
merge
the
downstream.
Then
you
merge
the
upstream
right.
A
A
A
A
Users
might
only
want
to
use
dfml
for
a
specific
use
case
right
and
for
them
you
know,
say:
maybe
they
wanted
to
use
the
transformers
code
which
we
had
to
take
out
right.
Well,
they
might
be
okay,
just
using
an
old
version
of
dffml
because
they
want
to
use
transformers,
in
which
case
it
would
be
nice
if
there
was
some
command
where
they
could
say
check.
A
If
my
installed,
you
know
my
installed
environment
right
all
the
packages
and
all
the
versions
that
I
have
right
now
are
compatible
with
this
tutorial,
and
this
would
prevent
people
from
not
understanding
why
things
aren't
working
so
basically
with
the
tutorials,
when
we
build
the
doc
site,
we
would
log
information
that
says
these
are
the
versions
of
these
plugins
that
are
used
in
the
tutorial
that
we
tested
this
tutorial
against
and
that
way
users
could
run
some
command.
That
goes
and
parses,
maybe
some
block
out
of
the
tutorial
and
tells
them
hey.
A
Yes,
you're
running
the
version,
the
same
version
of
dffml
in
the
same
version
of
all
these
plugins
that
you
know
the
tutorial
assumes
that
you're
going
to
be
running
and
what
was
about
the
I
don't.
Maybe
maybe
that
thing
with
the
docs
I
think
I
might
have
thrown
away.
I
have
a
bunch
of
notes
on
my
phone
that
I'm
trying
to
type
into
here.
A
I
think
that
might
have
been
an
old
version
because
yeah
that
that
it's
not
it
doesn't
end
up
being
that
that
ends
up
being
a
disaster,
anyways
so
okay,
so
that
was
that
so
then
we
wanted
to.
I
just
want
to
let
you
guys
know
that
I
have
to
do
that
and
that's
what's
good,
it's
going
to
be
a
giant
sort
of
ci
thing,
but
I
think
it'll
it'll
end
up
being
it'll
end
up
being
manageable,
so
cache
download
logging,
so
api
docs
are
still
out
of
sync.
A
A
Okay,
so
what
do
we
got
here?
Okay,
it
looks
like
things
are
being
put
into:
let's
see,
config
loader
dude.
Do
we
actually?
No,
we
actually
just
have
this
much
code.
Okay,
the
feature
feature
high
level
high
level.
Okay,
we
have
a
high
level
dot,
rst
and
high
level
okay.
So
maybe
this
is
part
of
what's
going
on,
let's
see
no
async.
B
A
B
A
A
B
A
Yeah
exactly,
I
think
one
of
us
will
tackle
this
offline.
I'm
I'm
happy
to
look
at
this.
Why
don't
I
look
at
this
because
if
I
do
the
second
party
stuff
well,
is
that
even
related
to
the
second
party
stuff-
I
don't
know
we'll
just
leave
it
up
there.
The
main
thing
is
we'll
we'll
fix
it
before
beta
or
before
our
next
release.
You
know
whatever
our
next
release
is
that
one
definitely
has
to
be
in
there.
A
A
A
So
what
this
comes
down
to
is
right.
You
know
just
so
we
all
recap
here,
but
basically
you
know
we.
We
have
certain
things
which
would
would
like
to
know
something
about
the
models
right
and-
and
the
first
thing
that
comes
to
mind
is
maybe
like
the
auto
ml
stuff.
You
know
right,
it
might
want
to
know
that
you
might
give
it
a
regression
regression
problem,
and
you
know
it
would
like
to
be
able
to
pick
all
the
applicable.
You
know
all
the
regression
models
right,
so
it
could
try
them
right.
A
Let's
see
what
model
trained,
not
strange.
Okay,
this
is
slightly
different,
so
this
is
about
properties,
and
this
is
maybe
another
method
that
we
might
need
to
add
to
the
model.
So,
let's
see
what
else
did
we
say?
So
what
should
be
the
correct?
Defining
model
type
should
be
property
and
model,
mainly
well-defined
model
class,
or
should
be
a
config
property
which
is
immutable,
and
we
have
an
exhaust
list
of
types
to
choose
from
both
cases
need
an
exhaustive
set
of
types
yeah.
A
I
believe
we
do
need
an
exhaustive
set
of
types.
This
anytime.
We
need
sort
of
an
exhaustive
set
that
usually
screams
plug-in.
You
know
so
that
we
can
define
more.
I
thought
about
the
word.
Usage
might
be
a
little
better
like
the
model
usage,
but
that
might
not
be
the
right
word.
Either.
I've
had
a
hard
time
trying
to
figure
out
what
is
the
name
for
classifier
regressor
or
you
know
clustering,
like
I
haven't,
seen
sort
of
an
official
name
for
that.
You
guys
might
know.
A
If
there
is
one,
let's
see
oh
and
then
we
talked
about
you
know.
So
if
it's
a
plug-in,
it
becomes
easy
to
override
with
config
and
then
there's
the
question.
Okay,
I
didn't
see
this
great,
then
there's
the
question
of
like
scope.
You
know,
should
we
be?
Let's
read
what
you
said:
shapes
numerator
types
from
the
types
mentioned
above
one
may
be
a
subtype
of
the
other,
for
example,
nlp
and
cv
models
will
be
classified
under
classifiers
and
vice
versa.
A
B
A
A
A
You
know,
there's
the
pros
and
cons
of
that
is
you
know,
maybe
if
some
modules
implementation
could
understand
that
it
should
be
doing
one
thing
based
on
the
other.
You
know
you
could
argue
also
that
you
should
just
written
another
class
for
that
so
or
we
could
make
it
sort
of
a
class
scoped
variable
right.
That's
that's
some
kind
of
metadata
object,
which
is
probably
just
you
know,
an
act
config
with
these
things
defined
in
it.
A
Right
then,
is
there
any
things
that
must
be
declared
or
might
be
optional
would
be
a
good
place
to
go
from
there.
So
what
do
you
guys
think?
Do
you
think
there's
value
to?
Should
it
be
a
runtime
thing,
or
should
it
be
a
static
thing?
It
should
probably
be
yeah.
It
should
probably
be
a
static
thing
right
because
you
you
can't.
D
A
A
A
A
A
A
A
A
A
This
this
stuff
should
probably
be
yeah.
Okay,
this
should
be
a
new
okay.
I
already
said
that
yeah.
So
basically,
what
we
would
do
is
we
would
say
you
know,
in
these
sub
subclasses
of
this
thing,
that
I'm
writing
in
right,
now,
we'd
say
metadata
equals
and
then
probably
you
know,
model
blank
model
metadata.
A
A
A
If
we
add
a
new
plugin
which
needs
to
be
a
new
model
type
right,
then
it
needs
to
know
it
needs
to
pick
it
needs
to
be
able
to
dynamically
declare
its
new
type
so
that
we
don't
have
to
submit
a
pull
request
to
the
main
library
to
add
the
new
type
right.
So
this
needs
to
be
some
kind
of
entry
point
this
month,
so
model
metadata.
A
A
Supervision
model
metadata:
is
this
a
you
guys?
Are
you
guys
do
you
guys
have
thoughts
on
what
I'm
doing
right
now?
Should
I
should
we
do
this
right
now,
because
I'm
just
trying
to
talk
and
figure
out.
You
know
what
what
do
we
end
up
with
here?
I
think
we
end
up
with
you
know.
Each
of
these
properties
is
an
entry
point
right,
so
supervision
model
metadata
ends
up
being
a
base,
entry
point
and
then
the
model
metadata
itself
is
some
class
right.
This
is
some
data
class
or
like
this
is
some
ad.
A
A
A
Why
is
the
base
entry
point?
Okay
so
say,
for
example,
say:
nlp
cv
right
so
say
we
don't
have.
Okay,
maybe
let
me
okay,
so
okay,
say
there's,
so
we
have
supervised
and
unsupervised
for
supervision
right.
Maybe
there
was
partially
supervised
right
and
say,
for
example,
that
we
currently
have
supervised
and
unsupervised
models
right,
but
somebody
invents,
you
know
in
their
genius
moment
a
partially
supervised
model.
A
You
know
for
the
take
of
example
right
and
if
they,
if
we
had
like
an
enum
that
declared
whether
it
was
supervised
or
unsupervised,
they
would
have
to
go
and
make
a
pull
request
to
the
main
dfml
library
to
add
the
unsupervised
enum
right.
If,
but
if
we
use
a
a
plus
the
plugin
system,
they
can
define
a
new
plugin,
which
is
the
partially
supervised
plugin
right,
and
so,
if
you
listed,
if
you
did
supervision
model
metadata.load,
you
would
end
up
with.
A
You
would
end
up
with
a
list.
You
would
end
up
with
with
this
as
your
return
list
right
when
day
partially
supervised
supervision
model
metadata
rights.
You
see
what
I'm
saying.
So
if
you
did
this,
you
would
end
up
with
this
list.
If
they
registered
their,
you
know
they
would
register
their
new,
partially
supervised
type
right,
and
that
way
you
could
have
another
plugin,
which
says
I
know
how
to
act
on
partially
supervised
models
right,
and
it
knows
about
this
partially
supervised
model
metadata.
A
You
know
partially
supervised
thing
and
your
model
that
implemented
the
partially
supervised
thing
knows
about
this,
but
dfml
the
main,
the
main
library
we
never
have
to
hear
twice
about
partially
supervised,
because
we
don't
we're
we're
just
the
foundation
that
connects
the
other
things
right.
So
no
one
has
to
add
any
code
to
the
main
library
to
declare
a
new
supervision
status
right.
They
just
declare
the
entry
point
right,
and
then
they
end
up
with
that
that
you
know
they
end
up
with
that
supervision
status
right.
Does
that
make
sense.
A
A
A
A
Okay,
great,
so
we
should
write
up
an
adr
for
this
as
well.
I
mean
what
we
should
write
up.
What
we
should
do
is
we
should
just
where's
that
issue,
so
we
will
turn
this.
We
will
probably
do
the
implementation
and
then
turn
it
into
an
adr
right
just
so
that
we,
you
know,
just
I
think,
we're
all
on
the
same
page
here
like
we
can
write
it
down
afterwards,
because
you
know
you.
A
A
A
Okay,
so
basically
yeah
okay.
This
is
probably
very
deep.
I
don't
think
I
ever
maybe
publicized
this,
but
we
came
up
with
this
way
of
sort
of
defining
pre-canned
data
sets
on
the
fly
by
using
this
wrapper,
and
this
wrapper
essentially
creates
a
source
out
of
a
function,
and
so
basically
you
could
say
you
know
you
could
you
could
download
your
data
set
and
then
yield
as
the
source
of
the
correct
data
type
right
and
then
all
you
have
to
do
to
use.
A
It
is
just
say
you
know
import
my
training
data
set
or
you
can
use
it
from
the
command
line.
You
know,
as
as
you
would
so,
it's
just
sort
of
a
when
you
say
dot
source.
So
it's
a
it's
a
shorthand
right
where
we
can
basically
take
a
function
and
turn
a
function
into
an
entire
source
right,
so
we
eventually,
let's
see
so
so.
This
is
the
type
of
thing
that
that
you
know
we
can
create
helper
functions
to
make
goddammit.
We
can
create
helper
functions
which
would
make
defining.
A
For
example,
I
mean
you
could
say
supervision
model
metadata,
equals
base
entry
point
okay,
like
make
base
entry
point.
How
would
you
you
know?
I
think
this
is
already
pretty
much
as
yeah.
This
is
already
pretty
you.
Could
you
could
make
it
something
like
this
right,
but
and
then
you
could
say
I'm
making
true
point.
A
A
A
A
We
might
declare
some
of
these
in
the
base
package
right,
we'll,
probably
declare
one
set
of
them
in
the
base
package,
and
this
could
be,
you
know,
a
nicer
way
of
declaring
them,
and
we
could
then
have
this
enum
thing.
Do
it
basically
would
handle
the
creation
of
these
classes
with
the
entry
point
decorators
appropriately.
A
D
A
A
A
I
don't
know
if
either
of
you
were
wanting
to
commit
to
pick
this
up,
but
this
is
a
little
bit
more
information
if
you're,
if
you're,
not
wanting
to
pick
this
up,
I
wasn't
assuming
that
somebody
was
trying
to
pick
this
up
right
now,
but
if
one
of
you
wants
to
great,
if
not
we
can
keep
sort
of
talking
about
it,
it
might
be
good
to
do
a
little
more
talking.
I
think
this
is
pretty
much
it
though,
like
does
that
sound
good
everybody.
A
A
Okay,
great,
let's
call
that
done
okay.
So
what
else
do
we
have?
So
we
have
the
cash
download
logging
fix
pr
review.
So
let's
just
do
pr
review
real
quick,
because
I
think
I'll
probably
just
I
think
I
skimmed
that
logging
one.
So,
let's
see
so
because
you
you,
you
have
seen
your
own
pr
hill
and
wait
now,
I'm
clicking
on
it.
I'm
clicking
all
the
wrong
things.
Okay,
so
let's
review
this
and
all
reviews
viewers
offline
or
if
we
get
to
it
somehow
for
the
10
minutes.