►
From YouTube: Open RFC Meeting - Wednesday, June 10th 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we're piloting an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
We'll
continue
to
do
weekly,
open,
RC
calls
like
this
and
hopefully
having
more
and
more
folks
be
able
to
attend.
We
may
potentially
change
at
the
time
of
this
call
to
allow
for
more
folks
to
join
I
know
that
there's
being
interested
in
doing
essentially
alternating
times
for
for
folks
in
different
time
zones.
So
again,
that's
something
that
I
would
love
to
to
see
us
change
in
the
future
so
quickly.
A
So
if
you're
looking
for
that,
feel
free
to
read
up
and
please
be
find
and
raise
your
hand
when
people
are
talking
and
just
to
be
mindful,
as
we
have
these
conversations
also,
you
know
the
idea
of
these
calls
is
is
hopefully
to
move
forward
and
make
forward
progress
on
the
RFC's
that
are
listed
and
the
feature
work
being
done
on
the
NPM,
see
and
so
yeah
with
that.
Is
there
any
announcements
anybody
else
I.
A
A
The
team
obviously
is
hoping
to
to
get
a
lot
work
done
here
in
the
next
couple
months,
as
we
get
ready
to
essentially
release
at
least
a
beta
of
M
chem,
seven
and
hopefully
get
that
in
the
hands
of
folks,
so
expect
some
forward
progress
there
so
again
we'll
be
following
along
the
agenda.
An
issue
159
feel
free
to
add
your
yourself
to
the
hack
MD,
and
the
first
item
that
we
have
on
the
agenda
is
NPM
fun
depth.
So
issue
number
152
is
this:
if
this.
B
B
A
B
Sure
so
yeah
we
don't
yet
and
yeah
I'm,
not
sure
I'm
bored
on
the
idea
of
the
RFC
itself,
but
first
of
all
like
this
is
the
kind
of
contribution
we
want
to
see
more
right.
So
I
would
like
to
thank
Charlie
like
for,
for
taking
the
time.
I
know
he
mentioned
is
the
first
time
he
actually
submitted
IRC.
So
it's
awesome
is
the
kind
of
participation
we
wanna
see
from
the
community,
but
yeah
extension
with
the
the
flag.
B
B
So
it's
kind
of
hard
to
translate
that
that
the
the
meaning
of
that
flag
in
the
then
confirm
command
so
I
see
I,
see
this
as
being
like
a
big
technical
problem
in
actually
implementing
this
as
a
flag,
but
also
something
we've
been
discussing
the
background.
There
is
no
official
RC
yet,
but
we
might
be
looking
into
maybe
modifying
the
output
on
all
together
in
the
future
for
NPM
7.
So
all
that
combined
make
me
think
like
that.
It
is
not
the
right
moment
to
implement
that
idea.
B
C
A
comment
alternative
could
it
be
doable
if
we
did
something
similar
to
what
we
did
with
outdated,
in
which
we
added
this
new
flag
called
all
and
we
could
have
like
basically,
two
functionalities
like
show
me
all
the
all
the
fun
information
we
can
get
out
of
a
package
or
just
show
me.
There
is
any
direct
dependency
that
has
a
funding
information
so.
D
D
It's
very
useful
to
know
to
limit
things
to
direct
dependencies
with
a
lot
of
NPM
commands
right,
like
NPM,
LS
G,
for
example,
like
I,
just
want
to
know
a
list
of
the
things
that
are
installed
at
the
top
level,
and
you
know
similarly
like
with
NPM
LS
for
the
local
ones
right.
So
I
can
absolutely
see
a
use
case
for
NPM
fund
where,
with
just
having
two
modes,
one
mode
is
the
whole
tree
and
one
mode
is
direct
dependencies
and,
of
course,
always
having
the
like.
D
Only
modifier,
where
I
can
limit
it
to
prod
or
dev,
or
both
right
and
I,
feel
like
that
in
general
applies
to
almost
any
NPM
should
apply
to
almost
any
an
NPM
command
that
deals
with
the
dependency
graph,
and
so
it's
not
that
in
fact,
if,
like
from
reading
this
RFC,
they
don't
really
want
seem
to
want
depth.
They
seem
to
want
direct
depth.
D
Only-
and
that
seems
like
something
that's
useful,
regardless
of
what
the
format
of
NPM
fund
output
is,
and
that
seems
like
a
direction
that's
worth
exploring
and
in
fact
that
was
something
I
brought
up
in
the
original
NPM
fund
RFC,
which
was
like
well.
Why
does
it
display
transitive
by
default
right-
and
you
know
and
I
argue
that,
given
like
even
knowing
that
the
majority
of
my
dependencies
are
used,
transitively
but
like
so,
the
more
I've
been
brought
around
to
Isaacs
a
rigid
like
way
of
thinking
and
with
it.
D
He
originally
replied
to
me,
which
is
that
it's
good
to
by
default,
expose
the
transitive
depths
that
you
depend
on,
because
you
know
if
they
break
it's
often
worse
than
if
the
director
wants
break
like
that,
doesn't
mean
that
there
shouldn't
be
an
opt-in
way
to
restrict
it
to
direct
debts.
Like
Claudia
was
saying
as
well.
A
The
one
unique
thing
about
I
think
fun
was
the
fact
that,
if
we
only
like
whatever
the
default
was,
we
were
a
bit
concerned
that
if
we
were
only
bubbling
up
information
about
your
direct
dependencies,
you
really
would
never
know
just
how
like
how
much
you
depend
on
like
those
downstream
dependencies.
Those
transit
dependencies
oftentimes
are
the
ones
that
don't
you
know,
might
not
be
getting
funding,
because
that
that
information
wouldn't
get
really
bubbled
up
there.
A
The
lower
level
things
that
often
are
depended
on
on
the
most
but
may
like
in
terms
of
being
a
consumer
of
you
know
direct
dependencies,
I,
don't
actually
know
I
actually
really
don't
know
like
the
entire
graph
like
I.
Never
have
have
you
know
what
that
that
package
has
has
used
itself
like
in
terms
of
being
able
to
build
up
the
functionality
that
I'm
consuming
today.
A
That
was
like
one
I
think
originally
the
thinking
of
why
the
default
would
be
to
include
transient
tendencies
or
transitive
dependencies,
because
it's
that
was
kind
of
the
ideas
like
we
want
to
bubble
up
and
make
sure
that
people
had
a
good
understanding
of
the
the
sort
of
ecosystem
that
they're
there
they
were
depending
on.
So
that's
like
one
thing
to
keep
in
mind
when
we're
talking
about
maybe
changing
the
default
behavior
and
then
and
aligning
it
with
LS.
There
might
be
a
different.
This
might
be
a
different
use
case.
A
Just
because
of
that
right,
like
that's
the
only
like
angle
I
would
take.
It
is
to
be
mindful
of
the
fact
that
we
really
want
fun
to
act.
As
you
know,
a
platform
for
for
developers
to
get
better
understanding
of
the
you
know
backing
your
stack
like
that
kind
of
like
mythology
ideology
that
you
know
you
you
want
to
fund.
B
Yeah,
honestly,
like
one
of
the
things
I
was
a
kind
of
when
we
first
implemented
the
fund.
Some
commands
right.
We
were
kind
of
like
wait
and
see
how
the
ecosystem
will
evolve
around
it
right
and
even
today,
I
don't
get
the
feeling
that
is
too
overwhelming
the
kind
of
tree
output
we
get
printed
like
evenly
large
projects
like
if
you
do
a
great
react,
app
right
in
which
you
have
thousands
of
dependencies
in
your
node
modules.
B
It
is
still
quite
manageable
to
kind
of
like
parse
and
read
through
the
output
of
the
command,
so
I
yeah
I,
don't
know
if
the
attend
again
like
I
would
love
from
anyone
in
the
car.
But
is
the
sentiment
around
that?
Do
we
really
need
that
path?
Tutoring
today?
How
do
we
stand
like
the
echo
system?
Stand
right
now,
turn.
E
So
I
guess,
like
my
perspective
on
how
does
the
system
stand
right
now?
Is
there
needs
to
be
another
step
like
its
funded,
like
putting
okay,
so
say,
I
have
a
two
thousand
multiple
dependency
tree,
there's
two
hundred
in
there
that
have
funding
possibilities.
Many,
like
probably
six
of
those,
are
maintained
by
earn
like
150
those
are
maintained
by
six
people.
E
That's
like
an
overload
to
the
point
that
it
becomes
too
noisy
and
there's
not
a
meaningful
step
to
okay.
How
do
I
go
and
fund
the
things
I
depend
on
how
do
I
prioritize
those?
How
do
I
I
mean
like
communicate
that
to
the
people?
Who
will
actually
give
me
money
for
that?
Like
yes,
individuals,
you
and
I,
and
everyone
at
is
called
think
it'll
give
money
to
folks.
E
It's
just
like
I
think
something
that's
a
relative
reality
is
it's
not
scalable
to
fund
50
people
by
clicking
a
link
for
each
of
them,
and
so
going
through
and
taking
like
figuring
out
how
you
can
kind
of
do,
connect
the
funding
to
making
it
easy,
making
it
approachable
for
the
people.
We're
actually
gonna,
give
you
money,
and
that
stuff
is
something
that
I
think
would
need
to
kind
of
be
found
out
before
approaching
it
in
that
way
or
like
thinking
about
it.
In
that
way,
a.
A
Group
I
totally
agree
like
this
was
sort
of
like
the
phase,
one
like
of
that
idea
and
and
I
think
the
next
step
would
be
because
we
allowed
for
type
and
sort
of
like
a
definition
of
a
type
of
URL
or
reference
in
the
future.
Potentially
that
could
be
truly
some
some
mechanism
that
could
be
like
we
could
build
off
of
that,
and
it
is
tangential
to
the
RFC,
but
like
there
could
be
some
sort
of
way
of
identifying
how
to
actually
distribute
funds.
A
So
this
is
just
created
like
this
was
the
first
step
of
like
creating
and
identifying
that
you
know
there
that
this
information
lives
somewhere
and
then
make
him
out
a
little
bit
more
meaningful
by
being
able
to
actually
direct
it
and
creating
like
some
sort
of
system
to
actually
distribute
money
to
that
graph.
I
think
makes
sense
coming
back
to
like
how
that
reflects
with
like
this
depth
again
like
I.
Just
go
back
to
my
only
concern
around
trying
to
do
something
like
that.
A
The
zero
is
just,
it
seems
to
be
counterintuitive
with
really
supporting
a
like
the
idea
behind
bubbling
up
this
information.
The
first
place
was
to
support
more
of
the
ecosystem
and
the
defaults,
the
default
for
the
funding
output
post
install
if
you
haven't
added
the
no-fun
flag,
it's
just
like
a
one-liner
with
the
number
of
depths
that
have
that
information
in
there
there
package.json
so
I.
Don't
think
it's
that
noise
here
today.
A
Definitely
the
like,
you
said
like
if
it's
like,
there's
200
depths
or
mm
depth
and
200
of
them
have
it
listed
once
you
actually
run
the
NPM
fun
commit
it's
not
as
useful
as
it
could
be
for
sure,
and
we
are
looking
at
how
we
could
redesign
it
with
some
help
from
like
design
folks
at
github.
Actually,
so
we
may
be
able
to
present
some
that
in
the
future
here
so.
A
C
A
D
B
Origin
of
this
whole
discussion
right.
We
wanted
to
make
sure
we're
not
super
getting
the
information
from
transitive
apps
so
that
you
know,
because
some
of
these
packets
might
be
as
important
as
or
more
and
then
we
kind
of
just
want
to
make
sure
the
information
gets
blowed
up
people
just
don't
get
into
the
habit
of
just
checking
the
top-level
dependencies
and
ignoring
all
the
rest
yeah.
So
maybe
we
want
to
present
because
then
maybe
we
want
to
prevent
that
from
even
being
the
possibility
that
that's
more
of
what
I'd
say.
It's
more
of
I.
A
B
Make
it
a
sense
to
have
that
bad
shape,
but
but
jarda
brought
a
good
point
right,
it
might
have
a
different
shape.
It
might
be
just
we
all
conceived
like
we
are
kind
of
flying
in
the
other
commands
today,
but
maybe
we
want
to
prevent
in
order
to
kind
of
like
not
even
give
that
possibility.
B
A
D
C
A
D
B
E
Yeah
I
think
the
other
thing
I'd
say
there
is
like
one
of
the
things
that
you
know
if
you're
constrained
different
flags,
one
of
the
things
that
I
think
is
severely
undervalued-
and
this
is
something
I've
tried
to
you
know
when
I've
really
got
get
over
what
they're
doing
with
funding
I've
tried
to
communicate
to
them.
You
know
one
of
the
things
I
think
it's
severely
undervalued
is
how
often
something
comes
up
so
like,
especially
as
we
move
into
workspaces.
You
know,
if
you,
you
have
a
workspace
with
ten
different
projects.
E
Load
ashes
in
all
of
them.
200
times,
like
probably,
should
prioritize
trying
to
find
the
thing.
I
depend
on
most
and
very
often
with
how
I'm
p.m.
is
set
up.
The
things
you
depend
on
most
are
also
the
things
that
are
most
invisible
and,
like
the
things
you
like,
you
know,
people
people
think
about
react
like
oh
I
need
to.
You
know,
support
react,
because
this
is
something
I
depend
on,
but
then
there's
some
dependency
in
reacts
dependency
tree.
E
That's
there
30
40
times
and
that's
getting
nothing
and
not
that's
not
like
a
you
know,
shaming,
react
or
anything,
but
like
that
kind
of
structure,
I've
seen
over
and
over
and
over
again
and
so
servicing
like
what
do
I
use
most
please.
Let
me
fund
that
and
prioritize
that
is
I,
think
something
that
should
be
considered.
A
Yeah,
those
are
all
good
takeaways
I,
just
want
to
be
mindful
of
time
with
I
think
we
have
another
seven
items
and
there's
one
last
thing:
I
added
to
the
hack
and
Vidocq
as
well.
In
terms
of
trying
to
to
clean
up
some
some
implemented
our
C's.
We
can
go
over
that
if
there's
time
at
the
end
here
so
right,
if
you
can
or
everybody
on
the
call
that
that
has
had
some
input,
maybe
we
can
provide
that
I
think
there
might
be.
A
You
know
a
follow
up
here
as
well
in
terms
of
an
another
flag,
potentially,
if
we're
talking
about
all
as
as
a
flag
and
we've
already
sort
of
agreed
on
that.
Is
there
one
like
direct
depth
direct
depths
or
something
I,
don't
know
anyways!
That's
besides
the
point,
cool
moving
on
number
150,
RC,
add
file
pack
dependency
protocol,
I.
Think
the
last
person
to
actually
touch
on
this
way.
I
know
we
added
the
label
David.
B
A
A
Nobody
has
any
updates,
let's
also
take
a
more
action
item
if
you
are
taking
notes,
Claudia,
just
also
ping
and
inside
the
issue
itself,
to
make
sure
your
folks
are
staying
up
to
date
on
that
yeah
awesome,
moving
on
1/29
rc4
overrides
so
Isaac's
again,
not
here
to
speak
to
the
current
progress,
although
I
think
he
had
cleaned
everything
up
the
last
time.
I
spoke
with
him.
A
A
A
A
B
C
D
D
It's
because
people
use
very
different
versions,
and
it's
like
when
there's
a
feature
that
requires
either
that
you
upgrade
NPM
or
that
you
use
a
specific
node
version.
It's
it's
tough
to
like
get
that
knowledge
spread
and
get
people
used
to
using
it.
So
whenever
it
lands
like
it
could
land
in
seven
one
or
seven
two
or
something
but
like
it
would
be
I
think
wise
to
try
and
rapidly
get
that
into
all
the
LTS
lines.
If
it's
possible,
that's
the
only
like
time-related
component
on
anything
right
here,
right.
E
E
A
A
A
E
He
said
forty
days
ago
that
so
the
last
weeding
they're
good
landis
like
the
guest
folks,
oh
yeah,.
A
Okay,
let's,
let's
wait
for,
let's
see
if
we
can
King
him
again
so
like
we'll,
take
action
items
for
folks
that
weren't
able
to
jump
on
especially
authors
of
the
RFC's
or
ideally
pinging
them
before
these
calls,
hopefully
again
I'm,
giving
them
a
chance
to
to
speak
to
sort
of
status.
So
I'll
take
that
as
a
to
do
or
action
item
and
hang
those
folks
at
least
before
arkfall
next
week.
A
Okay,
moving
on
121
ad
proposal
for
package
for
so
I
think
we've
spoken
to
this
a
couple
times.
I,
don't
know
the
status
of
tail
showed
up
the
other
day
and
we
were
talking
about
IBM
link,
essentially
I'm,
not
sure
if
this
still
makes
a
lot
of
sense
based
on
all
the
work
that
we're
doing
in
workspaces
as
well
and
I,
know.
Wes
also
had
strong
feelings
about
this
sort
of
use,
case
or
scenario
yeah,
so
you're
using
lerna.
A
B
B
B
B
A
B
I
think
yeah
I
think
there
was
a
comment
from
yeah,
something
that
proposed
like
just
adding
workspace,
but
then
it
small
relies
like
W,
which
simply
baby
pretty
nice
and
not
to
the
hard
to
type
so
I
will
be
onward
with
that,
doesn't
seem
bad
at
all,
seeing
it
the
examples
he
provided,
but
anyways
yeah,
making
the
poll
and
like
collecting
feedback.
But
what
would
be
the
best
place
to
share
that
so.
A
A
So
just
reference
it
in
the
chat,
so
you
can
create
right
there
in
an
issue
which
is
real
nice.
So
all
you
do
is
I,
think
it's
a
backslash
yeah
polls
and
then
the
options.
So
what
beaker
is
just
putting
like
the
different
I
think
the
four
different
designs
get
some
feedback
on.
What
people
prefer
would
be
good.
It
doesn't
necessarily
mean
that,
like
you
know
the
one
that
has
like
a
thousand,
if
other
people
vote
and
it's
like
800
or
it's
really
close-
we
might
she's
won
over
than
others
for
economics,
so
I.
E
Can
ask
just
one
question
like
a
clarifying
question
on
this,
so
if,
with
this
syntax,
it's
being
proposed
and
I'm,
not
not
gonna
fight
you
on
it,
I'm
just
more
acid,
like
is
an
extension
of
scripts
like
so.
If
you
did
npm
workspace,
plugins
tested,
that's
a
script,
but
if
he
dude
in
PM
workspace
plugins
installed,
will
that
install
the
node
modules
in
the
plugins
workspace
cuz?
That's,
that
is
the
pattern
that
I've
been
taught
by
NPM
and
that's
what
I
would
expect
and
if
that's
not
what's
gonna
be
there
I
would
be
very
confused.
E
B
D
B
You
should
be
able
to
like
run
fun
and
like
okay,
know
and
can
fund,
but
just
for
one
of
the
workspaces
in
there,
so
yeah
I
kind
of
made
a
list
of
commands
that
make
sense
to
support
using
this
and
then
yet.
I
think.
The
idea,
also
in
the
RFC,
is
that
by
default
and
p.m.
is
going
to
traverse
everything.
So
it
would
include
the
idea
for
all
the
workspaces
in
your
start
reading
so
yeah.
D
It
I
feel
like
right
now
in
a
non
mono
repo.
My
expectation
is
NPM
is
how
I,
like
I,
have
all
my
NPM
commands.
There's
NPM
run.
They
run
scripts
and
I
use
npx.
If
I
want
to
run
an
arbitrary
like
with
you
know,
if
I
want
dot
bin,
slash
whatever
you
know,
no
module,
slash,
I've
been
in
the
path
or
whatever
and
I
would
expect
the
same.
D
It
feels
weird
to
me
if
we're
picking
and
choosing
which
ones
work.
That
way
feel
like
it
should
just
everything
should
just
that
works
in
a
single
package.
Repo
should
just
naturally
work
in
a
workspaces
enabled
repo
I
shouldn't
have
to
do
it
like,
ideally,
anything
different,
except
maybe
like
have
NPM
workspace.
E
I
I'm,
looking
at
the
list
of
NPM
commands
and
like
such
stuff,
like
add
user,
make
sense
to
me,
I'm
like
when
I'm
publishing
a
package.
I
should
be
able
to
manage
that
from
the
workspace
command
rather
than
from
like
I.
Actually
don't
even
know
how
I
do
that
so
I
I
completely
agree
Jordan
on
that,
but,
like
basically
everything
except
for
the
global
commands
like
being
or
something
should
should
work
as
expected
or.
D
Isn't
to
be
more
specific,
everyone's
already
had
to
learn
all
sorts
of
idiosyncrasies
of
the
way
NPM
commands
work,
and
ever
it's.
You
know
how
everyone,
maybe
not
it
doesn't
understand
them,
but
it's
like
it's
widely
documented
and
some
amount
of
widely
understood
and
to
create
a
completely
new
landscape
of
brand
new
things,
for
everyone
to
learn
would
be
I,
think
really
unfortunate,
whereas
making
it
be
a
at
worst,
a
minor
tweak
on
the
current
set
of
knowledge
at
least
means
all.
The
current
documentation
is
pretty
still
it's
still
useful.
A
B
I
think
I
think
one
more
point
like
we
touched
in
the
session
there
is.
That
is
the
fact
that,
if
we're
using
basically
if
it
is
not
a
positional
argument
and
the
named
one
is
that
it
can
be
defined
in
your
config,
so
it
may
end
up
in
your
in
PMRC
and
that
might
be
a
complication,
but
we
also
yeah.
We
also
had
a
discussion
on
the
NPM
outdated
comment.
We
were
discussing
all
and
get
rid
of
that
and
I
think
that
makes
more
sense
to
be
addressed
as
a
separate
RFC.
A
A
B
C
A
A
So
I
think
the
that
at
least
where
my
mind
went
in
in
terms
of
if
we
landed
this
RFC
and
you
were
working
on
on
this
and
I
think
you
were
did
do
a
little
bit
of
work
into
this
already
but
like
the
first
command
to
tackle
would
be
like
run
script
because
essentially
it
is
the
precursor
to
every
other,
like
implementation
and
like
every
other
sub
command
right
like
so.
How
do
you
run
an
arbitrary
script?
A
A
A
E
That
was
those
basically
or
like
I
mean
if
you,
if
you
are,
it,
was
either
like
use
package
Jason.
That's
why
we
already
use
or
or
go
down
the
path
of
like
having
an
audit
file
and
not
like
a
like
less
specific,
like
highly
specific
file.
So
like
audit,
something
I
got
a
resolved
or
something
like
that
was
the
proposed
thing
and
yeah.
You
know
if
folks
are
adverse
to
using
package.
A
And
then
within
on
it,
Jason
and
you'd
have
the
resolutions
in
there
as
a
separate
like
G,
that
could
be
expanded
out
as
kind
of
your
thinking
at
that
grade.
So
yeah
I,
totally
agree.
I
know
that
CB
also
created
a
tool
for
this
I'm,
not
sure
if
it's
gotten
a
lot
of
usage
in
the
wild,
so
that
that
would
be
the
only
I
guess,
mitigating
factor
or
sort
of
thing
to
think
about
is,
if
you've
been
using
an
audit
resolve
previously
you're
gonna
have
to
transfer
that
over
in
your
projects,
but
ok
I'll.
A
A
A
So
everybody
seen
my
screen:
okay,
yep
cool
yep,
so
we
actually
go
into
accepted
just
recently.
We
also
implement
some
language
around
migrating
meaningfully
migrating
and
moving
certain
are
sees
that
we
might
have
accepted
previously.
That
may
not
make
sense
anymore,
I'm,
not
saying
that
now
is
the
time
first,
though,
sort
of
look
at
and
try
to
figure
out
which
ones
those
are
but
I
know
that
there's
a
couple
in
here,
specifically
that
we
have
executed
on
and
I
think
specifically
the
NPM
fund
and
the
NPM
multiple
funding
sources
can
actually
be
moved
to
implemented.
A
A
Something
that
we
cued
up
and
then
actually
did
the
work
to
do
to
get
done.
It's
awesome,
see
so
yeah,
so
I'll
take
a
takeaway
to
actually
move
those
unless
somebody
else
wants
to
do
that
and
I'm
not
sure.
If
there's
anything
else
in
here
that
people
know
that
is
actually
implemented
or
should
we
should
essentially
queue
up
to
be
reviewed.
A
A
B
A
That's
one
thing
to
consider:
when
do
we
actually
want
to
move
something
into
implemented
because
I'm
pretty
sure
in
the
actual
lifecycle
of
an
RCT?
I
I'm
not
sure
if
we
say
it
specifically,
but
I
think
general
availability
right
now
happy
I'm,
seven,
even
if
we
shared
with
the
branch-
and
we
told
people
to
go
download
that
there
would
be
breaking
test
for
a
lot
of
folks
and
it
would
not
be
fully
functional.
So
I
think
yeah.
A
That's
a
good
takeaway
as
well.
I
can
update
that
the
docs.
What's
the
definition
have
done
some
key
scrum
terminology
cool?
Did
anybody
else
have
anything
they
want
to
bring
up?
If
not,
we
can
get
five
ten
minutes
back.
Oh
good,
nine
one
thing:
no
I'm
gonna
start
another
poll
for
whether
or
not
about
an
alternating
time.
There's
been
some
interest
to
have
an
earlier
time.
There's
a
few
new
folks
that
want
to
chew
on
these
calls,
so
I
know
that
having
it
at
2:00
p.m.
Eastern
doesn't
work
for
everybody,
especially
it
folks.