►
From YouTube: Package Maintenance Team meeting - May 5 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
B
A
That's
probably
a
good
question:
I
haven't
looked
in
detail
enough
myself.
What
I
do
understand
so
far
is
it's
gonna
be
over
the
summit's
gonna
be
over
three
days
with
you
know,
one
of
the
days
being
I
think
more
focused
on
new
collaborators,
and
you
know
across
project
getting
people
involved.
One
of
the
days
is
gonna,
be
focus
on
sort
of
cross
project.
Cpc
discussions,
you
know
her
team's
working
together
and
then
the
other
one
will
be
for
each
of
the
projects
to
you
know
basically
have
sessions
on
of
interest
of
topic.
A
So
parallel
I
think
is
my
understanding
for
different
projects
to
have
topics
on
things
of
interest
to
themselves.
I'm
guessing
the
timeline
would
still
be
you
know,
kind
of
hour
or
maybe
hour-and-a-half
type
sessions,
and
the
last
thing
as
they
understand
is
it's
gonna,
be
the
same
time
like
Austin
time
and
I.
Think
the
last
thing
I
remember
was:
you
know
shorter
each
day,
so
maybe
four
hours
each
day
in
the
in
the
middle
of
that
Austin
time
like
we
can,
we
can
look
that
up
in
the
summit.
B
B
And
and
I
I
had
I
had
planned
on
doing
another
similar
thing
just
you
know,
life
can
get
in
the
way,
I'd
be
happy
to
I'm
interested
in.
So
one
of
the
reasons
why
I
think
we
got
the
engagement
we
did
is
because,
partly
because
it
was
in
person
so
totally
think
we
can
get
a
large
group
of
people
to
attend
something
I'm
interested
to
see
whether
we'll
have
the
same
long-term
efficacy
out
of
the
remote
event
and
that
sort.
B
Why
I
asked
the
question
for
the
for
this
for
us
running
one
for
the
package,
maintance
working
group,
you
know
irregardless
of
the
the
express
stuff,
because
we
already
do
a
lot
of
remote
meetings,
and
you
know
we
do
the
same
thing
for
the
express
triage,
Express
entry,
our
stuff,
it's
lately
at
least
and
I'm
just
interested
to
see.
If
people
think
how
effective
I
think
we
should
run
something
I'm.
Just
thinking
should
we
consider
it
being
remote
as
like
a
big
factor
and
what
we
decide
to
do.
I.
A
Think
it
would
be
good
like
if
you're
asking
like,
should
we
try
and
optimize
for
the
fact
that
it's
remote
I'd
agree
and
I
and
I
guess.
We
should
also
think
about
like
it's
an
opportunity,
perhaps
to
get
a
broader
audience
than
we
normally
get
right,
because
otherwise
you
know
if
it's
going
to
be
a
one-hour
session,
and
it's
going
to
be
just
the
same
people
that
we
have
on
this
call.
Then
your
point
about
how
much
different
is.
B
A
It
might
be
some
combination
of
the
two
I
know.
We
did
it
that
one,
the
one
in
Germany
I,
think
it
was
where
we
we
had
a
little
bit
of
context,
setting
up
front,
and
then
there
was
one
or
two
topics
that
we
doand
to
more
detail.
And
you
know
it
was.
You
know
we
could
treat
it
as
a
working
session
for
the
people
here,
but
also
then
potentially
get
more
and
you
know
different
views
into
those
to
those
areas
as
well.
C
Yes,
I
think
again
we
try
and
highlight
positive
light
and
try
and
take
a
learner.
So
we
can
get
people
on
board
to
maintain
the
project.
There's
also
things
we're
doing
as
a
group
of
defendants
we
can.
We
can
highlight
the
work
that
everyone
is
doing
there,
but
we
want
to
have
a
story
like
the
story
you
can
present
remotely
like
we
can
go
in
we've
been
into
the
expressed
as
an
on-ramp
for
help.
There's
an
off-ramp
thing
that
you
can
do
it
for
you,
you're
not
signing
up
for
life.
C
That
I
think
we
actually
were
extended.
The
positive
there's,
a
lot
of
work
that
community
is
doing.
We
should
say
hey.
These
are
some
of
the
rules
we've
come
up
with.
This
is
an
example
project
and
perhaps,
whereas
we
should
start
talking
about
other
projects
to
do
just
doing
the
Express.
One
is
really
limited.
C
B
This
idea
sounds
really
interesting
to
me,
because
one
thing
about
the
collaborator
summit
that
might
be
an
interesting
and
more
unique
opportunity
is
to
talk
with
some
of
the
other
open
J's
projects
and
see
if
any
of
them
are
interested
and
we
could
specifically
in
that
regard,
we
could
specifically
tailor
the
conversation
to
pay
other
project,
maintainer
x',
here's
the
things
we've
done
in
express
and
I
guess
expresses
the
the
main.
You
know.
B
Example
we
have,
but
you
know
we're
supposed
to
be
working
with
MQTT
as
well
in
the
quote-unquote
pilot,
but
I
think
that
has
maybe
eat
it
off
so
anyway.
My
point
is,
we
could
present.
What
we
are
doing
is
a
group
with
Express
sort
of
as
the
example
and
say
how
many
of
you
you
know
would
be
interested
in
working
with
us
on
something
like
this.
Do
you
have
any
feedback?
You
know
like
something
that
makes
more
sense
in
the
collaborator
summit
struck
structure
you
know
and
that
test
to
me
sounds
like
a
pretty
good.
E
B
And
you
know
what
this
might
be
a
really
great
opportunity
to.
If
we
do
structure
something
of
hey
here's,
the
things
the
package
means
working
group
is
offering
to
maintain
errs
and
then,
if
we
specifically
invite
the
Axios
maintainer,
that
might
be
like
a
decent
way
did
you
know
also
kick
off
that
conversation
in
a
more
concrete
fashion
as
well
as
talk
to
the
other.
You
know
open
justice
foundation
projects
and
maintain
jurors,
who,
you
know
will
be
present.
A
B
B
A
Of
a
you
know,
they
they're
always
asking
the
sooner
the
better,
because
they've
got
to
start
planning
and
arranging,
but
we're
still
six
weeks
out,
seven
weeks
and
so
I,
don't
I,
don't
think
one
week
is
an
issue
one
way
or
the
other,
but
just
we
should
make
sure
we
do
it
in
the
next
few
weeks.
It's
kind
of
my
take
as.
B
B
A
A
A
H
No
problem
so
I
think
this
issue
latest
update
on
this
issue
was
just
to
create
the
new
repo
over
at
PK
gjs
I
haven't
got
a
chance
to
start
looking
at
the
source
in
its
last
meeting,
but
Wes
D.
So
the
new
repository
issue
is
free,
v,
okay
and
I.
Think
the
main
discussion
here
was
well.
We
need
a
name
so
I
like
Jordans
I
or
with
our
grape
juice,
but
if
anyone
else
knows
any
of
our
suggestions.
I
A
A
B
A
B
G
Gonna
do
that
Wes,
yeah
that'd
be
great.
So
a
bit
ago,
I
was
talking
with
electronic.
They,
you
know,
they've
they've
had
an
a
repo
management
or
or
management
tool
for
quite
some
time
that
they've
been
working
on
and
they've
used
relatively
successfully
for
electron
and
keeping
it
locked
down.
It
basically
is
a
bot
that
you
know
they've
set
up
to
deploy
to
Heroku,
but
can
be
deployed
anywhere
that
and
configures
and
manages
get-up
organization
permissions,
repo
permissions,
repo
creation
so
like.
G
If
you
want
to
create
a
new
repo
yard
and
stuff
like
that
from
a
single
you
know,
file
and
a
single
repo.
It
also
integrates
with
slack
so
they
use
it
pretty
aggressively
to
monitor
when
things
aren't
how
they
should
be
so
it'll
kind
of
you
know,
be
the
sheriff
and
tell
you
when
something's
wrong
and
allow
you
to
go
fix
it.
So,
like
you
know,
if
someone
created
a
repo,
they
should
it'll
start
yelling
at
you
in
slack,
I.
Think
every
10
minutes-
or
you
know,
it'll,
say
this.
G
This
person's
access
level
was
changed
from
like
member
to
admin
in
a
way
that,
like
someone
manually,
went
and
did
this
when
that
should
never
be
the
case,
so
yeah
it.
You
know
it
does
that,
and
does
it
pretty
well
on
the
slack
integration
is
optional
and
I
believe
they
have
Google
G
suite
integration
too,
because
they
actually
have
SSO
enabled
for
their
github,
so
they
leave
are
actually
controlling
the
Google
permissions
through
suite
or
through
Sheriff
as
well.
G
B
The
questions
I
had
that
were
sort
of
open,
I
I
think
there
was
really
just
well
three,
maybe
okay,
so
one
is.
Does
this
matter
for
the
charter
sake
like
do
we?
We
need
to
know
the
details
of
how
we're
gonna
manage
it,
including
the
Charter,
because
then
it
maybe
doesn't
need
to
happen
in
this
conversation.
The
second
one
is
NPM
published
credit
management
would
be
probably
another
feature
we
wouldn't
want
that
need
but
want,
and
then
lastly
would
be.
Who
would
run
the
instance
and
I
know
you
mentioned?
B
Maybe
something
about
some
donated
hardware,
but
I
just
want
to
make
sure
we
have
that
out
in
there
or
open
those
questions
for
me
or
in
general,
I
think
in
in
general,
I
think
the
first
one
is
definitely
in
general
is
like
do
we
do?
We
think
we
need
to
know
about
the
details
of
how
we're
gonna
manage
that
that's
before
some
of
the
language
I
guess.
B
My
point
is
some
of
the
language
in
the
Charter
does
sort
of
get
to
details
and
if
we
think
we
need
to
get
mail
down
all
those
details
now
that
we
need
to
have
this
conversation.
But
it
might
be
make
more
sense
to
remove
those
details
and
just
say
it
will
be
managed
by
the
package.
Maidens
team
details
to
be
determined
or
something
yeah.
A
A
A
I
Like
the
to
itself,
it
does
not
matter
that
much
right.
The
Charter
describes
like.
If
you
want
a
a
new
repo,
then
you
open
an
issue
in
package.
Maintenance
I
mean
we
could
reward
it.
Then
you
open
a
pull
request
against
the
amo
file,
which
generates
the
repo
right,
but
I.
Don't
think
that
either
of
those
things
matters,
because
you
could
just
start
with
an
issue
and
package
maintenance
which
results
in
a
PR
which
one
gets
merged
automatically
merges
the
issue
and
we
can
enforce
the
time
and
stuff
the.
A
The
Charter
right,
like
it's,
not
I
the
kind
of
changes
to
the
Charter.
That
might
be
more
difficult
as
if
it's
like,
we
said,
okay,
we're
gonna,
have
you
know
a
smaller
group
of
people
who
can
create
repos
versus
anybody
can
create
repos
and
we'll
just
any.
You
know
to
be
to
become
one
of
the
people
who
can
create
repos
just
raise
an
issue
and
you're
in
automatically
right.
But
you
know
as
it's
more
the
level
of
sort
of
control
and
you
know
and
how
things
are
going
to
be
managed.
B
Okay,
that
makes
sense
to
me
so
that
answers
that
question
I
guess
the
NPM
published
thing
is
sort
of,
maybe
not
an
issue
we
need
to
actually
discuss
just.
We
should
probably
open
an
issue
on
their
repo
and
say:
hey.
Would
this
be
something
you'd
be
interested
in
us
either
working
on,
or
do
you
just
doing
I.
G
Can't
say
that
I
might
accept
that
as
a
contribution
as
like
a
plug
in
you
also
brought
up
Wayne
when,
when
it's
Wes
and
I
were
discussing
it,
there's
the
possibility
of
using
it
as
a
middleware
for
express
and
then
also
a
bit
like.
They
probably
won't
actively
do
that,
just
because
they
have
their
own
system.
That
they've
already
built,
there's
like
relatively
comprehensive
for
mantheon
publishing,
and
it's
not
tied
into
that
at
all.
But
I,
don't
think
they
would
be
opposed
to
having
a
plug-in
that
they
just
don't
enable
and.
I
I'm
not
sure,
if
anyone's
familiar
with
how
its
structured,
but
how
hard
would
it
be
to
like,
does
it
have
to
be
an
an
application,
that's
running
somewhere
on
an
instance
yeah,
because
that
implies
monitoring.
Can
it
not
be
converted
into
a
CLI
tool
or
something
like
that,
then
you
can
do
it
and
get
AB
actions.
You
can
do
it
locally
right.
G
G
A
B
A
B
I
was
sort
of
digging
through
it
a
little
bit
also
I'm
I'm,
not
super
typescript
proficient.
So
you
know
maybe
I'm
wrong
in
some
of
my
conclusions
here,
but
partly
the
reason
it
does.
This
is
cuz
it's.
It
is
running
as
like
a
slack
pot
as
well,
so
it
needs
to
have
a
bunch
of
persistent
stuff.
I
mean
I,
guess
in
fear,
and
it's
listening
for
webhook
calls
so
I
guess
in
and
it's
listening.
If
your
weapon
calls
from
more
than
just
github.
B
So
in
an
action
you
can
hook
into
github
actions
on
a
web
hook,
but
I
don't
know
how
we
would
go
about
doing
that
for
some
of
the
other
integrations,
and
that
might
be
something
that
breaks
their
version
of
it
again.
We
could
maybe
take
some
sort
of
slimmed
down
version,
but
then,
at
that
point
we've
we'd
probably
either
looked
at
forking
it.
B
G
E
I
can
see
that
as
well,
who
maintains
to
maintain
errs,
understood
but
I
think
it's
certainly
a
compelling
idea,
and
you
know
in
terms
of
like,
could
other
teams
take
advantage
of
it?
So
I
don't
know
if
there's
just
a
way
to
maybe
use
the
package
maintenance
to
provide
visibility,
or
maybe
it's
an
opportunity
to
like
fork
and
try
it
out
in
pkgs,
and
you
know,
make
modifications
that
maybe
spit
back.
E
B
What
it's
worth
I
think
what
you're
saying-
and
this
is
now
becoming
more
and
more
common
I've-
seen
it
in
a
few
other
projects
as
well,
where
people
have,
because
we
didn't
have
things
like
we.
We
had
things
like
github
actions,
but
we
didn't
specifically
have
github
actions,
so
people
have
a
ton
of
things
that
run
as
bots
and
they're
very
interesting,
but
all
of
them
require
some
sort
of
server
somewhere.
B
So
I
think
this
is
a
really
common
thing
that
we'll
need
to
look
at
when
we're
looking
at
these
type
of
tools,
moving
forward,
whether
it's
for
pkg
GSO
or
for
just
recommending
to
maintainer
groups.
So
it
might
be
nice
for
us
also
to
see
if
there's
any
good,
like
proof
of
concepts
of
taking
some
of
these
services.
B
So
I
think
one
thing
we
could
do
is
like
see
if
anybody
has
any
really
quality
examples
of
something
that
used
to
operate
is
a
bot
and
now
operates
as
a
github
action
and
see.
If
we
can
then
go
shop
that
idea
around
to
some
of
these
maintainer
zuv
these
tools
that
we'd
like
to
either
integrate
or
recommend
to
other
ecosystems,
because
it
really
does
lower
the
barrier
if
it's
just
to
get
up
action
like
like
significantly
so.
A
End
of
my
soapbox
on
that
particular
topic,
so
it
I
guess
what
I'd
suggest
is
like
I,
don't
think.
That's
related
necessarily
to
this
issue
like
trying
to
get
to
the
point
where
we've
got
the
Charter
approved
and
the
other
issues.
It's
an
interesting
thing
in
terms
you
know,
there's
a
bunch
of
different
aspects
like
Owen
mentions.
A
If
you
know
a
bunch
of
if
it
would
be
useful
for
maintainer
x',
then
actually,
if
we
had
a
champion
in
the
the
team
you
know,
maybe
we
should
experiment
on
ourselves
right
to
learn
more
about
it
and
see
how
it
works
and
be
able
to
explain
it.
But
I
do
think
that
would
require
somebody
who
sort
of
says
yeah,
I'm,
gonna
own
this
and
and
help
keep
it
going
right
and
otherwise,
like
you
know,
other
ideas
are
like
Wes
said
you
know.
A
E
I
Don't
know
anybody
who's
once
again,
familiar
with
this
more,
but
at
the
very
bottom
up
the
sheriff.
There's
two
known
limitations,
not
capable
of
inviting
people
and
not
capable
of
creating
repositories.
Is
this
simply
because
of
the
lack
of
time?
Is
that
an
opportunity
for
contributing
to
this
I
would.
F
B
Is
pretty
straightforward?
I'm
not
gonna
lie
I
only
took
me
a
few
minutes
to
sort
of
crack
it
open
and
understand
the
general.
You
know
concepts
in
it,
so
would
definitely
be
a
good
first
contribution.
I.
Think
for
somebody
to
Michael's
point,
though
maybe
we
should
get
back
on
topic.
Is
that
bit
we
have
that's
a
quite
a
bit
of
a
tangent
from
what
do
we
need
to
do
to
weigh
in
the
Charter
right.
A
J
E
B
Right
we
do
I
I
would
really
be
a
big
fan
of
that
change,
which
I
don't
think
got
brought
up
specifically,
which
is,
if
you
are
the
only
maintainer
you
are
allowed
to
I'm,
pretty
sure
the
way
it's
worded
in
the
draft
and
even
in
all
the
comments
we've
made
was
really
the
distinction
between
two
and
one
other
maintainer,
but
I.
Think,
like
I'd,
write.
C
B
I
J
A
J
I
Think
that's
good
practice.
Do
we
then
okay,
should
we
then
I
think
that
we
should
change
the
wording
that
it
requires
one
other
person
than
the
reviewer,
but
there's
sometimes
multiple
persons
pushing
again
to
pull
requests
and
then,
but
if
there's
two
the
way,
we
have
phrase
that
that
work
is
every
PR
has
to
have
two
sets
of
eyes,
which
is
excluding
people
who
only
have
one
or
fewer
ties
and
M,
not
funny
and
but
I
think
so
I
think
we
should
rewarded
one
other
person
at
least
one
other
person.
I
B
B
A
B
A
A
J
J
B
B
J
A
That's
actually
going
like
currently,
this
just
says
that
administrative
members
are
given
them,
and
this
is
where,
like
ok,
I,
think
I
I
tried
to
take
the
simplest
approach
as
opposed
to
letting
each
repo
be
managed
separately.
I
just
said,
administrative
team
member
administrative
members
are
giving
the
maintainer
role
they're
the
ones
who
can
actually
add
and
remove
people
from
that
team.
A
It
doesn't
actually
talk
to
the
process
in
terms
of
like
you
know,
do
you
open
an
issue
just
require
any
approvals,
I
think
it's
based
saying
we
trust
the
administrative
members
to
add
or
remove
the
people
appropriately,
and
then
we
could
then
use
that,
to
you
know,
define
processes
that
the
administrator,
the
administrative
people
say.
Okay,
once
this
happens,
then
I'm
gonna
go
and
do
it,
but
that
level
doesn't
necessarily
need
to
be
in
the
Charter
right.
A
This
is
more
just
in
the
Charter
it's
outlining
who
who
is
going
to
be
able
to
do
that
kind
of
thing?
If
we
then
want
to
make
that
automated
I
don't
know
if
that
really
changes
things
like,
certainly
the
removal,
the
way
you
talked
about,
it's
still
a
PR
right.
So
the
PR
might
land
somebody
would
still
have
to
go
and
say:
okay,
I'm
gonna.
Take
you
out
of
this
team
yeah.
D
B
C
B
Across
the
Horde,
do
we
add
people
on
a
repo
by
repo
basis
or
a
or
across
the
Eric?
So
today
it
just
because
I've
been
the
only
one
doing
it.
It's
been
across
the
whole
or
great
I,
just
added
you
as
a
member,
not
an
administrative
member
right,
so
you
still
can't
right,
yeah,
add
or
remove
people
from
teams,
or
maybe
you
can't
delete
repos
I,
don't
know
it's
whatever
the
owner
role.
I
think
I
still
might
be
the
only
one
or
maybe
Michael
I
added.
You
I,
think.
J
J
We
should
add
them
that
way,
and
they
should
be
added
to
the
team
for
that
package
and
we
parent-child
teams
as
needed
and
so
on,
and
we
should
strive
to
avoid
individuals
being
added
onto
a
repo,
but
that
whole
model
breaks
down
pretty
much
as
soon
as
you
have
more
than
a
handful
of
people
outside
the
org
having
access
to
repos,
at
which
point
you
might
as
well
just
do
it.
You
know
you
either
write
a
tool
to
fake
the
team's
like
an
automated
or
you
know
you
just
do
it
by
hand.
B
J
So
if
we
do
that,
it's
simple
because
then
we
everyone
can
just
be
put
into
an
appropriate
team,
and
that
way
the
repo
management
is
are
the
team's
correct
and
the
team
management
is
a
much
smaller,
simpler
question
to
answer
and
it's
easier
to
keep
the
teams
in
sync
and
not
have
to
check
all
the
repos
and
so
on.
I
was
just
pointing
out
that
if
we
don't
go
with
that,
adding
everyone
to
the
org,
then
there's
complications
of
you
have
multiple
sources
of
truth
of
who
has
access
to
the
repo
okay
and.
B
J
C
J
It
brought
in
New
York
personally
I'm
cool
with
adding
anyone
to
the
org.
It's
just
that
effects
billing
potentially,
although
the
recent
pricing
changes
and
stuff
might
make
that
less
of
a
problem
and
then
it
allows
people
to
put
a
org
badge
on
their
profile.
So,
like
you
know,
that's
not
a
huge
deal
but
depends
on
who
the
people
are
I.
Suppose
that's.
B
A
good
thing,
too,
you
know
right,
I'll,
give
visibility,
I
might
language,
but
I
definitely
think
that
all
of
these
things
we
should
figure
out
a
way
to
phrase
the
Charter
such
that
these
are
not
in
them.
I
think.
The
thing
we
would
have
to
say
is
other
than
administrators
access
is
granted
per
repo
or
something,
and
then
we
can
figure
out
like
what
that
means.
A
I
think
what
this
says
the
way
it's
currently
written.
It
basically
says
the
maintainer
x',
who
are
going
to
be
able
to
yeah
it
currently
is
written,
is
like
one
set
of
maintainers
across
all
the
repos
and
then
the
admin
members
from
the
package
maintenance
team
are
the
administrators
who
control
who
can
be
in
that
particular
team.
A
If
we
want
to
have
it
be,
and
indeed
you
know
the
the
flip
would
be,
there
is
multiple
teams,
one
for
every
individual
repo
and
then
you
could
still
go.
You
know
you
could
still
stick
with
the
administrative
members
are
added
to
all
of
those,
and
so
it's
still
the
administrative
members
who
can
decide
who
can
be
added
or
removed
from
the
individual
teams.
But
then
you
control
access
individually
as
opposed
to
across
the
repos.
So.
J
My
suggestion
would
strongly
be
multiple
teams.
The
browserify
org
has
been
managed
in
the
sense
that
everyone
in
the
or
gets
permissions
to
everything,
but
what
that
also
means
is
that
I
get
listed
as
the
maintainer
on
like
30
NPM
packages
that
I
don't
touch
or
have
context
on,
and
so
I've
slowly
started
to
make
some
teams
in
the
NPM
org,
but
also
in
the
github
org.
For
that,
and
similarly
like
it's
it's
nice
to
be
give
people
access
that
and
trust
them
that
they'll
use
it
well.
J
B
If
we
start
doing
automated
NPM
published
right
so
right,
that's
why
I
think
it's
it's
just
safer
to
me
and
I.
Don't
think
it's
there's
not
that
many
people
like
we
could
go
in
and
set
up
teams
for
everything
and
add
the
appropriate
people
today
in
like
the
next
30
minutes
and
be
done
with
it,
probably
for
a
while,
like
other
than
you
know,
you
know
random
addition
or
removal,
which
is
really
easy.
B
A
J
J
A
J
That
down
what
I
mean
is
we
should
make
the
obstacle
not
be
that
the
feature
is
not
in
the
governance
dock.
The
abstract
should
be
that
the
thing
you're
trying
to
do
and
not
allowed
to
do
is
something
that
we
don't
want
you
doing
right,
and
so
so.
I
would
hope
that
the
mechanism,
then
for
laying
out
those
boundaries,
is
not
delineating
features
on
a
website,
but
is
instead
talking
about
yes,
actually
what
we
want
to
do
or
not
do
yeah.
A
So
that
line
we
could
adjust
to
say
you
know,
administrative
members
are
giving
them
in
turn
a
role
for
the
team
and
can
add
or
move
members
as
appropriate.
In
addition,
you
know,
based
on
consensus
based
on
the
consensus
of
administrative
members.
Additional
maintained
errs
can
be
added
to
that
team,
or
something
like
that
right.
A
B
A
Was
no
L
no
I
was
I
was
more
of
the
you
know.
That
would
be
an
option
but
more.
What
I
was
thinking
was
that,
in
addition
to
the
administrative
members
being
added
and
being
maintained,
errs
the
administrative
members
have
the
right
to
nominate
additional
maintainer
'he's
right.
So
it's
it's
not
that
just
once
you're
a
maintainer
you
yet
you
get
to
become
add
more
maintainer
x',
but
that
the
people
who
are
currently
written
there
as
the
ones
who
can
who
are
maintainer,
x',
well,
administrative
member.
So
we've
called
that.
A
A
A
A
B
A
Way
it's
the
way
it's
currently
written
the
administrative
members,
yes
need
to
approve
that
PR
and
they
would
go
in
and
do
that,
the
the
question
I
thought
Jordan
was
saying
is
we
might
want
to
allow
somebody
else
to
add
a
maintainer
to
a
team
that
who's,
not
an
administrative
member
and
currently
the
governance
wouldn't
allow
for
that.
So
we
would
need
to
add
something
if
we
want
to
do
that
as
well.
B
J
J
And
then,
when,
given
those
abilities,
we
should
they
should
be
trusted
with
them
until
we
have
deemed
that
they
have
misused
them
and
so
create
like
anointing.
New
maintainer
x'
is
something
that
maintainer
should
be
able
to
do
in
general,
I
think
and
until
we
see
that
becoming
a
problem.
I
would
prefer
to
have
everything
worded
that,
in
a
way
that
trusts
maintainer
is
to
to
grow
their
own
ranks.
It's
hard
enough
to
find
new
maintainer
x'.
We
don't
need
to
add
bureaucracy
to
it
and
we
just
face
to.
J
A
My
reference
I
think
if
we
can
just
get
some
suggested
wording
like
it
could
be
that
you
know
it's
an
extra
couple
sentences
saying
you
know
in
addition
to
the
administrative
members
being
in,
you
know,
being
maintained
being
able
to
add
an
add
and
move
maintainer
x'.
They
can
also
nominate
you
know,
or
you
know,
existing
maintainer
x'
are
also
allowed
to
nominate
or
whatever
the
you
know,
captures
what
we
want.
What
we
think
makes
sense
and
of
course
we
can't
change
this
as
well.
A
B
Okay,
there's
other
things
but
I
just
do
we
want
to
wait
until
we
land
the
Charter
to
make
the
appropriate
changes
to
the
pkgs
or
or
do
you
want
me
to
just
start
going
because
I
could
go
and
make
teams
for
all
this
I'd
be
happy
to
do
that
and
then
I
think
there's
some
member
default
settings.
We
might
have
to
tweak
to
get
the
teams
to
be
the
thing
that's
like.
Are
we
alright
with
me
just
starting
to
do
that,
like
administrative
work.
A
A
1
1,
we
have
only
one
minute
so
I'm,
just
gonna,
say
in
the
next
steps
of
support
levels
for
packs
Jason.
The
the
one
thing
I
was
trying
to
unlock
was
work
on
the
tool
that
does
the
validation
generation
have
scheduled
a
meeting
for
later
on
this
week.
I
think
it's
Thursday.
The
link
is
in
that
issue.
So
if
anybody
else
is
interested,
you
know
welcome
to
come
and
that's
kind
of
the
neck.
The
last
thing
on
that
and
we're
exactly
at
four
or
anything
else.
I
Added
a
label
on
issue
three
for
eight:
the
housekeeping
one
I
think
I
have
two
questions
there.
One
is
the
approval,
so
I
think
I
have
the
approvals
just
need
to
get
out
and
March
the
issue.
The
other
one
is
the
existing
repos.
They
may
have
got
of
conduct
contributing
and
PR
templates
on
them.
Do
you
want
to
remove
those
and
just
rely
on
the
central
one,
or
do
you
want
to
keep
the
individual
ones
or
the
customized?
Yes,
I?
Think.