►
From YouTube: 2022-03-10-Node.js Technical Steering Committee 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
So
welcome
to
the
node.js
technical
steering
committee
meeting
for
march
10th
to
2022
we'll
follow
the
agenda
that
we
had
in
the
issue
in
the
tc
repo,
which
is
issue
number
1184.
A
Okay,
so
I
think
there's
no
announcements
this
week
in
terms
of
cpc
and
board
meeting
updates.
I
guess
there's
no
board
meeting
updates
there.
A
The
last
cpc
meeting
was
a
working
session
and
the
thing
that
we
worked
on
was
related
to
the
community
fund
and
a
proposal
that
we
use
some
of
that,
probably
a
pretty
small
amount
for
awards
once
a
year
at
openjs
world,
and
you
can
take
a
look
at
what
that
looks
like
comment
and
so
forth.
If
you're
interested
in
this
particular
pr
which
documents
some
of
the
some
of
the
details,
so
I
paste
that
in
the
chat
I
can
get
back
to
the
chat.
A
Okay,
so
if
there's
no
questions
or
comments
on
that,
we
can
move
on
to
the
issues,
tag
for
the
agenda
and
we're
going
to
kick
off
by
starting
with
talking
about
the
issue
related
to
a
built-in
test,
runner
that
is
number
40954.
B
Sure,
thanks
so
yeah.
The
issue
is
about
whether
node
should
ship
a
a
built-in
test.
Runner
dino,
you
know
also
ships
a
built-in
test
runner
now,
so
there's
there's
a
little
more
precedent
for
it.
I
think
it
makes
sense.
You
know
a
lot
of
projects.
B
You
know
if
you're
trying
to
avoid
a
lot
of
npm
dependencies,
you
still
end
up
having
to
npm
install
a
test
runner.
So
it
would
be
nice
if,
if
node
kind
of
offered
a
minimal
one
out
of
the
box-
and
so
the
discussion
on
that
issue
seems
to
be
an
agreement
that
that
we
should
offer
some
sort
of
test
runner
and
I
think
the
agreement
was
that
it
should
be
kind
of
a
minimal
custom
built
one.
B
But
then
there's
also
been
some
some
discussion
on
twitter,
where
you
know
people
are
advocating,
for
we
should
ship.
You
know,
insert
your
favorite
test
runner
here
and
so
there's
there.
You
know
the
the
issue
in
question
here
has
some
engagement
from
tsc
members.
I
know
myself
james,
I
think
rich
has
been
involved.
I
can't
remember
anyone
else,
but
so
I
just
wanted
to
bring
it
up
to
the
tsc
before
I
personally
invest.
You
know
more
time
in
it
to
decide.
B
B
So
that,
I
think,
would
depend
on
how
feature-rich
we
want
to
make
it
so
the
what
I
currently
have
is
is
pretty
minimal.
I
think
I'd
be
ready
to
start
making
a
couple
pull
requests
with
probably
less
than
a
thousand
lines
and
changes,
but
you
know
the
more
features
you
add
like,
for
example,
I
looked
on
the
npm
page
and
tap
is
like
almost
30
megabytes,
which
I
think
we
don't
want
to
include.
C
C
Yeah
hello,
so
I
love
the
idea
of
a
test
runner.
I
guess
a
question
that
I
would
have
would
be
for
reporters
right
like
there's
so
many
different
output
reporting
structures
we
could
use
whether
it
be
like
you
know,
junit
or
or
tap.
Are
we
gonna
just
pick
one
and
bless
it
or
are
we
gonna
have
multiple
reporters
for
this.
B
So
the
discussion
so
far
in
in
the
issue
has
been
you
know.
People
seem
to
agree,
let's
just
output
tap
and
then
the
way
I
have
currently
written
it
so
far
is
it's
a.
It
basically
gives
you
a
readable
stream
that
generates
tap,
so
you
can
take
that
and
convert
it
to
you
know.
Whatever
other
format
you
want.
C
That
seems
very
reasonable
to
me.
It's
top
that
we
were
like,
I
would
say,
a
good.
A
good
smell
test
would
be
is
like
we.
We
are
the
first
customer
of
this,
so
that's
what
we
use
in
ci,
so
that
makes
a
ton
of
sense
and
that
I
think,
would
be
a
good
way
to
go
forward,
and
maybe
we
could
look
at
dog
foodiness
in
you
know
the
various
other
repos
that
we
have,
I
know
like
sitkin,
for
example,
has
a
test
suite
and
various
other
repos.
We
could
try
utilizing
this.
A
So
I'd
go
back
to
like
if
tap
is
30
mag.
Do
we
think
this
is
like
10
meg,
one
meg
kind
of
size,
just
a
just
a
guesstimate
is
what
I'm
trying
to
understand.
Oh.
B
I
would
say
far
far
under
one
meg
at
this
point:
okay,
because
we're
not
pulling
in
any
you
know
external
dependencies.
It's
all
you
know
everything
is
coming
from
core
itself.
There's!
No!
You
know
new
third-party
things
or
anything
like
that.
B
What
about
code
coverage?
Is
there
anything
for
that
at
this
point?
No,
but
that's
that's
been
discussed
on
the
on
the
issue
as
well.
That's
something
we
would
want.
I
think
we
would
probably
want
to
incorporate
something
like
c8
into
intercourse
somehow,
but
you
know
I'm
just
not
that
far
along
yet,
but
if
anyone
else
wanted
to,
you
know
explore
that
more
power
to
them.
So.
C
Isaac
may
be
a
good
person
to
hit
up
about
this.
I
was
just
recently
talking
to
him
about
some
of
the
exploration
and
tap
where
they
want
to
be
dropping.
The
use
of
nyc
and
v8
does
have
built-in
capabilities
for
this
now,
but
it
like
reports
everything
so
there
may
be
some
like
v8
related
changes
that
we
need
to
make
to
do
this
properly.
Yes,.
B
There's
an
open
issue
on
that
exactly.
I
think
he
actually
just
closed
it
and
referred
to
an
issue
in
v8
for
it.
But
yeah
isaac
has
has
seen
the
proposal
and
has
also
started
opening
some
related
issues
on
the
issue
tracker.
As
far
as
like
mocking
and
code
coverage,
and
things
like
that.
B
It's
probably
possible,
I
I
I'm
not
familiar
enough
with
all
the
third-party
dependencies
and
and
whatnot
inside
of
tap
that
would
have
to
wade
through.
That's
also
something
I'm
not
putting
my
hand
up
to
to
do,
but
I
guess
that
would
be
theoretically
possible.
B
B
And
also,
if
you,
if
you
look
through
the
the
issue
at
one
point,
I
linked
to
a
development
branch
that
I
have
of
my
own,
you
can
see
what
the
state
of
the
code
currently
is
as
well.
If
you
have
any
questions
about
that
and
I'm
happy
to
answer
any
questions
too,.
B
I
guess
if,
if
nobody
has
anything
any
other
comments,
I
guess
I'll
work
under
the
assumption
that
you
know
it's
been
brought
to
the
tsc
and
I'm
gonna
try
to
move
forward
with
with
building
something
out.
Thank
you.
E
A
Okay,
so
I
just
took
taking
some
notes
there:
okay,
well,
we'll
go
back
to
the
issues
tagged
on
the
agenda,
then,
in
the
order
that
they
were
tagged,
the
first
one
was
grant
treasurer's
the
ability
to
rerun
a
failed
ci.
D
D
The
issue
is
overloaded,
with
the
number
of
additional
suggestions,
such
as
needing
some
dedicated
effort
to
deflate
the
ci
itself,
the
scope
of
the
charging
rule
between
traj
work
versus
a
collaborator
intern
and
the
current
ability
to
run
the
first
ci
is
a
side
effect
or
it's
an
intentionally
provided
capability
to
the
triages,
renaming
the
tragic
team
and
so
many
other
things.
But
the
key
aspect
for
which
I
actually
added
the
psc
label
is
to
discuss
and
agree
on
a
policy
that
is,
should
the
triages
be
able
to
run
the
ci
at
all.
D
If,
yes,
to
what
level,
what
scope,
whether
should
be
able
to
run
the
fresh
eye
or
should
be
able
to
run
resume
ci
and
things
like
that.
D
Yeah
so
traditionally,
when
we
provide
access
to
anybody
on
the
ci
infrastructure,
practically
they
can
do
many
things.
They
can
alter
many
different
jobs.
They
can
change
the
configuration
of
the
jobs
and
things
like
that.
But
when
we
are
talking
about
access
to
the
triages,
we
are
talking
about
the
access
through
the
labels,
because
originally
the
the
labels
is
what
the
triages
have
access
to
and
with
the
invention
of.
D
Ci,
the
I
forgot,
the
actual
label
name
trigger
ci,
then
triages
are
able
to
kick
start
the
ci.
So
that
way,
I
don't
see
any
security
implications.
C
Yeah
yeah,
our
build
infrastructure
is
long
living,
so
any
bad
code
that
gets
run
in
those
environments
could
have
permanent
long,
lasting
effects
on
our
ci
infrastructure.
Now
our
ci
infrastructure
is
air
gapped
from
our
release
infrastructure
to
be
very
clear
so
and
they
use
different
vms.
C
So
the
the
risk
is
limited
to
our
test
infrastructure,
but
our
test
infrastructure
does
have
certain
credentials
in
it
that
could
be
utilized
for
evil.
I
don't
think
they
have
like
push
access
or
anything,
but
we
could
maybe
do
an
audit
of
that
and
make
sure
that
we're
comfortable
with
it
and
it
might
be
worth
just
kind
of
like
you
know,
auditing
or
augmenting
read
access
is
like,
I
think,
even
if
it
has
read
access
to
some
private
stuff,
there's
nothing.
We
have
going
on.
C
That's
so
private,
it's
an
issue
in
the
main
repo,
so
we
should
just
make
sure
that
it
doesn't
have
right
access
to
things
that
it
shouldn't
and
then
I
personally
wouldn't
see
a
problem.
D
F
A
Yeah
I'd
add
that,
like
you
know,
our
triagers
are
still
like
nominated
and
approved
right,
so
they're,
not
people
that
we
don't
know
at
all
so
seems
like
the
the
risk
is
should
be
should
still
be
fairly
low.
C
Yeah,
I
think,
like
the
only
concern
that
I
see
there
being
right,
is
that,
like
triagers,
don't
necessarily
have
the
in-depth
technical
knowledge
of
the
platform
in
the
same
way
a
collaborator
might?
But
I
think
if
we
want
to
be
pragmatic
about
it
like
how
much
in-depth
review
do,
we
think
people
always
do
and
there's
all
sorts
of
tricks.
People
can
do
for
social
engineering,
and
I
think
we
need
to
you
know
if
we
approach
this
from
zero
trust.
We
should
just
lock
down
our
infrastructure
so
that
there
isn't
like
really
really
bad
stuff.
G
A
A
C
At
a
high
level,
I
think
where
I'm
landing
on
this
is
like
any
problems
that
we
have
are
actually
infrastructure
problems,
not
trust
problems
with
these
people,
and
maybe
it's
worth
doing
like
a
review
of
our
build
infrastructure
and
what
access
it
has.
But
that
should
be
fixed
independent
of
what
we
do
with
the
triagers.
G
So
just
something
a
nature
I
understand:
if
we
are
not
giving
them
access
to
gen
games,
they
already
have
access
to
adding
labels,
so
they
can
request
ci.
I'm
not
sure
I
understand
what
we're
discussing
here.
I.
A
D
Yeah,
that's
right.
In
the
current
context,
there
are
two
questions:
one
is
yeah
ability
to
run
ci.
Did
it
come
accidentally
if
at
all
it
came
accidentally?
Are
we
okay
with
that
number
two?
If,
if
it
is
okay,
I
mean
in
theory
they
should
also
be
able
to
rerun
the
ci
just
like
they're
able
to
run
the
fresh
ci
and
right
now
we
don't
have
a
capability
or
a
label
to
do
that.
We
have
to
go
through
jenkins
workflow.
A
A
A
A
F
B
B
D
There
is
a
percentage
of
workload
that
is
run
by
default
and
not
producing
enough
result
versus
a
human.
D
A
Yeah,
I
agree
with
that,
and
I
also
like
even
them
looking
to
say
like
does
it
look
like
we've
got
this
issue
because
we
did
have
like
a
team
ci
day
a
month
or
so
ago
and,
like
I
think,
what
I
feel
out
of
that
is
like
unless
there's
issues
open,
they're
totally
ignored
the
flakes
people
just
rerun,
whereas
you
know
I
went
through
and
opened
a
bunch
of
issues,
and
at
least
some
of
those
were
investigated.
A
Okay
right
like
if
we,
if
we
just
leave
them
to
be
flaky
and
never
create
an
issue,
they'll
just
stay
flaky
in
there,
if
they're,
if
they're,
obviously
a
hardware
issue
or
something,
then
that
one
doesn't
make
sense-
and
that's
where,
like
you
were
saying
like
the
person's
a
person,
can
look
at
that
and
say
make
a
judgment.
Call
like
this
looks
like
oh
yeah.
It
was
just
a
machine's
like
it
failed
in
the
middle
of
the
run,
I'm
gonna
rerun.
A
F
But
I
think
we're
you
know
taking
this
issue
in
the
wrong
place.
I
don't
think
test
flight
connects,
should
have
any
relevance
in
prs.
F
Actually
it
should
be
there
there.
We
should
just
re-run
them,
it
should
be.
We
should
have
some
kind
of
task
on
master,
but
you
know
run
a
ci
on
master
and
see
if
that's
flaky
and
that's
where
you
know
we
should
be
sorting
out
flakiness,
not
in
different
pr's.
That
doesn't
really
actually
have
anything
to
do
with
the
fakiness.
A
F
A
A
I
agree
with
that.
I
just
like
the
bar
of
saying,
okay,
I
say
I'm
trying
to
get
my
own
pr
landed
if
it.
If
there's
two
failures,
I
I
typically
try
and
go
and
say:
okay
are
those?
Is
there
an
issue?
Yep,
okay,
I'll
restart
it?
If
not,
I'm
going
to
create
an
issue
and
yeah
it's
a
balance
like
we
can
do
nothing.
I'm
just
not
sure.
A
A
A
F
C
I
don't
think
we
need
to
block
anything
for
right
now.
Personally,
like
the
the
it's
been
working
fine
for
right
now,
I
I
don't
like.
I
don't
hear
anyone
saying
I'm
gonna
run
and
go
do
the
audit
this
afternoon,
and
I
think
it
could
both
like
be
demoralizing
to
have
things
taken
away
that
you
were
able
to
do
and
like.
I
don't
think
it's
fair
to
do
that
to
our
volunteers,
for
something
that,
like
we're
not
going
to
be
having
a
timeline
on
doing.
G
So
so
I
guess
the.
If
anyone
wants
to
champion
making
a
level
to
re
resume
the
ci
it
would
be
welcomed,
but
maybe
the
their
effort
would
be
better
on
making
the
ci
less
flaky.
A
D
A
And
but
it
does
take,
I
think,
like
a
conservative,
concerted
effort
or
something
that
helps
to
to
sort
of
make
it
part
of
either
needs
like
concerted
efforts
or
somehow
you
know
a
little
bit
of
tax
every
time,
you're
doing
the
other
work.
One
of
those
two
are
going
to
be
needed
to
to
really
change
it,
because
we
don't
have
like
somebody,
we
can
say:
hey
it's
your
job
to
go,
make
this
green
right.
D
A
Yeah
and
you
know
sometimes
it's
sometimes
you
can
add
value
by
tracking
down
like
okay,
who
changed
the
test
last
or
who
knows
about
that
like,
for
example,
you
know
one
of
the
ones
that
I
opened
an
issue
for
was
related
to
the
recursive
removed
here.
A
So
I
kind
of
pinged
the
tooling
theme
and
said:
hey
we're
getting
this.
These
pers
pervasive
failures.
Anybody
you
know,
can
you
take
a
look?
Otherwise
you
know,
maybe
I'm
just
going
to
exclude
it
for
now
and
in
the
end,
then
we,
you
know,
I
think
ben
benco
took
a
look
and
fixed
it
and
you
know,
got
the
test
working
so
that
that's
kind
of
thing
where
you
know
people
can
can
invest
some
effort
without
necessarily
fixing
it,
but
also
help
bringing
focus
to
it.
D
A
D
I
don't
think
so,
because
those
are
transactional
questions
not
necessarily
related
to
the
policy.
For
example,
does
the
triage
team,
the
renaming
of
the
trash
team
as
a
collaborator
in
turn,
makes
sense?
A
A
E
H
I've
just
joined
so
apologies
I
had
to
be
in
another
meeting.
I
did
put
a
little
note
in
the
meeting
saying
that
I
for
this
labeling
issue.
I
don't
object
to
the
labels.
I
just
pointed
to
to
point
out
that
it's
going
to
be
a
lot
more
complicated
to
implement
behind
the
scenes
than
the
existing
request.
Ci
label
so
request
ci,
you're,
basically
just
saying
to
jenkins.
I
want
to
start
a
build,
but
resume
requires
you
to
basically
find
the
existing
build
that
you
want
to
resume.
So
somebody
yeah.
H
H
And,
as
far
as
I
know,
I
don't
think
it
requires
any
more
build
privileges,
so
I
think
it
should
be
doable
if
it's
doable
at
all
via
changes
to
no
no
call
utils,
and
so
at
the
moment
the
builds
are
being
triggered
by
node
core
utils.
D
If
somebody's
willing
to
implement
richard,
are
you
happy
to
mentor.
H
I
don't
know
if
it's
possible,
because
at
the
moment
starting
a
ci,
there's
a
there's,
a
jenkins
api
endpoint
for
it,
and
I
don't
know
if
there's
an
equivalent
for
resume
because
resume
is
provided
by
one
of
the
plugins
we're
using,
and
I
I
don't
know
if
there
is
a
api,
so
I
am
willing
to
help
mentor,
but
I'm
not
in
a
position
where
I
could
actually
tell
you
that
it's
even
possible.
H
H
A
A
You
know.
I
think
the
let's
see
build
is
one
that
I
think
richard.
We
still
need
to
figure
out
what
it
all
would
affect
the
snap
one.
I
think
you
volunteered
to
look
to
look
at
that.
One
right.
H
Yeah,
I
think
I've
got
a
reasonable
idea
in
theory,
but
I've
never
really
fiddled
with
the
snap
side
of
things,
but
I
think
in
theory
I
know
what
needs
to
change
and
the
same
same
with
unofficial
builds.
I
I
think
I
know
what
needs
to
change
and
unofficial
builds
would
require
some
deployment
changes,
as
well
as
the
repository
being
updated.
A
H
A
A
I
think
rich
hume
did
you
you
added
to
the
tse
label.
Do
you
want
to.
C
I
A
I
Was
also
me,
that's
just
that
was
over
72
hours,
nobody
objected
so
antoine
and
I
should
probably
schedule
an
onboarding
or
something
there
might
not
even
need
to
be
an
onboarding
session
actually
but
yeah.
I
need
to.
I
need
to
go
through
the
onboarding
checklist
and
make
that
happen,
and
thank
you.
Thank
you.
Thank
you
antoine.
A
A
I
So
do
we
want
to
go
back
to
email,
yeah,
okay,
let's
go
back
to
clean
up
yep
yeah
yeah,
so
this
is
just
a
bunch
of
things
that
need
to
happen
in
the
in
the
in
the
email
stuff,
and
I,
why
did
I
add
tsc
agenda?
Oh
oh,
just
just
just
informational
seems
like
we're
gonna,
be
making
significant
change
like
getting
rid
of
the
ctc
emailing
list,
for
example,
which
I
think
we
already
did.
It
seems
like
you
know.
I
People
should
know
that
that's
happening.
So
that's
all
there
isn't
anything
on
here
to
discuss.
I
don't
think
and
no
decision
to
be
made
today
just
for
information
purposes
and
I'm
gonna
go
ahead
and
remove
the
tse
agenda
label
at
this
time
sounds
good.
E
A
I
A
I'm
guessing
antoine
put
this
on
the
list.
I
think
we
discussed
it
in
the
past.
I
think
I
seem
to
remember
us
like
saying:
let's
just
go
with
it,.
I
I
It's
like
a
new
user
or
org
for
automation.
The
proposal
from
from
you,
michael
and
that
yeah
was
also
a
seconded.
A
A
Yeah,
like
we,
we
had
a,
we
had
a
user,
but
it
was
never
intended
to
be
used
for
publishing
and
it's
probably
best
to
figure
out
the
and
we've
had
discussions
like.
Should
we
have
an
org
and
all
that
so
that
you
know
this
might
best
drive
that
versus
just
using
something
where
it's
actually
even
called
mpm
found
it
or,
I
think,
node
foundation,
which
you
know
we've
had
people
say
you
should
rename
that
okay,
so
I
don't
know
that
there's
any
reason
to
leave
it
on
the
tsc
agenda.
A
E
A
I
Got
that
right
and
I'm
taking
it
off
because,
basically
there
is,
you
know,
nobody's
objecting,
there's
some
thumbs
up,
I'm
in
favor
and
I
think
it's
just
a
matter
of
someone
probably
tierney
doing
the
work
to
actually
make
it
happen
and
asking
for
help
from
the
right
people.
But
I
don't
think
there's
any
reason
for
it
to
be
on
an
agenda
item.
I
think
it's
good
to
go.
A
Okay
sounds
good,
okay,
so
now
that
takes
us
down
to
the
end
of
the
issues,
tag
for
the
agenda
and
we
still
have
a
few
minutes.
So,
let's
flip
over
to
the
strategic
initiatives.
I
I
can
get
my
medals
to
click
so
there's
there's
the
next
10,
which
you
put
the
update
in
the
in
the
issue
for
and
then.
I
Put
the
put
the
currency
update
in
the
issue,
yeah.
A
Okay,
I'm
just
quickly
gonna
get
there
so
that
I'll
have
my
context,
strategic
initiatives
pulling.
A
The
sure
why
don't
you
read
michael's
and
I
can
I
can
go
through
the
one
that
I
do
what's
that.
I
Go
ahead,
I
thought
somebody
else
tried
to
say
something:
okay,
on
v8
currency,
v8,
9.9
and
later
are
blocked
on
a
windows,
compiler
issue
and
michael
says
that
they
haven't
found
any
work
around
for
it
yet,
and
there
is
a
v8
issue
in
the
v8
issue
tracker,
but
no
comment
on
it.
Yet
so,
if
any
windows
or
v8
people
want
to
take
a
look
at
that,
don't
let
me
stop
you
and
that's
it.
A
Yeah
on
the
next
10,
the
next
10
initiative-
I'm
just
going
to
go
back
to
my
notes
here.
A
So
the
last
in
the
last
meeting,
the
a
lot
of
the
discussion
was
around
getting
ready
for
the
next
a
couple
deep
dives,
so
we're
planning
at
the
next
virtual
summit
on
seventh
of
april
on
wasm
and
security.
So
people
are
interested
in.
That
would
be
great
to
see
you
there
and
security
is
in
in
in
the
sense
of
things
like
you
know,
a
security
model
and
policies,
as
opposed
to
you,
know
our
security
releases
or
anything
like
that.
A
We're
also
thinking
for
the
open.js
world
that
it
would
be
great
to
have
some
sessions
during
the
collaborator
summit.
So
that's
where
we
planned
the
the
esm
and
observability
as
as
two
deep
dives,
as
well
as
we're
hoping
to
like,
if
there's
a
common
track,
to
be
able
to
have
something
where
we
introduce
the
overall,
you
know
concept
and,
what's
being
worked
to
the
to
all
the
collaborators,
to
to
get
broader
visibility
on
that.
A
Looking
back
on
some
of
the
previous
work,
since
this
is
the
first
update
in
terms
of
suitable
types,
you
know
the
outcome
of
that
was
that
we
wanted
to
work
towards
improving
how
we
can
automatically
generate
our
json
documentation
and
its
contents.
A
And
you
know
the
next
step
is
to
peer
in
some
changes
to
the
style
guides,
and
so
that's
being
worked
in
terms
of
single
binary
exes.
We
had
a
good,
great
discussion
in
the
mini
summit.
We
came
up
with
what
we
believe
is.
You
know
the
way
that
node
could
support
that,
but
we
don't
necessarily
have
a
champion
to
push
that
forward.
So
I
don't
think
there's
any
active
work,
something
I
might
try
still
do
is
to
land
somewhere
in
the
documenting.
A
What
the
agreement
was
in
terms
of
you
know
what
would
make
sense.
Modern
http,
you
know
the
one
of
the
the
key
things
that
came
out
of
that
was
to
land,
a
fetch,
which
you
know.
Indeed,
she
was
landed
to
support
that
and
still
being
tweaked
there's
some
discussions
around
the
implementation,
but
that
that
was
a
good
outcome
and
then
for
documentation.
A
You
know
there's
a
pri
open
just
in
terms
of
one
of
the
outcomes
from
the
the
mini
summit,
discussions
about
having
examples
for
all
of
the
the
methods
functions
and
then
the
other
thing
that
that
was
sort
of
a
high
priority
was
to
document
the
metadata
and
its
usage.
So
those
are
sort
of
two
things
that
are
in
the
list
of
work
items.
A
E
A
I
Just
a
note
for
tsc
members
that
daylight
savings
time
is
about
to
start
in
the
united
states.
I
think
this
weekend
or
next
weekend.
I
think
this
weekend
it's
this
weekend,
which
means
that
it's
probably
about
time
to
go
into
the
spreadsheet,
and
you
know
change
your
times
if
you're
going
to
be
affected
by
daylight
savings
make
sure
your
times
are
right.
I
Out
right
now,
I
just
wanted
to
tell
people
that
that
it's
a
good
time
to
start
thinking
about
going
to
the
spreadsheet,
because
I
know
it's,
you
know
a
tedious
task
for
some
people,
so.