►
From YouTube: Package Maintenance Team meeting - Aug 25 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).
A
A
A
I'm
just
gonna
do
that
myself
as
well
before
I
get
started
okay.
So
first
of
all,
the
first
issue
on
the
agenda
is
communicating
that
only
the
latest
version
of
a
major
release
line
is
supported.
Number
393
and
I
think
dominica
unless
you
had
kicked
that
one
off.
B
B
Yeah,
so,
as
we
were
discussing
see,
I
can
fix
travis,
basically
the
default
setup
of
see
I
config
travis
sound
of
travis
in
general.
If
you
leave
out
the
specific
version,
if
you
just
say,
install
the
major,
it
will
install
the
latest
version
in
that
major,
which
means
that
if
you're
a
package,
maintainer
you're
effectively
only
testing
in
by
default
with
the
most
conventional
configurations
out
in
the
wild
and
the
recommended
setups
right,
you
would
only
be
testing
in
the
latest
version
of
a
of
any
major
release
line.
B
However,
in
the
engines
field
of
package
json,
the
engines
field
is
somewhere
compatible
right,
so
you're
meant
to
enter
a
symbol
range
in
there.
Most
of
the
people
would
put
in
say,
14.x
or
something
greater
than
14.
14,
which
means
that,
technically
speaking,
strictly
speaking
when
you
are
communicating
that
in
your
package,
json's
engines,
you
are
meant
to
support
all
of
the
versions
on
the
14
release
line,
even
though
you're
only
testing
in
the
latest
version.
B
So,
even
if
you're
say
communicating
that
via
your
package,
support
that
you're
only
supporting
the
latest
version
right,
and
that
is
what
we
recommend,
because
you're
only
meant
to
be
running.
The
latest
note
version
in
production
right,
you're,
you're
not
supposed
to
be
running
something
like
14.0.0,
because
that
has
known
security,
vulnerabilities
and
probably
bugs
that
were
fixed
later.
B
However,
sember
does
not
allow
communicating
that
in
a
automated
fashion
right,
you
could
be
bumping
the
engine's
field
every
time
you
actually
change
the
requirement,
however,
that
could
be
sort
of
construed
as
a
something
that
requires
a
new
major
release
of
your
package.
B
Right,
so
suppose
you,
your
engines,
communicate
that
you
support
14.0.0,
yet
you
start
using
a
feature
which
was
introduced
in
14.3.0
and
all
of
a
sudden,
your
package
no
longer
works
and
14.0.0,
which
means
that
you're
essentially
changing
a
requirement,
which
means
that
you
should
be
bound
to
major.
So
there
is
no
way
to
to
sort
of
communicate
that
that's
one
issue
and
the
other
issue
is
that
the
recommendation
of
you
know
you
should
only
be
supporting.
B
The
latest
line
is
actually
potentially
could
be
releasing
breaking
changes
without
a
sampler
bump,
which
my
personal
opinion
is
that
it
is
fine.
However,
that
is
a
sort
of
technicality
that
maybe
we
should
see
if
there's
a
way
to
address
that.
C
A
A
B
B
C
So
I
have
a
well
first,
I
want
to
say
that
is
the
approach
that
express
will
probably
be
taking
with
five
right.
The
the
code
is
still
compatible
but
they're.
It's
just
going
to
bump
the
the
engines
field
and
call
that
the
breaking
change.
So
that
is
definitely
a
use
case.
I
think
to
to
make
clear
is
a
pretty
good
practice.
I
would
say,
but
I
was
going
to
say
separately
from
that.
C
What
really
we're
talking
about
here,
I
think,
aligns
well
with
npm's
engines
output
like
when
it
processes
the
engines
field
respecting
those
aliases.
We
we
defined,
because
if
because
those
aliases
do
explicitly
say
this
alias
points
at
the
tip
of
the
current
branch
of
that
you
know
whatever.
That
is,
I
think-
and
I
and
I
made
this
point
I
think,
get
some.
I
can't
remember
it's
been
a
while,
but
I
I
really
think
the
engines
field
should
support
those
aliases,
because
really
what
we're
doing
is
it's
not
telling
the
it's?
C
Not
that
the
code
is
actually
breaking
like
you
say
right.
What
we're
saying
is
this
is
what
we
support,
so
the
engines
field,
even
today,
is
intent
right.
Obviously,
npm
tries
to
interpret
that
intent
to
install
a
version
that
has
a
compatible
engines
field,
but
really
still
that
could
still
be
broken
right.
Like
the
point
is
the
author
is
saying,
I
intend
for
this
code
to
work
in
the
node
14
latest
right.
Whatever
you
know,
I
think
we
have
a.
I
guess
that
would
be
latest
right
currently
and
anything
else.
C
I
mean
that's
really
what
the
engines
field
is
telling
them,
so
I
would
actually
like
to
see
npm
adopt
those
aliases,
even
though
yeah
that
would
be
a
breaking
change
and
it
would
be
different
from
what
the
ecosystem
expects
today,
but
I
think
it's
actually
more
accurate
to
the
way
folks
use
the
engines
field
in
practice
because,
again,
like
you
said
people
say
14
right
like
in
practice,
they're
saying
greater
than
14.,
they
don't
necessarily
mean
that,
because
they
may
start
using
one
of
those
new
features
that
lands
in
14
and
like
almost
guarantee
across
the
ecosystem.
B
Definitely
not
this.
This
came
out
of
a
discussion
on
ci
config
travis
that
maybe
the
ci
config
travis
configs
should
explicitly
also
include
0.0
just
so
that
you
can
double
check
that
you're
not
introducing
inadvertent
breaking
changes.
In
the
end,
we
sort
of
came
to
the
conclusion
that
you
know
this
is
not
what
the
ecosystem
expects
right.
Strictly
speaking,
this
is
the
correct
thing
to
do,
but
that's
not
the
reality
in
the
world,
so
we
didn't
do
that.
B
There
is
a
plan
to
introduce
a
way
of
doing
that,
but
right
now
the
defaults
there
do
not
so
yeah.
It's
only
like
everybody's
only
testing
in
latest
and
everybody
recommends
you
use
latest
and
everybody
assumes
you
use
latest.
I
know
of
packages
that
do
explicitly
call
out
a
specific
up
to
the
patch
release
that
they
support
as
the
minimum
version,
but
I
think
that's
that's
in
the
minority.
A
You
know
see
that
that's
where
I
like.
I
agree
that
everybody,
you
know
my
understanding
has
always
been.
If
you
want
to
get
a
fix,
you
got
to
go
to
the
latest,
but
that
is
subtly
different
from
I.
As
a
package
maintainer,
I
could
still
say
that's
the
case
like
if
you
want
to
fix
it's
going
to
be
in
the
latest,
but
I
could
be
careful
not
to
to
avoid
using
anything
that
was
introduced
that
wasn't
in
14.0.
C
A
C
B
A
C
C
C
A
C
A
C
I
agree
on
that.
I
would
love
to
hear
if
I
can't
remember
when
I
brought
it
up
to
y'all
at
npm.
So
rory
do
you
know,
do
you
remember
this
conversation
and
did
the
npm
changing
or
npm
supporting
that
in
its
engines
field
ever
get
any
traction.
D
C
D
I
don't
I'm
not
even
sure
if
it
works,
I
think
it
too
warns
you
but
yeah.
I
I
think
there
is
a
strict
mode,
an
opt-in
with
a
config
that
you
can
make
it
break
if
you
want,
but
today,
I'm
pretty
sure.
D
Yeah,
oh
yeah.
If
I
remember
correctly,
it
was
one
of
the
first
bug
fixes
I
did
when
I
joined
the
team.
The
warning
wasn't
even
being
printed,
so
it
was
one
of
the
first
things
I
fixed
on
olympian
6..
So
it
does,
it
does
print
the
worn.
But
if
you
want
it
to
fail,
you
need
to
use
a
an
obtained
flag.
Yet.
C
I
thought
so
because
I
added
an
engines
thing
to
one
of
my
internal
projects
just
recently,
because
a
user
reported
it
breaking.
It
was
internal.
So
I'm
not.
You
know
super
strict
about
how
I
do
some
of
these
things
when
I'm
working
on
them,
but
right
and
I
was
like
hey,
but
I
added
an
engine's
field.
Did
you
not
see
the
warning
and-
and
he
did
not
see
the
warning
so,
but
so,
but
the
point
stands,
though,
I
think
it's
all
about
intent
right
like
if
the
code's
gonna
break
the
code's
gonna
break,
whether.
C
Field
is
defined
correctly
or
not
right.
So
I
think
if
npm
were
to
accept
these
aliases
print
a
warning,
then
I
think
the
users
would
be
served
better
than
they
are
today
in
that
then
by
the
authors
having
to
maintain
a
either
loose
semver
range,
where
they
don't
really
test
it
correctly
or
a
very
meticulously
maintained
summer
range
in
their
engines,
field
which,
like
again
I'd,
say
jordan's,
probably
the
only
person
doing
he's.
If
he's
even
doing
it,
you
know,
I
don't
know,
I
I
don't
know
of
anybody
else
doing
it.
D
F
Is
there
any
opportunity
or
overlap
with
ci
tools
like
could
have
actions
that
allow
you
to
run
your
again?
I
suppose
you'd
have
to
have
ci
as
a
prerequisite
of
course,
but
with
something
like
github
actions.
Then
it
becomes
a
little
bit
easier
to
take
that
engine's
range
and
put
it
into
a
matrix
and
then
get
a
little
bit
more
confidence
in
the
the
support
that
you
do
declare,
or
rather
that,
as
you
add
things
it's
you
know,
it's
like
a
form
of
regression
testing
in
a
sense.
A
F
C
A
Up,
oh,
go
ahead,
I
was
just
gonna
say
I
think
that's
kind
of
related
to
where
this
came
out
of
right.
Dominicus
was
working
on
the
entries
for
our
ci
configs
and
some
of
those
ci
configs
were
intended
to
match
what
we've
got
like.
You
know
if
you
say
that
you
in
your
support
field,
this
is
what
you
intend
to
support.
A
F
I'm
sorry-
and
this
is
the
first
part
so
does
it
still?
Is
that
still
the
behavior,
that
if
you
have
an
engine
for
like
node,
12
and
you're
on
10
it'll,
stop
the
install
completely.
D
Yeah
there's
a
config,
so
you
should
npm
install
dash
dash
engine
dash
street
and
that
should
make
your
install
fail.
In
case
you
have
a
mismatching
engine
in
one
of
the
installed
packets,
but
it's
not
by
default
anymore.
No,
no,
no
yeah!
That's
what
I'd
say
like
it's
an
option
because
yeah
by
default,
it's
turned
to
false
yeah.
Okay,.
F
So
I
mean
because
there
is
that
I
know
that
I
think
it's
been
touched
upon
so
far
in
this
discussion-
that.
F
Support
you
know
the
engines
is,
is
really
good,
but
maybe
you
forget,
maybe
that's
one
thing
that
you
forget
to
bump,
so
you
know
how
does
it
you
know
it
kind
of
becomes
another
part
of
the
maintainers
checklist
right,
like
kind
of
like
the
fable
thing
it's
like
for
every
you
know
pr
that
comes
in,
and
you
have
to
double
check
that
the
feature
is
you
know
was
only
introduced
in
14.10,
not
14.6,
or
things
like
that.
So
it's
almost
like
it's
there.
F
It's
actually
reminds
me
of
a
neat
babel,
eslint,
plug-in
right
where
there's
a
tool
called
browsers
list
where
you
can
define
the
browser,
support
for
your
particular
project
in
babel
and
those
kind
of
transformation
tools
will
leverage
that-
and
you
know,
if
you're
using
modern
browsers
it
only
transfiles
to
modern
code.
So
there's
an
eslint
plugin
where,
if
you
have
that
browser's
list
it'll
actually
tell
you
like.
Oh
hey
this
feature,
you
know
you're
trying
to
use
promise
and
your
browsers.
Don't
support
promise
it'll
fail
you.
You
know
something
like
that.
C
So
I
linked
something
I
did
bring
this
up
a
little
bit.
It
was
a
while
ago
and
as
I
threw
the
link
in
here,
but
basically
when
I
first
posted
this
was
like
look.
We
shouldn't
they
like
this
is
way
early
in
the
actions
it
was
before
like
they
went
out
of
beta-
and
I
said:
look
you
shouldn't
launch
this.
C
If
you
don't
have,
if
you
have
matrix
support
and
you
require
people
to
update
their
config
every
single
time,
a
new
node
lands,
which
is
the
current
state
today
and
it's
the
current
state
in
travis
and
all
these
others,
it's
just
a
bad
experience
right
so
like
what
my
my
idea
was
to
them
was
hey.
If
you
support
these
out
of
the
box
via
some
sort
of
you
know,
alias
or
template
setup
or
whatever
it
you
know
needs
to
be.
You
know
you're
just
going
to
be
giving
your
users
a
much
better
experience.
C
I
don't
haven't
seen
any
real
action
on
it
and
then,
like
a
bunch
of
people
who
just
seem
to
have
totally
you
know
no
connection
directly
with
a
lot
of
the
node
stuff
came
in
with
these
alternate
proposals,
and
then
it
just
sort
of
died
on
the
vine.
As
far
as
I
can
tell
and
has
been
sitting
here-
and
my
last
comment
was
march
8th,
so
I
don't
you
know
anyway.
C
C
Whole
ecosystem
supports
this
start
using
it
you'll
get
the
benefit
right
away.
The
problem
is
today:
we
can't
do
that
until
we
get
these
tools
on
board
and
github
actions
is
pushed
back.
Jordan
pushed
back
because
he
didn't
want
to
do
time,
manipulation
in
nvm,
and
you
know
I
understand
that
and
then.
C
Yeah
anyway,
my
point
is,
I
think,
there's
a
lot
of
moving
pieces
when
you
talk
about
how
does
ci
end
up
adopting
this
methodology
and
it's
way
more
than
just
like
github
actions,
supporting
it
or
travis,
supporting
it
or
us
even
having
tool
we
need
to
actually
have
like
buy
in
from
all
of
these
tools
that
manage
node
versions
before
the
the
real
benefits
going
to
come
into
play.
I
think.
E
A
I
think
in
terms
of
this
issue,
because
we
we
have
used
half
the
meeting
already
next
step
are
for
us
to
open
the
pr
to
update
the
support
docs
to
clarify,
what's
meant,
if
we,
if
we
believe
that
the
common
use
case
is
really
just
the
tip
and
that
you'll
have
to
move
up
to
the
tip
to
potentially
get
a
new
version,
we
should
clarify
that
that,
hopefully
answers
your
question
dominique
has
in
terms
of
what
we
want
to
do
in
the
configs.
A
Because,
again,
if
our
argument
that
it's
a
very
non-common
case,
those
configs
are
not
meant,
they're
meant
to
give
the
common
cases
right.
If
you
can
do
something
else,
if
you
want
and
then
it
sounds
like
the
other
action
would
be
to
restart
the
discussion
of
npm,
supporting
those
definitions
that
sound
like
that,
the
two
next
things
we
want
to
look
at
on
that
front.
D
B
B
Just
a
quick
double
check
are
we
meant
to
create
issues
or
discussions
for
that
for
the
second.
A
One,
we
probably
want
to
open
an
issue
to
track
us
doing
something
for
it
and
then,
like
I
guess,
you're
you're
talking
about
opening
issues
in
npm
or.
D
D
B
D
D
C
C
A
an
rfc
pr
to
get
the
ball
rolling
because
I
think
I
understand
most
of
what's
needed
and
I
could
probably
write,
I
think,
a
technical
write-up,
so
so
I'll
I'll.
Take
that
on
I'll.
Probably
do
it
later
this
week
would
be
my
guess.
A
I
have
written
in
wes
has
the
action
in
terms
of
updating
a
pr
for
updating
the
support,
docs
any
volunteers
for
that.
B
Yeah,
okay,
I'll
take
a
look
into
that
and
then
I
think
what
I
will
do
is
is.
I
was
planning
to
do
that
this
week,
anyways
I
will
be
updating
the
readme
files
in
ci
config
travis,
and
I
will
be
including
some
examples
and
I'll
mention
that
you
know
there
is
this
sort
of
problem
and
I
guess
the
there
is
a
good
practice.
If
you
want
to
go
an
extra
mile,
then
you
should
be
explicitly
including
the
minimum
version
in
your
travis
ci
setup.
I'll.
B
B
A
If
you're
going
to
make
that
commitment
right,
yeah
yeah
exactly
okay,
but
we,
but
we
won't
necessarily
have
you
know,
default
configs
that
does
that
for
people
no.
B
That's
not
feasible!
That's
because
the
default
config
means
that
for
us
to
generate
that
config,
it
means
that
people
would
have
to
change
their
javascript
anyways
because
they
need
to
change
the
import.
So
they
may
as
well
just
change
the
version
explicitly
in
the
ammo
file.
Okay
and
get
the
rest
automatically.
B
F
I'm
gonna
drop
a
link
in
the
chat,
since
I
know
that
wes's
link
from
npm
mentioned
aliases.
I
know
there's
another
conversation
in
the
node
release
channel
about
the
understanding
of
aliases
like
lts.
So
you
know
if
we
incorporate
aliases
into
the
specification,
it
would
seem
that
the
understanding
of
things
like
lts
are
consistent
or
across
the
ecosystem
as
well.
A
A
A
The
next
one
was
suggest,
ignoring
a
vulnerability
by
the
package
maintainer
this
one.
We
tried
to
get
a
few
people
together.
I
think,
unfortunately,
like
darcy
was
then
gonna
be
on
vacation
and
I
didn't
actually
get
back
to
see
if
we
could
get
louran
to
this
call.
So
maybe
for
the
next
call,
we'll
try
and
arrange
that
is
there
anything
that
we
should
discuss
on
this
one.
This.
A
C
A
Yeah,
I
think
that's
what
I
was
I
was
thinking,
maybe
I'll,
try
and
see
if,
like
I
think,
darcy
would
be
back
next
time
and
I'll
see
if
lauren
can
make
it,
and
then
you
know,
basically
with
with
people
from
both
snick
and
npm,
to
represent
that
discussion
we
could
do
a
deep
dive.
C
C
A
A
Okay,
if
not
the
next
one
is
pkgs
org
for
wbg,
supported
tooling,
that
one
I
I
think
our
next
steps
is
really
just
to
kind
of
audit
what
we've
got
and
make
sure
we're
ready
for
a
switch
to
move
it
into
the
under
the
node.js
governance
or
actually
even
just
start
start
to
do
some
of
that,
because
we've
already
got
agreement
to
do
it.
C
D
C
C
Folks
on
two
packages
in
the
npm
side,
that's
clearly
not
scalable,
so
I'm
wondering
what
we
like
it's
more
than
just
two
factor
authority,
because
we
also
need
to
just
like
automate
that
the
access
granting
thing
right,
like
did,
I
add
anybody
else
as
as
an
owner
of
the
npm
org.
I
can't
remember.
B
C
Okay,
I'll
probably
need
their
npm
credentials
and
also
I
would
love
to
turn
on
required.
Two-Factor
auth,
but
the
only
other
person
I've
added
and
I'm
not
going
to
call
it
out
on
stream
here,
but
needs
to
turn
on
two
factor
off.
C
A
A
So
I'm
not
sure
what
I'm
gonna,
whether
I'll
have
time
in
the
near
future,
but
you
know
try
and
get
to
the
point
of
just
looking
at
our
you
know
who
has
what
have
we
met
all
the
the
requirements
we
kind
of
wrote
down
and
then
I
think
finally
add
like
the
tfc
members
and
everything
like
that
and
you
know
change
the
accesses
so
that
it
it's
aligned
with
the
node.js
oregon,
like
the
moderation
team,
can
access
it
and
that
kind
of
stuff.
A
C
A
A
C
A
Teams
across
yeah
synced
across
orgs
that
would
be
interesting.
C
D
C
A
Of
us
gets
in
enough
pain
of
adding
people
we'll
we'll
we'll
bring
that
back
up
right.
A
B
There's
there's
also
the
housekeeping
prs.
I
still
have
six
open,
we
should
yeah.
I
need
somebody
to
look
at
them
and
oh
this
one
which
ones.
B
C
While
we're
making
progress
dom
is
your
is
your
get
sorry
your
npm
handle
the
same
as
your
github
handle
correct.
Yes,
okay,
cool,
I'm
gonna.
Add
you
because
I
think
you're
currently,
the
only
other
owner
on
the
pkg
js
org,
but
I
offered
it
to
others
if
they,
but
nobody,
nobody
said
yeah.
I
want
that
so.
B
B
A
A
C
B
A
Oh
my
npm
one
hold
on
I'm
gonna
have
to
look
that
up
and
I
have
a
feeling
it
might
be.
Mh
dawson
one,
but
I'm
not
100
sure
so
send
it.
A
C
C
A
C
A
C
A
A
Okay
right,
so
I
guess
yeah
that
that
point
once
those
land
you
figure
we're
in
we're
in
good
shape.
Right
is
the
okay.
C
B
C
C
Also
quick
question:
nobody
has
picked
up
the
create
repo
at
all
and
the
goal
is
to
actually
pivot
it
to
be
the
basis
for
this
thing
that
darcy
and
I
were
chatting
about,
do
we
want
to
just
archive
if
we
archive
it,
we
can't
do
so.
What
do
you
want
to
do
since
the
code?
That's
in
there
isn't
the
code
that
we
think
should
be
in
there.
I
just
did
push
some.
B
C
Well,
I
think
the
goal
is
but
darcy
I
think,
has
been
really
busy
and
I've
been
I've
been
sort
of
working
actually
on
some
pieces
related
to
this,
just
not
directly
in
this
repo,
like
I
have
a
create
package.
Jason
project,
which
is
hopefully
would
be
used
in
hours,
which
will
do
things
like
you
know
what
npm
and
it
does,
but
a
bunch
of
other
smarter
things
better.
C
C
The
create
package
is
the
one
that
actually
bundles
it
all
into
like
a
package
generator
not
just
like
a
you
know,
piecemeal
thing,
and
the
idea
would
be
that
you
know
that
darcy
was
talking
about,
which
is
like
basically
make
npm
init
outsource
to
this
package,
which
would
come
with
all
of
the
best
practices
that
our
group,
you
know,
defines.
A
I
think
getting
like
getting
it
into
the
state
where
it
was
what
what
we
could,
if
that
it
was
clear
what
we
need
to
do
on
the
support
side
we
might
get
like
riordan
has
been
pretty
active
in
trying
to
help
push
that
forward.
A
I'm
thinking
he
might
have
some
interest
in
you
know
helping
on
that.
One.
C
Yeah
and
I'd
also
be
happy
to
make
some
proof
of
concept
code
for
this
too,
because
I
have
been
working
in
this
space
off
and
on
you
know,
for
a
while,
and
I'm
gonna
have
to
do
it
as
part
of
my
my
normal
work,
so
I'll
be
definitely
involved.
So
if
I,
if
I
can
sorry
scaffold
some
stuff
out,
that
might
also
help
set
the
direction
and
then
we
can
get
darcy's
opinion
on.
If
that's
like
this,
if
he
agrees
that
that's
the
good
direction
so.
A
I
just
figure
like
if
you
have
limited
time,
even
just
writing
up
the
concept
so
that
other
people
could
then
say.
I'm
going
to
take
this
piece-
and
you
know
start
to
experiment
yeah-
that
that.
A
A
A
A
A
E
C
A
Validation,
which
we've
got
so
now,
I
think
we've
we've
got
agreement
that
we
can
break
the
blog
post.
I
just
need
to
find
the
time
to
do
it
and
if,
if
anybody,
I
I'm
hoping
to
do
that
in
the
next
week
or
two,
but
if
anybody
has
cycles
and
wants
to
write
it
or
help
write
it
just
put
your
hand
up
and
don't
want
to
be.
There.
E
A
Yep,
this
has
got
my
name
on
it
for
now
so
we'll
leave
it
leave
it
like
that
for
now,
okay-
and
that
actually
is
the
end
of
our
agenda-
is
there
any
other
things
people
want
to
bring
up.
F
You
beat
me
to
it:
glenn
yeah,
I
was
gonna,
ask
I
must
have
added
the
label.
Well,
let
me
paste
it
in.
I
think
I
might
have
added
the
label
too
late,
but
I
just
wanted
to
get
some
help
getting
closure
on
this
pr.
I
think
it's
got
approvals
and
I
just
didn't
know
because
there's
still
an
outstanding
change
request,
but
I'm
pretty
sure
hopefully
well,
I
know
glenn
has
made
changes
since
those
were
requested.
Now.
E
But
this
comes
under
the
be
careful
what
I
promise
thing,
because
I
already
have
several
approved
pr's
in
several
places
and
they're
not
getting
merged,
not
just
this
repo
but
other
repos.
A
C
Concerns
not
that
I
think
we
should
have
too
much
official
process
all
the
time,
but
do
we
have
a
process
for
if
somebody
has
a
descent,
but
then
the
dissent
is
resolved,
but
the
person
doesn't
come
back
and
comment.
I
think
tierney
would
come
back
if
he
knew
he
probably
just
missed.
D
F
Yeah,
why
I
didn't
well,
I
that
was
for
me
the
the
part
that
wasn't
clear,
or
you
know
what
the
sop
would
be
in
a
situation
like
this.
A
E
E
F
C
B
I
think
governance
defines
a
process
for
conflict
resolution
for
dissent
and
there's
the
consensus
seeking
process
right.
That
is
defined,
and
so
I
mean
maybe
we
should
have
followed
that,
but
I
think
in
this
case
maybe
we
should
have
given
tony
a
chance
to
get
back
or
raised
another
specific
issue
there.
So
I
don't
know
we
did.
We
did.
F
And
that
was
19
days
ago
so
summer.
E
A
This
is
what
I
might
I'm
just
pasting
in
what
a
comment
we
could
make
on
the
issue,
but
I
mean
I
think,
we're
discussing.
We
don't
necessarily
have
consensus,
but
this
could
be
the
you
know
that
we
had
we'd
not
had
a
response
from
the
originator
of
the
last
objection
and
we
believe
the
objection
had
been
addressed
right
so.
E
E
E
F
Month,
yeah-
and
I
guess
that's
an
interesting
point
to
I
don't
know
if
this
is,
you
know
bike
shedding
too
much,
but
you
know,
is
there
a
distinction
between
feedback
for
typo
versus
feedback?
Like
this,
you
know,
code
doesn't
have
tests
or
this
you
know,
concept
doesn't
align
with
the
vision
of
the
team.
You
know,
is
there
you
know?
Are
there
degrees
of
you
know.
C
One
one
thing
I've
done
in
the
past
and
we
could
maybe
recommend
this
to
other
folks
who
find
typo
type
updates
is
you
can
still
make
the
change
requests
and
not
say
requesting
changes
right
which
would
indicate
you're
not
blocking
you're,
not
dissenting
you're,
just
saying,
like
here's,
here's
a
few
small
fixes.
C
Sometimes
when
it
you
know
on
github,
you
have
that,
but,
like
I,
you
know
we
have
a
lot
of
like
stash
or
whatever
bitbucket
and
doesn't
have
quite
the
same
nuance
to
the
way
you
do
review,
and
I
always
when
I
have
something
where
it's
like
like
this.
I
just
say
this
is
not
blocking
like
do
not
consider
this.
You
know
blocking
merging
this,
and,
and
that
would
be
another
thing
we
could
just
tell.
People
is
be
clear.
C
B
I
think
I
think
going
forward.
We
should,
at
the
very
least,
explicitly
call
out
that
you
know
you
know
that
that
we
want
to
do
that.
I
agree
and
give
give
the
person
a
chance
to
respond
explicitly
with
the
request
that
you
know
have.
We
addressed
the
comments
and
there's
an
agreement
that
these
have
been
addressed
and
just
get
some
more
grace.
F
B
B
We
do
have,
we
do
have
a
couple
of
time
limits
defined
there
yeah.
I
don't
know
it's
just
that.
It's
it's
just.
What
I'm
saying
is
that
it's
it's
not
enough
to
just
ping
the
person,
but
we
need
to
explicitly
start
a
counter
saying
that
this
is
the
counter,
and
this
is
what
we
agreed.
That
should
be
done
in
case
of
no
response.
E
Well,
let's
update
the
docs
to
reflect
that
and
I'll
create
a
pr
to
do
that,
and
we
can
look
at
it
in
the
next
meeting
saying
we,
we
explicitly
need
to
create
a
counter
ping
them
and
say
a
counter
has
started.
You
know
if
no
feedback
is
had.
You
know
we're
going
to
proceed,
but
you
know
you
have
this
amount
of
time
and
we
can
just
change
the
dates
on
it
as
as
as
we
feel
best.
So
let
me
do
that.
I
think
I
wrote
the.
A
While
you're
writing
that
you
might
also
I
mean
the
tsc
is
often
like.
If
there's,
if
there's
a
stalemate
on
the
node
side,
it
can
be
escalated
to
the
tsc
and
then
by
consensus
of
the
tsc.
We
basically
say:
okay,
we're
overriding
the
objection
it
can
move
forward
yeah.
So
I
think
there
should
be
that,
probably
through
the
administrative
members
or
all
the
members
or
some
you
know,
some
combination
of
the
members
could
take
that
decision.
F
Yeah,
I
think,
there's
a
little
room
for
yeah.
I
agree
that
you
know
in
this
situation
like
this
yeah.
You
know
specifically
specifically
requesting
you
know
or
with
a
countdown
or
something
like
that.
So
that
way
you
know
if
you
are
maybe
because
part
of
it
is.
If
you
are
leaving
feedback
and
you
are
applying
a
hold,
then
it
would
seem
that
as
a
professional
courtesy
that
you
would,
you
know,
maintain
interest
or
activity
in
said
thing
right,
you
know
to
help
move
it
along,
or
else
you
know
this.
My
pr
might
have
been.
F
Not
not
to
you
know,
cast
generalizations,
but
you
know
just
trying
to
balance
the
you
know
the
impact
of
all.
F
A
A
Sounds
good
any
other
issues
that
people
want
to
bring
up.
B
B
C
Sounds
good,
okay
and
I
had
one
question-
and
I
maybe
just
am
missing
this
in
my
memory,
but
did
we
come
up
with
a
process
for
proposing
new
pkjs
projects
or
are
we
still
sort
of
on
the
like
go
by
you
know
just
do
it
no.
B
Does
yeah
yeah
it
defines
what
you
need
to
do
to
start
a
repo
whether
a
project
is
worthy
or
not
worthy
to
study
people
that's
another
discussion,
but
I
guess
that
can
be
always
discussed
in
an
issue
right.
It
starts
with
an
issue
too.
C
Okay,
I
have
been.
I
have
something
I've
been
working
on,
that
I
might,
I
think,
might
fit
it's
one
of
the
things
we've
talked
about
in
express
with
utilizing
scopes
and
in
order
to
properly
utilize
scopes,
we
need
to
migrate
a
bunch
of
packages
and
so
we're
you
know
discussing
different
approaches
and,
just
so
happens,
I've
had
to
write
something
for
work
that
I
think
well,
that
does
that
and
I
think
it
might
work
you
know
for
for
open
source
stuff
as
well.
C
So
I
was
thinking
about
that
might
be
a
nice
thing
under
the
pkg
js
org,
since
it
you
know
would
help.
I
don't
know
if
you
all
remember
the
big
babel
migration,
but
it
was
painful
and
a
lot
of
work
so.