►
Description
ContribEx GitHub Administration Subproject Meeting for 20200924
A
A
B
B
Let
me
pull
that
up
myself,
so
the
the
the
text
or
command
can
literally
be
you
know
whatever
you
want,
we
can
configure
it,
and
then
you
know
you
can
sort
of
at
at
the
person
and
give
you
know
nice
little
message,
sort
of
like
a
shout
out
and
that
will
actually
appear
on
their
profile.
So
you
will
get
sort
of
like
a
a
stream
of
things
there,
just
as
a
way
of
recognizing
people.
A
A
Having
having
another
way
to
like
collect
these
is
good,
can
we
like
something
that
isn't
shown
in
the
preview?
Is
there
a
way
for
like
for
somebody
whether
it's
like
a
repo,
maintainer
or
nerd
maintainer,
or
something
like
that
to
be
able
to
like
collect
these
and
and
and
see
like
from
one
at
the
repo
level
or
the
orig
level,
the
kudos
actions
that
are
being
taken.
B
C
B
B
B
C
B
A
Yeah
yeah
that'd
be
that
that'd
be
cool
just
for
for
understanding
and
also
just
understanding
uptake
like
hey.
If
we
enable
this
feature,
is
this
something
that
people
like
to
use
as
a
as
a
method
of
kudos
and
to
just
link
it
in
with
our
other
channels,
because
we've
also
got
yeah
the
shout
outs
channel?
We
do
tweets
about
things.
C
C
So
just
really,
that's
just
long-term
tracking
issue
links
out
the
github
github
renaming
repo,
so
it
looks
like
starting
on
october,
1st
newly
created
repositories
will
default
to
main
as
the
branch
as
a
default
branch
name
and-
and
I
think
we
have
the
consensus
that
we
do
not
want
people
to
move
forward
until
we
have
a
more
seamless
integration
right
for
them.
So
things
to
still
work
out.
B
A
Time
now
like
that
button
already
exists.
It's
gonna,
it's
gonna,
automatically
click
in
a
week
from
now,
but
we
can
click
that
button
anytime,
but
that
button
and
and
have
it
do
we
know
of
there
being
any
issues
with
us
making
that
move
right
now,
like
with
our
automation
systems.
I
don't
know
of
any
so.
B
B
C
A
I
don't
think
we
need
to
be
bound
by
an
arbitrary
date,
one
way
or
another
like
we
could
do
it
sooner
or
later.
I
don't
think
it
matters
to
us
whether
we
flip
along
with
the
rest
of
github,
because
I
don't
I
don't-
have
any
objection
doing
that
sooner.
If
we
know
that
it's
not
going
to
break
anything
or
at
least
if
we
don't
have
any
clear
indications,
that's
going
to
break
anything.
C
So
I
think
that
I
think
that
we're
talking
sooner
or
later,
but
like
we're
going
to
blink
and
october
1st
we'll
be
here,
so
I
would
say
I
would
say
given
what's
in
the
issue
and
given
what's
in
renaming
just
for
the
sake
of
less
confusion,
we
should
try
to
do
it
around
the
same
time
for
the
template
project
as
well,
especially
given
if
the
template
project
is
only
in
effect
for
new
repositories.
Anyway,
then
it
shouldn't
affect
anything
that
currently
exists.
A
I'm
okay
with
this,
with
the
the
asterisk
of,
if
we
start
noticing
things
that
we
don't
know
and
aren't
prepared
for
as
far
as
flipping
the
the
default
branch
that
we
can
revisit
this
decision,
and
basically
okay,
we
don't
like
our
automation-
is
not
yet
set
up
for
something
that
is
not
master.
So,
let's,
let's
unbreak
it
for
now
and
then
figure
out
what
we
need
to
do
to
fix
our
automation
stuff,
to
cut
it
back
over.
A
B
A
A
C
Action
and
say
we
want
to
look
inside.
We
want
to
look
at
places
that
might
be
referencing
like
blob
master,
there's
some
things
that
will
default
switch
over,
but
in
general
we
want
to
make
sure
that
any
automation
applying
to
new
repositories
that
potentially
have
the
new
default
branch
name
that
we
want
to
want
to
poke
at.
A
C
Looks
like
you
got
the
next
one
results
yeah
yeah,
so
I
guess
question
for
the
crew
so
for
people
who
are
because
I
think
I
had
mentioned
this
to
you
christoph
a
while
back
so
for
people
who
are
stepping
down
from
github
admin,
github
administration
or,
more
specifically,
like
new
membership
coordinator
duties
right.
I
had
requested
that
my
privileges
remain
in
place
for
config
reviewer
approver.
C
A
A
The
thing
that
we
maybe
should
have
done
was
there's
like
emeritus
lines
in
those
waterfalls.
Like
I
don't
mind,
recognizing
that,
like
these
are
people
who've
done
the
job
before
and
know
what
they're
talking
about.
As
far
as
like
you
know,
technical
pieces,
but
it's
you
know
when
you're,
when
you're
wearing
the
hat,
here's
the
privileges
when
you're
no
longer
wearing
the
hat,
you
don't
really
need
the
privileges
anymore.
C
That
point,
so
I
would
say
that
I
would
be
curious
because
I
think
we
also
talked
about
this
at
some
point
that
I
would
eventually-
and
I
believe
others
would
have-
eventual
interest
in
like
understanding
and
moving
towards
the
path
of
like
what
does
it
look
like
to
be
in
kubernetes
owners
and
the
right
now.
For
me,
the
path
is
not
clear.
A
So
that's
that's
the
second
question
that
you
have
there,
or
the
second
part,
is
like
the
managing
groups
and
managing
teams
that
shouldn't
be.
That
shouldn't
be
really
anybody
in
the
github
management,
where
we
want
to
try
and
delegate
that
out
to
sigs
as
much
as
possible
and
then
like
the
thing
you're
responsible
for
your
teams
will
just
from
the
oregoner
level
we'll
connect
permissions
where
we
need
to
to
be
like
okay,
repo
admin.
A
You
actually
get
the
admin
permission
and
you're
done,
because
we
haven't
turned
on
those
bits,
although
we
could
at
some
point
look
at
turning
on
some
of
those
bits,
because
parabolous
has
some
of
those
and
it's
doing
it
in
other,
like
other
instances
where
we
run
parabolas,
there's
probably
some
like
api
things
that
we
need
to
clean
up
there.
If
I
understand
it
correctly.
A
The
last
time
I
talked
to
my
my
red
hat
on
red
hat's,
running
parabolos,
red
hat's,
running
paravolos
and
they're,
doing
a
bunch
of
repo
permission
stuff
that
we
don't
have
turned
on,
but
it's
been
a
little
while,
since
I
talked
to
steve
about
that
and
what
what
we're
doing
in
red
house
configuration
versus
upstream.
So
there
are
some
other
things
that
we
could
do
as
far
as
like
even
connecting
and
getting
more
stuff
out
of
the
control
of
of
basically
gonna
have
owner's
team.
A
There
is
no
clear
path
right
now,
as
far
as
like
word
ownership
and
who
should
be
an
org
owner
or
what
the
path
is
to
do
that.
The
the
historical
precedent
I
can
definitely
like
shed
some
light
on
so
the
historical
precedent
is,
there
was
no
clear
policy
I
came
in
when
I
was
a
technical
leader
contributes
and
was
like
hey,
there's,
no
clear
policy.
How
does
somebody
get
that
and
they
were
like
okay
write
a
policy,
so
I
did
and
then
I
became
an
order
until
they
wrote.
A
Many
years
ago,
when
this
was
the
wild
west
of
open
source
software,
there
wasn't
anything,
wrote
a
policy,
that's
how
it
happened.
The
policy
is
basically
like
what
the
procedure
is
for
getting
people
to
be
work
owners,
but
we
have
no
policy
as
far
as
like
you
know
terms
or
really
how
many
org
owners
we've
there
needs
to
be
like
the
consensus
of
the
current
owners
to
propose
somebody
new,
and
anybody
that
does
get
proposed
needs
to
get
a
sign
off
from
steering.
A
There's
there's
that
step
in
there
that,
like
that's
one
thing
that
steering
will
explicitly
sign
off
on
is
saying
like
yes,
this
person
is
trustworthy
to
give
them
the
keys
to
the
castle
as
it
were,
but
yes,
other
than
that
procedure.
There
really
isn't
a
ladder
or
a
path,
because
it's
one
of
those
like
super.
B
A
Highly
privileged
permissions,
there
isn't
necessarily
a
hey.
We
like
we,
we
don't
necessarily
want
there
to
be
like
a
clear
ladder
of
like
you
know.
Okay,
maybe
we
have
like
third
short
owners,
because
everybody's
just
done
the
ladder
and
his
guns
done
through
the
steps
and
gone
up
and
threw
it.
So
it
is
ambiguous.
I
agree
is
it?
Is
that
a
good
thing,
though
I
definitely
like
yeah?
We
did
have
a
conversation
about
your
your
interest.
A
There,
stephen,
I
did
pass
it
on
and
when
I
don't
know
when
we'll
be
talking
next
about
org
ownership
like
when
somebody
wants
to
step
down
what
the
you
know
who
we
nominate,
how
we
choose
the
new
person,
if
there's
more
than
one
person,
that's
interested
like
all
of
that
is,
is
unfortunately
ambiguous
at
this
point
just
because
we
haven't
really
dealt
with
it.
I
think,
like
yeah,
I
believe,
we've
cycled
out
one
owner,
since
this
permission,
thing
happened
and
yeah.
So
it's
like
it's
it's
new
ground.
C
C
A
Privileged
and
there
wasn't
a
lot
of
like
sean
on
our
discussion
or
processes
which
isn't
really
the
open
source
way
if
it
doesn't
need
to
be
so
like
that's.
The
point
of
this
meeting
as
mister
is
to
shine
some
light,
at
least
onto
the
thinking-
and
I
don't
mind
like
talking
about
my
thought
process
in
an
open,
honest
recorded
way,
but
yeah
like
at
this
point.
It's
kind
of
like
shrug.
There
really
isn't
a
clear
answer
and
stuff,
but,
like
you
know
it
is,
it
is
a
topic
of
discussion
that
is
coming
up.
A
Basically,
in
every
place
of
the
project,
is
succession
planning
and
what
does
succession
planning
work
will
look
like
in
different
areas
of
the
project?
How
do
we
create?
You
know
continuity
in
the
project
as
people
as
jobs,
change
as
people's
priorities,
change
like
either
work
priorities
or
life
priorities,
and
all
that
kind
of
stuff.
As
this
is
a
you
know,
anything
we're
doing
around
managing
our
our
orgs
and
stuff
as
it
is
such
a
critical
role?
It's
definitely
a
critical
discussion
for
us
to
be
having
so
like.
A
Thank
you
for
bringing
it
up
we're
going
to
need
to
keep
talking
about
that
and
we're
going
to
need
to
kind
of
figure
that
out,
because
you
know
we
might
be
bandwidth
constraint
now,
but
we
won't
be
even
more
bandwidth
constrained
in
the
future
or
people
may
just
get
burned
out.
I
want
the
life
cycle
out
of
the
project
and
as
they
do,
we
need
to
kind
of
have
a
way
to
do
that
appropriately.
So
we
are
at
time.
Is
there
any
last
comments
before
we
wrap
up
for
today?.
A
Cool
well,
thank
you
to
the
two
of
you
in
new
york
in
the
hangover
today,
the
we
we
are
scheduled
to
have
a
meeting
next
month,
if
there's
anything
in
the
meantime
or
for
anybody
who's
watching
this
recording.
You
can
please
reach
out
in
the
github
management
channel
on
the
kubernetes
slack
or
if
you
need
to
talk
to
us
privately
github
at
kubernetes.io
or
public
discussions
can
go
to
the
controvex
mailing
list.
Thank
you.
Everyone
take
it.