►
From YouTube: 2022-01-06 Governance Committee private meeting
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).
B
Seems
good
to
me,
I
think,
ted
is
well.
Ted,
has
coveted
he's,
not
very
sick,
but
he's
out.
For
that
reason
I
can't
speak
for
anyone
else.
I'm
actually
sick
too,
but
I
don't
have
covet
I'm
just
plain
old,
sick
yeah.
I
mean
I
don't
know.
There's
the
fairly
incendiary,
like
thread
that's
going
on
is
when
it's
called
call
it
for
what
it
is.
I
don't
know
what
we
want
to
resolve.
B
I
still
wasn't
totally
sure
I
did
ask
the
question
like
okay,
so
we're
having
a
gc
meeting
we're
talking
about
this.
What
decision
are
we
making
kind
of
thing
and
then
I
don't
know
like
it
seems
like
something's,
not
working,
that's
evidence.
So
we
could
talk
about
that
too,
but
I
I'm
not
sure
where
people
want
to
go
with
this.
D
B
E
E
Similar
rules
on
our
own,
but
we've
kind
of
left
it
up
to
sigs.
To
do
that,
I
guess
the
question
is:
is
the
collector
a
regular
sig
that
comes
up
with
its
own
rules,
or
is
it
important
enough
to
the
overall
health
of
the
project
that
it
needs
to
have
similar
rules
to
the
specification
and
the
other?
E
Because
you
know
I
I
think
the
three
major
parts
of
the
project
are
the
specification,
the
collector
and
then
all
of
the
implementations
are
kind
of
like
on
their
own.
So
I
see
the
collector
as
really
important
in
terms
of
the
actual
issue
that
brought
all
this
up.
E
I'm
not
sure
you
know
one
way
or
the
other
on
that,
but
in
terms
of
the
multi-vendor
approval
rules
on
the
collector,
I
guess
the
question
we
have
is:
do
we
view
the
collector
as
a
a
more
important
like
higher
tier
of
component,
similar
to
the
specification,
or
is
it
just
a
sig
like
the
clients,
are.
D
I
don't
think
I
mean
even
the
specifications
for
the
collector
are
defining
the
specification,
like
the
high-level
specification,
like
protocols
that
we
implement
otlp
is
defined
there,
so
we
we
are
just
implementing
that.
Okay,
sure
we
we
maybe
we
used
more
like
the
collector-
may
be
used
more,
but
I
don't
see
a
huge
difference
compared
with
other
things,
but
if
we
want
to
treat
it
special.
E
I'm
not
sure
that
I'm
proposing
anything
either
way.
I'm
asking
do
we
view
the
collector
as
a
more
important
component
that
needs
these
types
of
protections
or
not,
you
know,
should
should
those
protections
be
applied
to
the
specification
and
anything
that
needs
to
be
protected
should
be
in
the
spec
or
should
those
protections
be
also
applied
to
the
collector,
because
it's
more
important,
I
think,
that's
the
question.
We
need
to
answer
yeah.
A
I
mean
daniel,
I
I
think
I
mean
again.
I
do
think
that
the
collector
is,
you
know
as
important
as
the
specification
of
the
other
implementations,
but
it
does
have
its
it.
It
has
a
larger
ecosystem
of
dependencies
and
user
facing
breaking
changes
right
so
end
users,
you
know,
tend
to
use
the
collector
a
lot
and
also
you
know.
A
Configuration
changes
for
example,
or
configuration
management
is
definitely
a
huge
area
which
you
know
affects,
and
so
we
have
to
be
extra
careful
because
there
are,
you
know,
receivers
as
well
as
exporters
with
different
types
of
interfaces
as
well.
As
you
know,
tlp
right,
so
it's
a
more
complex,
you
know
set
of
components,
and-
and
bogdan
I
mean
again,
you
may
be
looking
at
core
collector,
but
we
are
looking
at
the
overall
collector.
A
You
know
with
all
its
parts
in
contrib,
as
well
as
the
configuration
management
and
you
know
other
moving
parts
that
need
to
be
streamlined
right.
A
So
so
it's
definitely
more
complex
in
the
pipelines
that
it
supports
than
than
any
specific.
You
know
language,
sdk,
sdk,.
D
C
I
think
dan
kind
of
got
to
the
the
heart
of
it
at
the
beginning
of
his
statement
where
he
says
that
small
changes
in
the
spec
can
have
large
ramifications
for
the
rest
of
the
implementations,
and
I
think
the
collector
core,
as
a
framework,
is
in
a
very
similar
position.
It's
a
framework
for
the
development
of
telemetry
management
agents
and
small
changes
to
that
framework
can
have
significant
effects
on
the
telemetry
management
agents
that
are
built
on
top
of.
B
It
I
mean
so
just
summarizing
some
of
the
things
that
have
been
written
in
github
in
the
last
72
hours,
like,
I
think,
there's
there
are
concerns
about
like
development
velocity
for
the
collector
and
being
able
to
make
changes
their
concerns
about
opacity
in
the
collector
and
not
understanding
like
the
design
direction
and
having
alignment
around
that
sort
of
strategy.
B
There
are
I'm
trying
to
think
about
like
when
I'm
the
I'm
trying
to
choose
concerns
that
are
sort
of
like
more
like
outcomes
of
the
work
than
like
how
we
do
it.
If
that
makes
sense
like
velocity
is
an
important
thing
to
be
optimizing
for
transparency
and
roadmap
is
another
thing
to
be
optimizing
for
bogdan
you're,.
D
C
D
D
B
I
actually
said
that
velocity
is.
Let
me
want
to
optimize,
I
think,
or
we
I
don't
know
it
was
a
recorded
call.
Maybe
I
didn't
say
that,
but
I'm
trying
to,
I
think
frankly
about
me,
I
think
you're
feeling
pretty
defensive
is
how
it
comes
across
to
me,
because
I'm
not
saying
that
and
that's
what
you're
hearing.
So
what
I'm?
What
I'm
trying
to
understand
here
is
like
what
we
should
do
next.
B
I
don't
think
what
we're
going
to
do
in
this
meeting
is
decide
that
we're
going
to
gc
by
fiat
is
going
to
make
a
decision
about
the
open,
telemetry
collector.
What
I
am
observing,
which
I
think
is
pretty
uncontroversial,
is
that
there's
like
a
huge
trust
issue
in
the
hotel,
collector
sick,
like
huge
and
and
what
I
did
say
in
the
github
thing,
which
I
totally
believe
is
somewhat
neutral
party
in
all
this.
B
I
don't
do
anything
on
the
collector
like
when
any
group
of
engineers
are
trying
to
do
things
in
a
low
trust
environment.
It's
just
effing
slow,
like
I'm.
The
one
saying
velocity
is
important
and
I
think
the
trouble
is
that
the
changes
that
are
being
proposed,
which
is
to
add
multi-vendor
approvals
and
every
change
in
the
collector,
will
be
very
slow
in
terms
of
what
that
does
for
the
velocity
and
the
project,
and
I
think
that's
concerning,
I
think
you
might
even
agree
with
me
on
that
podcast.
B
The
the
thing
that
I'm
worried
about
is
that
there's
apparently
you
know
I
mean
anthony,
is
certainly
one
person
who's
mentioned
this,
but
I
will
say
I've
done
some
digging
in
the
past
couple
of
days
privately
and
many
other
people
share
this
concern.
They
have
no
idea
what
the
direction
is
so
like
there
is
an.
B
There
is
also
an
opacity
problem,
and
I
I
my
hypothesis
is
that
if
we
could
get
to
a
place
where
the
project
had
like
an
appropriate
ratio
of
sort
of,
like
you
know,
product
management
and
technical
strategy
to
just
like
raw
engineering,
if
we
could
fix
that
ratio,
a
lot
of
the
problems
that
we're
having
would
be,
you
know
manageable
or
smaller,
or
something
like
that.
So
that's
my
act.
If
you
want
to
get
to
solutions,
I
don't
actually
like
personally,
don't
like.
B
I
would
love
it
if
we
could
find
a
way
to
just
make
the
pro
the
collector
sig
or
the
the
structure
of
the
collector
sig
and
the
processes,
and
so
on
so
forth
such
that
we
would
have
a
more
collaborative
environment,
because
I
think
until
we
get
back
to
that
sort
of
state,
it's
going
to
be
very
slow
going
and
the
collector
is
a
very
important
part
of
the
project
and
I
don't
want
to
make
it
slow
going.
It
feels
like
we're.
B
We
would
be
instituting
the
sort
of
processes
that
are
appropriate
for
a
maintenance
mode
project
yeah
and
it's
not
a
maintenance
mode
project.
So
I
I
find
that
to
be
like
that's
my
that's
my
actual
motivation,
bogdan,
I'm
not
accusing
anyone
of
anything
so
but
I,
but
I
do
want
to
decide
like
okay.
So
what
what
is
like?
What
is
the
right
thing
to
optimize
for
here?
Maybe
we
could
have
that
discussion
and
then
like
how
do
we?
How
do
we
structure
some
next
conversation?
B
That's
probably
a
combination
of
dc
people
involved
in
the
collector
tc.
I
don't
know
a
group
of
people
to
like
talk
about
what
we
want
to
do
about
this,
and
I
agree
with
you
bogdan.
It
wouldn't
be
this
set
of
people,
but
I
thought
maybe
the
gc
meeting
would
be
a
good
place
to
bring
this
up.
The
reason
anthony
is
here
is
because
he
was
invited,
I
think
in
one
of
those
threads.
B
I
think
there
was
a
concern
that
having
this
discussion
that
anthony
basically
brought
up
with
you
here,
bogdan
and
not
anthony,
didn't
make
a
lot
of
sense.
Having
you
not
joined
bogdan
also
didn't
make
a
lot
of
sense,
so
we
thought
we
would
invite
anthony.
So
that's
why
anthony's
here,
but
I
I
think
that
having
a
separate
conversation
makes
sense.
I
just
want
to
figure
out
what
we're
talking
about
in
that
conversation,
rather
than
just
like
you
know,
kind
of
getting
into
the
weeds
of
the
various
proposals
and
stuff.
B
Like
that,
I
don't
know,
that's
my
two
cents,
but
I
I
am
worried,
though,
that
if,
if
the
solution
that
we
go
with
is
just
to
like
add
a
you
have
to
have
two
vendors
to
approve
things,
and
we
make
that
change,
I
don't
think
that's
really
going
to
address
what
seemed
to
be
more
fundamental
issues
around
trust
and
transparency
and
stuff
like
that.
E
Yeah,
I
agree
with
that,
especially
for
small
changes
like
having
having
multi-vendor
approvals
for
small
changes
is,
I
think,
for
the
most
part,
unnecessarily
slowing
things
down,
but
then
you
have
to
like
have
this
line
drawing
exercise
of
what
constitutes
a
small
change
and
nobody
wants
to
do
that
and
there
nobody
will
agree
anyways
on.
E
What's
what's
a
small
change
and
what's
not,
and
is
it
small
in
impact
or
small,
in
scope,
exactly
yeah,
and
then
you
also
have
you
know
back
to
you
back
to
what
I
was
saying
earlier
is:
is
it
small
an
impact
just
to
the
collector
or
is
it
you
know?
Is
it
is
it
a
large
impact
on
the
collector,
in
terms
of
we
have
to
change
a
lot
of
lines
of
code
in
the
collector
for
this,
or
is
it
a
large
impact
on
the
overall
project?
E
I
would
argue
that,
actually,
even
though
the
collector
is
very
complex
and
is
a
very
important
component,
it
is
fairly
separate
as
long
as
the
the
the
protocol
is
implemented
to
specification.
E
The
question
may
be:
should
more
of
the
collector
configuration
be
specified
in
the
specification?
I
don't
know
how
strict
the
collector's
specification
is.
I
know
at
least
the
protocol
is
very
strict,
but
beyond
that
I
don't
think
I've
seen
very
much
in
the
way
of
collector
specification,
so
maybe
configuration
and
things
like
that
should
be
specified.
E
But
beyond
that,
I
I
think
the
collectors
should
be
free
to
make
refact
internal
refactors
without
having
to
have
specifications
and
stuff
like
that
and
multi-vendor
approvals,
and
I
just
I
agree
with
ben.
I
see
that
as
slowing
it
down
and
as
a
a
a
symptom
of
distrust,
rather
than
a
fix.
A
A
That's
always
been
the
case
that,
where
internal
changes
have
been,
you
know
continuously
made
and
there's
never
been
any
any
issue.
It's
just
that
you
know
when
there
are
public
interfaces
or
there
are
discussions
again.
It's
a
lack
of
lack
of
being
in
sync
right
on
on.
You
know,
core
components
that
are
changing
or
and
and
as
you
know,
you
know,
the
collector
is
also
still
in
development.
It's
also
being
optimized,
for
you
know,
from
the
pre
or
from
the
open
census
era
to
the
post,
open
census
era.
So
there's
a
lot
of
work.
A
That's
ongoing
at
different
layers
and
bogdan's
been
very
instrumental
in
making
many
of
those
changes,
but
so
we
I
mean,
and
many
other
maintainers
have
contributed
and
contributors
have
contributed
too.
So
we
do
care
about
the
design
and
architecture
of
the
collector
and
we
do
care
about.
You
know
as
as
as
equal
participants.
E
D
I
I
would
propose
that
gc
focuses
on.
There
is
a
issue
in
the
community
which
is
very
related
to
this,
and
maybe
maybe
gc
should
come
up
with
the
rules
about,
for
example,
there
is
the
problem
with
the
with
trust.
There
is
a
problem
with
becoming
maintainer,
because
a
lot
of
people
are
asking
me:
why
do
we
not
have
more
maintainers
in
in
collector?
D
We
do
have
more
in
country,
but
we
don't
have
mooring
collector.
I
think
that's
one
thing
that
gc
can
solve.
The
other
thing
is
gc
may
come
up
with
a
generic
rule
across
all
the
orgs
about
how
to
merge
vrs
if
they
want-
and
I
think
this
will
be
reasonable
for
for
the
collector
to
adopt.
If
there
is
a
rule.
D
B
B
B
I
don't
think
this
would
be
an
easy
thing
to
measure,
but
if
it
was
possible
to
measure
the
the
I
don't
know
for
folks
that
are
contributing
regularly
to
the
collector
like
do
they
understand
like
the
technical
direction
of
the
collector,
and
you
know,
is
there
some
reasonable
process
to
like
debate?
I'm
not
suggesting
it's
consensus,
necessarily
if
there
are
50
people
involved
but
like,
but
is
there
a
reasonable
process
for
deciding
on
the
technical
direction
like
that
sort
of
stuff?
B
I
think,
is
sort
of
a
governance
issue
at
some
level,
even
though
it
gets
not
that
gc
should
decide
what
the
technical
direction
is,
but
that
there
should
be
some
checking
to
balance
that
that's
something
that
can
be
can
be
discussed
like
in
an
open
forum
and
decided
upon
and
committed
to
in,
like
a
reasonable
way
like.
B
That
seems
like
something
that
gc
could
be
involved
in
just
sort
of
like
as
a
yeah
as
a
check
and
a
balance
that
it's
acceptable
and
then
I
think
the
gc
is
responsible,
just
full
stop
for
the
overall
health
of
the
project,
and
I
think
we
can
all
agree
that
collector
is
a
very
important
piece
of
open
telemetry
and
the
collector
becomes
sort
of
dysfunctional
and
there
are
all
sorts
of
things
that
can
go
wrong
for
open
telemetry
in
the
span
of
years,
and
I
think
we're
actually
not
quite
there
yet,
but
we're
getting
there
fairly
quickly
to
a
dysfunctional
state
where
I
think
you're
going
to
find,
like
you
know,
committers
sort
of
pulling
out
of
the
project
and
just
like
yeah,
like
loss
of
trust,
etc,
etc.
B
So
I
think
it's
the
gc's
responsibility
to
try
and,
like
I
don't
know,
arbitrate
in
that
in
some
way
like
I
I'm
not
suggesting
that
we
would
necessarily
make
a
rule,
but
it's
more
like
just
like
try
to
help
mediate.
I
think
it's
a
better
word
like
what
what
are
we
like?
What
are
the
actual
problems
we're
trying
to
solve?
I
don't
know
you
and
I
have
known
each
other
for
probably
ten
plus
years.
B
I
I
have
no
question
about
your
technical
integrity
or
intentions
or
anything
like
that
to
be
clear,
but
there
is
like
a
problem
here
for
sure
around
just
like
the
the
contributor
experience
with
the
collector
and
anthony
brought
it
up
publicly,
but
other
people
have
brought
it
up
privately.
So
there
is
a
problem
that
we
have
to
address
and
I
don't
think
it's
going
to
be
some
sort
of
like.
I
hope
it's
not
some
super
dramatic
thing.
B
I
think
we
just
need
to
like
make
an
adjustment
to
the
way
the
project
is
operating
in
some
capacity,
and
I
think
the
gc
could
be
helpful
in
mediating
that,
but
it's
not
some
it's
more
of
a
mediation
thing
than
like
a
dictatorial
thing.
If
that
makes
sense,
so
I
think
that
might
be
an
appropriate
thing
to
do,
because
it
is
important
to
the
project
that
the
collector
gets
back
to
like
a
high
trust
state,
which
I
think
is
where
it
was
you
know
a
year
ago
or
something
like
that.
B
I
don't
know
whatever
and
then
it's
just
gotten,
I
think,
with
the
number
of
participants
and
the
amount
of
activity
and
production
of
the
collector.
It's
gotten
higher
stakes
to
make
changes
and
I
think
that's
causing
a
lot
of
friction.
So
that's
my
two
cents
does
that
make
sense.
I
mean
bogdan
I'm
kind
of
talking
to
you
here,
but
but
also
to
like
for
me
for
me.
D
I
can
tell
personally
I
I
don't
know
if
any
project
any
any
when,
when
a
project
grows
without
having
strict
rules
about
what
gets
in
what
gets
out
or
stuff
like
that,
I
don't
think
you
can
scale.
I
mean
you
can
scale,
but
you
will
never
be
able
to
to
run
it
for
a
long
time
like
look
at
kubernetes.
Do
you
think
in
kubernetes
it's
easy
to
to
push
a
change
or
is
easy
to
collaborate
with
them?
They
have
super
strict
rules.
C
My
my
concern
is
not
necessarily
that
it's
harder
to
get
changes.
There
is
a
structural
imbalance.
The
thing
that
prompted
this
discussion
in
particular
is
the
changes
that
you
made
to
the
configuration
subsystem
and
that
relates
to
discussions
that
have
gone
back
for
several
months.
Proposals
have
been
made,
we've
had
conversations
about
this
between
you
and
me,
and
tigran
tigran
had
a
proposal.
He
had
a
pr
that
was
up
for
review.
You
said
that
was
too
complicated
and
you
were
going
to
make
a
counter
proposal.
C
C
D
C
D
Maybe
but,
but
to
be
honest,
you
could
have
come
simply
and
say,
because
we
have
only
like
three
or
four
these
kind
of
users
or
five.
We
have
way
more,
the
ones
that
are
operating
and
deploying
which
were
definitely
not
affected
correct,
so
they
were
affected
and
even
splunk
was
affected
by
this,
which
is
building
their
own
sting
and
they
came
nicely
and
say:
hey.
This
kind
of
things
will
break
me
and
they
show
me
how,
but
you
you
came
very
aggressively
and
telling
me
that
no,
you
don't
know
what
to
do.
D
B
Can
I
interrupt
for
a
second
daniel's
correct
that
we're
going
to
run
out
of
time?
I
am
concerned
that
we
don't
have
a
follow-up
scheduled
or
at
least
sort
of
like
scoped
out
I
would
suggest,
but
I'm
open
to
I
mean
I
know
everyone
wants
to
finish
this
discussion,
but
I
promise
we
won't
in
the
next
three
minutes.
B
Is
it
possible
to
say,
like
we're
going
to
have
a
meeting,
for
you
know
we're
going
to
explicitly
invite
people
from
the
collector
community
that
are,
you
know
approvers
and
maintainers,
and
then
say
others
in
the
collector
community
are
welcome
to
join.
B
I
don't
know.
Hopefully
the
gc
will
be
there
and
we'll
try
and
talk
about
some
of
the
issues
here
and
figure
out.
You
know
something
to
do
about
it.
An
alternative
would
be
to
have
a
much
smaller
meeting
like
like
you
know.
I
don't
know,
would
be
somewhat
like
this
one,
but
I
don't
know
if
that's
going
to
accomplish
that
much
with
the
the
goal
being
to
kind
of
like
you
know
at
least
just
document,
the
issues
that
are
had
or
that
are
on
the
table
brainstorm
some
possible
things.
B
We
could
change
about
the
structure
of
the
project,
that
sort
of
stuff,
but
not
make
an
actual
decision
and
then
and
then
the
decision
could
be
something
that
would
be
done
async
does
that
seem
like
a
reasonable
thing
to
do.
I'm
just
trying
to
come
up
with
like
I.
I
do
think
that
there
are
like
actual
concerns
here
I
mean
the
anthony's
are
some,
but
there
may
be
others,
and
I'm
just
I'd
like
to
have
a
separate
conversation.
As
you
said
bogdan
with
more
folks
in
the
collector
involved,
and
then
we
can
again.
B
I
think
the
gc's
role
would
be
more
to
mediate
things
than
to
dictate
things,
but
we
could
hopefully
like
help
with
that
process,
and
the
ideal
outcome
would
be
some
structural
changes
to
the
collector
sig
and
the
way
things
are
done
to
help
address
these
issues.
Does
that
seem
like
a
possible
thing.
A
A
What
were
the
assumptions
at
the
beginning
of
the
project
when
you
know
the
collector
was
formally
instantiated
are
very
different
from
what
is
going
to
be
in
this
next
coming
phase
as
we
go,
take
metrics
ga
and
as
we
take
logs
logging,
ga
right
so
again,
this
is
something
we
will
need
to
address
and
having
a
collection
of
you
know
what
are
some
of
the
general
issues
right
now
is
a
good
thing
to
do
absolutely.
This
is
by
no
means,
you
know
something
that
just
we
are
just
asking
for
or
anything
of
that
sort.
A
It's
more
trying
to
figure
out.
You
know
how
can
we
make
sure
that
the
collector
stays
the
star?
You
know
one
of
the
stars
of
the
project,
so
ben
I
mean
I
would
definitely
say
that
having
a
larger
discussion
absolutely
is
useful.
Also,
you
know
perhaps
lining
you
know
outlining
then
working
with
the
tc
and
the
maintainers
to
identify
what
works
and
then
continuously.
You
know
kind
of
have
a
review
of
it
over
time.
Over
you
know,
a
regular
time
period
would
be
useful
this
year.
B
Yeah
all
right,
well,
I
don't
know,
does
anyone
else
have
a
different
suggestion
for
something
to
do
next
about
this?
I
don't
think
we
should
just
move
back
to
github.
I
think
we
need
to
continue
talking
about
it.
E
Yeah,
I
think
we
we
don't
necessarily
need
to
schedule
it
right
now,
but
we
at
least
need
to
decide
who
we're
going
to
invite.
So
I
guess
the
question
is:
is
this
a
gctc
issue
or
is
it
a
collector
issue?
In
my
opinion,
should
be
collector
issue
and
if
that's
the
case
who
joins
to
mediate,
I
think
the
gc
makes
sense
for
that,
and
possibly
at
least
one
tc
representative,
or
at
least
one
person
who
is
a
member
of
both.
I
think
we
still
have
some
yeah
and
should
we
invite
additional.
E
Collector
distribution
developers,
I
know
aws,
is
you
know,
has
a
collector
distribution,
but
are
there
others
and
should
we
invite
the
developers
of
those.
F
I
mean
I
mean
we
we're
tigran
for
splunk
could
be
good,
no
he's
a
maintainer,
no.
F
You
cannot
invite
splunk,
that's
what
I'm
saying
there
are
probably
others
as
well.
Who
should
come
here,
anthony
you're
shaking?
How
do
you
have
some
in
mind.
G
B
E
B
G
Yeah,
I
don't
know:
okay
all
right,
see
everyone.