►
From YouTube: CNCF SIG Contributor Strategy 2020-09-24
Description
CNCF SIG Contributor Strategy 2020-09-24
A
A
A
A
A
This
discussion
started
this
discussion,
the
contributor
growth
working
group,
but
it
really
needs
to
be
in
the
main
meeting
here,
which
is
we're
busy,
generating
a
lot
of
content
via
contributor
strategy,
and
one
of
the
questions
is:
what
is
our
publication
path
for
the
various
kinds
of
content?
I
mean
for
the
templates,
it's
obvious
right.
We
just
update
the
main
branch
of
the
templates
repository
and
anything.
That's
in
the
main
branch
is
basically
done.
A
C
A
Either,
but
for
other
stuff,
like
feedback
and
additional
material
and
requirements,
the
various
advisory
documents,
you
know
in
terms
of
you
know:
hey
here's:
how
to
select
project,
here's
ways
to
select
project
leadership,
et
cetera
that
we've
been
busy
writing
you
know,
what's
the
path
to
go
from
work.
Draft
work
in
progress
to
this
is
a
official
resource
for
the
cncf.
A
D
C
C
D
A
A
D
Our
general
idea
was
at
least
for
our
documentation
specifically,
was
providing
a
set
of
recommendations
right
and
a
very
controlled
space,
so
whether
it
be
a
repo
subdirectory
somewhere
that
will
eventually
be
proposed
to
some
body
in
the
cncf.
Maybe
that
maybe
we
call
that
the
tfc
and
and
then
at
the
point
at
which
that
higher
body
approves
the
documentation
for
use
across
the
project
or
foundation,
we'd
move
it
into
somewhere
more
official,
so
maybe
that
is
contribute.
D
Maybe
that
is
the
cncf
foundation
repo,
I
think
foundation's
name
of
it.
So
there
are
a
few
options,
but
we
do
want
to
make
sure
that,
like
the
documentation
that
we
say
is
like
under
review,
do
we
want
to
have
a
separate
under
review
section
that
eventually
gets
graduated
or
a
set
of
decisions
to
potentially
make
like
these?
Are?
These
are
in
review.
These
are
newly
proposed.
These
are
these:
are
graduated
decisions
and
now
live
in
some
canonical
place.
A
Yeah
and
and
that's
something
I'm
particularly
for
requirements,
material
that
very
definitely
needs
to
have
an
official
approval
chain.
I
mean
advice,
is
advice
and
it's
really
it's
more
important
for
it
just
to
be
noted,
which
items
are
finished
rather
than
which
items
are
approved.
If
you
follow
me
because,
because
it's
not
like
you
know,
it's
not
like
we're
going
to
cause
major
political
problems
with,
with
general
advice
the
but
knowing
the
toc,
I
will
say
we
will
get
a
lot
further.
A
D
A
A
A
A
So
requirements
would
require
a
small
structural
change.
The
requirements
would
at
least
right
now
go
under
the
toc
directory,
because
that's
where
the
sort
of
general
requirements
documents
are
the
concern
about.
That
would
be
that
those
would
need
to
turn
into
directories
instead
of
single
documents,
because
right
now,
they're
single
documents
right
now.
There's
this
omnibus
document
that
is
project
maturity.
I
forget
exactly
what
the
file
name
is
within
cncf.
A
That
covers
the
whole
maturity
cycle,
and
it
doesn't
make
sense
to
make
that
single
document
150
pages
long
in
order
to
include
all
the
backing
material
that
we
will
eventually
generate.
So
you
know
so
we'll
need
to
approach
the
toc
with
the
idea
that
hey
this
should
actually
be
a
directory
with
multiple
different
documents.
A
F
D
So
I
guess
for
the
so
because
it's
in
the
repo
it's
technically
published
already,
what
we
want
is
the
once
it
has
been
approved
or
ratified,
or
you
know,
becomes
law.
Where
should
it
live
right?
Maybe
that's
toc.
Do
we
feel
that
the
toc
repo
is
the
most
representative
of
where
we
want
this
information
to
be.
A
D
C
C
I'll
also
say
this
that
it's
kind
of
awkward
and
undiscoverable
to
have
just
a
bunch
of
random
markdown
files
and
a
github
repo
yeah.
One
thing
is
to
have
something
that's
collected
together
and
actually
publish
like
a
website,
as
opposed
to,
like
I
said,
just
hear.
Some
markdown
files
have
fun
reading
them,
you'll
never
find
them
if
they're
just
randomly
in
the
toc
repo.
Unless
you
are
already
heavily
involved
in
everything
and
knew
where
they
were
to
begin
with.
B
Yeah,
I
would
agree
with
that.
If
you
look
at
what
the
to
do,
group
has
done
with
some
of
their
guides
they've,
you
know
they've
they're,
all
in
in
the
repo
and
they've
got.
You
know,
that's
where
all
the
development
happened,
but
then
they
have
like
a
guides
section
on
the
website
that
has
all
of
the
all
of
the
guides
in
a
place
where
you
can
easily
find
them,
and
you
don't
have
to
dig
through
a
repository.
D
C
A
C
Oh,
I
had
one
more
thing
about
when
we're
having
documents
that
aren't
published
already,
I
would
suggest.
Maybe
we
also
put
something
in
the
document
itself
saying
that
it's
not
published
and
done
yet
it's
still
draft
just
having
it
in
a
folder
on
our
github
repo.
This
is
the
folder
path
is
draft.
I
think
it's
pretty
subtle
for
some
people
and
they
may
find
it
and
then
think
it's
real
and
not
know
our
convention
that
that
well,
it's
in
a
folder
called
draft
like
it's
pretty
easy
to
overlook
a
url
like
that.
C
A
A
B
D
C
D
So
I
think
what
might
be
cool
is
that,
as
we
publish
things
into
this
newfangled
place,
that
it's
going
to
live,
that
we
start
removing
them
from
the
repo
as
well
right
and
we
can
maybe
tabulate
a
like.
These
are
lists
of
decisions
that
we've
made
right,
and
this
is
where
the
final
decision
guidance
lives
right.
That
way,
there's
no
duplication
of
content
and
like
yeah,
we
have
to
we'll
have
to
strip
a
draft
header
once
but
like.
I
think
we
can
live
with
that.
A
Yeah,
well,
I
don't
think
it
needs
to
be
anything
more
than
italicized
text
at
the
top
of
the
document
that
says
this
document
is
currently
under
review,
yeah.
So,
okay,
the
so
I
guess
my
question
is:
do
we
want
to
propose
basically
a
new
site
for
this,
or
do
we
want
to
propose
that
this
lives
somewhere
under
cncf.io.
D
Both,
I
think
the
I
think,
cncf,
I
think,
with
a
new
netlify
site.
It
should
be
fairly
easy
to
if
cncf.io
is
already
nullified,
which
it
probably
is
to
stick
a
link
into
a
different
repo
reference
right,
so
that
content
can
live
in
one
repo,
but
it
can
the
site
can
link
out
to
it.
So
I
think
we
we
do
some
of
that
across
kubernetes
already
as
well.
A
F
F
G
No,
I'm
not
sure
again,
as
you
mentioned,
it's
it's
way
easier
to
set
up
the
dedicated
sub
domain
for
samsung
at
cnc.io
and
to
have
it
redirected
or
to
use
the
existing
contribute
dot
cnc
of
the
dial
sub
domain,
but
it
will
be
even
difficult
and
I'm
not
sure
completely,
I'm
not
sure
if
there's
a
strong
purpose
to
do
something
on
there.
Cncf.Io.
G
The
easiest
way
here
is
to
try
to
set
up
the
github
pages
which
are
pointing
to
the
contribute
triple,
and
in
this
case
this.
This
can
also
solve
both
scenes.
Steven
mentioned
it's
easier
for
folks
to
contribute
if
you
are
contributing
something
and
people
have
experience
with
git.
So
it's
easy
to
contribute
content
where
we
are
gateway
github
as
a
code,
and
if
this
reaper
is
set
up
as
the
github
pages,
it
will
appear
there
automatically
so
that
that's
probably
the
easiest
way
to
handle
this.
D
D
D
G
G
A
D
So
I'm
thinking
like
some
of
it
is
it's
it's
guidelines.
Some
of
it
is
advisory
like
I,
I
worry
about
choosing
a
name
that
is
like
I.
I
think
the
name
should
be
descriptive
enough,
that
we
know
what
we're
getting
out
of
it,
walking
into
it
right.
If
someone
ends
up
in
our
if
someone
ends
up
in
our
repo,
I
think
it
is
valuable
for
us
to
put
something
of
a
note
that
the
content
herein
is
advisory
and
not
officially
ratified
by
some
cncf
body,
yada
yada
for
things
that
we
have.
D
G
Within
we
can
we
can
explicitly
mention
the
c
contributor
strategy
on
within
the
contributors
report
with
me
so
like
just
to
mention
that
there
is
some
x-ray
advisor
content
available
at
this
contributor
stretch.
Report
that
you
can.
You
can
also
be
interested
in
if
you
don't
want
to
put
everything
into
the
same
place.
D
Well,
alternatively,
we
could
rename
our
repo
to
something
and
let
our
repo
content
kind
of
shift
around
the
directories
and
let
our
repo
content,
be.
You
know
if
you
want
to
see
drafts
of
the
things
that
we're
working
on
go
here.
If
you
want
to
see
things
that
have
been
officially
approved
by
the
toc
go
here
so.
D
F
F
D
B
Talk
about
it,
the
more
unsure
I
am
about
that
because
to
me,
like
you,
think
about
like
the
contribute.md
files
you
see
on
on
github,
that's
about
how
to
contribute
to
a
project
and
that's
kind
of
what
this
contribute
repo
already
has.
So
it's
you
know:
how
are
you
interested
in
contributing
to
one
of
the
cncf
hosted
projects?
Here's
a
big
list
of
projects
you
can
contribute
to,
and
what
we're
talking
about
more
is,
I
don't
know,
sort
of.
A
B
G
D
G
We
can
easily
mention
that
as
well.
So
if
you
go
to,
if
you,
if
we
walk
through
the
contributory
board
in
the
bottom,
you'll
notice
that
we're
not
not
on
only
mentioning
cncf
projects
there,
but
also
some
different
ways,
how
can
you
contribute
to
to
cncf
ecosystem?
So
the
original
intention
of
this
trip
was
to
just
to
put
just
to
have
the
single
point
of
reference,
and
how
can
you
be
useful
in
the
kubernetes
community?
G
You
can
start
with
contributing
to
projects
you
can
also
do
you
can
contribute
to
at
the
toc
level
like
to
be
the
uc
contributor,
you
can
contribute
to
the
community
to
the
ecosystem
like
running
the
meetups
running,
the
community
groups
being
an
ambassador
and
so
on.
So
the
original
goal
of
developing
this
trip
is
just
to
have
all
the
useful
links
on
how
to
get
started
with
this
in
a
single
place.
It's
not
about
projects,
it's
about
all
the
all
the
useful
links,
and
we
can
definitely
restructure
that.
D
Yeah,
so
I
think
I
think
that
the
you
know,
a
lot
of
the
content
is
going
to
be
geared
towards
maintainers
or
people.
Looking
for
maintainership,
we
had
talked
about
maintainers.cntf.io
before
right
now
that
redirects
to
just
the
google
sheet,
and
I
think
that
a
link
to
the
google
sheet
could
just
as
easily
live
in
this
new
repo.
B
Because
a
lot
of
our
guides
are
going
to
be
more
about
how
to
how
to
set
up
governance,
how
to
measure
whether
you're,
successful
or
not.
It's
not
really
how
to
contribute
to
things.
It's
really
how
to
set
up
your
project
for
success
from
a
contribution
standpoint,
which
I
feel
is,
is
different.
Getting
back
to
what
josh
said,
I'm
I'm
not
proposing
it.
I
can't
think
of
anything
better.
This
is
my
problem
I
feel
like
contributes
not
right,
but
I'm
struggling
to
find
something
better.
F
D
Else
I
mean,
but
previously
we
had
discussed
that,
like
is
maintainers
even
super
useful
having
this
displayed
as
a
google
sheet
right,
ideally,
ideally
as
a
maintainer,
as
I'm
onboarding,
a
a
new
project
for
the
cncf,
hopefully
the
process.
I'd.
Imagine
the
process
eventually
getting
to
simpler
points
where
you're
putting
you
know,
you're,
essentially
putting
stuff
into
a
yaml
file,
lovely
love,
yaml,
right
and
and
running
some
script,
and
that
you
know
and
that's
generating
a
you
know,
that's
generating
a
new
list
of
maintainers
or
updated
lists
of
maintainers.
D
A
D
D
D
A
G
Games
just
just
to
close
the
discussion
with
contributor,
sorry
for
interrupting
josh.
So
if
you,
if
you
have
any
suggestions
on
that
on
the
currently
existing,
was
the
person
who
originally
was
building
it
from
mostly
from
scratch,
so
I'm
happy
to
collaborate
with
you
if
you
have
any
specific
items
for
what
can
we
implement
here?
So
just
let
me
know.
A
C
No,
no,
of
course
not.
I've
submitted
a
template
to
our
project
template.
If
people
could
take
a
look
at
it
again,
the
goal
for
these
is
we
stopped
doing
kit.
I'm
sorry,
google
docs
and
we
just
start
doing
prs
for
everything,
and
people
want
to
do
more
changes
on
top
of
them.
We'll
encourage
pull
requests
instead
of
endlessly
asking
one
person
to
do
the
edits
for
them,
and
then
paris
is
working
on.
C
You
know
I
think
yeah
system
here
she's
working
on
community
management
documents
like
how
to
contribute,
recruit
contributors
and
I'm
working
on
taking
the
good
first
issue
guide
that
I
wrote
for
kubernetes
and
refreshing
it
and
making
it
not
specific
to
kubernetes
workflows.
So
we
can
put
it
up
at
the
cncf
level.
H
A
A
F
Here's
the
thing
paris
wants
to
be
able
to
actually
do
a
survey
about
you
know
being
able
to
get
people
to
register
for
the
maintainer
circle.
Piece
in
here
I
have
looked
at
the
calendars,
and
there
is
a
lot
going
on
in
here,
so
like
adding
in
another
meeting
is
probably
not
going
to
be
as
relevant.
My
suggestion
was
taking
one
of
the
normal
contributor
strategy
meetings
and
putting
maintainer
circle
in
here
and
correct
me
was:
was
this
actually
the
plan
in
the
first
place?
This.
D
F
D
F
Their
goal
here
is
to
be
able
to
do
like
breakout
for,
like
10
people,
breakout
groups
based
on
the
amount
of
frankly
people
that
we
get
in
these
meetings.
I
don't
know
that
breakout
meetings
are
going
to
be,
as
compel
I
read
exactly
like
certainly
figure
out,
if
I
can
turn
it
on
for
these
meetings.
That's
fine,
but
you
know
I
don't
know
if
it's
meaningful.
That's
all.
A
Yeah,
I
mean
one
thing
I'll
say
for
this
particular
meeting
time:
slot
is
not
terrifically
friendly
to
europe.
Dawn
is
up
late
here
and
it's
well
not
super
late,
but
it's
still
dinner
time
and
and
it's
definitely
not
friendly
to
asia.
So
yeah
we'd
want
to
have
some
around-the-clock.
You
know
things
different
time.
D
Slots
yeah,
so
you
know
what
could
happen.
Is
a
us
east,
emea,
time
slot
and
a
us
west
apac
time
slot,
and
we
can
probably
find
some
balance
there.
I
think
that
I
think
that
at
least
starting
in
this
time,
slot
will
get.
You
know
allow
us
to
key
in
on
some
things
that
we
might
want
to
tweak
if
we
expand
to
multiple
meetings,
but
I
would
agree
with
the
whole,
like
thursday.
D
D
C
Had
a
topic
yeah,
it's
not
a
fun
topic,
though,
but
I
hear
this
actually
more
than
any
of
these
other
things
that
we're
talking
about.
Currently
a
lot
of
stuff.
We
talk
about
adds
to
the
time
commitment
to
maintainers,
but
every
single
maintainer
I've
talked
to,
especially
this
year
has
been
saying
that
they
are
over
subscribed,
essentially
and
they're.
C
Looking
for
ways
to
keep
the
project
going
and
just
kind
of
deal
right
now
without
hurting
the
project
right,
they're
dealing
with
the
backlog,
they're
trying
to
not
lose
people
but
at
the
same
time
they're
trying
to
keep
features
going
or
deal
with
security
issues
that
are
coming
up
and
just
all
the
various
things,
and
it's
like.
We
can't
maintain
the
level
of
like
fostering
new
contributors
and
doing
all
the
various
things
we
need
to
do
that.
C
Our
group
actually
talks
about
as
being
really
important
good
stuff
to
do
at
the
same
time,
because
there's
a
lot
going
on
and
there's
lopping
asks
of
maintainers
right
now.
So
how
do
you
go
into
like
yellow
alert,
I
guess
and
take
care
of
your
project
and
not
trash
your
project
while
you're
taking
care
of
things?
I
guess
that's
what
I'm
hearing
people
talk
about.
D
No,
I
I
love
it
and
I
feel
it
too.
You
know
I
feel
like
every
every
interrupt
that
we
get
like.
Sometimes
you've
got
your
schedule
in
line
like
it's
perfect
you're
like
I
know
exactly
what
I'm
gonna
do
this
week
and
there's
like
one
interrupt
that
comes
and
just
throws
the
entire
thing
out
of
whack
and
yeah,
and
it's
usually
never
just
one
so,
and
you
know
when
this
happens
across
multiple
projects
and
different
venues
and
foundations,
it's
yeah,
it's
super
stressful,
so
I
yeah.
C
Yeah
yeah,
because
I'd
love
to
like
support
support
people
with
this,
because
this
is
like
this
is
really.
This
is
really
hard
to
figure
out
and
I
feel
like
some
projects
aren't
like
doing
so.
Well,
I
had
to
like
set
down
my
project
for
a
couple
months
and
that
really
sucked
and
it
hurt
the
project,
and
I
don't
know
how
to
have
done-
that
better.
C
F
So
I
think,
being
able
to
like
start
from
that
as
a
base
to
be
able
to
say
what
would
it
be
like
if
we
were
considering
resiliency
as
we
were
kind
of
looking
at
schedules
and
road
maps
and
kind
of
like
how?
How
could
I
actually
make
this
easier
for
everyone,
including
me,
because
I
love
this
baby
little
project
and
I
wanted
to
succeed.
But
I
also
understand
that
my
availability
is
really
inconsistent
right
now.
Given
that
what
do
we
do
next,.
D
I
think
yeah,
I
think
one
of
the
trickiest
parts
of
this
is
is
it
becomes
another
interrupt
rate.
It
becomes
something
that
you
have
to
like
sit
down
and
consider
at
least
for
sig
release,
and
maybe
this
is
actually
a
discussion
for
the
time
that
we
discussed
this
right.
But
you
know
for
sig
release.
We
recently
brought
on
two
new
technical
leads
and
a
program
manager
right,
and
I
think
you
know
it's
the
first
time
that
we've
done
our
people
have
done
a
program
manager
like
embedded
in
asig.
D
So
there
are
growing
pains
and
there's
like
an
additional
there's,
an
additional
overhead
for
like
interrupts,
bringing
people
up
to
speed
so
that
they
can
help.
You
shift
shift
the
workload
right.
So
it's
like
it's
like
yes.
I
know
I
need
to
do
this
thing
or
I
know
we
as
maintainers
need
to
do
this
thing,
but
right
now
it's
another
meeting
or
it's
another
set
of
meetings
before
we
get
to
some
reasonable
outcome
right
totally.
F
And
I
think
a
lot
of
that
is
also
looking
like
what
are
the
priorities
for
the
project
like
what
could
fall
off
and
no
one
will
like?
No
fairies
will
fall
and
what
things
can
we
push
off
towards
hey,
perhaps
in
spring
we
could-
and
I
guess
I'm
using
more
of
like
the
program
manager,
like
expectation
of
if
we
didn't
do
this,
what
would
happen?
D
D
And
you
know
I
I
you
know
this
is
like
internal
gripes
from
the
past,
like
I
think
of
you
know,
I
think
of
the
potential
things
that
we
could
have
done
in
sig,
pm
and
and
kubernetes
right,
and
you
know
just
hearing
project
project
roadmap
right
and
having
an
idea
of
like
what
we're
actually
going
to
be
able
to
deliver.
That
comes
from
being
able
to
aggregate
the
ideas
of
multiple
maintainers
right
and
have
them
deliver
those
things
at
on
a
certain
timeline
right.
D
Right,
maybe
you're
an
engineer
who
is
like
fairly
organized
like
cool
you're
kind
of
like
our
pm
person
now
you're,
like
whoa
hold
on.
I'm
not
sure
I
signed
up
for
that,
and
you
know
so.
There's
there's
a
lot
going
on
with
with
maintainers
in
general,
where
they're
wearing
maybe
five
hats
that
could
be
you
know
delegated
out,
but
also
delegating
out
takes
time.
So,
yes,
I
think
this
is
an
excellent
topic
to
talk
about
yay.
D
All
right,
so
we
do,
I
mean
like
let's,
let's
hype
it
up,
you
know
it's
and
we
have
to
figure
out
times
right
when
we're
officially
going
to
kick
these
things
off,
so
that
was
pierce's
question
of
when
yeah,
because
we
is,
I
think
last
we
talked
about
what
kickoff
looks
like
we
were
like.
Well,
let's
just
there
was
there
was
a
want
to
do
something
for
for
kubecon
and
have
that
be
like
a
kickoff
event,
but.
D
F
So
you've
got
a
couple
different
options
here.
You
could
track
towards
being
able
to
take
like
the
october
8th
meeting
for
this
particular
group
and
saying
man.
That's
something
we
really
want
to
do.
You
could
promote
it
at
the
tuesday
october
6th
toc
meeting
and
that
kind
of
leads
from
there
and
that
that
means
that
you
don't
have
to
have
a
lot
of
momentum
in
order
to
be
able
to
make
this
work.
F
D
Yeah,
I
would
lean
towards
something
later.
I
would
lean
towards
the
22nd
meeting
for
myself
at
least
I
will
have
limited
ability
to
facilitate
all
of
this
or
some
of
these
things
with,
like
all
of
my
attention,
because
I'm
also
that'll
be
the
point
at
which,
like
kubecon
prep,
is
already
getting
pretty
crazy.
So
we're
working
on
program
review
stuff
right
now
and
it
will
only
get
deeper
as
as
october
goes
on
for
me.
So.
D
I
don't
have
a
good
answer
here
and-
and
you
know
maybe
it's
we
wait.
Maybe
it's
we
wait.
We
get.
You
know
we
get
the
conversations
going
on
mailing
lists.
We
could
be
doing
more
to
hype
up
the
fact
that
we
have
a
mailing
list.
I
think
a
lot
of
the
discussions
that
could
happen
on
the
contributor
strategy.
Mailing
list
are
currently
still
happening
on
the
toc
list
right.
So
I
think
the
tfc
list
becomes
this
kind
of
like
garbage
bucket
for
anything
to
potentially.
B
D
B
B
Combining
this
into
kubecon,
because
the
I've
been
on
the
soapbox
for
for
months,
but
the
idea
of
combining
everything
around
when
everyone
is
physically
going
to
be
in
a
place
is
not
the
same
as
trying
to
combine
everything
around
a
virtual
conference
where
we're
sitting
on
video.
It's
not.
It
doesn't
work.
D
D
I
would
love
to
start
something.
I
don't
know
what
that
something
exactly
looks
like
and
I,
but
I
do
think
it's
fine
to
start
something
small
and
see
at
least
get
feedback.
I
do
worry
about
continuing
to
wait.
Post
cube
con
like
we're,
gonna,
blink
and
kubecon
will
be
upon
us
as
as
usual,
but
it
it
is
in
november.
So
there's
a
bit
of
time
that
we
could
be
doing
stuff
if
we
wanted
to.
C
B
F
D
Okay,
all
right
so
yeah,
we'll
plan
to
plug
on
the
october
6th
meeting
and
maybe
try
to
do
something
not
for
the
8th
but
the
22nd
at
least
so.
We
can
have
one
more
meeting
here
where
we
have
all
the
chairs
in
attendance
potentially
to
I
don't
want
to
make
this
decision.
You
know
for
everyone
little.
F
F
F
No,
the
to
recap:
the
conversation
was
really
looking
at
the
maintainer
circle
kind
of
planning,
on
tracking
towards
the
22nd,
for
that
and
the
piece
that
has
really
kind
of
risen
up
as
a
a
possible
topic
is
talking
about
oversubscribed
maintainers
burnout.
And
how
do
you
take
care
of
your
project
when
you
have
inconsistent
availability?
F
A
A
D
H
A
D
So
this
is
yeah.
This
moves
towards,
like.
Is
it
possible
to
do
a
recorded
session
style
situation?
I
would
say
I
would
say:
do
this
try
to
do
this
ahead
of
time,
because
this
is
again,
this
is
coming
up
for,
for
other
talks
precede
the
question
right
precede
the
question:
get
people
submit
the
kind
of
paperwork
that
they
want
to
cover
right,
and
then
you
have
a
basis
for
building
the
session
as
opposed
to
getting
caught
off
guard
with
anyone
potentially
popping
in
right.
A
A
D
Fair
yeah
there
is,
there
is
a
bit
of
clairvoyance,
that's
going
to
be
required
because
the
timelines
are
tight
for
everything.
So
just
a
suggestion,
I
would
say
it's
because
figuring
out
how
to
do
the
live
thing
is,
I
don't
think
is
a
solved
problem
right
now
and
I,
if
I
was
thinking
about
the
session,
I
would
think
about
like.
Let's
take
you
know
how
much
time
do
we
have?