►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Public Technical Oversight Committee (TOC) Meeting - Moderated by Chris Aniszczyk, CTO, The Linux Foundation
Speakers: Chris Aniszczyk
This session is a panel discussion moderated by Chris Aniszczyk with members of the Technical Oversight Committee. Feel free to come with questions, but we'll be doing an overview of the Technical Oversight Committee's governance structure, scope, mission and processes.
To learn more about the TOC, visit https://github.com/cncf/toc
A
Okay,
hi
everyone
welcome
to
the
last
day
of
of
kubecon
and
kind
of
one
of
our.
You
know
Traditions
to
kind
of
make
the
you
know
our
technical
board,
the
TOC
kind
of
more
open
and
welcome
to
all's.
We
generally
Host
this
Toc
session
to
kind
of
explain.
You
know
how
we
work
as
an
organization
and
have
an
opportunity
to
meet
folks
that
are
on
on
the
TOC.
So
you
know
we
have
technically
11
people
on
the
TOC.
A
C
E
F
G
G
H
A
Aaron
Boyd
who's
at
no
red
hat
now,
back
at
Red
Hat
has
been
involved
in
a
lot
of
storage
projects
and
then
Harry
zank
from
from
Ali
who
can't
make
it
here,
but
this
is
kind
of
our
group
folks
that
overall
decide
the
technical,
Direction
and
vision
for
the
organization,
so
I'll
do
kind
of
a
brief
kind
of
refresher
for
folks.
You
know
that.
Don't
really
know
how
cncf
is
structured.
A
This
is
kind
of
how
the
sausage
is
made
and
less
interesting
in
my
opinion,
but
does
give
you
kind
of
an
important
Insight
of
how
the
organization
is
structured.
So
you
know
my
name
is
you
know
Chris
anazick
I'm
serve
as
the
CTO
of
the
organization.
I
helped
start
at
about
seven
years
ago,
and
the
way
the
organization
is
structured.
You
know
you
basically
have
a
separation
between
business,
governance
and
Technical
governance,
so
there's
a
board
of
directors
at
governing
board.
That
decides.
A
Basically,
you
know
the
overall
kind
of
you
know
how
the
budget
is
spent,
how
the
overall
strategy
for
the
organization
goes
and
kind
of
is
shaped
over
over
time.
It's
mostly
consistent
of
vendors.
You
know
that
kind
of
build
products
on
kubernetes
and
other
cncf
projects.
There
are
some
end
users
there,
so
they
handle
like
the
boring
business
stuff.
In
my
perspective,
you
have
the
technical
oversight
committee
or
Toc,
as
we
call
them
the
11
folks
that
generally
have
worked
on.
A
You
know
cncf
projects
or
have
deep
technical
expertise
in
in
some
domain.
They
are
the
folks
that
decide
which
projects
get
in
the
organization
which
projects
that
archived
they
decide
the
overall
technical
kind
of
strategy
and
vision
for
the
org
and
they
kind
of
act
as
a
resource
on
a
laser
on
between
projects.
The
board
and
kind
of
you
know,
and
also
as
mentors
to
kind
of
help
projects
out,
and
then
we
have
an
end
user
kind
of
group
that
essentially
represents
end
users.
A
People
are
billing
building
and
using
you
know,
cncf
projects
and
interesting
ways,
but
actually
not
selling
them.
No
they're,
not
selling
Cloud
native
services
or
they're,
not
really
vendors.
So
this
kind
of
three
weird
three-ring
circus
makes
up
the
the
cncf
and
the
tocs
kind
of
I
have
a
view
in
the
middle
of
it
kind
of
bridging
the
gaps
between
these
organizations.
So
one
thing
that
the
TOC
does
is
help.
You
know
come
up
with
a
set
of
principles.
This
was
recently
refreshed.
Thank
you
very
much.
A
A
Each
project
kind
of
operates
on
its
own
projects
are
self-governing,
which
for
you
who
may
have
you
know,
had
experience
with
other
open
source
Foundation,
whether
it's
like
an
Apache
or
an
eclipse
or
openstack
cncf's
a
little
bit
different,
where
we
kind
of
lead
projects
to
their
own
devices
to
kind
of
come
up
with
their
own
way
to
operate,
which
is
you
know,
could
be
a
little
bit
confusing,
but
gives
people
the
flexibility
to
operate.
Some
have
steering
committees,
some
don't
some
have
a
flat
list
of
maintainers.
A
Some
have
senior
maintainers,
so
projects
are
very
self-governing
in
how
they
run
and
operate.
What
does
the
TOC
look
for
in
general,
they're
generally
looking
for
high
quality
velocity
projects,
but
everyone
has
their
own.
You
know
preferences.
The
other
big
thing
here
is:
there's
a
philosophy
around
no
King
makers.
So
you
know
generally,
we
allow
competitive
projects,
so
there's
I
can't
even
count
how
many
service
meshes
anymore.
You
know,
there's
a
bunch
of
get
Ops
projects,
there's
a
little
overlap
and
competition.
A
The
old
the
whole
idea
is
to
you
know
not
have
just
one
prescriptive.
You
know
solution,
allow
kind
of
competition
and
allow
the
market
to
kind
of
you
know
flourish
and
kind
of
decide.
What
is
what
is
what
is
best
we're
not
really
a
traditional
standards
body.
So
we
don't
really
do
long,
International,
ISO
style
standards.
We
more
do
de
facto
standards
that
are
defined
by
code.
A
A
You
know
Wonderful
projects
to
build
products
or,
in
some
other
way,
kind
of
fill
the
gaps
as
kind
of
the
the
attitude
we
have
and
like,
above
all,
you
know
the
theoc
kind
of
wants
to
stay
out
of
the
way
they
just
want
to
help
projects
when
they
need
it.
So
I
think
this
kind
of
set
of
principles
has
served
the
organization
fairly
well,
and
you
know,
they're
not
locked
in
stone
could
always
evolve
these.
A
If
we
need
to
over
time
a
lot
of
people
ask
how
do
I
get
involved
in
this
like
mysterious
body,
sometimes
well.
The
best
way
to
get
involved
is
to
actually
contribute.
So
we
have
a
variety
of
technical
advisor
groups
or
we
call
them
tags.
They
usually
represent
some
topic
area.
Security
Storage.
You
know
contributor
strategy
observability.
These
are
the
best
Avenues
to
get
involved.
If
you
ever
want
to,
potentially
you
know
run
for
a
Toc
seat,
it's
a
great
Avenue
to
kind
of
get
started
in.
A
In
my
opinion,
sandbox
processes,
the
project
processes,
so
there
are
three
different
types
of
cncf
projects.
We
have
sandbox
incubation
and
graduation
and
they
roughly
map
the
maturity
level.
Sandbox
projects
are
early
stage,
they're
meant
to
be
experiments.
Some
fail.
Some
grow
into
crazy
large
projects,
incubation
a
little
bit
more
mature,
there's,
probably
a
little
bit
more
diversity
in
the
project
in
terms
of
maintainers,
more
companies
involved
and
then
graduation,
which
really
is
the
tocs
like
stamp
of
approval
that
you
know
this
project
is
mature.
A
You
could
bet
your
business
on
it
and
use
it
and
not
worry
too
much
over
over
the
long
term.
So
this
is
kind
of
the
thing
that
they,
you
know
as
a
group
control
overall,
to
ensure
that
you
know
end
users
and
adopters
of
software
have
some
type
of
stamp
to
look
at
right.
We
do
have
a
brand
new
Sandbox
process.
That
was
just
you
know,
we're
fine.
Thank
you.
A
So
you
know
we
kind
of
keep
this
informal.
Like
you
know
from
my
time
as
organization,
a
lot
of
people
have
asked
like,
oh,
like
I,
would
love
to
like
go
meet
a
Toc
member
to
ask
them
about
you,
know,
project
or
some
questions,
and
this
is
really
about
kind
of
lowering
that
barrier
you
know
here.
We
are
open
to
take
any
questions
and
you
know
meet
folks
that
may
have
not.
You
know,
met
each
other
before
so.
I
have
some
kind
of
like
basic
questions
that
I've
kind
of
always
asked
I.
A
Think
I'm
going
to
ask
a
couple
and
then
really
I
would
just
like
to
hear
you
know
from
the
audience
of
like
what
do
you
want
to
ask
these
folks?
You
know
anything,
you
know,
you
know
anything.
You
know
dramatic,
or
you
know
just
like
random
questions
of
like
what
you
know.
You
know
what
do
you
think
about
this?
We'll
have
that
option
available
for
you,
so
you
know
my
you
know.
You
know,
we've
probably
accepted.
Oh,
you
know
almost
close
to
30,
you
know
or
so
projects.
A
You
know
you
know
this
year
and
you
know
I
would
love
to
kind
of
hear
the
toc's
thoughts
on
you
know
what
it's
like
landscape
keeps
growing.
Emerging,
pull
requests
almost
every
day
on
this
thing.
What
what
is
missing
from
like
our
comprehensive
you
know,
tool
chain.
Is
there
something
particularly
missing
that
you're
interested
in
that
you
want
to
fill
and
and
see?
A
Maybe
our
community
help
out
with
or
is
there
something
that
you
know
you
think
we
should
focus
on
kind
of
like
you
know,
in
the
in
the
future,
so
like
either
like
what's
missing,
or
what
do
you
think?
Are
there
future
directions
for
us
as
an
organization?
Anyone
want
to
start
with,
you
know,
potentially,
what's
missing,
Tims.
D
D
So
that
is
probably
one
thing
that
if
we
want
to
fill
the
void,
we
should
probably
start
there,
but
there's
so
many
things
that
we
need
to
do
and
we
should
be
doing,
but
from
the
point
of
view
of
the
users
of
our
ecosystem,
they
don't
really
have
an
option
there,
other
than
Walt,
for
example.
Right
now,
so
we
should
try
to
do
something
about
it.
C
I
can
go
next,
I
think
the
landscape
has
been
growing
a
lot
throughout
the
years,
and
everyone
can
see
that
there
are
a
lot
of
names
around
the
vastness
of
the
landscape.
However,
I
think
nowadays
we
reach
a
maturity
level
where
multi-tenancy
has
not
been
solved
as
a
problem
that
well
anymore.
There
are
multiple
solutions
that
have
been
multiple
initiatives.
To
do
that,
however,
we
don't
have
anything
comprehensive
that
is
truly
open
source
based,
and
it's
not
just
delegating
a
problem
to
a
vendor.
C
C
It
is
overwhelming
to
consider
how
many
tools
you
have
to
use
in
production
you're
not
going
to
use
just
kubernetes
you're,
going
to
use
at
least
a
couple
of
tools
for
observability.
You
have
networking,
you
have
storage,
you
have
runtime
secret
manager,
it's
just
best
like
as
an
engineer.
You
need
to
work
with
at
least
10
tools,
and
this
is
the
minimal
viable
option
for
you
to
to
run
a
very
successful
production
environment.
C
So
in
terms
of
improving
and
simplifying
the
developer,
experience
I
think
that
still
requires
a
bit
of
work
from
from
our
community.
Yaml
is
great,
but
maybe
we
need
to
look
at
the
next
best
thing
and
try
to
include
more
people
from
different
development
backgrounds
to
to
be
able
to
configure
and
deploy
kubernetes
and
anything
related,
Cloud
native
and
then
the
last
thing
I'm
going
to
mention.
I
know
it's
not
going
to
be
very
technically
infused,
however.
I
think
we
need
to
work
better
at
developer
retention
as
well.
C
G
I
I
think
we
know
that
sometimes
for
same
on
space
or
problems,
we
have
multiple
projects,
I
think
it's
not
very
easy
for
the
end
user
to
choose
you
know
or
which
one
should
I
use
or
should
I
try
to
apply.
I
think
one
way
we
can
help
with
that
is
we.
We
can
have
very
good
document
on
what
other
you
know
overlapping
functionality.
What
are
the
differences?
G
What
are
the
different
uses
scenarios
and
also
the
architecture
difference
right
and
as
it
will
be
better
if
we
can
have
the
pros
and
cons
of
each
product,
each
product
is
what
is
a
pros
and
cons.
I,
think
that
and
using
scenarios
I
think
that's
a
very
important
to
help
users
to
choose.
Okay
for
my
scenario,
which
one
I
should
it's
better
for
my
UC
scenario.
K
I
Think
one
thing
where
there's
still
work
to
do
is
the
area
of
managing
multiple
clusters.
It's
a
common
part
pattern
that
has
been
picked
up
for
a
while
now
and
not
only
managing
those
clusters
and
the
applications,
but
also
handling
like
scheduling
of
applications
across
multiple
clusters.
It's
something
that
quite
a
lot
of
people
struggle
with,
and
there
has
there
have
been
multiple
efforts
to
try
to
solve
it,
but
I
don't
think
we're
there
yet
so
there's
still
space
there.
F
I
think
there's
still
a
bunch
of
gaps
around
developer,
tooling
and
I.
Think
you
know,
we've
we've
done
a
good
job
of
making.
You
know
getting
kubernetes
out
there
and
the
bits
you
need
to
operate
it,
but
the
the
whole
developer
effect
because
we
we
started
having
a
few
more
developer,
focused
projects
recently,
but
there's
still
a
lot
there's
a
huge
kind
of
cab.
First
until
and
we've
got
a
few
webassembly
projects
which
is
kind
of
cool,
but
there's
lots
more
scope.
There
too.
B
The
tooling
around
what
should
actually
exist,
arguably
like
something
or
as
Katie
mentioned,
yaml
is
nice.
But
when
you
look
at
where
it's
coming
from
it's,
it's
a
serialization
format
where
you
have
something
else
which
which
compile
was
what
which
was
compiled
into
this
and
the
whole
Space
of
defining.
What
should
actually
be
running
and
what
should
be
deployed
is
extremely
hecky
and
there's
no
defective
standards
in
this
area.
B
A
That's
good,
so
I'll
ask
I,
think
one
more
one
or
two
more
questions
and
then
I'll
we'll
hand
it
off
to
the
audience
to
tell
us.
So
you
know:
I
had
a
crazy
week
at
kubecon,
probably
met
you
know
thousands
of
people
attending
a
few
sessions.
You
know
what
was
kind
of
maybe
the
most
interesting
thing
that
you
saw
or
kind
of
thing
that
surprised
you
in
terms
of
maybe
like
a
technology
or
a
project.
So
for
you
know
me,
I
was
kind
of
excited
to
see
how
much
you
know.
A
People
are
experimenting
with
webassembly.
You
know
today,
Justin,
for
example,
you
know
Docker
integrated
with
you
know,
wasm.
You
know
Edge
and
kind
of
modify
the
container
D
shim
to
support
that
in
in
kind
of
the
workflow,
so
I'll
be
kind
of
curious.
If
there's
any
TSC
members
of
like
what
did
you
see
that
you
thought
was
like
interesting,
that
you
know
caught
your
attention
that
you
know
you
think
especially
promising
for
for
the
cloud
native
community.
H
I
mean
excuse
me,
I
was
just
going
to
second
webassembly
I.
Think
webassembly
is
one
of
the
neatest
things
that
I've
seen
in
a
while
with
its
potential
around
performance
resource
utilization,
the
security
model
I'm,
really
the
speed
at
which
it's
gone
from
Something
That
We're.
Tinkering
with
to
being
something
that
you
can
really
consider
is
is
pretty
fast
and
I'll
be
curious
to
see
where
it
is
a
year
from
now,
I
expect
a
lot
of
great
things.
H
J
So
well,
not
necessarily
at
this
conference
I
remember
early
on
when
I
got
started
in
Cloud
native,
the
I
was
introduced
to
the
idea
of
a
sidecar
and
like
how
much
coming
from
a
former
government
that
sounded
like
agents
on
hosts
all
the
time
taking
up
compute
and
resources.
So
it's
interesting
to
start
to
see
projects
talk
more
about
sidecar
lists,
and
what
does
that
mean,
but
the
amount
of
innovation
that
can
happen
on
top
of
that,
once
that's
removed
from
an
entire
architecture,
could
potentially
unlock
new
technology
emergence.
G
F
I
mean
I
always
like
to
see
all
the
new
the
new
faces
at
Cape
can
the
new
people
who
are
coming
along
for
the
first
time.
It's
always
really
exciting
to
it's
better.
You
know
the
people
are.
People
are
still
coming
into
this
ecosystem,
they're
still
growing,
still
a
lot
of
work
to
do
to
help
them,
and
it's
that's
always
what
I
kind
of
find
exciting
yeah.
B
One
one
thing
which
I
find
super
interesting
is
that
initially
Cloud
was
like
about
breaking
out
all
those
old
service
barriers
and
making
everything
horizontally
scalable
and
like
making
things
much
more
malleable,
and
you
see
this
trend
going
backwards
again,
like
it's,
not
all
tiny,
microservices
anymore,
you
have
a
need
for
multi-tenancy.
There
are
sidecars,
there's
service
meshes
like
all
those
old
concepts
of
of
how
to
deal
with
the
total
amount
of
complexity
are
coming
back
in
this
pendulum
swinging
back
and
forth,
as
we
try
to
figure
out
where
the
nice
point
in
between
us.
D
Not
super
interesting,
what
has
become
important
to
me
is
like
just
seeing
the
scale
of
you
know
how
many
clusters
are
out
there
across
the
cloud
providers
and
how
people
are
able
to
do
day,
two
stuff
to
upgrades.
You
know,
scale
everything
and
how
it's
becoming
ubiquitous
now,
with
almost
like
you
saw
some
numbers
right
like
Gartner,
was
talking
about,
like
95
of
new
projects,
will
end
up
using
some
kubernetes
angular.
So
we
want
to
get
boring.
D
So
it's
not
interesting,
but
there
is
still
a
lot
of
activity
coming
from
the
kubernetes
team.
So
you
know
there
are
certainly
challenges
around
like
upgrades
and
things
like
that,
but
we
would
welcome
more
participation
in
the
different
projects,
not
just
kubernetes,
to
make
the
ecosystem
healthy
and
make
sure
that
it's
gonna
there,
it's
gonna,
be
there
to
serve
you
in
the
you
know,
future.
A
Thank
you
James,
so
we're
kind
of
a
little
bit
about
halfway
through
so
I'd
love
to
kind
of
turn
it
over
to
the
audience.
The
whole
purpose
of
this
kind
of
session
is
really
to
kind
of
introduce
people
to
Toc
humanize,
make
it
more
make
them
more
accessible
to
everyone
to
ask
you
know
questions.
So.
Does
anyone
have
questions
out
there
that
they
would
like
to
ask
the
steam
Toc?
L
Great,
so
thank
you,
so
the
cloud
native
Space
is
really
Broad
and
a
lot
of
the
kind
of
edges
of
the
space
are
even
growing
to
things
outside
of
cloud
native,
where
a
lot
of
projects
are
getting
use
outside
of
that
space.
So
it's
been
some
discussion
about
potentially
dual
homing
projects,
or
things
like
this
with
things
like
the
open,
ssf
and
I
just
wanted
to
know
people's
thoughts
about
it.
J
Thanks
so
much
for
the
question
Justin,
it's
funny
that
you
mentioned
that
I've
actually
been
in
communication
with
the
open,
ssf
technical
advisory
Council,
as
well
as
our
governing
board
about
what
does
it
mean
for
projects
moving
forward
as
more
and
more
foundations
set
up
and
there's
a
lot
of
overlap
between
the
projects
and
the
efforts
and
initiatives.
So
I
I
believe
that
the
cncf
TOC,
open,
ssf,
Tac
and
other
foundations
are
starting
to
figure
out.
J
What
does
that
look
like,
because
we
still
want
to
be
able
to
empower
all
of
the
projects
underneath
each
foundation
and
the
way
that
those
foundations
are
set
up
to
be
run
and
those
projects
are
established
to
be
governed
but
still
allow
that
open
collaboration
across
different
groups,
because
ultimately,
there's
only
a
few
folks
with
certain
specialty
skills
that
can
translate
between
the
different
foundations,
and
we
certainly
don't
want
to
be
pilfering
Talent
from
one
another.
When
collectively,
we
need
to
move
forward
together.
A
Yeah
there
is
an
open,
GitHub
issue,
I
think
where
this
is
being.
You
know
discussed
that
you
kind
of
follow
and
you
know
from
a
Linux
Foundation,
you
know
perspective.
A
lot
of
these
things
are
structured.
You
know
differently,
you
know
some
are
more
focused,
maybe
on
specs
or
communities
of
practice.
Some
are
security
focused
right,
maybe
more
policy,
so
you
know
I
think
at
the
end
of
the
day
you
know
people
have
realized.
A
This
is
somewhat
maybe
confusing
for
end
users,
I
mean
you
need
to
figure
out
how
to
you
know,
work
together
in
a
way
that
makes
sense
that
doesn't
make
like
the
legal
side
of
like
who
makes
decisions
who
owns
things.
However,
that's
governed,
and
it
doesn't
confuse
that
that
aspect
with
the
actual
needs
of
the
community.
D
D
So
far
it's
been
like
people
floating
around
the
different
organizations,
but
you
know
we
have
done
it
before
right,
like
oci,
Arc,
and
projects
here
overlap
a
lot
because
both
deal
with
containers,
so
I
would
like
to
turn
that
question
to
ask.
What
is
it
like
that
you
would
see
as
a
benefit
of
the
collaboration
and
how
what
it
should
look
like
going
forward
that
will
help
inform
us
on
what
we
need
to
do
on
our
end.
L
D
E
You
know
present
lots
of
failure
story,
not
bad,
not
not
only
for
success
story,
but
so
that
most
of
the
people
think
that
you
know
failure
are
going
to
be
the
inevitable,
but
you
can
get
back
from
failure
to
be
successful.
So
right
now
most
of
the
keynote
speech
keynote
presentations,
the
more
I
go.
We
are
good.
We
are
great
we're
so
good
people.
We
love
you
South
Africa,
but
you
know
the
grand
native
is
more
like
you
know.
The
failure
is
the
the
fact
or
maybe
is
included.
E
D
D
So
if
you
go
there,
you
will
see
all
the
horror
stories
and
we
always
encourage
people
to
post
their
own.
You
know
Journey,
so
to
say
there
I
mean
if
you
just
Google
for
it.
You
will
see
why
I
didn't
use
kubernetes
right,
like
this
lots
of
stories
like
that,
we
talk
about
the
failures
all
the
time.
You
know
what
went
wrong
and
why
we
were
not
able
to
get
a
feature
or
like
we
had
a
feature.
D
We
are
going
to
drop
it
because
it
was
not
working
properly
right.
So
we
talk
about
failures
all
the
time.
Yes,
we
need
to
figure
out
how
to
do
this
in
this
environment,
where
60
or
newcomers
who
don't
know
you
know,
so
it
might
turn
them
off
a
little
bit.
So
you
know
yes
you're
right.
We
should
do
more
of
it,
and
people
will
learn
more
from
it
than
all
success
stories.
Yes,
thank
you.
C
I
have
a
comment
to
this
one
as
well.
Actually,
while
you
whilst
you're,
asking
a
question,
I
realized,
we
don't
really
talk
too
much
about
our
archived
projects,
because
they
were
actually
very
successful
at
the
time
when
they
entered
the
space
and
they
were
archived-
and
this
is
a
very
normal
step
throughout
the
life
cycle.
It
just
didn't
reach,
for
example,
maybe
the
or
didn't
cover
all
the
use
cases
that
we
had
within
the
adoption
base,
so
I
think.
C
Maybe
we
definitely
should
have
a
highlight
session
of
why
the
projects
were
archived
and
and
celebrated,
because
they
actually
did
a
lot
of.
They
had
a
lot
of
impact
on
the
ecosystem
and
we
actually
should
treat
it
as
such.
So
I
think
this
is
definitely
something
that
I'll
think
I'll
submit
as
a
next
keynote
or
on
the
keynote
talk.
C
A
K
J
J
Some
of
them
were
available
online,
but
it
was
a
good
opportunity
for
us
to
hear
a
little
bit
more
about
their
concerns
with
the
current
process,
because
we
do
so
have
some
communication
challenges
and
ensuring
the
things
that
the
TOC
discusses
and
gets
out
of
our
head
are
conveyed
in
a
way.
That's
actually
actionable
both
for
the
projects
themselves,
but
also
the
tags,
because
we
really
rely
on
their
expertise
of
the
various
domains
that
they
cover
to
assist
us
and
extend
our
body
of
knowledge,
so
it's
relevant
and
actionable
for
those
projects.
J
So,
as
a
result
of
that,
we've
been
really
thinking
through
how
we
can
go
about
changing
sandbox
to
incubation.
How
do
we
set
projects
up
for
greater
success?
How
do
we
allow
them
to
do
better
self-governance
and
ensure
that
the
kind
of
like
Road
bumps
and
detours
that
often
happen
with
projects,
aren't
new
learning
experience
for
every
project
every
single
time?
J
So
if
that
means
defining
milestones
for
projects
to
hit
before
they're
eligible
for
application
to
incubation,
maybe
that
is
getting
sponsorship
or
recommendations
for
multiple
tags
who
have
looked
at
the
project
of
their
various
domains
because
a
lot
of
this
stuff
overlaps.
If
it's
security,
if
it's
not
working,
if
it's
storage,
anything
like
that,
getting
that
feedback
from
them
and
also
that
drives
a
lot
more
contributions
back
into
the
tags
as
well.
So
we're
we're
considering
a
lot
of
changes,
but
we
really
need
the
community
feedback.
F
D
F
I
I
think
it
was
a
part
of
part
of
the
reason
we've
been
changing
the
sandbox
process.
A
few
times
is
just
it's
been
incredibly
successful.
We've
LED
an
awful
lot
of
projects
in
and
there's
still
more
and
more
demand
to
come
in.
So
I
think
you
know
it's
really.
You
know
we
know
we.
We
know
that
the
backlog's
too
long
it
takes
too
long,
like
the
the
all.
F
The
original
changes
were
to
make
this
process
faster,
but
it's
still
it's
still
having
to
scale
up
because
there's
more
and
more
demand
and
we
have
a
lot
more
projects
now.
So
we
know
we're
a
bit.
We
know
we're
kind
of
overwhelmed
by
the
by
the
number
of
projects
we
had
to
review
and
we're
trying
to
get
make
it
easier
and
and
continue
to
make
it
easier.
D
D
We
say:
go
file
an
issue,
so
we
don't
try
to
lose
track
of
the
things
that
you
are
telling
us
what
is
broken
right,
so
this
feedback
loop
and
doing
it
asynchronously
helps
a
lot
we
earlier,
we
used
to
try
to
do
things
in
a
Google
doc
and
get
to
a
consensus,
and
things
like
that.
It
was
very
hard
and,
like
all
of
us,
have
like
Google
Docs,
going
way
back,
which
we
never
did
anything
about
right
or
it
was
hard
at
that
time.
D
Right
like
we,
we
kind
of
reached
consensus,
but
then
you
know
something
came
up
or
something
dropped,
so
our
Focus
changed
and
then
you
know
we
left.
So
we
are
trying
to
do
this
consciously.
So
you
can
hold
us
accountable
for
the
things
that
you
have
told
us
that
we
need
to
worry
about
or
fix
or
change.
D
So
we
are
trying
to
do
that
consciously
now
so
and
we
are
inviting
people
to
like
help
with
PRS
to
existing
documents
and
such
as
well
so
we
want
to
it,
you
know
we
can't
do
it
without
you
all
right,
like
so
I
would
like
you
to
participate,
not
just
in
the
tax
in
the
TOC.
Also,
okay,
two
minutes.
Thank
you.
So.
G
I
think
there's
another
missing
part
we
can
help.
Is
we
can
help
connect
the
products
which
need
more
contributors
to
people
who
like
to
contribute?
Because
sometimes
we
found
out
the
project
and
do
not
meet
the
crow.
Commandment
is
not
because
not
enough
people
is
working
on
it
right
for
every
aspect,
and
then
there
are
some
people.
We
know
from
some
companies
who
like
to
contribute,
but
they
don't
know
which
one
you
know
best
match
their
skill,
settle,
which
one
need
contributors
so
we're
working
with
a
contributor
strategy
tag.