►
From YouTube: Steering Committee 20181205
Description
Notes: http://bit.ly/k8s-steering-wd
Chat transcript (times may be off):
00:13:14 Michelle Noorali: I was looking at the autoscaling sig earlier today and will review today
00:13:38 Michelle Noorali: +1
00:13:41 Timothy St. Clair: +1
00:14:37 Brandon PHilips: Aaron, if it will be available by Wed next week I can do it.
00:32:23 briangrant: https://github.com/kubernetes/steering/issues/57
00:35:03 Clayton Coleman: Red Hat has this service
00:35:05 Clayton Coleman: It’ll cost you
00:36:16 Michelle Noorali: dope
00:37:32 Clayton Coleman: https://marketplace.visualstudio.com/items?itemName=redhat.fabric8-analytics
00:37:43 Clayton Coleman: The go stuff is still in preview, let me check with them
00:41:07 Michelle Noorali: Yes absolutely
00:41:11 Phillip Wittrock: +1
00:41:34 briangrant: Go itself: https://www.cvedetails.com/vulnerability-list/vendor_id-14185/product_id-29205/Golang-GO.html
00:42:30 Clayton Coleman: Brendan there is a CVE DB they’re maintaining but it’s supposed to be preview jan
00:42:33 Clayton Coleman: I’ll connect you to them to get details
00:43:09 Brandon PHilips: We need to work with the Go community to enable developers to add CVE data
00:43:27 Michelle Noorali: true
00:44:08 Dims: ++ Brandpn
00:48:23 Clayton Coleman: As a fun aside, reading their design proposal for golang detection support this gem jumped out:
00:48:25 Clayton Coleman: Moreover, an analysis of the 10000 most popular Golang packages across Github by comparing at the source file level shows that the most popular dependencies are those from the Kubernetes ecosystem/Kubernetes API itself, see [11]
00:48:38 Dims: :)
00:48:41 Michelle Noorali: cool
00:49:01 Michelle Noorali: We need an owner for the issue
00:49:23 Clayton Coleman: The net result though was a lack of high quality CVE source but they are motivated to make it happen
00:49:30 Michelle Noorali: https://github.com/kubernetes/steering/issues/85
00:50:08 Michelle Noorali: great to know @clayton
00:51:52 briangrant: SIG Diagram: https://twitter.com/bgrant0607/status/862091393723842561
00:53:01 Michelle Noorali: I could get with that
00:54:07 Michelle Noorali: Dan mentioned this to me a bit but it would be nice to know who is leading this effort
00:54:17 Michelle Noorali: Seems like something Brandon and I should be involve din.
00:54:21 Michelle Noorali: Involved in*
A
So
welcome
everybody
to
the
steering
committee
meeting
for
Wednesday,
December
5th
I'm
sure
we
are
all
incredibly
busy
in
preparation
for
coop
con.
So
I
tried
to
look
through
the
action
items
in
our
agenda,
which
I
will
post
into
the
chat
here
and
I
think
where
we
had
left
off
the
last
time
we
met,
which
was
four
weeks
ago,
because
we
canceled
the
meeting
in
proximity
to
Thanksgiving
was
we
wanted
to
push
on
having
all
of
the
charters
reviewed
and
pushed
forward.
So
we
can
talk
about
that
at
the
contributor
summit.
A
Most
of
the
action
items
related
to
you
actually
pinging
about
that.
There's
also
an
action
item
about
the
CLA,
but
James
is
not
here
at
the
moment
and
we'll
talk
about
that.
I
also
had
an
action
item
to
review
the
infra
working
group
charter
to
see
if
I
could
make
it
less
sig
like
and
I
did
not
get
that
done
in
time.
For
this
meeting,
I
would
really
like
to
get
that
charter
merged
before
the
contributors
on
it
where
we
had
left
it.
A
But
the
working
group
would
be
working
on
policies
that
made
sense
for
how
to
to
run
things
appropriately,
I'd
like
one
or
two
proxy
people
that
I
could
pay
to
get
a
sign-off
once
I
have
done
that
rewording
rather
than
having
to
go
through
a
majority
vote
from
the
steering
committee.
If
you
are
all
in
favor
of
that
I'm.
A
A
Busy
I
will
try
to
keep
it
short,
okay,
I'm
gonna
pop
up
in
a
window,
and
we
can
run
through
our
project
board
because
I
know
I
tried
to
go
through
and
take
a
look
at
all
of
the
sick
Carter's
and
then,
if
there's
anything
else,
we
wanted
to
talk
about.
That's
not
on
the
board.
Please
add
it
to
the
agenda
at
the
bottom
there.
So
let
me
figure
out
how
to
do
this
mean
sharing
thing
cool.
A
A
Documentation
and
sunset
procedures
for
SIG's
and
working
groups
is
blocked
on
me,
as
I
recall,
I
think.
Basically,
this
is
done.
I
just
needed
to
sanity
check
that
we
have
D,
duped
the
governance
files,
but
I'm
happy
to
close
this
out
and
carry
forward
with
that
off
of
this
board
and
out
of
this
meetings,
purview
ensuring
all
repos
have
the
same
contributing
structure.
I
think
where
we
were
at
last
time
was
that
somebody
under
fill'
I,
don't
know.
A
Geoff
freegan
had
some
concerns
that
we
were
forcing
too
many
files
into
the
root
of
a
repo
and
phil
was
gonna.
Go
talk
to
Jeff
to
just
kind
of
deal
with
it.
For
now,
Phil
can
I
get
you
to
follow
up
on
that
and
then
ping
Nikita,
because
she's
been
the
person
who's
been
pushing
forward
a
lot
of
the
like
contributing
MD
and
security
contacts
files.
So.
A
Also
connect
you
with
Nikita,
and
maybe
she
can
help
to
carry
that
forward.
Okay,
yeah,
okay
in
progress,
let's
take
a
look
at
where
we
are
at
with
the
Chargers.
We
are
a
lot
further
along
than
I
thought.
We
would
be
by
this
point
honestly.
So,
thanks
to
everybody
who's
pushed
on
that
Michelle,
you
said
you
were
gonna.
Take
a
look
at
Sega.
Auto
scaling
afterwards
appreciate
that
API
machinery
is
also
under
review
at
the
moment.
I
think
Brian
I
know
you've
expressed
a
number
of
comments
that
haven't
gotten
resolved.
A
A
E
A
I
am
I
pinged
the
contributor
experience
folks
at
the
meeting
this
morning,
I'm
just
kind
of
waiting
for
them
to
address
some
feedback.
I
dropped
down,
get
consensus
at
that
point.
I
need
to
hand
it
off
to
one
more
steering
committee
reviewer
to
do
so.
Sarah
was
the
person
who
was
listed
for
this,
but
I'm
not
sure.
If
I'm
going
to
be
able
to
reach
her,
is
there
anybody
who
would
like
to
volunteer
to
be
a
reviewer
in
her
stead?
A
The
contributor
experience
I
can
do
that:
okay,
Phil
Thank
You
Phil,
so
that
leaves
us
with
sig
p.m.
who
I
have
not
really
I've
reached
out
to
them.
They
kind
of
have
this
in
their
readme,
but
it's
not
quite
the
same
thing
as
charter
I've
reached
out
to
Steve.
Make
us
this
a
number
of
times,
but
look
like
it's
gonna
get
done
before
the
summit.
I
can
try
to
aim
that
one
more
time
and
see
what
happens
there.
A
We
hide
oh
I,
can
help
push
that
one
as
well.
Okay,
Steven!
That
would
be
greatly
appreciated.
We
have
this
wonderful
thing
where
Brian
I
feel,
like
you've,
been
talking
long
enough
about
how
you
think,
big,
big
big
data
shouldn't
actually
be
a
cig,
and
then
somebody
up
and
wrote
a
charter
for
it.
I
feel
like
we
have
written
down
some
comments
as
to
why
we
feel
this
doesn't
necessarily
qualify
for
sake,
but
I'm
not
entirely
sure
how
you
think.
We
should
proceed
with
this.
B
A
I
suppose
that
is
fair.
I
think
this
is
just
going
to
reinforce
that.
Just
because
we
have
charters
doesn't
necessarily
mean
that
these
sakes
are
going
to
be
set
in
stone
and
live
forever
and
to
maybe
emphasize
that
one
of
the
first
things
we
as
the
steering
committee
are
going
to
be
looking
at
this
coming
week,
is
how
best
to
sort
of
reconcile
and.
F
A
A
And
then
that
leaves
us
with
all
of
the
charters
that
pertain
to
clouds
so
sig
Asher
snuck
in
before
we
had
a
template
and
then
it's
like
GCP
and
OpenStack
have
held
off
because
we're
thinking
those
sakes
would
like
to
sort
of
fold
in
the
cloud
provider
and
I
think
even
I've
had
Stephen
comments
somewhere.
Maybe
it's
on
whatever
this
links
to
nope
that
he
would
like
to
focus
on
moving
I
think
you
could
comment
it
at
the
bottom
of
this
issue.
A
Actually
that
he'd
like
to
spend
more
time
rolling
the
sake
in
to
say
cloud
provider
and
that's
something
that
requires
more
discussion,
I
think
on
our
part
and
his
best
done
face
to
face
with
all
of
those
involved
at
the
contributor
summit,
so
I'm
comfortable.
You
know
at
least
most
of
the
way
there
you
can
stand
up
and
say
we
have
most
every
sink.
Has
a
charter
except
for
the
cloud
stakes,
because
we're
figuring
out
how
to
sort
that
out
any
questions,
comments
or
concerns
before
we
move
on
from
charters.
A
A
B
I
think
we
can
do
a
better
job
of
maybe
answering
when
when
it's
asked,
if
there
are
any
concerns
we
want
brought
up
with
uni,
we
should
probably
put
a
little
bit
more
thought
into
that
in
the
future.
Maybe
we
can
schedule
if
we
know
in
advance
where
the
meetings
are
gonna
be.
Maybe
we
can
discuss
it
at
one
of
these
meetings?
A
B
G
A
A
A
A
A
Okay,
where
does
the
effort
to
move
Kate's
infrared
estancia
fall?
It
falls
on
your
working
group,
a
charter
that
I
will
work
on
document
what
working
groups
are
and
how
to
form
disband.
This
is
the
reason
this
is
still
open
going
down
to.
The
bottom
is
because
we
want
to
add
a
field
to
SIG's,
so
we
can
formally
specify
for
given
working
group,
but
SIG's.
Does
it
cut
across
and
interact
with
and
the
other
one
is.
A
Then,
once
we
decide,
we
know
what
working
groups
are
and
we
have
that
fully
defined.
We
need
to
go
through
and
actually
audit
the
existing
working
groups
I.
Think
again.
This
is
something
that
we
can
talk
about
at
the
contributor
summit,
as
part
of
our
update
as
part
of
the
rationalization
process
and
the
the
version
and
I
gave
at
this
morning's
meet.
Our
contributor
edition
was
that
we
think
working
groups
should
be
temporary
and
ephemeral
ephemeral.
A
They
should
disband
once
they're
documented
stated,
goals
have
been
accomplished
and
there
are
a
number
of
working
groups
today
that
seem
to
exist
in
perpetuity.
So
it's
probably
time
for
us
to
revisit
whether
those
makes
sense
as
working
groups
or
if
they
need
to
be
turned
into
sub
projects
or
if
the
goal
has
been
accomplished
and
they
should
move
elsewhere.
G
A
A
This
again
came
up
in
the
content
in
this
morning's
meet
our
contributors
call
in
the
context
of
Brandon
mentioning
the
nodejs
dependency
vulnerability.
That
happened
where
there
was
some
malicious
backdoor
patch
that
was
committed
to
one
library,
which
was
then
pulled
in
as
a
transitive
dependency
to
another
Bitcoin
library
and
it
allowed
them
to
steal,
keys
or
coins
out
of
various
people's
wallets,
which
just
reinforces
the
notion
that
we
as
a
project,
are
where
the
buck
stops
when
it
comes
to
you
fully
vetted
inge
and
auditing
our
third-party
dependencies.
A
So
while
we're
doing
this
from
a
licensing
perspective,
first,
that's
great,
but
we
need
to
make
sure
we
kind
of
have
some
sort
of
ongoing
process.
And/Or
team
that
we
feel
is
capable
of
vetting
dependency
changes
as
they
come
in.
We
do
already
have
some
sort
of
documentation
checklist
for
why
you
might
need
to
rationalize
bringing
in
a
dependency
it's
in
a
doc.
That's
named
go
deaf
MD
in
community.
A
We
could
probably
find
a
better
place
to
surface
that
information,
but
I
do
think
we
probably
have
some
more
policy
stuff
to
do,
but
as
far
as
licensing
goes
I
remember,
heck
Hetty
was
definitely
a
thorn
in
our
side,
but
I
don't
think
it
was
the
only
one
I'm,
not
sure
how
much
more
we
have
to
go
here.
Yeah.
B
A
Guess
I'm
kind
of
feeling,
like
we,
someone
should
take
an
action
item
to
have
this
list
refreshed
so
that
we
can
talk
more
substantively
about
this
that
are
face
to
face
because
it
sounds
like
we
need
to
figure
out
what
what
the
policy
is
and
then
what
automation
we
are
lacking
to
help
us
maintain
a
good
known
State.
It
sounds
like
we're
still
in
the
process
of
getting
to
that
known,
good
State.
First.
E
Totally
true,
but
in
the
interim
I
think
we
need
to
make
sure
that
we
feel
like
we
have
enough
eyeballs
on
every
time
a
dependency,
at
least
in
KK
changes,
and
perhaps
we
need
to
change
the
you
know
the
pull
bot
to
represent
that
somehow
or
something
because
I
am
DYI.
I
think
this
is
all
good
stuff,
but
I
worry
it'll.
Take
us
a
year
and
I'm
a
suspect
that
this
style
of
attack
is
going
to
get
worse
before
it
gets
better.
So.
A
The
number
of
people
who
can
actually
approve
changes
to
vendor
is
relatively
small.
Let's
go
see
what
def
owners
actually
resolves
to,
but
I
know
just
anecdotally
that
Christoph
Blocher
is
one
of
those
people
and
he's
really
on
point.
As
far
as
are
you
sure
you
want
to
make
this
change
yeah,
it's
Christoph,
Tim,
Hawkin
and
Stephen.
A
F
E
H
We
already
have
a
replacement
which
many
people
are
using,
so
it's
mostly
trying
to
drive
changes
that
already
been
done
in
KK
repository
in
the
other
repositories.
That's
what
we
need
to
do
now.
So
that
is
one
part
you
know
as
part
of
the
existing
stuff.
That
is
a
broken
that
we
need
to
fix.
The
other
one
is
Steven.
August's
is
at
a
point
where
we
can
switch
on
fossa
the
plug-in
fossa,
whatever
github
scanner
thingy,
where
you
know
it
gives
you
a
badge
that
we
can
put
on
multiple
repositories,
so
that
is
in
progress.
H
They
are
I
just
asked
even
a
couple
of
days
ago.
What
state
it
was
in
I
won
one
more
time,
I
think
they're
very
close,
so
that
was
one
then
the
other
one
was
Nikita
and
I
talked
to
the
legal
representative
from
CN
CF
and
he
does
his
own
scanning
apparently,
so
he
promised
to
scan
all
the
repository
in
one
more
time
at
the
beginning
of
the
year.
So
those
are
the
things
that
you've
been
doing
on
the
side
on
this
topic.
I.
E
Guess
I'm
not
that
worried
about
the
licenses.
I
mean
it's
good
to
do
it,
but
I'm
not
as
worried.
I
is
very
concerned
that
that
this
will
be
the
flavor
of
the
month.
Attack
for
2019
and
I
strongly
suspect
that
we
are
vulnerable
and
like
in,
and
it's
only
luck
effectively
that
we
don't
get
attacked
right.
B
I
E
E
I
I
I
E
E
E
There
is
fine
yeah,
a
lot
of
maida
tools
are
not
gonna,
find
bugs
subtle,
bugs
right,
exactly
so,
and
and
and
and
that's
better
to
I
guess,
because
humans
can't
won't
find
the
subtle
bugs
either,
except
for
you
know,
accidentally
or
whatever,
but
it's
the
like
injection
attack,
where
somebody
says
hey
like
I
guess,
like
my
thought
exercise
to
you
is
like,
if
you
thought
about
a
way
to.
If
you
wanted
to
attack
a
cloud,
the
public
clouds
say
today.
I
would
absolutely
go
in
through
an
open
source
project.
Mm-Hm.
H
H
So
for
this,
one
of
the
things
that
I've
been
looking
at
is
what
is
a
list
of
personal
repositories
that
we
use
in
our
dependency
chain
right,
because
not
all
of
the
stuff
that
we
use
comes
from
other
all
repositories.
A
lot
of
personal
repositories
are
being
used
in
our
dependency
chain.
That
would
be
like
you
know,
the
first
leaf
that
we
need
to
go
yeah.
E
F
It
seems
to
me
like
this
is
possibly
like
it's
it's
a
build
test
and
release
process
right.
Yes,
yeah,
a
group
of
folks
who
are
empowered
to
make
sure
that
this
happens
and
whether
or
not
we
even
hire
them
from
the
CN
CF
or
what
not
is
debatable
if
we
don't
have
enough
resources
to
do
it.
But
I
do
consider
this
to
be
like
a
super
high
priority
item.
Yeah
I
mean
do
we
want.
A
C
I
mean
I
think
the
critical
piece
is
no
one.
Has
a
database
of
go
package
to
CDs
like
I've?
Very
rarely
even
see
TVs
for
Co
software.
So
that's
like
kind
of
the
linchpin
we
can't
activate
until
either
a
vendor
or
somebody
commits
building
on
database.
The
Red
Hat
I
have
a
view
on
it,
but
it's
not
probably
gonna
be
the
same
view.
We
need
totally
based
on
rpm
yeah.
H
B
C
E
E
A
Admire
your
enthusiasm,
Brendon
and
I
want
you
to
channel
it
into
a
hosel
that
is
relatively
pre-baked
that
we
can
actually
review
face
to
face,
because
that
we
need
as
a
group,
rationalised
who
should
like.
How
should
we
solve
this
problem
up
front
so
like
what
dims
has
been
doing
for
a
licensing
perspective?
How
do
we
kind
of
get
to
a
known
good
place.
A
H
A
H
A
Thanks
cuz,
like
I,
do
believe
it's
important
but
I.
Think
like
you,
should
you
know
defining
the
request.
The
proposal
should
at
least
include
like
who's
going
to
own
this
within
the
project.
Would
it
be
the
product
security
team?
Would
it
be
a
say,
could
it
be
a
working
group?
Would
it
be
the
steering
committee
and
we've
just
contracted
out
to
a
third
party,
but
and
then
how
would
the
solution
actually
work?
Would
it
be
build
or
buy?
Do
we
need
lawyer
cats,
whatever.
B
E
A
A
So
if
this
leads
us
to
a
huge
discussion
of
charter
scope,
I'm
just
gonna
punt
it
to
face
to
face,
but
Zig
release
noticed
yesterday
that
there
are
two
bullet
points
in
our
Charter
one
says:
decide
how
and
when
official
releases
of
kubernetes
artifacts
are
made
and
what
they
include,
and
another
bullet
point
says,
declare
a
release
so
that
the
committee
can
ensure
qualify,
/features,
/font,
sorry,
quality,
/features,
/font
mints
are
met.
I
do
not
think
we
have
been
doing
either
of
these
things.
A
A
So
that
brings
me
to
the
the
meta
point,
which
is
I
think
there
are
a
lot
of
points
in
the
Charter
that
we
have
delegated
the
execution
of
these
to
other
groups,
presumably
because
we're
just
the
escalation
point
of
last
resort.
We
don't
actually
do
that
as
execution,
but
there
are,
it
seems,
like
we're
kind
of
execute
the
escalation
point
of
last
resort
for
everything
on
the
project,
so
I'm
not
sure
why
it
makes
sense
for
us
to
explicitly
list
these
things
out
made.
A
Nobody
had
clear
authority,
so
I
think
the
reason
I'm
raising
just
this
tiny
point
up.
I,
don't
want
to
cover,
like
all
the
other
things
that
are
supposedly
covered,
is,
as
we
start
to
look
to
redefine
what
it
means
to
release
kubernetes
looking
at
repositories
moving
out
of
looking
at
functionality
moving
out
of
tree.
Who
do
we
need
involved
in
that
discussion,
Mike
and
response?
My
hope
is
that
sig
release
and
sig
architecture
could
hash
this
out
amongst
themselves
and
that's
where
the
key
decisions
would
lie.
A
B
Other
I
was
just
looking
at
the
original
charter
before
the
edits,
because
I
thought
in
the
original
charter
we
had
said
something
about
intending
to
delegate
but
I
mean
I,
don't
know
you're
the
obvious,
but
yeah
I
mean
in
general
this
steering
committee.
We
don't
intend
to
get
involved
in
technical
decisions,
even
escalations
more,
it's
more
about
the
meta,
solving
the
meta
problems,
of
structuring
the
project
and
setting
up
the
governance
and
deciding
who's
the
decider
on
technical
issues.
B
A
I
think
that
broader
theme
is
something
we
want
to
keep
in
mind
face
to
face.
We
probably
want
to
like
review
our
backlog
and
review
our
charter
and
see
which
priorities
and
things
make
sense
to
live
on
or
not
so
I'm,
not
gonna,
look
to
clarify
at
the
language
for
this
at
this
point,
but
this
gives
me
enough
to
move
forward
for
those
parties
who
are
interested
in
changing
what
release,
as
a
word
means
to
some
people.
B
Yeah,
just
just
as
one
example,
Cuba
I,
think,
is
still
in
the
release
from
the
cluster
directory
and
has
been
deprecated
for
like
two
years
at
some
point.
We're
gonna
have
to
replace
that
in
the
end-to-end
tests
and
move
it
from
the
release,
bundle.
So
I
think
these
things
will
evolve
in
the
relevant.
Things
will
should
be
involved
in
making
these
incremental
changes.
Well.
F
B
And
the
main
thing
I
wanted
to
bring
up
is
the
contributor
summits.
At
the
end
of
the
day,
there
was
Q&A
with
the
steering
committee.
Okay,
I
think
everybody
saw
email
thread,
but
just
want
to
make
sure
people
are
aware
of
that,
so
they
can
be
there
and
George
had
a
good
list
of
I
think
three
things
they
asked
us
to
talk
about.
B
In
addition,
as
a
warm-up,
well,
four
things:
okay,
introducing
ourselves
summary
of
what
we
accomplished
and
we
can
probably
talk
about
that
off
the
top
of
our
heads,
but
it
might
be
worthwhile
to
just
think
about
what
we
plan
to
do
for
the
coming
year.
That
seems
like
a
good
topic
that
people
reasonably
would
be
interested
in.
We
can
start
an
email
thread
on
that
or
we
can
discuss
it
now.
I
guess
we
have
a
few
minutes
left.
A
One
of
the
canned
answers
I
gave
this
morning
during
need.
Our
contributors
was
that
we
want
to
kind
of
reframe
what
we
do
towards
the
model
that
has
worked
well
for
us
this
past
year,
when
somebody
comes
with
a
fully-formed
solution
or
when
we
have
delegated
the
execution
of
something
to
some
entity
that
then
owns
it
and
so
to
find
a
way
to
empower
as
many
people
as
possible
to
move
forward
on
these
issues,
rather
than
create
an
expectation,
as
perhaps
we
had
over
the
past
year,
that
the
steering
committee
would
take
care
of
it.
A
B
A
The
so
the
themes
that
sorta
came
to
my
mind,
where
the
this
whole
rationalization
of
trying
to
kind
of
like
make
the
scope
and
size
and
organization
of
the
project
a
little
more
sane.
This
flat
space
of
30,
+,
6,
+
7
to
10
or,
however
many
working
groups
is
really
just
oppressive
to
a
newcomer,
let
alone
somebody
who's
trying
to
figure
out
which
place
they
need
to
go
to
find
a
decision
maker.
So
scoping
that
down
and
adding
some
kind
of
taxonomy
or
hierarchy
seems
like
it
might
make.
A
lot
of
sense.
A
I
also
think
that
as
this
project
grows
and
matures
were
really
focused
to
what
it
were
really
focused
on
what
it
takes
to
keep
kubernetes
boring.
So
the
we
are
interested
in
it
being
less
of
a
bumpy
ride
for
the
project.
I,
don't
think
the
steering
committee
is
involved
in
this,
but
I
would
impart
as
our
vision
a
desire
for
the
project
to
focus
on
its
health.
So
that
means
dee
flaking
tests
having
a
more
sane
and
reliable
release
process,
better
understanding
why
we
have
all
of
these
tests,
starting
to
put
formal
gates
in
place.
A
A
If
you've
dropped
me
in
front
of
the
audience,
that's
what
I
would
have
said
so
I
think
like
having
either
a
project
mailing
lists
or
a
Google
Doc
to
to
riff
on.
That
would
be
good
and
then
again,
I
think
saving
some
time
at
the
end,
for
us,
each
to
individually
give
some
shoutouts
just
so
that
we
can
give
some
recognition
without
necessarily
singling
people
out
as
the
project,
but
just
as
people.
A
B
If
people
aren't
aware
there's
discussion
in
various
places
about
smaller
conferences,
so
Prometheus
started
with
smaller
contributor
conferences,
prom
con
well,
not
just
contributors
for
smaller
conferences
envoy
had
on
vikon.
There
seems
to
be
traction
on
that.
Finally,
after
t
years
and
since
yes,
so
folks
are
looking
at
that,
you
know.
Obviously
you
have
had
some
smaller
events
like
the
contributor
summits,
the
leadership
summit
and
the
project
is
sort
of
huge,
so
getting
it
as
small
as
some
of
the
smaller
projects
would
be
hard,
but
I
think
that's
definitely
worth
looking
at.
B
So
what
one
theme
is
more
local
events
for
people
who
can't
travel
to
the
ginormous
conferences
which
have
fewer
venues,
so
they
would
be
smaller
just
because
they
would
be
at
smaller
venues
and
they'd
be
advertised
as
being
more
local,
but
that's
something
that
we
could
get
involved
with
at
the
conference.
There's
going
to
be
a
session
about
how
to
make
the
conference
better
is
on
Thursday
Thursday
afternoon.
So
take
a
look
at
that
and
come
to
that.
B
Yeah
there
was
a
today
I
think
in
Toronto.
Maybe
it
was
last
year
there
was
co-located
with
another
event
that
had
really
poor
turnout,
but
I
think
the
the
kubernetes
days
that
are
more
local.
Now,
there's
enough
interesting
kubernetes
that
that
seems
like
it
might
do
pretty
well
like
meetups
on
steroids
in
some
sense,
so
we'll
see
how
it
goes.
I
think
there
are
some
other
locations
that
have
been
discussed.
A
So
each
reminded
me
of
something
real
quick
I
personally
have
been
a
huge
fan
of
the
contributor
summit.
I
know
in
order
to
keep
it
as
small
and
focused
as
we
have.
It's
had
to
be
sort
of
an
invite-only
thing
or
as
close
to
invite-only
as
as
possible
one
of
the
ways
we
qualify
people
to
get
into
it
this
year
was
by
using
dev
stats
numbers
weird,
nearly
coincidentally,
ever
since
we
noticed
that
we
mentioned,
we
were
using
dev
stats
numbers
for
voter
eligibility.
A
I've
noticed
a
large
increase
in
the
number
of
people
who
are
submitting
random
type
OPRS
to
the
point
where
it
seems
like
more
people
are
noticing
it.
It's
unclear
to
me
whether
or
not
it's
increasing
a
burden,
but
they're
definitely
I'm
hearing
more
and
more
about
it.
So
I
think
that's
one
of
the
most
valuable
conferences.
I
think
we
should
probably
move
it
to
invite.
Only
and
one
of
the
things
that
I
have
always
complained
about
with
the
contributor
summit
has
finally
been
fixed.
A
This
year's
I
just
wanted
to
thank
Paris
for
putting
effort
into
making
sure
that
all
of
the
sessions
will
be
recorded
at
the
contributor
summit
this
year.
So
even
I
often
feel
like
that's
some
of
the
most
valuable
content,
so
I'm
really
thankful
will
at
least
be
able
to
link
to
that.
Even
though
not
everybody
will
be
able
to
participate
day
of,
and
that's
a
trend,
I
think
could
help
with
having
more
of
these
smaller
focused
conferences
going
forward.
A
But
I
do
think
that
just
relying
on
raw
numbers
that
can
be
easily
games
like
I,
don't
want
to
get
into
the
discussion
about
measuring
the
value
of
contribution.
I
just
think
that
we
should
move
to
some
sort
of
invite-only
model
for
that,
as
with
some
room
for
for
newcomers
is
as
hostile
as
that
seems
to
newcomers.
I
can't
think
of
other
better
ways
to
keep
that
that
kind
of
conference
focused
yeah.
B
A
Four
times
that
size,
it
was
400
and
it
was
put
on
the
main
funnel
for
the
conference,
which
I
think
was
a
mistake,
because
there
were
a
number
of
people
who
were
just
like
yeah
sure,
I'll
click,
every
checkboxes
as
I
register
for
koukaon
I'll
totally.
Do
this
thing
as
well,
and
there
was
a
lot
of
time
spent
being
like.
Have
you
actually
contributed
to
committees?
If
not
we're
going
to
move
you
to
the
new
contributor
workshop?
A
B
I'm
one
I
think
that's
a
good
point.
One
thing
I
found
last
year
is
just
being
really
clear
about
what
the
point
of
it
is
can
help
like
I
know
at
some
of
the
sig
deep
dives
and
intros
people
showed
up
who
had
no
interests
in
directly
participating
in
the
SIG's,
because
it
wasn't
super
clear
what
they
were
about.
So
we
could
just
make
it
more
easier
for
people
to
self-select.
A
E
H
E
H
A
G
Did
items
so
the
end
of
the
agenda?
Nobody
else
has
anything,
go
for
it,
the
we're
planning
on
meeting
Thursday
evening
and
Friday.
So
I,
don't
know
if
any
prep
has
been
done
for
that
in
terms
of
get
an
agenda,
so
I
just
added
a
github
issue
to
start
on
that,
maybe
we
could
just
I'll
add
things
that
we
want
to
talk
to
up.