►
From YouTube: WebPerfWG TPAC meetings 2022 09 16 - Rechartering
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
So
we
are
currently
living
under
our
2021
charter.
I
send
a
link
to
this
page
of
the
notes
as
well
in
case
anybody
else
wants
to
well.
They
might.
A
A
We
are
currently
under
the
2021
treasure
which
we
did
in
2021.
That
expires
in
february
of
next
space.
A
All
good
okay,
that
expires
in
february
of
next
year,
so
you
know
five
or
six
months
from
now
so
before
then,
we
need
to
take
a
look
at
our
current
charter.
What
we
have
renew
it,
I'm
assuming
everybody
wants
to
renew
it
here,
see
if
we
want
to
make
any
changes
to
it,
whether
there
are
any
specs
we
either
want
to
adopt
from
incubations
whether
there
are
any
specs
we
want
to
discontinue,
etc.
A
A
You
know
it
starts
out
with
our
scope,
which
kind
of
gives
some
of
our
mission
statements
some
of
the
things
we
want
to
focus
on
a
couple
years
ago,
in
2021,
when
we
were
looking
at
this
in
2020
2021,
we
did
go
through
all
of
the
in
scope
out
of
scope,
and
you
know
make
some
modifications
to
some
of
the
the
key
topics
there.
A
So
I
guess
I
would
invite
folks
to
look
at
the
current
charter
to
see
if
there's
anything
that
they
think
is
missing
or
inappropriate.
Then
we
can
always
re-evaluate
it
for
the
2023
charter.
A
A
That's
because
we're
moving
that
stuff
to
html,
I
don't
believe,
that's
complete
yet,
and
I
did
notice
like
I
was
taking
a
look
at
all
the
repos
to
see
if
we
discuss
any
of
these
items
and
there's
no
current
hints
in
the
repo
that
this
is
happening,
I'm
not
sure
if
we
want
to
just
wait
until
that's
done
before
we
would
mention
it,
but,
for
example,
in
the
preload
and
page
visibility
repos,
we
do
mention
that
the
work
has
been
transitioned
to
html,
so
there
may
be
some
work
to
do
just
in
the
repo
after
it
gets
transitioned
to
kind
on
wrap
it
up.
A
Preload
preload
was
discontinued
as
well
in
our
2021
charter.
We
have
moved
all
of
that
text
into
the
repo
has
been
archived
in
github,
so
you
get
a
nice
sketch
repository
archived
by
the
owner
to
read
only
and
the
text
describes
how
that
has
been
moved
into
html.
So
I
think
this
is
a
nice
buttoned-up
archival
of
what
the
work
was.
It
tells
you
where
to
go
next.
A
Page
visibility:
this
is
one
we
probably
should
discontinue
in
our
2023
charter,
because
we
have
moved
that
work
to
the
html.
A
However,
I
think
that
we
should
probably
do
a
little
bit
of
just
one
more
commit,
or
so
just
to
like
mention
what
we're
doing
here,
why
it's
been
archived
and
moved
to
html,
and
if
you
look
at
the
page,
it
does
say
it's
discontinued,
but
it
doesn't
tell
you
why
or
where
I
don't
think
I
don't
know.
I
guess
it
goes
on
here.
A
So
maybe
we
do
or
do
not
want
to
do
a
little
bit
of
auto
redirects
or
when
we're
connected
to
repo.
Just
to
mention
why
there's
no
more
work
in
there
for
on
the
reading.
A
We
have
a
couple
other
specs
that
we
were
pushing
to
get
towards
rec,
for
example,
beacon
and
cooperative
scheduling
of
background
tasks
or
requests
that
will
call
back
we're
thinking.
Some
of
the
other
incubations
might
be
appropriate
to
wrap
into
those
instead
of
finalizing
them
towards
rec.
Right
now,
for
example,
for
beacon
we
have.
The
proposals
for
the
pending,
beacon
or
unload
beacon
seems
very
appropriate
to
consider
pushing
that
into
the
beacon
spec
same
thing.
With
the
operative
scheduling
of
background
tasks.
A
A
Event:
timing
in
lcp,
I
know
that
we
recently
adopted
those
we
have
they're
not
listed
in
our
current
charter,
obviously,
because
that
chart
was
from
before
when
we
adopted
them
last
year
or
earlier
this
year
I
should
say
so.
We
just
want
to
make
sure
that
they
are
officially
adopted
in
you
know
in
the
right.
A
Way
in
the
next
charter,
lcp
could
potentially
incorporate
some
of
the
element-
timing
stuff
as
well
since
they're
very
linked
together,
something
for
us
to
consider
as
working
group,
and
then
I
also
we
have
the
timing
names
registry.
I
was
hoping
to
chat
with
philippe
a
little
bit
more.
He
had
mentioned
yesterday
how
they
had
like
a
different
process
for
registries,
and
we
may
want
to
like
get
that
under
that
official
process
for
adoption
by
the
w3c
for
for
a
registry
yeah,
because
right
now,
it's
enough
right,
yeah
nick
you
skipped
paint.
A
Oh
yeah,
I
guess
I
had.
A
Then
well,
one
consideration
would
be.
Does
something
like
lcp
and
or
element
timing
further
belong
in
something
like
paint
timing
as
well.
They
are
not
today.
I
think,
for
us
to
consider
as
working
group.
A
And
then
we
have
a
list
of
incubations.
You
know
these
are
all
various
different
states.
A
I
was
hoping
to
as
part
of
the
discussion
after
this
presentation
just
talk
about
some
of
these
and
see
if
there
are
any
interests
or
barriers
to
moving
these
forward.
Specifically,
I
don't
know
that
one
again
to
any
of
these
more
without
actually
being
able
to
have
a
discussion
about
them.
So
why
don't?
We
say
that
for
actual
chatting
after
we
stop
recording
in
a
moment,
is
there
anything
else
from
a
high
level
to
review
at
this
point
before
we
start
chatting
about
things.
A
Yes,
I
will
actually
michael,
if
you
don't
mind,
one
thing
that
we
are
considering
looking
at
is
with
the
effort
for
interop
2022,
there's
a
newly
initiated
effort
for
2023
to
consider
things.
Maybe
this
working
group
might
want
to
highlight
from
a
performance
perspective,
so
michael's
had
put
a
few
thoughts
into
that
so
I'll
pass
the
journey.
B
B
B
So
this
kind
of
summarizes
how
they
prioritize
the
work
that
went
into
2022,
so
they
focused
on
developer
surveys,
usage
numbers
and
the
number
of
bugs,
and
so
that
makes
sense
that
those
would
be
the
focus
areas
you
know,
there's
demand
is
there,
the
usage
is
there
and
work
exists,
so
they
cover
kind
of
an
update
on
what
2022
did,
but
they
are
now
beginning
planning
for
2023
and
there's
a
timeline
about
how
to
make
proposals,
so
we
don't
need
to
get
in
the
weeds,
but
I
thought
there
were
a
few
reasons
why
we
might
consider
some
at
least
soft
participation
in
this
effort
in
2023.
B
We
might
not
be
selected
there's
this
selection
criteria,
but
first
of
all,
I
do
think
there
is
demand
for
the
performance
work
that
we
do.
There
are
significant
usage
numbers
on
some
of
the
apis
that
we
provide,
and
yet
there
are
bugs
and
interop
issues
so
both
for
us
internally,
I
mean
we
certainly
do
spend
a
lot
of
time
on
specification
and
interop,
but
it
maybe
it
isn't
the
number
one
top
priority
all
of
the
time.
B
Certainly
this
week
we've
had
a
few
fantastic
conversations
about
things
we
can
do
to
to
work
on
that,
and
so
this
would
be
kind
of
a
narrowing
of
focus,
especially
on
what
platform
to
us
to
sort
of
take
it
past
that
finish
line
and
okay,
there's
also
somewhat
developer.
Confusion
demand,
I
think
it
fits
well
within
this
prioritization.
B
The
other
reason,
perhaps,
is
just
a
certain
signal
to
the
community
who's
focusing
on
interop
there's
a
lot
of
attention
on
this
effort.
But
you
know,
web
performance
is
a
part
of
the
web
platform.
It
is
part
of
what
we
deliver
to
developers.
The
demand
is
there.
It
doesn't
have
to
be
a
large
effort,
but
I
thought
for
both
of
those
reasons.
I
thought
it
might
be
worth
a
shot
to
think
about.
B
You
know
which
things
do
we
want
to
carve
out.
I
had
a
few
proposals
myself,
but
mostly
it's
just.
Is
it
even
a
good
idea
to
get
started?
Brainstorming
and
perhaps
that's
enough.