►
From YouTube: 2022-09-07 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
B
C
B
D
Go
ahead
so
on
this
issue,
we
were
just
making
a
change
to
try
and
fix
some
units
on
the
elasticsearch
receiver,
and
it
came
up
that
we
are
in
the
collector.
It
seems
like
we're
using
kby
to
denote
1024
bytes,
and
this
is
not
how
it
is
in
ucum,
which
is
from
my
understanding,
what
we're
using
to
base
our
units
on.
D
So
the
question
is:
is
that
what
we
want
to
be
doing,
or
do
we
want
to
be
using
the
ucum
as
our
standard
for
kilobytes
versus
kibabytes.
D
And
yeah
my
opinion
is
that
we
should
probably
follow
the
uc
since
that's
what
the
spec
says
we
should
be
using,
but
yeah
I'd
just
like
to
get
thoughts
of
of
the
maintainers.
A
D
Yeah
bogdan,
I
know
you
were
on
the
other
side
of
this
conversation,
so
maybe
you
know
more
about
why
it
is
the
way
it
is.
E
And
I'm
not
saying
that
is
good
or
bad.
I'm
just
saying
that
is
an
inconsistency
and
you
come
up
with
something
new
which
maybe
is
correct.
If
it's
the
way
how
you
see
us
defines
it
but
yeah.
D
Okay,
so
maybe
what
we
need
is
an
issue
to
go
through
and
audit
all
the
units
that
are
using
k
by
and
make
sure
they're
you
know
they
conform
to
uc.
Does
that
make
sense.
E
D
It
okay
and
for
this
current
elasticsearch
receiver,
one
dude
can
we
like
do
you
think
that's
good
to
go.
E
E
No,
no,
it
doesn't
need
more
discussion,
it
just
needs
just
for
my
ocd.
Can
you
can
you
just
create
a
issue
before
I
merge
so
then
I
can
make
sure
that
we
don't
forget
about
checking
all
the
other
places.
D
A
A
E
A
E
B
F
Yeah
so
boxing-
and
I
have
a
brief,
open
discussion
about
the
name
of
an
interface
this.
This
interface
is
being
proposed
to
be
moved
to
a
different
package
and
we're
taking
the
opportunity
to
reconsider
the
name
as
well.
F
B
C
C
C
E
Yeah,
but
we
can
handle
that
we
can
still
respect
our
interface
with
the
goal,
it's
very
easy
to
have
anonymous
and
with
the
dark
typing
interface.
It's
super
easy
to
support
this.
E
B
A
Cool,
let's
move
to
the
next
looking
for
input
on
potential.
Am
I
reading
the
right?
Yes,
potential
improvements,
the
contribution
backlog.
B
H
So
yeah
the
trip
backlog's
got
like
750
plus
issues.
You
know
quite
a
few
come
in
all
the
time
it's
pretty
active,
so
I'm
looking
at
I'm
trying
to
triage
new
issues
right
now.
I'm
also
trying
to
take
a
look
at
old
ones
see
if
any
can
be
closed.
H
But
in
addition
to
that,
I
was
looking
for
input
from
anyone,
contributors
code
owners,
approvers
maintainers
about
any
pain
points
or
any
kind
of
improvements,
the
triaging
process
or
improvements
to
kind
of
looking
at
the
open
issues
for
a
given
component,
just
any
kind
of
input
that
anyone
might
have.
H
And
if
there's
nothing
at
this
time,
then
I
can
just
kind
of
keep
at
it
and
ask
again
later.
B
One
thing
that
I
think
could
be
interesting:
I
don't
know
if
it's
exactly
triaging
but
github
has
these
issue
templates
on
it
may
be
useful.
Sometimes
people
don't
know
how
to
use
markdown
and
just
paste
the
logs
or
stack
trace
and
it
gets
tumbled
up.
So
if
we
can
help
people
with
that,
that
could
be
an
improvement.
A
Yeah,
that's
a
good
point.
I
think
we're
we're
doing
that
in
some
other
repositories,
and
I
I
did
notice
some
people
actually
keep
all
that
noise
there
in
the
issue
right.
They
forget
to
delete
irrelevant
bits
from
there,
so
maybe
that
could
help
with
having
cleaner,
easier
to
read
issues.
That's
a
good
point.
Pablo.
G
Hi
everybody,
so
this
is
chatty
from
logic
monitor.
We
are
planning
to
contribute
new
vendor
specific
component
logic.
Monitor
exploding,
as
a
representative
of
logic,
auditor
and
I've
also
raised
an
issue
for
the
same
in
the
contract.
Currently
we
do
not
have
any
sponsor,
so
I
would
like
to
request
if
any
one
of
you
can
volunteer
responsive
for
this
component.
G
So,
and
I
also
wanted
to
know
the
procedure
after
assignment
of
the
sponsor.
E
So
for
the
for
the
vendor-specific
things
we
we
have
a
rotation
mechanism,
you
can
read
the
link
that
even
pointed
so.
Whoever
is
in
top,
I
think,
but
I
think
jurassic
picked
the
last
one,
so
it
may
be
dimitri.
Who
is
next
yeah?
We
need
to
figure
it
out.
I
E
Yeah
as
a
nice
thing
to
to
gp,
let's
do
that.
I
K
Yeah,
I
mean
hey
anthony,
hope,
you're
doing
well
and
evan
and
everybody
yeah.
I
mean
I
I
thought
about
it
for
all
the
30
seconds
since
evan
asked
the
question,
so
my
thoughts
are,
you
know
they'd
like
the
definition
of
half-baked,
but
that
was
just
a
common
pinpoint.
K
I
seen
anecdotally
is
yeah
random
questions
that
are
like
really
specific
to
like
some
vendor
api
endpoint,
or
maybe
some
implementation
detail
of
their
exporter
or
whatever
sort
of
like
exist
forever
as
an
open
issue
and
there's
you
know
some
follow-up
that
happens
at
some
interval.
That's
not
clear
and
like
really,
if
you
were
you
know
like
if
you
had
reached
out
at
the
equivalent
repo
of
say,
like
some
vendor
component,
that
they
owned,
they
would
just
direct
you
to
a
support,
work,
workflow
and
you'd
get
like
faster
follow-up.
So
I
think
that's.
K
Maybe
one
reason
why
there's
750
open
issues
like
not
all
750,
but
a
chunk
are
sort
of
like
stuck
in
that
purgatory,
so
yeah
any
solutions.
People
have
for
resolve
it
for
improving
that
space,
which
I
don't
have
good
solutions
for.
I'm
just
kind
of
thinking
out
loud.
I
think
we
go
a
long
way
and
you
know
help
separate
some
of
the
noise
out.
E
Should
we
require
every
vendor
to
have
a
github
team
or
a
github,
something
that
we
we
can
use
to
to
kind
of
associate
all
the
the
issues
and
stuff
and.
C
C
J
I
think
at
that
point
we
would
redirect
the
user
to
the
vendor
support,
rather
than
doing
it
ourselves,
but
yeah,
whether
it's
a
github
team
or
some
other
mechanism
for
contacting
the
currently
responsible
parties.
I
think
another
issue
that
we've
we've
seen
with
vendor
components.
Is
people
come
and
go
and
if
you
have
an
individual
listed
as
a
code
owner
or
it's
a
responsible
party
for
a
component
and
they
leave
that
vendor.
We
may
not
know
for
some
time,
but
it
may
be
challenging
to
then
find
the
right
party
afterwards.
J
Yeah,
whether
it's
a
team
or
an
email,
alias
that
can
be
used,
you
know
some
vendors
may
not
be
able
to
make
public
teams.
But
as
long
as
we've
got
an
identifier,
we
can
say
we're
gonna
fire
something
out
to
this
location
and
expect
that
there
will
be
a
response
coming
back.
A
Eric
maybe
can
you
maybe
open
an
issue
there
in
the
country
repository
and
mention
the
the
the
current
maintainers
approvers
and
we'll
take
it
from
there.