►
From YouTube: Package Maintenance Team meeting - Sep 8 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
B
C
Yeah,
so
almost
oh,
my
goodness,
almost
a
year
ago,
I.
D
C
Maybe
less
than
that,
I
came
upon
the
create
pkg
package,
which
was
sort
of
dormant,
and
I
know
that
there
was
discussions
being
had
about
sports
or
the
sport
json
sort
of
schema,
and
and
at
that
time
you
know
we
had
drafted,
or
there
was
a
draft
of
what
was
going
to
go
into
that
and
to
try
to
get
some
traction
around
that
or
or
other
kind
of
you
know,
package,
defaults
or
or
defaults
that
we
and
standards
that
we
thought
would
be
good
for
the
community
to
adopt.
C
C
That
would
could
get
some
wider
adoption
in
a
meaningful
way,
and
so
the
reason
why
create
a
dash
pkg
is
such
a
good
package
to
be
owned
by
this
group
and
and
by
you
know,
node
project
is
that,
based
on
the
way
that
npm
runs
essentially
and
and
initializes
packages
is
that
we
use
the
create
dash
prefix
as
sort
of
an
identifier
as
a
type
of
a
template,
and
so
if
somebody
were
to
run
npm
init
pkg,
this
package
would
then
be
run
and
then
would
give
you
prompts
or
whatever.
C
You
would
like
to
essentially
start
to
scaffold
or
create
your
package.
And
so
I
looked
at
this
as
an
opportunity
for
us
to
to
use
this
and
create
some
recommendations
around
what
we
thought.
Good
defaults
were
beyond
what
you
know
exists
today,
and
I
know
wes
had
you
know,
done
a
lot
of
work
in
this
space
in
the
in
the
past.
C
Writing
scaffolding
and
generator
tools,
and
so
we
had
a
brief
discussion
last
week
with
roy
when
I
finally
was
able
to
transfer
this
package
to
the
pke
pkgs
on
npm.
So
it
now
is
officially
something
we
can
use
and
and
start
to.
C
You
know
publish
to
you
for
this
group,
so
we
had
a
brief
little
discussion
about
what
we
might
want
to
do
and
how
to
go
forward.
And
so
I
want
to
document
essentially
the
notes
from
that
discussion
in
that
issue
and
yeah.
So
so
we
had
a
couple
questions
initially
that
wes
had
about
you
know
sort
of
what
exactly
do
we
want
to
define
or
what
would
be
good
to
define
when
running
a
tool
like
this,
so
some
defaults
obviously
is
package.json
with
some
default
fields
defined.
C
You
know
after
you've
run
through
some
sort
of
wizard
or
some
sort
of
command
prompt
and
then
also
sort
of
the
secondary
and
licensing
and
some
other
files
that
you
might
want,
and
we
can
discuss
essentially,
whether
or
not
we
think
those
are
useful
and
what
files
we
should
and
shouldn't
there
might
be
people
that
you
know
have
strong
opinions,
one
way
or
another
about
certain
files
or
fields
that
we
want.
C
You
know
to
have
defined,
and
then
the
sort
of
secondary
aspect
to
this
is
also
what
kind
of
tooling
or
or
how
should
we,
you
know
disseminate
this
and
what's
had
the
good
idea
of
you
know
this
should
be
available
and
we
should
provide
some
sort
of
programmatic
way
of
people
being
able
to
extend
this
tool
so
that
they
could
provide
their
own
kind
of
defaults
as
well.
So
this
can
grow
beyond
west.
Did
you
want
to
add
anything.
A
No,
I
think
you
covered
it.
That
was
the
the
notes
actually
covered
quite
a
bit
too,
which
is
great,
I
think,
could
we
maybe
have
these
two
questions
posed
to
the
group
and
see
if
the
the
what
they,
what
everybody
else
thinks
aligns
with
what
we
have
in
the
notes
here
like
maybe
would
that
be
productive
use
of
our
time
like
on
these.
C
Yeah,
so
the
the
two
questions
I'm
talking
about
are
actually
in
there
in
the
in
the
dock,
and
we
I
just
documented
essentially
what
we
had
come
to
so
the
the
first
one
is:
what
do
we
want?
The
scaffold
output
to
include
and
the
second
is
sort
of
the
what
api
surface
do
we
want
to
expose
to
both
users
and
the
folks
who
want
to
see
compute
compose
the
base
generator
with
their
own
custom
options.
B
A
One
fairly
straightforward
at
the
top,
which
I
think
is
good.
I
I
really
after
this
I
also
remembered
repo,
which
did
not
make
it
into
this.
A
No,
but
it
works
for
more
than
just
that.
I
think
too,
doesn't
it
anyway,
even
if
not
just
having
the
repo
to
find
the
source
code
is
nice.
C
B
C
Yeah
got
it
to
sort
of
validate
sort
of,
the
approach
would
be
and
again
west
had
ideas
about
how
we
built
this
so
that
either
something
like
that
like
where
maybe
we
don't
want
to
have
it
as
the
baseline
default,
because,
again
it's
it's
something
that
we're
experimenting
or
like
we're.
We
want
to
get
traction,
but
we
don't
necessarily
want
to
put
into
these
defaults.
Yet
maybe
is
is
we
could
have
a
separate
tool
or
we
can
put
into
this.
I
don't
know.
A
I'm
easy
so
one
of
the
things
if
you
look
at,
we
have
a
few
listed
as
contentious,
and
I
think
support
would
probably
fit
into
those
like
how
how
do
we
show
these
to
users
because
they're
in
some
ways
more
power
user
features
and
so
like,
if
the
if
npm
is
pushing
people
to
use
npm
init
pkg,
it's
effectively
the
de
facto
standard
right
like
package
initializer
like
like
today,
it's
npm
init,
dash
y
or
something
this
would
be
the
future
where
we
that's
what
we
push
people
to.
A
A
So,
like
you'd,
you
know
probably
say
something
like
you
know
with
support,
and
then
it
would
ask
you
some
questions
about
how
you
do
support
or
something
something
to
that
effect
where
maybe
like
we
have
a
baseline,
and
then
we
have
all
of
these
other
extensions
built
in
and
just
hidden
behind
flags.
I
think
things
like
all
the
github
files,
the
ones
that
tie
specifically
to
github
apis,
could
be
a
similar
one
like
with
github.
B
A
B
B
A
Yeah,
I
just
think
about
you
know
we
have
the
support
info
if
we
add,
if,
if
we
put
funding
behind
the
same
kind
of
question
and
the
github
stuff
like
there
is
a
little
bit
of
command
for
like
prompt
fatigue,
you
know
that
I
know
I've
seen
this
with
other
generators.
I've
used,
I'm
just
like
I
don't
know,
now,
go
away.
E
A
Ask
me
something:
give
me
the
basics
and
I
think
again
there
we
have
to
look
at
it
through
the
lens
of
if
this
were
to
be
the
default
behavior
of
npm.
A
D
Cut
into
this
to
your
thought
about,
you
know:
there's
the
default
set
and
then
you
can
enable
further
prompts
with
further
flags.
Could
it
be
such?
Could
it
be
designed
in
such
a
way
that
in
a
month
when
you
know
that
information,
you
could
run
the
command
with
the
support
flag
and
it
would
just
patch
your
package
json,
like
oh
now,
that
you
know
okay
hit
me
with
all
the
questions,
and
you
know
just
stick
in
those
three
or
four
new
keys
into
my
package
json.
So
it's.
D
A
A
I
think
I
think
we
should.
We
should
set
out
to
do
that
because,
with
the
package
jason
at
least
it's
pretty
easy
to
do.
If
you
look
at
like
some
of
the
tools
offer
some
really
nice
like
diffing
and
you
can
say
like
well,
I
want
yeah.
I
do
want
to
take
that
change
or
no
ignore
this
whole
file.
You
know,
maybe
we
can
even
get
more
advanced.
A
A
Yeah,
so
let
me
maybe
also
give
a
quick
synopsis
of
the
history
that
I
have
on
this.
I
made
the
package
create
dash
package
json
a
while
back
as
a
first
attempt
at
the
like.
You
know,
actual
implementation.
For
this
I
found
a
couple
of
things
when
it
came
to
composition
of
this
stuff.
I
was
trying
to
follow
the
create
react,
app
sort
of
way.
A
They
did
it
because
a
very
successful
you
know
scaffolder
anyway,
I
found
a
few
things
where
it
was
like
really
boilerplate
code,
like
really
boilerplate
heavy,
like
just
repetitive
stuff
over
and
over
taking
the
things
that
you
take
from
the
cli
prompt,
sorry
from
the
cli
flags
from
yards,
passing
them
to
inquirer,
which
then
has
like
anyway.
It
just
ended
up
being
a
ton
of
glue
code
that
was
really
hard
to
manage,
so
the
pkg
js
create
repo.
Today
was
just
a
small
abstraction
that
I
pulled
out
of
that.
A
Like
the
the
create
package
json,
I
think
we
just
need
to
delete
that
code
or
move
it
off
somewhere
else,
and
then
this
would
be
the
the
new
thing
which
actually
so
that's
like
a
tool
that
you
would
use
in
a
scaffolding
tool
to
collect
the
user
input,
whereas
what
I
think
needs
to
live.
There
is
what
we've
outlined
in
this
this
issue,
which
is
a
concrete
implementation
of
a
package
scaffolding
that
would
then
be
published
as
create-pkg
in
the
end.
Does
that
make
sense,
yep.
A
And
and
whether
or
not
we
use
what
is
in
the
create
repo
today
as
the
technical
underpinnings
of
the
scaffolder
or
not
is
totally
up
for
question,
I've
actually
abandoned
that
and
went
to.
I
even
changed
its
focus
to
be
a
little
bit
tighter,
which
there
is
a
link
into
the
into
what
I
have
evolved
to
so
you
know,
but
again,
totally
optional.
If
everybody
is
like,
you
know,
let's
just
build
a
yeoman
generator
like
you
know,
I
won't.
I
won't
push
back
too
hard,
but
I
also
don't
like
yemen
generators
so.
D
One
minor
observation
back
to
the
top
of
the
list
is,
I
saw
funding
under
the
I
guess,
michael,
if
you
could
scroll
up
a
little
bit,
yeah
funding
is
under
package.json
and
the
funding
gamble
are
those
meant
to
be
different
sections
that
come
in
at
different
times
or.
C
C
The
funding
yaml
is,
and
that's
the
reason
why
you've
said
it's
a
bit
more
contentious
is
because
it's
it's
only
specific
to
the
github
platform.
So
yeah
we
tried
to
identify
the
sort
of
the
fields
that
we
thought
would
be
contentious
or
even
like
when
we
were
kind
of
discussing
it
that
we
were
like.
Do
we
really
want
to
do
this?
Does
it
overlap?
Does
it
actually
make
sense?
We
don't
also
want
to
make
this
like.
C
Have
a
thousand
prompts
for
the
user
right,
because
then
they're
not
gonna,
actually
fill
it
out
or
it
could
be.
Potentially
there
might
be
a
way
to
set
this
up.
So
it's
like
a
one-time.
You
know,
config,
that
you
know
global
user
config.
That
then
gets
pulled
from
once.
C
You
start
your
package
right
and
your
next
package,
so
there
could
be
like
maybe
a
one-time
cost
for
a
lot
of
this
stuff,
especially
something
like
funding
and
might
be
information
that
is
carried
over
to
each
one
of
your
projects
or
similar
to
maybe
licensing
and
that
that
might
be
a
good
exercise
to
go
through
which
ones
might
not
have
to
be
which
might
be
redundant
over
time.
C
Author
license
things
like
that
might
might
be
things
that
that
we
could
find
ways
to
to
make
sure
the
user
isn't
prompted
for
each
time,
but
yeah
that
one.
That
one
is
those
are
just
used
in
two
different
sort
of
ways.
D
Context
yeah:
I
guess
that
that
also
now
that
I'm
looking
at
it
obviously
I
know
that,
like
a
code
of
conduct
isn't
or
like
a
contributing
file,
isn't
necessarily
specific
to
a
code
hosting
platform,
but
certainly
github
adds
a
lot
of
nice
workflow
extensions
on
top
of
documents
like
that.
D
Do
we
know
if
I
use
bitbucket
at
work,
so
I
don't
think
so,
but
do
bitbucket
or
gitlab
or
anything
else,
try
and
extend
the
experience
in
the
sense
of
like
templates
or
anything
like
that
or
does
it
you
know
again
not
that
a
code
of
conduct
would
be
exclusive
to
github,
but
you
know
is
there
a
way
that
we
can
signal
like
certain
files,
get
like
it
and
get
an
enhanced
experience
in
certain
platforms
in
any
way,
shape
or
form
like
hey?
D
If
you
add
the
contributing,
then,
if
you're
using
github
everybody's
gonna
see
this
thing
every
time
they
open
a
pull
request,
you
know,
I
don't
you
know.
I
assume
the
majority
of
projects
are
on
github,
but
you
know
I'm
not
sure
if
it's,
even
if
it's
at
least
worth
some
of
our
time,
just
to
scan
what
other
things
do,
and
maybe
it's
maybe
in
a
way
it's
like
you
could
have
like
the
github
sub
package
or
something
and
it'll
prompt
you
through
like
hey.
D
These
are
cool
like
you
know,
but
I
don't
want
people
to
only
do
added
contributing
just
because
of
github.
You
know
it's
probably
good.
Either
way
you
know
not
to
entangle
them
all
together,
but
just
just
thinking
out
loud.
I
guess
on
that.
What.
A
A
I
think
I
think
your
point
is
the
the
what
I
would
like
to
boil
that
down
to
is.
Should
we
have
tight
coupling
with
popular
platforms
or
something
like
like,
for
example,
tight
coupling,
in
my
opinion,
is
dot,
github,
dot,
issue,
template
or
sorry
dot,
github
issue
templates
to
me.
That
would
be
if
we
added
that,
especially
if
we
added
it
by
default,
would
be
considered
tight
coupling
to
the
github
platform.
Now
that
might
be
90
of
our
99
of
our
user
base.
A
I
don't
actually
know,
but
I
know
I
would
be
a
user
and
I'm
often
scaffolding,
things
for
internal
projects
which
are
not
on
github.
So,
like
you
know,
I
think
I
think
your
point
is
good
if
there's
common
ground,
so
I
now
that
I
see
I
think
contributors
might
be
contentious
as
well.
Only
because
a
lot
of
folks
don't
need
it,
but
like
to
me
code
of
conduct,
that's
just
a
great
thing
for
us
to
help
push
right.
Like
we
say:
hey.
A
B
True,
maybe
this
might
be
the
same
for
like
license
and
contributors.
It's
like
those
are
all
good
things
to
have
now
I
could
see
you
know
what
you're
just
saying
is:
maybe
there's
a
difference
between
it's,
an
external
and
or
external
project,
so,
like
an
internal
flag,
might
disable
some
of
those
or
something.
A
Yeah,
I
would
rather
go
individual
and
say
dash
dash,
no
dash,
contributor,
contributing
or
dash.
You
know
no
dash
code
of
conduct
to
opt
out
and
do
that
on
an
individual
basis,
then
try
to
assume
intent
right
because
some
people
like
like
internal
to
me.
A
A
A
Yeah,
so
actually,
when
darcy
was
saying
that
it
got
me,
thinking
like
we
could
definitely
one
thing
that
I
could
definitely
see
would
be
a
hey.
This
looks
like
it's
the
first
time
running
the
generator.
Can
you
answer
these
upfront
questions?
First,
we're
going
to
store
these
off
and
reuse
them
between
runs
or
something
like
that
would
be
like,
I
think,
a
pretty
nice
user
experience
and
then
it
asks
extra
prompts
stores,
those
in
your
home
directory
or
some
you
know,
shared
location
and.
D
Maybe
yeah
I
mean
I
like
that
idea.
Maybe
we
could
have
the
concept
of
like
a
profile
and
then
the
profile
is
just
a
pre-set
list
of
options,
you've
already
selected,
so
you
can
run
the
tool
pass.
The
profile
it'll
you'll,
be
like
oh
you've
already
have
values
for
license
private
this
that
and
the
other
I'll
fill
those
in
ask
you
the
rest
and
then,
if
you
add
any
additional
flags
on
at
the
end,
I'll
ask
those
two.
So
then
you
can
have
like
on
one
machine.
A
D
Nice
and
for
the
package.json
are
these:
the
are
these
just
mapped
to
the
defaults
from
npm
in
it
right
now
or
they
are
their
differences?
D
C
We
have
a
lot
less,
that
we
define
usually,
and
we
prompt
for
and
that's
kind
of
why
this
came
about
like
we
didn't
want
to
be
blocking
like
we
kind
of
like
the
the
small
defaults
and
that
we
have
today
and
we
do
pull
from
user
config
if
we
can
so
like
for
author,
for
example,
we'll
we'll
try
to
get
like
the
the
git
config
to
define
the
author.
C
So
we'll
just
immediately
like
be
able
to
prompt
that,
for
you
versus
having
you
to
like
type
that
in
but
yeah
we
we
define
a
whole
lot
less
and
and
really
the
the
idea
here
is
to
try
to
decouple
that
you
know
these
defaults
that
we
want
from
and
not
be
a
blocker
like
on
our
side
from
from
you
know,
especially
if
we
want
to
be
more
aggressive
with
you
know,
standardization
of
certain
fields
or
or
trying
in
this
all
came
about
because
of
sort
of
the
support,
work
and
schema
that
I
I
felt
like
we
were
being
more
of
a
blocker.
C
You
know
privileged
or
blessed
sort
of
access
into
the
ecosystem,
just
by
the
way
that
you
run
it
with
npm
right
so
yeah.
D
D
So
at
least
there's
a
distinction
between
npm
in
it
and
this
and
then
I
like
west's
idea
where
pretty
much
everything
else
is
just
kind
of
like
a
flag
on
top,
so
like
one
flag
per
option
and
then
you
can
just
chain
them
or
you
know
just
stuff
them
into
a
profile,
and
you
know
something
like
that
kind
of
gives
you
a
nice
progression
from
you
know,
I'm
just
using
npm
in
it
to
you
know.
I've
got
the
same
template.
D
C
Yeah
I
just
wanted
to
be
mindful.
I
I
did
note
that
I
think
the
contributor
sympathy
is
supposed
to
be
contributing.
C
So
that's
one
thing
that
I
think
I
messed
up
when
taking
notes
there.
I
think
that's
less
contentious
to
to
have
a
contributing
empty,
a
foul
in
in
your
repo
versus
contributors.
C
B
A
B
A
We
should
we
should
at
least
establish
next
steps.
Do
we
think
that
we
want
to
what
do
we
think
we
want
to
do
next?
C
A
A
If
people
aren't
opposed,
I
have
technically
already
started
building
the
tools
I
mean
I
have
like
three
or
four
of
the
the
primary
components
I
think
already
done.
So.
If
we
wanted
maybe
like
how
much
technical
involvement
people
want,
maybe
we
can
have
another
sync
like
we
did
last
week
and
and
really
nail
down
how
the
you
know
how
the
code
will
look,
what
components
we'll
have
so
I'd
be
happy
to
lead
that
effort.
If
that's
seems
like
a
good
next
step.
A
Yeah,
I
think
I
do
and
yeah.
If
we
we
can
just
make
an
issue
I'll
open,
an
issue
right
after
the
call.
B
B
Okay,
anything
else
before
we
move
on.
E
Yeah
so
dominic
has
said
you
know
after
we
landed
it
last
week
and
we
pressed
she
said,
I'm
not
quite
so
sure
we
should
have
done
that
and
then
we
discussed
well.
Actually
what
should
we
do
in
this
circumstance?
So
we
wrote,
we
wrote
this
up
and
it's
there.
I've
modified
the
wording
and
the
contributions.
E
I
think
we
have
a
reasonable
way
around
what
to
do
noting
that
this
is
not
an
effort
to
get
around
trying
to
get
consensus,
but
what
you
do
when
you
think
you've
addressed
everything,
but
one
of
the
reviews
is
still
outstanding
and
that
reviewer
hasn't
replied.
You
can't
contact
them
and
dominica
said
we
need
to
start
a
countdown
and
make
every
possible
effort.
B
D
I
mean
I
already
approved
so
we'll
say
too
much
more.
I
think
it's
also
a
big
part
of
it
was
just
understanding
like
the
the
spirit
of
the
group
as
well,
and
I
think
to
glenn's
point.
You
know
this
isn't
and
run
around
anything.
Obviously
you
know
if
this
was
like
a
an
application
with,
like
you
know,
there's
context
right,
documentation
versus
workflows
versus
like
production
code.
Obviously
you
might
have
different
stages
of
leniency,
but
you
know
I
think
it's
just
setting
some
initial
groundwork.
D
As
I
you
know,
I
often
I
guess,
maybe
being
somewhat
newer.
You
know.
I
definitely
wanted
her
on
the
side
of
caution
before
merging
or
doing
anything
to
rub
anybody.
The
wrong
way.
D
E
E
Because
you
just
can't
help
yourself,
we
leave
that
once
we
get
that
done,
I
can
start
on
the
cicd
pipeline
work,
which
will
refer
back
to
the
testing
docks,
which
I
promised
to
refer
them.
Interlink
them
to
dominic
has
had
some
questions
raised
on
that.
That's
why
we'll
do
next
once
this
gets
land
landed.
B
E
B
Okay,
so
let's
move
on
to
the
next
issue,
which
is
adding
package
maintenance
to
node.js
website
number
402.
B
I'm
not
sure,
there's
too
much
to
discuss.
I
guess
rxmarbles
is
working
on
a
description
for
the
website.
There
are
a
few
questions.
Discussion
back
and
forth
are
people,
okay
with
where
that
that's.
B
B
D
D
Yeah
my
understanding
was
mostly
just
to
maybe
add
a
more,
I
guess,
like
catchier
or
more
concise,
like
top
level
summary
of
the
group.
That
could
also
be
reused
in,
like
a
you
know,
a
different
context
like
on
the
website.
So
if
we're
going
to
write
it
for
the
website,
maybe
add
it
to
the
docs
or
vice
versa,
but
I
think
it
was
just
like
one
or
two
line
settings
to
really
sum
up
the
group.
You
know
as
opposed
to
changing
anything.
That's
there
yep.
B
B
F
Yeah,
I
was
just
going
through
various
repositories
in
node.js
organization
to
check
the
travis
seamless
there
and
I
spotted
this
repo.
I
guess
and
yeah
just
wondering
what's
the
status
there,
but
I
think
in
the
discussion
in
the
issue.
The
agreement
is
that
yeah,
the
assumption
is
that
the
gs
support
takes
over,
which
means
we
should
probably
as
long
as
we
have
feature
parity.
I
don't
know
we
should
probably
archive
this
repo.
I
don't
know.
What's
the
like,
I
haven't
looked
at
the
code
or
anything
just
figure
that
there's
some
duplication.
F
F
E
B
B
F
When
can
we
get
that
into
a
phase?
I.
C
F
C
B
F
B
Okay,
so
let's
move
on
to
the
next
one,
which
is
draft
text
for
support
info
blog.
We
talked
about
this
last
time.
I
had
the
action
to
write
up
the
draft
blog,
which
I've
done,
and
I
guess
just
wanted
to
see
if
there's
more
any
more
feedback
comments,
and
are
we
ready
to
go
ahead
and
work
with
the
foundation
to
get
this
published?
D
Maybe
it's
just
as
a
point
of
order,
while
everybody's
doing
that
is
it
common?
I
guess
what's.
This
is
just
more
more
for
my
own
education
around
like
blogging
and
promoting
node.js.
B
D
Yeah,
I
imagine
it
probably
lets
you
move
faster
than
going
through
the
website,
docs
or
anything
like
that,
but
yeah.
I
was
just
kind
of
curious
because
I
know
that
there's
you
know
a
lot
of
often
a
lot
of
discussion
around.
You
know
even
earlier,
not
coupling
to
a
particular
platform,
but
I
guess
sometimes
that's
inevitable.
D
A
B
D
B
Yeah,
I
don't,
I
don't
think
we've
thought
about
doing
that.
It
kind
of
makes
sense
like
we
could.
We
could
take
this
text
well,
it'll
be
in
an
issue,
but
we
could
also
put
it
in
in
a
like.
We
could
start
putting
a
blah
have
a
blog's
director
if
we
wanted
to
in
the
in
the
repo
and
land
things
there.
D
Yeah
yeah
interesting
direction
to
take
with
node.js,
oh
yeah,
at
least
you
know,
js.
You
know
that
kind
of
mantra
of
own
your
own
content.
I
mean
use
other
platforms,
but
the
content's,
always
yours
at
the
end
of
the
day,
somewhere
safe
anyway,
I
digress.
Yeah,
yeah,
cool.
C
Yeah
kind
of
like
I
would
say
that
would
be
the
first
thing
you'd
want
to
do
like
if
you
read
this,
the
sport
spec
or
schema,
and
you
disagree
with
it,
you
know
partially
like
if
you
you
think
it's
something's
wrong,
then
that's.
The
first
thing
we
want
you
to
do
is
give
us
right
back
and
then
how
about
like
here
right,
yeah,
because
for
so
some
folks
this
might
be
the
first
time
they
hear
about
this.
C
C
E
B
C
B
Okay
sounds
good,
so,
let's
move
on
to
the
next
issue,
then
communicating
that
only
the
latest
version
of
a
major
release
line
is
supported.
This
is
393
and
I
think
dominicus
were
you
the
one
who
opened
that
okay.
F
Yeah,
yes,
we
there's
some
actions
to
be
taken
there.
I
did
take
one
of
the
two
that
we
discussed
last
time
around.
I
have
a
request
open
and
see
I
can
fix
travis.
I
appreciate
some
reviews.
There
just
updates
the
readme
files.
F
A
B
B
B
C
D
A
B
A
B
Okay,
so
let's
move
on
to
the
next
one,
then,
which
is
the
pkgs
org
for
work
group,
supported
tooling,
that
one
we
did
talk
about
briefly
yesterday,
there
were
a
few
things
that
we
were
doing.
I
know
dominicus
was
doing
a
few
things.
B
F
Yeah
having
connection
issues
you're
into
the
or
just
gonna
resend,
that.
F
B
Okay,
well
we're
just
two
minutes
left,
so
the
next
one
is
next
steps
on
support
levels
and
package
to
jason.
I
think
we
already
talked
about
the
next
step,
which
was
the
blog
post.
B
A
C
A
Good
next
step,
because
that
I
think,
would
be
either
that
that's
probably
the
best
option,
but
either
that
or
like
maybe
some
of
the
github
stuff
like
we're
gonna,
need
one
first
trial
for
like
here's,
this
thing
to
find
somewhere
else.
How
does
it
work.
C
A
B
B
Okay,
so
that's
the
end
of
time.
Is
there
anything
the
agenda?
Is
there
anything
else
that
people
want
to
talk.
B
E
It's
glenn
here,
if
I
could
have
you
micro
and
where's,
just
for
a
minute
at
the
end
off
after
we
finish.
E
B
Okay,
so,
let's
close
out
for
today,
I
will
stop
the
story.