►
From YouTube: 2020-09-03 Spec SIG
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
Hi
everyone.
I
think
we
should
wait
another
minute
or
two
here.
Please
add
your
name
to
the
agenda.
If
you're
here.
A
I
did
a
little
triaging
of
hotel
metrics
issues
in
this
back
repo
earlier
today
and
have
written
or
you
know,
pasted
links
to
the
sort
of
most
most
of
the
issues
I
didn't
quite
be
exhausted,
but
but
they're
here
just
to
give
us
an
idea
of
where
we
are.
I
know
that
right
now
chasing
is
going
through
a
kind
of
burn
down
to
get
to
ga
and
we're
going
to
have
that
happen
soon.
A
Here
I
think-
and
I
think
it'll
be
nice
when
the
I
guess
the
managers
in
the
room,
I'm
thinking
of
andrew
and
morgan
finish
their
pressure
on
the
hotel
tracing
committees,
we're
going
to
start
seeing
that
same
pressure
here,
so
we
should
get
ready
for
it
just
to
get
to
kick
us
off
here.
I
want
to
congratulate
everyone,
including
bogdan
for
the
release
of
v0.5.
A
It
was
a
huge
step,
I'm
really
happy
that
we
made
it
there.
So
thank
you.
I
didn't
finish
writing
notes
together
for
this
for
this
meeting,
but
we
should
talk
a
little
bit
about
the
current
state
of
v0.5
and
the
collector
release
and
what
kind
of
timing
we
should
expect
to
happen.
As
far
as
coordinating
of
releases,
anybody
on
otlp
v0.4
is
probably
going
to
get
broken,
and
we
need
to
think
about
how
that
happens.
A
I
guess
maybe
maybe
not,
but
as
I
I'm
looking
at
this
list
of
issues
which
you
can
see
is
quite
long,
I
think
that
that
it
basically
to
me,
looks
like,
for
the
most
part,
we've
settled
all
the
debates
about
many
things,
except
for
this
one
at
the
top
here,
which
is
about
we've
been
discussing
every
week
now.
This
is
about
the
default
aggregation
for
the
value
recorder
instrument
and
whether
we
want
to
go
with
a
sketch,
as
opposed
to
a
histogram
or
some
of
the
other
options.
A
This
has
been
discussed
quite
a
lot,
and
I
found
an
issue
this
morning
to
formalize
that
notion
here.
I
tagged
michael
who
I
see
is
on
the
call
with
some
sort
of
questions
here.
I
love
dd
sketch
just
to
saying,
but
I
find
some
some
details
are
missing
when
I
closely
at
it,
and
so
I
I
wrote
down
those
those
concerns.
A
I'd
like
to
see
the
authors
of
dd
sketch
pitch
in
here,
I
wrote
down
what
what
to
me
looks
like
a
viable
draft
representation
for
the
the
data
and,
but
I
I
did
make
it
up
so
this
is
this.
This
is
what
the
level
of
detail
that
we
would,
I
think,
need
to
finish
this.
I'm
still
looking
for
everyone's
opinion
on
whether
this
this
structure
here,
which
is
you
know,
quite
mathematical
and
and
quite
a
lot
more
sophisticated
than
histograms
as
we
know
them
is
going
to
fly.
A
I
think
there
there
are
some
questions
for
for
compatibility
that
we
need
to
think
about.
As
far
as
when
a
user
is
running
like
a
legacy
prometheus
server,
what
are
they
going
to
get
if
they
do
end
up?
Looking
at
this
data
and
the
problem
being
that
prometheus's
back
end
doesn't
really
have
an
internal
notion
of
a
histogram,
so
this
might
end
up
looking
pretty
funny
and
we
need
to
vet
those
sorts
of
questions.
B
Please,
oh
no,
I
wasn't
sure
if
that
was
agenda
or
a
chance
to
step
in,
but
I
did
talk
to
the
people
who
did
write
it
and
I
sent
them
this
when
I
saw
it
so
they're
discussing,
but
I
do
have
by
in
in
principle
to
to
contribute
here.
I
need
to
talk
with
the
product
managers
to
make
sure
I
get
they
get
out
of
the
way
and
all
of
that,
but
but
but
we're
moving
forward
with
your
comments
here.
So
thank
you.
A
Cool,
I
think
that
there
is
some
degree
here
of
question
about
whether
the
community
at
large
wants
this
type
of
complexity.
I
think
a
lot
of
the
practitioners
in
the
room
do
so
so
it's
a
question
of
if
the
spec
said
that
this
is
the
default
or
is.
Are
we
going
to
have
to
come
up
with
an
implementation
in
every
language?
Is
datadog
willing
to
contribute
their
implementations?
Is
there
a
licensing
question?
I'm
not
a
lawyer,
so
I
don't
have.
I
don't
have
a
position
on
that.
A
I
I've
already
seen
a
little
bit
of
a
grumbling
about
naming
like
openometry.
Being
a
vendor
neutral
project
to
have
a
data
type
called
dd
sketch
is,
is
potentially
an
issue
and
I'm
I'm
again
I'm
not
a
marketing
person
either.
So
so
I
there's
a
question
there,
I'm
not
going
to
state
it,
but
but
we
might
want
to
talk
about
whether
we
call
this
duty
sketch
or
whether
we
call
this
sketch
or
hotel
sketch,
or
something
like
that.
A
Even
though
it's
going
to
refer
to
dd
sketch
very
clearly
question,
there
might
be
an
issue
there,
but
you
know
we've
talked
about
this
for
a
long
time
now.
I
think
it's
time
to
just
make
a
decision.
A
We,
the
there
are,
the
the
number
of
options
are
known
and-
and
we've
discussed
they're
up
here
essentially,
and
I
think
we've
decided
that
last
value
is
not
a
good
choice,
but
if
users
really
want
that
they
should
by
default,
they
should
choose
the
asynchronous
form
that
the
value
observer
case
instagram
the
problem
is
fixed,
buckets,
are
not
always
good
and
then
nexon
count.
The
problem
is,
it's,
maybe
maybe
too
minimal
it
it.
A
It
doesn't
include
anything
about
the
the
distribution
other
than
the
range
of
it,
and
you
know
sketch
is
vague.
That's
why
we're
talking
about
this
and
then,
of
course,
the
exact
idea
of
exact
or
raw
data
is
a
performance
problem.
My
the
type
of
nuance
that
we
might
end
up
with
here
is
something
like
to
the
effect
of
you
know,
let's
suppose
you're
I
I
don't
want
to
pick
on
php,
but
it's
often
held
up
as
a
special
case
because
of
its
own
sort
of
runtime
environment.
A
If
someone
didn't
have
a
and
also
there's
no
aggregation
possible
in
php
because
of
the
statelessness
of
its
run
time.
So,
if
you're
going
to
be
an
implementation
in
php,
it
just
doesn't
make
sense
to
implement
this.
Can
we
then
have
raw
values
be
a
compliant
implementation
for
some
implementations,
raw
values
will
go
to
the
collector.
A
The
collector
will
implement
dd
sketch
just
fine,
that's
the
type
of
thing
that
we
might
end
up
needing,
but
I
leave
this
to
you
all
I've
written
a
lot,
and
so
it's
a
question
of
whether
the
datadog
team
can
make
us
happy
and
whether
the
sort
of
practitioners
are
willing
to
take
this
as
default
any
discussion
there.
I'd
like
to
hear
from
anybody
who
wants
to
talk
about
this.
A
B
Yeah
in
that
week,
I
should
be
able
to
get
you.
Some
of
the
answers
here,
and
also
I
mean
a
week-
is
a
very
short
amount
of
time
with
labor
day,
but
hopefully
a
little
bit
more
about
how
we
would
convert
to
prometheus,
fixed
bucket
time
series
as
well
right.
A
Yeah,
that's
a
good,
that's
a
good
one
to
have.
I
remember
we
talked
about
that
last
time.
Okay,
unless
anyone
else
here
wants
to
kick
to
speak
up
on
this
matter,
we
can,
I
think,
move
on
to
some
other
pressing
issues.
A
A
I
think
before
we
talked
about
it,
I'd
like
to
hear
bogdan
talk
about
the
timeline
for
getting
a
new
collector
out
and
what
the
release
schedule
is
going
to
look
like
like
how
do
we
prevent
breaking
a
bunch
of
clients?
I
know
we're
going
to
break
a
bunch
of
clients,
but
it'd
be
nice
to
kind
of
like
try
to
avoid
invited
a
little
bit.
C
So
I
don't
know
if
you
read
the
guitar:
the
code
is
checked
in
in
the
collector
in
the
snapshots
that
we
publish
every
every
time
when
we
push
pr
to
master,
are
now
capable
of
accepting
zero.
Five
java
did
a
release
of
zero
five.
Fortunately,
unfortunately,
everything
works.
That's
the
fortunate
part.
Unfortunately,
user
will
have
to
use
a
collector
build
from
from
master,
not
a
released
one.
The
release
for
the
collector
is
planned
tuesday,
so
they
will
have,
I
think,
is
0
10,
the
collector,
which
will
fully
support
this.
A
That's
great
cool
yeah
were
there,
does
anyone
who
is
working
with
this
protocol
so
far
seen
any
like
gotchas
or
pitfalls
that
we
didn't
anticipate.
C
So
I
was
working
with
these
a
lot
because
I
changed
a
lot
of
code
to
to
use
this
so
far.
Nothing
stops
us,
I
would
say
summary.
Support
is
unexpectedly
hard
for
the
collector
part,
because
we
have
we
have
prometheus
coming
receiver
coming
with
summaries
and
we
also
have
open
sensors
coming
with
summaries
for
the
moment.
I
just
decided
to
drop
this,
so
we
drop
the
data
not
ideal,
but
I
need
to
to
to
come
up
with
the
solution.
That
doesn't
mean
it's
a
problem
without
erp,
it's
a
known
problem.
C
We
we
knew
when
we
made
this
call,
it's
just
a
fact
that
we
need
before
ga.
We
need
a
solution
for
how
to
change
somebody's
into
collector.
A
A
You
need
to
do
something,
and
I
guess
traditionally
there
has
been
a
conversion
from
sort
of
classic
summary
into
many
time
series
where
you
prefix
or
suffix
the
metric
name
with
underscore
sum
and
so
on.
I
don't
know
if
we
want
to
standardize
on
that
or
whether
we
want
to
create
a
data
type,
which
is
that
actually
I'd
like
to
hear,
if
michael,
has
a
thought
given
that
datadog
has
sort
of.
B
Worked
through
this,
in
my
experience-
and
this
is
just
my
experience-
it's
if
you
suffix
with
the
aggregator
it's
confusing,
because
the
semantics
are
the
you-
have
the
aggregator
in
the
query.
So
you
end
up
summing
sums,
whereas
that's
not
necessary,
because
the
sum
of
a
sum
is
a
sum.
B
This
is
the
worst
for
averages
which
we're
avoiding
anyway.
So
it's
not
a
huge
deal
and
I
think
it'll,
work
and
it'll
be
readable
anyway,
but
in
my
experience,
just
keeping
everything
in
the
in
the
aggregator
instead
of
in
the
metric
name
is
preferable.
A
So
then
you'd
prefer
to
see
metric
names
and
sort
of
hide
the
complexity
and
the
aggregator.
Then
it
could
be
so.
This
is
something
that
we
haven't
really
done
in
otlp,
I
think,
and
maybe
intentionally
so,
but
maybe
it's
time
to
move
past.
It
is
that,
like
we
describe
what
the
data
type
is,
we
describe
what
the
metric
kind
is
and
we
and
we
sort
of
let
you
infer
what
the
aggregator
is
because
of
the
data.
B
Right,
we
control
the
query
also,
and
you
are
just
talking
about
the
the
metric
itself
so
in
hours,
because
we
control
the
query.
Also,
when
you
make
a
query
to
the
sum
you
you
specify
the
metric
name
and
there's
a
bunch
of
the
metric
name
is
basically
just
some
chrome
in
front
of
five
time
series
and
based
on
the
aggregator.
We
choose
the
right
one.
A
I
see
so
so
you
transform
the
query
and
then
look
up
different
metric
names
yeah
based
on
that,
but
you
might
not
want.
A
Right
so
we've
sort
of
avoided
like
right
now,
you've
got
you
know
the
metric
kind.
It's
like
it's
a
gauge
or
it's
a
sum,
and
then
you
know
the
point
time
is
the
integer
or
float.
But
right
now
you
can't,
you
can't
say
here's
a
metric
name,
and
this
is
an
average
or
this
is
a.
This
is
a
another,
a
max
there's
no
way
for
us
to
say
what
the
aggregation
is.
That
shows
that
for
that
scalar,
so
we're
doing
a
lot
of
inference
and
I'm
not
sure
why
we
ended
up
there.
A
I've
we,
I
don't,
I
don't
know
anyone's
proposed,
having
like
an
enum
of
aggregation
kind.
That
would
be
part
of
otlp,
but
when
you
think
about
that,
you
end
up
with
this,
like
kind
of
sparse
matrix
of
which
metric
kinds
can
produce,
which
data
point
kinds
which
have
which
aggregations
applied,
because
if
you're
a
counter
or
a
gauge
or
you
know
adding
or
grouping
you
end
up
with
different
properties,
and
some
of
them
are
not
meaningful
and
that's
why
we,
I
think,
maybe
why
we've
never
gotten
this
far.
A
So,
anyway,
that's
why
summary
is
complicated.
I
guess
I
think
the
the
looking
forward
hope
is
that
we,
we
convinced
the
world
to
adopt
dd,
sketcher
or
a
sketch-
that's
a
mergeable
sketch
rather
than
summary,
which
is
questionably
mergeable,
but
we're
not
going
to
get
away
from
this
issue
so
easily.
I
think
I
don't
have
any
good
ideas
here.
I
think
we
should
move
on
unless
anyone
else,
I
think
actually
does
anybody
have
any
good
ideas
here.
If
you
don't
have
here.
C
So
what
I
think
we
need
to
maybe
consider
is
the
fact
that
we
may
have
you
know
tlp
some
types
or
some
some
some
metric
types
that
will
will
be
only
for
for
backwards
compatibility,
but
will
never
be
the
the
used
by
the
library.
So
that
may
be
a
reasonable
solution.
So,
for
example,
define
summary
the
way
how
prometheus
open
sensors
and
other
protocols
are
are
used
to
it,
but
we
never
never
use
that
in
the
library
we
never
produce
it
in
the
library.
A
A
Yeah.
Okay,
I'll
try
to
write
an
issue
just
to
capture
that
issue
about
summaries
and
file
that
in
the
coming
week,
proposing
to
move
on.
There
are
some
open
questions
about
otlp
still
other
than
summary.
There's
the
raw
value
question.
I
don't
think
it's
urgent
right
now,
but
it's
definitely
hanging
out
there.
I
filed
one
this
week,
which
has
an
open
pr
about
item
potency
keys,
also
not
urgent,
but
you
know
take
a
look
at
that.
I
don't
think
we
should
discuss
it
right
here.
A
What
I
so
preparing
for
this
anticipation
that
that
we're
going
to
get
a
lot
of
pressure
in
coming
months
to
just
ga
this
stuff
is:
we've
got
a
lot
of
spec,
that's
unwritten
and
that's
a
real
problem.
I
I'm
part
of
the
problem
because
I've
been
dragging
my
feet
for
for
months
on
this
as
well.
I
do
have
an
open
pr
and
I'd
like
to
discuss
that
some
point
in
the
next
40
minutes,
because
it
seems
that.
A
My
what
I'm
trying
to
say
is
we
need
more
attention
and
authoring
of
sex.
A
I
was
gonna
put
that
in
discussion
below,
but
this
is
a
daunting
list
of
like
things
that
either
there's
literally
nothing
written
about
in
the
spec
where
we've
got
a
kind
of
the
state
is
in
this
group
in
our
in
our
minds,
rather
than
in
a
you
know,
language
in
a
document
and
or
they're
minor
issues
that
just
there's
there's
there's
so
much
lower
priority
than
getting
those
big
blocks
of
text
written.
So
this
is
the
area
where
I
think
the
most
work
is
actually
needs
to
be
done.
A
Sorry,
I'm
selecting
the
wrong
the
wrong
area.
This
is
what's
hard.
The
the
issues
about
getting
the
spec
written.
A
These
issues
are
all
about
semantic
conventions
and
they've
been
lingering
and
kind
of
moving
slowly
for
months
now,
but
I
actually
don't
think
that
there's
a
tremendous
amount
of
debate
or
hard
problem
here
left
these
are
more
about.
We.
We
want
to
make
recommendations
about
metric
names
and
label
names
and
there's
some
sort
of
technical
issues
there
that
need
to
be
written
into
the
spec
and
there
are
some
standard
names
for
host,
metrics
and
and
so
on
that
we've
described,
I
think.
A
Which
means
that
all
of
these
issues
c
and
d
are
kind
of
all
about
writing
specs,
and
so
I
guess
what
I'm
about
to
say
is
we
need
help
if
one
person
or
two
people
try
to
write
this
it'll
be
done
a
year
from
now,
and
I
think
that
that's
too
late,
so
just
just,
for
example,
I
wrote
this
pr.
A
When
did
I
do
that
eight
days
ago
so,
and
there
has
been
some
some
feedback
and
I
addressed
some
of
it,
and
partly
I've
not
been
focused
on
merging
this.
As
my
first
priority,
there
has
been
some
debate
and
you
know
these
are
real
questions
here,
and
so
I
need
to
come
back
to
this
and
hope
to
get
that
done
before
this
meeting,
but
didn't
so.
A
I
won't
try
to
answer
these
questions
right
now
before
the
whole
group,
but
so
I'll
I'll
work
on
this,
but
but
we
need
more
spec.
Writing
I'm
asking
for
volunteers,
and
this
issue
with
is
pretty
pretty
big,
so
it's
a
little
hard
to
know
where
to
start.
A
Let
me
say
this:
if
you
are
someone
who
is
motivated
to
get
this
thing
to
ga
like
many
of
us
are
and
want
to
contribute
to
writing
some
sdk
specification
or
some
semantic
convention
specification
or
just
revisiting
the
entire
api
and
sdk
specification
that
we
have
for
clarity
or
for
for
areas
that
are
just
not
well
under
understood.
I
think
that
there
are
still
some
areas
in
the
api
specification
that
could
use
some
rewording.
A
There
were
some
evidence
there
was
evidence
of
this
discussed
recently
a
couple
few
issues,
so
this
is
a
call
for
help.
A
This
everything
else
section
down
here
is
a
grab
bag,
a
small
grab,
bag
of
of
sort
of
other
issues
that
are
independent
from
all
the
stuff.
Above
I,
I
don't
think
we
need
a
block
ga
on
on
some
of
these,
but
they're
important
anyway.
We
could
use
more
attention
if
you
are
someone
who
feels
like
contributing
it,
but
don't
know
where
to
start
feel
free
to
reach
out
to
me
directly
like
on
getter,
email,
etc.
A
A
So
I've
done
a
lot
of
talking
now,
but
I
just
ran
through
everything,
that's
sort
of
like
in
the
spec
issues
list.
We've
got
this
item
potency
thing.
This
is
about
actually
using
deltas
instead
of
using
cumulative
all
the
time,
which
is,
I
think,
pretty
pretty
nice
and
then
I'll
get
back
to
the
the
pr
about
the
accumulator
specification.
D
So
I
have
a
I
mean
it
is
a
meta
comment,
not
a
not
at
all
a
criticism
of
any
of
this,
but
I
think
all
of
us
are
kind
of
swamped
and
overloaded
and
oversubscribed
like
as
a
domain,
a
maintainer
of
a
separate
repo.
I
think
I
definitely
will
say
that,
and
I've
heard
tyler
say
that,
although
I
won't
speak
for
him
in
this
meeting,
but
we're
both
we're
both
very
busy
we're
both
very
interested,
but
so
the
meta
discussion
is
if
there
are
vendors
who
are
interested
in
metrics.
D
Can
those
vendors
please
get
some
people
to
help
out
who
are
not?
Who
are
not
already
maintainers
and
oversubscribed.
A
Yeah,
that's
right.
I
think
I
appreciate
that
john,
like.
If
you
look
at
metrics
vendors,
what
kind
of
contributions
have
been
coming
in,
especially
I
mean
michael,
is
representing
datadog
here
and
it
hasn't
tradition
hasn't
been,
but
datadog
hasn't
been
too
involved
until
recently,
but
I
think
the
contribution
of
data
dd
sketch
is
huge
so
like,
let's
just
just
give
data
dog
credit
there,
you
know
bogans
coming
from
the
sort
of
signalfx
and
you
know
tyler
and
john
representing
new
relic.
I
don't
want
to
list
everybody.
A
Keith
is
here
from
google
like
we've
got
aws
in
the
room
like
there
are
a
lot
of.
There
is
a
lot
of
presence,
but
there
are
some
missing
vendors.
We
do
need
more
energy
written
here.
We
need
more
people.
I
agree.
I
don't
know
how
to
get
those
people.
There
are
some
underrepresented
vendors.
Definitely,
and
you
know.
A
Well,
yeah,
that's
all
I
know
okay,
so
this
is
a
call
for
support,
call
for
contributors.
We
aren't
experiencing
the
type
of
pressure
that
tracing
is
experiencing.
Maybe
when
that
pressure
relieves
is
off
tracing
when
they
have
some
ga
we'll
get
more
cycles
out
of
some
of
the
other
contributors.
I
don't
know.
I
think
that
this
pressure
is
likely
to
rise
in
october
and
we
have
a
few
weeks
before
it
happens.
D
A
Yeah
I
I
same
here
like
white
steph:
has
I've
been
working
in
hotel
for
over
a
year
now
almost
entirely
full
time,
and
myself
wants
me
to
be
giving
back
to
the
company
now
and
so,
for
example,
I
worked
on
the
otp
0.5
receiver
for
our
our
infrastructure
this
week
and
it
was
great,
but
I
didn't
get
to
work
on
hotel
a
lot
this
week,
so
I
think
we're
all
experiencing
that
and
maybe
the
motorcycles
will
come
available
once
once.
We've
finished
tracing
for
me,
but
I
I
don't
know.
C
A
Yeah,
I
know
I
sorry
I
should
have
followed
up.
I
did
not
have
any
gashes.
I
was
quite
pleased
with
it,
but
I
was.
I
was
only
focusing
on
counters
and
gauges
kind
of
because
the
the
first
milestone
for
us
is
to
get
the
host
metrics
and
the
and
the
runtime
metrics
into
the
our
system,
which
all
of
those
can
be
basically
expressed
with
counter
engages.
So
so
I
didn't
need
to
have
summaries
or
histograms
working.
Okay.
C
C
Yeah,
nice,
nice
also
for
everyone.
I
changed
the
host
metrics
that
we
produce
in
hotel
to
use
the
the
the
new
otlp
things
and
there
were.
There
was
a
issue
which
I
pointed
to
you:
josh
about
people,
not
understanding
very
well
the
non
the
non-cumulative
systems-
and
I
I
I
spent
I
spent
time
explaining
to
the
google
person
who
wrote
most
of
the
host
metrics,
why
certain
things
are
non
cumulative
sounds
and
are
not
gauges.
A
That's
that's
here.
I
did
respond
to
this
last
night
because
I
know
you
would
ask-
and
I
was
following
the
conversation,
so
I
think
we
are
hopefully
making
progress.
I
this
is
another
area
where
updating
the
this
is
what
I
was
actually
thinking
about
when
I
said
taking
a
password
with
the
api
for
clarity
or
sort
of
confusion.
A
This
this
is
an
issue
where
I
feel
that
it's
pretty
hard
to
describe,
and
I
think
we're
we're
still
trying
to
do
something
that
hasn't
really
been
done
in
metric
specs
in
the
past,
about
like
separating
api
and
semantics
from
sdk
and
implementation.
So
it's
it's
really
hard
to
describe
in
abstract
terms
without
an
actual
implementation.
At
the
same
time
like
what
do
you
mean?
A
This
is
about
adding
versus
you
know
whatever
anyway,
so
I'd
like
help
as
well
on
this
issue,
and
anybody
who
thinks
who
thinks
that
they
can
improve
the
language
and
the
api
spec.
A
Please
help,
because
I,
when
I
read
this,
I
wasn't
sure
if
I
wrote
it
or
you
wrote
it
bogdan,
but
it
doesn't
sound
very
I
it
left
me
feeling
confused
and
I
and
I
I
shouldn't
feel
I
don't
know
I
felt
like
I
understood
what
I
was
what
I
was
trying
to
say,
but
the
words
didn't
really
work
out
and
I
think
we
can
all
improve
this,
but
we're
all
oversubscribed.
A
A
Well,
we
released
two
0.5
we've
all
got.
We've
all
got
lots
of
work
to
do.
I
think
we
can
have
the
other
half
an
hour
back
here,
but
you
know
if
you're,
if
you're
here
representing
a
vendor
and
you're
like
a
manager
or
leader,
probably
go
back
to
your
leadership
and
say:
hey
hotel
metrics
is
crawling
along
and
it
could
be
moving
faster
and
we
probably
want
it
to
move
faster,
but
we're
all
playing
this
game
of
like
competition
between
vendors.