►
From YouTube: 2021-01-05 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).
A
A
C
D
E
C
Arrived
at
five
minutes
past
the
hour,
should
I
start
with
the
first
agenda
item:
yeah
all
right
I'll,
give
the
status
update
of
the
ga
spec
burndown
tracking
project
standing
agenda
item
in
order
to
see
how
we're
progressing
across
the
items
that
we
would
like
to
track
on
the
specification
repo,
the
ones
are
the
must-haves
for
ga
release.
So
I'm
filtering
by
that
just
to
give
summary
that
we
have
22
in
the
to
do
column
three
in
the
linked
pr
column
and
we've
resolved
55
of
them.
F
F
I
don't
remember
which
issued
number
that
is,
but
we
this
is
something
we
absolutely
have
to
get
nailed
down
before
we
can
do
1.0
and
I
don't
think,
we've
gotten
a
good.
We
haven't
gotten
much
feedback
on
the
issue
and
it
would
be
good
to
sort
it
out
should
look.
I
would
search
for
it's.
The
service
name
should
be
it's
though
it's
the
one
that's
allegedly
resolved,
so
the
same
should
be
mandatory
all
configured
resources,
but
there
was
a
follow-up
to
it.
C
Okay,
yeah
yeah
added
to
the
list
of
items
to
talk
about
and
I'll
start
with
the
triaging
first
we'll
get
through
this
quick
and
then
we'll
jump
back
into
that
john.
C
C
C
Release:
okay,
and
if
it's
a
p1,
it
requires
an
assignee.
G
C
H
J
G
G
E
You
know
because
I
think,
there's
other
environment
variables
already
that
have
timeouts
and
they
use
a
duration
like
10
s
or
10
seconds
and,
as
you
know,
a
consumer,
it
makes
this
a
lot
easier.
You
know
I
mean
I'm
mainly
dealing
with
go,
so
we
just
can
parse
these
as
durations
automatically,
but
singing
billy's
means
that
now
you're
you're
stuck
with
well
do
I
need
to
put
60
000
in
here
or
you
know,
30
000
versus
I
don't
know.
I
I
find
the
duration
more
easier
to
use.
I.
L
K
Yeah
and
you
can
even
limit
it
to
make
it
like-
we
only
allow
lowercase
s,
for
example,
and
lowercase.
Ms,
you
know
what
I
mean
like
you:
can
you
can
do
things
in
the
spec
where
go
might
be
more
flexible
than
spec
that
make
it
easier
for
languages
that
don't
have
this
out
of
the
box?
So
that
would
be
my
recommendation
because
it's
way
nicer
for
the
user.
M
We
just
need
to
make
sure
that
the
that
it's
locked
down
to
the
subset
so
that
people
don't
get
people
don't
get
used
to
using
like
goes
extended,
syntax
and
then
it's
it
sort
of
silently
works,
but
then
fails
in
other
languages.
Right.
F
I
think
trying
to
get
to
one
point
as
quickly
as
possible
and
any
additional
implementation
that
maintainers
are
going
to
have
to
write
to
make
this
work
is
going
to
make
it
take
that
much
longer,
even
if
it's
just
a
day
or
two
a
day
or
two
a
day
or
two
a
day
or
two.
It
adds
up
to
a
lot
of
days
and
we
really
want
to
get
to
1.0.
M
F
John,
for
you,
all
we're
doing
is
changing
the
name
of
an
environment
variable
that's
very
simple,
having
to
write
a
parser
and
test
it.
I
mean
it's,
maybe
not
difficult,
but
it
takes
time
and
it
takes
time
away
from
maintainers
who
are
trying
to
desperately
get
ready
to
do
a
1.0
release.
Yep.
That's
a
very
call.
K
G
Sorry,
I
think
we
can
start
as
someone
dimension
in
languages
where
this
parsing
is
not
available.
We
just
ask
people
we
support
only
the
suffix,
ms
or
s
or
whatever
we
picked
one
of
them
and
say
this
is
currently
supported
only
and
then
in
two
months
or
whatever.
When
we
have
time,
we
add
support
for
the
the
other
thing,
because
that's
backwards
compatible,
we
we
just
add
more
support.
G
If
we
change
the
environment
variable
name,
though,
to
include
millies,
then
we
preclude
that
option
correct.
But
my
my
suggestion
is
to
not
include
millis
in
the
variable
name,
but
just
say
that
in
java
we
support
only
the
suffix
ms
for
the
moment
and
not
we
don't
know
to
parse.
Let's
say
us
for
micros
or
something
like
that.
Yet.
P
A
C
In
the
interest
of
keeping
to
the
time
box,
I
suggest
we
perhaps
find
a
signee,
and
then
this
discussion
can
continue
on
the
on
the
issue
itself.
C
H
C
G
It's
interesting:
if
you
have
two
services,
one
in
go
one
in
java
and
you're
using
environment
variables
to
configure
both
of
them
and
in
one
of
them
let's
say
you
have
a
value
that
is
larger
than
integer,
and
one
of
them
will
work.
The
other
one
will
not
work.
Is
that
something
you
expect
or
you
want
both
to
work.
G
M
It's
not
a
it's,
not
a
limit.
It's
saying
every
anyone,
it's
always
safe
to
use
a
number
up
to
x.
Any
numbers
above
that
are
implementation.
You
know,
support
for
them
is
implementation,
specific,
that's
a
reasonable
solution
right
then,
then,
there's
no
implementation,
change
required.
You're,
just
saying
we
all
agree
up
to
and
max
or
whatever
up
to
this
specific
2
to
the
32.
Minus
1
is.
O
H
That
makes
it
that
makes
sense
to
me.
Whoever
is
gets
assigned
to.
These
will
have
to
verify
that
there's
no
exotic
environment
variable
that
needs
some
huge
value.
Otherwise
it
sounds
fine.
M
I
don't
think
I'm
a
member,
but
I
don't
know
who
can
be
assigned
these
issues,
but
if,
if
I
can,
if
it
can
be
assigned
to
me,
I'd
be
happy
to
take
it.
I
don't
know
how
it.
Q
L
H
And
by
the
way,
by
being
assigned,
you
don't
have
necessarily
to
solve
it
just
to
help.
G
H
H
H
C
Doesn't
sound
like
a
bad
idea,
so
I'm
leaving
it
like
that
you
can
change
it
later
if
it's
more
suitable
to
change
it
later.
Okay,
thank
you.
There
is
one
last
issue
in
otep,
which
I
added
actually
to
another
agenda
item
at
the
bottom.
We
can
discuss
later
alolita's
on
the
call,
but
I
saw
this
one
propped
up
and
it
crosses
across
all
the
six.
R
Yeah
and
we've
been,
we've
been
working
on
these
and
adding
them
to
the
to
the
different
peer
reapers
and
and
the
collector
the
associated
contrib
java
javascript
go.net
python.
We
have
added-
and
you
know,
submitted
prs
for
those,
so
thanks
to
the
maintainers
for
reviewing
them
and
enabling
them.
R
G
R
G
R
I
mean
so
bogdan,
that's
a
good
point
right,
because
the
first
step
is,
of
course,
to
you,
know
kind
of
identify
from
the
scans
what
issues
exist
and
then
there
are
two
ways
of
handling
this
one
that
we
enable
the
you
know
these
to
be
converted
into
prs
or
I'm
sorry
into
issues
that
are
then
addressed
for
specifically
for
p
zeros
that
are
reported
which
are
then
you
know,
tagged
to
be
blockers
for
release
right
or
that
they're
informational,
which
is
the
way
they
are
set
up
right
now,
and
they
are
reviewed
by
the
maintainers
and
then
identified
as
to
what
needs
to
be
fixed.
R
So
again,
it's
it's
on
an
it's
not
on
an
aggressive
mode
right
now,
it's
more
informational
in
terms
of
the
notification,
but
we
could
change
it.
Otherwise,.
G
R
Sure
I
mean
I
think
bogdan
we'll
have
to
figure
that
out
that
what
makes
sense
for
and
what
prioritization
we
do.
So,
let's
kind
of
discuss
that
on
on
the
issue
itself
and
figure
it
out.
N
R
C
R
It's
allowed
would
be
good
because
you
know
one
of
the
things
that
we
are
hearing
a
lot
from
our
customers,
it
it
it
does
give
customer
trust
and
also
our
security
reviews
that
we
do
for
the
hotel
components
as
we
release.
Aws
distro
is
also
something
where
we
are.
You
know
getting
asked
to
enable
these,
because
it
really,
you
know,
conveys
the
security
scan
information
and
the
reliability
of
the
code
back
to
what
we
are.
C
Releasing
all
right
thanks
for
that.
I
I
think
I've
concluded
the
my
agenda
item.
We
move
on
to
the
next
one
I
see
alex,
has
put
one
in
I'm
happy
to
keep
sharing
if
that's
helpful
or
I
can
relinquish
control.
If
this
is
something
that
alex
you
want
to
be
able
to
present.
D
No,
no,
no!
That's
that's
fine!
I
haven't
written
anything
up,
so
I
didn't
know
that
if
this
sig
meeting
was
appropriate
for
this,
this
topic
before
writing
and
a
proposal
itself.
D
But
in
generally
it's
it's
about
having
open,
telemetry
data
over
like
the
zinc
system
like
pops
up
I've
written
a
pr
for
this,
it's
open.
It
can
be
there
for
a
while
we're
using
it
currently.
But
then
the
issue
came
up.
Maybe
we
should
add
it
to
the
spec
of
how
to
do
it.
D
It's
a
harder
implementation
and
if
your
batch,
if
something
goes
wrong
along
the
way,
there's
like
a
lot
more,
it's
possible
to
duplicate
messages
on
the
messaging
bus
so
before
starting
under
the
implementation
would
wanted
to
know
what
kind
of
your
thoughts
are
there
or
should
I
just
start
to
write
a
proposal
with
the
two
two
proposals
in
there
and
discuss
it
on
the
pr
so.
G
First
of
all,
I
don't
think
this
is
a
spec
problem.
It's
a
collector
problem
and
if
you
have
a
proposal,
you
will
be
good
to
to
have
it
under
the
collector
documents
as
okay,
how
the
collector
will
interact
with
messaging
systems
like
pubsub
kinesis
kafka,
whatever
you
name
it.
So
if
you
want
to
have
a
proposal
that
that
generalize
across
across
messaging
systems,
I
think
it's.
The
collector
itself
is
the
place
to
to
have
this
in
their
in
the
documentations
there
and
go
ahead.
G
Collector
is
not
necessarily
an
implementation
of
the
spec.
The
spec
is
right
now
the
specification
is
mostly
focused
on
the
language
libraries,
not
the,
not
necessarily
the
collector
itself.
I
mean
there
are
a
couple
of
parts
of
in
the
specification
that
are
documented
about
the
collector,
but
not
a
lot
of
the
decisions
are
itself
because
it's
it's
a
separate
component
compared
with
the
rest
of
the
libraries
that
we
have
it's
completely
different
than
the
the
other
libraries.
G
That
being
said,
we
can
have
it
in
the
spec
if
we
expect,
for
example,
a
language
like
java
to
have
an
exporter
directly
to
kafka,
because
if
that's
the
case,
then
they
should
follow
the
same
behavior
as
the
collector
will
follow,
because
from
from
consumer
producer
perspective,
the
producer
doesn't
matter
if
it's
collector
or
any
other
any
other
source.
So
if
that's
your
goal
and
that's
what
you
are
aiming
for,
then
the
spec
is
a
better
place
to
for
this.
Does
it
make
sense
where
I'm
coming
here.
D
Yes,
yes,
yeah
all
right
yeah!
I
I
think
both
things
if
you're
saying
that-
and
actually
it
still
makes
sense,
because
if
you
do
it
like
you
have
that
proposal,
then
in
the
collector
and
then
somebody
decides
so
then
don't
have
to
look
at
at
the
collector.
Well,
what
I
will
do
I'll
I'll
make
a
proposal
and
we
can
still
move
from
that
on
and
say:
okay,
this
just
makes
sense,
let's
move
it
to
the
collector.
The
other
thing,
the
other
thing,
if
you.
G
G
You
you
you
put
it
there.
We
comment
it's
a
larger
document
explaining
explaining
motivations
goals
and
so
on
so
far
and
then
and
then
once
we
we
agree
on
the
things
we
can
say.
Okay,
these
parts
goes
to
the
specs.
This
part
goes
to
the
collector
and
so
on.
So
right,
that's
another
way
to
to
start
the
initiatives
and
then
have
multiple
people
seeing
these
and
comment
where
exactly
this
should
be,
and
I
would
like
to
understand
also
this
request,
problem
and
stuff
so.
D
I
There
was
a
related
request
at
some
point
to
to
talk
about
item
potency
keys
and
to
make
otlp
correctness
for
delta,
encoded
metrics
and
I'd
like
to
just
flag
that
as
something
we
still
sort
of
want.
So,
if
you're
routing
messages
over
a
message
bus,
the
idea
is
that
you
can
then
get
correctness
here.
Let's
make
sure
that
we
can
do
that.
D
C
This
I
see
there's
a
more
items
added
to
the
genesis.
I'll
just
keep
this
one
short.
I
brought
this
up
to
the
maintenance
meeting
and
it
has
to
do.
It
was
decided
that
maybe
you're
good
to
bring
it
up
here
as
well:
open,
telemetry,
ga,
high
level
items.
So
this
is
another
project.
That's
used
to
track
high
level
items,
not
just
in
the
specification
repo,
but
across
all
the
language
repos
of
big
ticket
items.
We
want
to
make
sure
we're
hidden
palm
for
ga.
C
I
copied
this
over
from
a
google
spreadsheet
that
was
put
up
months
ago
and
I've
been
focusing
on
spec
repo
stuff,
but
I
need
help
in
updating
the
status
of
these
and
also
owners
whether
all
these
owners
are
appropriate
for
these
items.
So
I
took
the
initiative
to
update
like
stuff
that's
in
progress.
I
saw
this
in
progress,
but
I
see
that
some
might
some
things
that
might
need
some
linked
issues
or
prs
or
or
updates
inside
of
each
one
of
these
issues.
C
C
D
C
Okay
thanks
the
action
I'm
specifically
requesting
is
that
we
have
a
standing
agenda
to
track
this
project
as
well.
The
high
level
items
on
a
weekly
basis
at
the
spec
meeting,
maintainers
meeting
spec
meeting
one
or
the
other,
and
that
by
next
week
each
one
of
the
owners
in
these
items
there's
only
11
items
each
one
of
the
owners
look
into
it
and
then
either
update
their
ownerships
like
yeah.
I
shouldn't
be
an
owner
or
negotiate
with
whoever
else
would
be
the
appropriate
owner
and
then
update
the
description
and
appropriate
linked
issues.
C
So
that
way
we
can
see
the
ones
that
are
tracking
specifically
for
required
for
ga
of
which
there
are
do
math,
quick
11.
I
think
yep
or
nine
nine,
eight
nine
right
yeah,
because
there's
two
that's
allowed
for
gaa,
but
not
required
for
ga
that
we
will
then
have
a
clear,
clear
understanding
of
where
we're
sitting
on
that.
So
that's
the
specific
action
on
them.
If
that's
okay,.
C
D
R
Yep,
I
will
do.
F
F
It's
currently
written
that
way,
and
this
particular
pr
was
put
in
to
clarify
what
that
meant
and
how
that
would
work,
and
it
has
gone
through
several
revisions
and
is
now
in
a
place
where
it
basically
makes
it
not
required
anymore,
to
have
a
service
name
in
the
resource
and
which
defeated
the
purpose
of
actually
having
that
requirement
in
the
first
place.
So
if
you
want,
if
you
scroll
up
just
a
tiny
bit
andrew
right
there,
on
that
my
comment
there,
we
have
three
options.
F
I
think
at
the
moment
about
what
we
do
about
this.
It
would
be
really
good
to
have
spec
people
look
at
this
and
think
about
it
and
maintainers
also
because
there's
some
fairly
significant
implications
to
what
it
means
to
have
a
resource
attribute
actually
be
required
by
an
sdk.
H
F
That's
the
problem
is
that
the
there's
been
options
have
changed
throughout
the
life
of
this
pr,
and
so
I
actually
pulled
my
approval
back
because
it
ended
up
not
being
what
was
originally
written.
This
make
sure
you
actually
are
approving
what
is
currently
written
because
it
has
changed.
G
C
Is
this
issue
associated
with
one
of
the
p1
issues
that
we
went
over
earlier,
or
should
there
be
an
issue
created
for
this.
F
C
Would
you
mind
finding
that
issue
and
reopening
it
if
it's
the
most
appropriate
thing
to
do
or
creating
another
one,
and
then
I
can
help
track
with
if
this
is
like
super
high
priority
one?
I
will
reopen
edition
all
thanks.
F
Was
a
related
one
that
spawned
off
another
issue,
it's
probably
linked
to
in
here
as
well
somewhere.
This
was
the
original
issue
that
I
logged,
because
it
wasn't
clear
what
to
do
and
then
you
already
suggested
making
it
required,
which
people
generally
agreed
to
and
then
you
know
we
are
where
we
are
I'll
find
the
original.
The
original
issue,
though
so.
G
John,
what
what's
your
goal?
Now
you
are
trying
to
just
make
people
look
at
this
issue
or
you
have
a
proposed
solution
that
you
are
trying
to
to
propose.
No.
F
I
honestly
don't
care
very
much.
I
just
want
to
make
sure
that
it's
clear
so
we
can
implement
all
the
solutions
are
totally
okay,
but
right
now
like,
for
example,
the
core
issue
is
that
our
jaeger
exporter
is
not
like
there's
no
there's
no
specification
for
it
at
all,
and
so
it's
basically
because
jaeger
requires
a
service
name,
we're
left
in
a
place
where
we
don't
have
a
way
to
actually
know
how
to
implement
that
exporter.
F
G
Maybe
maybe
that's
that's
a
good
start
and
maybe.
R
G
All
right
thanks
should
we
move
on
to
the
next
issue.
I
would
just
want
everyone
to
think
about
this
and
prioritize
this,
because
it's
probably
one
of
the
last
blocking
really
blocking
issue
for
for
regime.
S
I
F
Easy
we've
got
hard
problems
to
solve,
it's
not
a
hard
problem
to
solve,
but
we
actually
have
to
make
a
decision
and
someone
has
to
write
it
and
what
we
have
right
now
with
this
particular
pr
that
that
christian
ended
up.
Writing
is
undoing
the
solution,
basically
making
it.
So
we
don't
have
a
solution
anymore.
G
Yeah,
I
revoked
all
the
approvals.
I
asked
everyone
to
reapprove
because
it
had
they
happened
during
the
different
lifetime
of
the
pr
not
to
annoy
anyone,
but
to
make
sure
that
we
are
proving
what
will
be
merged,
not
a
previous
version
and
sorry
everyone.
If
I
bother
you
because
of
this,
but.
C
Okay,
I
think
these
two
agenda
items
are
fyi
agenda
items
that
were
brought
up
from
the
maintainers
meeting
to
bring
attention
towards
the
spec
prs,
and
this
issue.
H
H
So
basically,
one
is
for
the
actual
api
and
sdk
right
and
and
then
there's
one
and
a
separate,
separate
issue,
because
we
wanted
to
discuss
more
in
a
more
calm
way
with
taking
our
time.
What
guarantees
do
we
need
for
for
the
for
the
actual
expected
open,
telemetry
data,
and
the
reason
is
that
we
want
to
have
the
guarantees
for
for
versioning
for
the
api
and
sdk
as
soon
as
possible.
And
we
know
that
you
know
the
expectations
on
the
backends
that
can
take
a
little
longer.
I
Okay,
so
is
it
something?
Could
you
kind
of
similarly
say
that
as
we're
writing
one
spec
on
versioning
stability
for
api
and
sdk
and
we're
writing
another
spec
for
instrumentation
packages,
essentially.
G
Okay
and
josh
is
not
about
the
api
of
the
instrumentation
packages,
because
those
api
will
will
follow
the
api
sdk
convention,
it's
just
the
data
that
they
produce.
So
it's
right.
G
What
labels
you
use
and
don't
use
yeah
correct
correct
what
what
is
optional?
What
is
that
option,
and
a
bunch
of
things
like
that?
So
it's
we
we
try
to
separate
like
don't
break
our
api
users
versus
don't
break
the
back
end.
I
R
I
I
C
Sorry,
I
just
noticed
this
issue
stopped
by
my
my
triage
list.
I
was
wondering
if
we
just
quickly
do
a
triage
on
this
one.
C
I
Carlos
just
implied
that
it
was
we're
going
to
take
our
time
with
this
one,
as
opposed
to
the
first.
It's
not
answering
your
question,
though,.
H
I
It
it's
actually
later
down
in
the
notes.
Let
me
find
the
number.
A
H
P
I
There's
also
a
connection
between
required
resource
attributes
and
label
removal
and
metrics,
like
it's
only
safe
to
do
label
removal.
As
long
as
you
leave
one
unique
identifier,
and
so
we
we
may
need
we're
going
to
be
talking
about
service
instance
id
pretty
soon.
But
it's
a
metric
topic,
not
a
trace
topic.
Q
R
This
is
a
very
quick
update
and
and
again
andrew.
This
is
also
related
to
the
larger.
You
know
general
item
that
we
have
on
ci
cd.
We
had
an
action
item
of
migrating,
the
remainder
of
the
three
reapers,
the
three
languages
actually
and
the
collector
over
from
circle
ci
to
github
actions.
So
that
has
been
completed
and
again
the
wagon.
R
R
Okay,
I'll
make
sure
that
that's
completed
bogdan,
but
again
it
should
be
more
or
less.
I
know
we
did
that
for
the
contrib
repos
for
the
languages
so
I'll
make
sure
that
that's
completed.
R
G
R
Yep
yep
exactly
so
again,
this
was
just
an
update,
so
bogdan
just
to
be
clear.
Do
we
want
to
have
the
collector
contrib
also.
R
All
right,
so
that's
the
last
one
left,
but
other
than
that
all
the
other
reapers
have
been
completed,
and
I
will
link
all
the
issues
and
the
pr's
back
if
they
haven't
been
already
to
the
high
level
items
andrew
and
and
then
this
is
related.
R
R
G
So
yeah,
I
think
it
makes
sense
to
have
a
separate
issue
for
this
security
and
also
have
you
looked
at.
I
don't
know
if
this
is
code,
ql
or
something
else,
but
I
saw
in
github.
There
is
an
option
to
for
securities
and
github
sends
you
security
emails
with
dependencies
that
are
that
have
security
issues
and
stuff
like
that.
Yeah.
R
That's
a
defender
but
workflow
bugden,
and
I
think
that
that's
that
also
should
be
enabled
as
a
second
step
in
the
security.
R
R
C
I
can
help
make
up
open
up
a
tracking
issue
in
the
high
level.
Okay,.
R
C
P
R
F
R
And
that's
all
I
had
andrew
just
an
update.
C
I
One,
I
don't
think
we
have
time
to
discuss
everything
and
that's
why.
At
the
end
of
last
year,
we
talked
about
having
some
all-day
workshops
to
just
nail
out
a
bunch
of
work
on
metrics,
and
so
I
wanted
to
repeat
that
call
and
advertise
that
I
am
extremely
interested
in
getting
this
work
done.
So
I
my
idea
was
to
propose
through
a
doodle,
I
guess,
some
days
where
people
are
willing
to
be
available
all
day.
I
I've
listed
below
some
of
the
sort
of
bigger
topics
that
are
on
the
plate,
still
for
sort
of
discussion
and
specification
decision
making
where
we
still
have
like
technical
work
that
we're
doing,
and
then
I,
but
what
I'm
mostly
trying
to
call
out
here,
is
that
there's,
basically
a
backlog
of
spec
writing
work
that
we
haven't
been
doing,
and
part
of
that
is
that
I
think
our
reference
implementations
have
been
moving
and
it's
actually
really
easy.
I
In
my
opinion,
to
write
a
spec
once
you've
written
an
implementation,
then
you
want
to
just
describe
your
implementation,
but
at
the
moment
we've
got.
Our
implementations
are
still
moving
to
help
with
that
problem.
I'm
here
to
call
for
more
reviewers
and
approvers
on
metrics
work,
and
particularly
what
we
have
is
a
situation
where
to
try
and
finish
up
some
of
the
histogram
or
the
aggregator
work
that
has
been
done
in
the
hotel.
Go
repo.
I
I've
put
together
a
bunch
of
very
small-ish
prs
that
are
now
sitting
there's
about
six
of
them
or
so,
and
if
we
could
get
those
reviewed
and
merged
quickly,
it
would
really
help
us
write
specs.
So
the
problem
is,
I
don't
want
to
burden
the
hotel
go
reviewers,
who
are
rightly
working
on
tracing
support
and
ga
for
chasing.
I
So
what
I'm
hoping
we
could
do
is
get
some
a
dedicated
sub
team
here
of
metrics
approvers,
who
will
look
at
go
code
or
java
code
to
bring
our
reference
implementations
into
line,
because
once
we
have
these
written
it'll
be
really
easy
to
write
a
spec.
I
think
anyway,
that's
all
I
have
to
say
I'll.
Do
the
thing
about
the
doodle
and
posting
it
everywhere
and
get
get
these
meetings
started,
but
then
I
guess
calling
for
help
with
reviews
as
well.
Can
you
can
you.
G
See
me
just
tag
me
on
the
on
on
one
comment
on
all
these
pr's,
so
I
can
yes.
I
Be
great
though
I
actually,
I
wanted
to
raise
this
as
a
sort
of
like
kind
of
a
not
quite
governance
question
here,
but
as
a
member
of
the
tc,
I
am
able
to
merge
prs
now
right,
but
I
haven't
been
merging
pr's
in
the
go
repository
because
I'm
not
the
maintainer
there.
I
wanted
to
kind
of
clear
it
with
the
go
maintainer,
I'm
not
sure.
If
tyler's
on
the
call
or.
I
Yeah,
I'm
here.
Okay,
I
wanted
to
see
if
we
could
sort
of
clear
a
sort
of
sub
project
in
the
hotel
go
repository.
If
that's
okay,
with
anthony
and
tyler
to
just
have
me
and
a
team
of
metrics
reviewers,
merging,
metrics
pr's
and
go.
I
just
want
to
make
sure
that
that
was
okay
with
everybody
before
we
did.
It.
S
Yeah
I
mean
if
we
can
talk
more
about
this,
but
I
I
think
that
that
seems
reasonable.
I
like
to
have
things
progress
and
that
it
might
be
helpful
to
split
things
off
like
that.
Well,
yep.
I
agree.
G
The
other
the
other
option-
tyler
anthony
you
just
trust
us,
and
as
long
as
you
see
me
and
josh,
agreeing
on
that,
you
do
a
light
review
and
merge
by
yourself
just
to
to
follow
the
process
and
just
to
confirm
with
the
other
parts
of
the
the
project
that
you
have.
L
Yeah
and
I'm
fine
with
that
as
well-
that's
kind
of
how
I
expected
it
to
to
happen.
You
know
I've
been
trying
to
review
the
metrics
prs,
but
my
understanding
of
the
metric
system
is
not
quite
as
strong
as
understanding
phrasing.
As
strash
mentioned
perfect.
G
So
josh
another
way.
Another
thing
to
do
this
is
we
create
a
label
ready
for
merge
or
whatever,
and
then
anthony
and
tyler
can
just
scroll
and
see
whenever
pr
is
marked
with
that
they
do
their
light
review
on
top
of
what
we
do
and
they
merge
just
try
to
to
give
them
the
the
last
the
last
call
and
merging
and
follow
the
process.
I
G
Thank
you
send
send
an
email
to
to
morgan.
If
you
have
his
gmail
account
or
stuff
send
an
email
to
him.
He
he
offered
to
to
help.
I
R
I
C
Gosh
this
first
date
january
7th,
is
pretty
close
the
day
after
tomorrow
is
there
particularly
like
quorum?
Let's,
let's.