►
Description
To learn more about critical open source JavaScript projects like Appium, Dojo, jQuery, Node.js, and webpack, and 27 more checkout The OpenJS Foundation: https://openjsf.org/
A
A
B
Biggest
breaking
news
is
The.
Sovereign
Tech
fund
out
of
the
German
government
is
funding
the
openjs
foundation
to
the
tune
of
almost
just
a
little
over
nine
hundred
thousand
dollars
a
long
time.
Community
open
source,
Community
folks,
Adriana,
Fiona
and
Tara
have
been
sort
of
championing
that
work
inside
the
government,
and
this
is
really
this-
is
the
largest
one-time
government
contribution
to
any
open
source
project
that
we
know
of,
and
that's
not
of
course,
just
one
project.
B
We
have
41,
but
hopefully
everything
that
we
do
will
scale
more
broadly
to
all
of
the
JavaScript
projects
in
the
world.
Joseppi's
going
to
be
taking
a
lot
of
the
work
from
openssf
through
the
openjs
security,
collab
space
and
customizing,
that
for
JavaScript,
we'll
have
Audits
and
we're
going
to
have
shiny
new
infrastructure
for
a
lot
of
our
projects,
which
is
sorely
needed
because
many
have
been
around
for
a
long
time.
So
exciting
news.
A
Is
huge
news
I'm,
so
excited
I
mean
this
is
going
to
be
such
a
big
difference
maker
for
some
of
our
projects
like
jQuery
that
have
had
to
sustain
and
change
and
improve
infrastructure.
That's
such
a
big
lift
for
projects,
and
so
just
Echo
all
of
the
excitement
and
gratitude.
So
tell
your
friends,
you
know
and
and
repost
for
us.
If,
if
then
you
don't
mind,
that's
a
big
announcement,
so
other
just
reminder:
slash
announcement,
T
things,
there's
something
happening
next
week:
it's
open.js
world
and
the
collab
Summit.
A
So
if
you
are
going
to
be
in
Vancouver,
we
hope
to
see
you
there
on
Tuesday.
There's
lots
going
on
if
you
can't
make
it
to
Vancouver
some
of
the
collab
summit's
going
to
be
live
streamed.
Some
of
the
virtual
talks
will
be
there
for
the
event,
of
course,
we'll
record
a
lot
of
the
talks
and
have
those
up
later.
So
it's
gonna
be
a
good
time
and
if
you're
around,
let
us
know
we'd
love
to
say
hi
in
person.
A
The
other
thing
that
we
are
reminding
folks
is
that
the
the
secure
the
web
forward,
Workshop
that
we're
doing
with
w3c
and
open
ssf
and
owasp
we're
still
sourcing
proposals,
for
that
would
love
your
help
connecting
with
folks
who
have
something
you
know
to
to
say
something
to
contribute.
Some
big
idea,
because
securing
the
web
is
a
really
important
effort.
A
It's
going
to
take
all
this,
so
we're
gonna
have
a
little
session
in
London
in
June
and
would
like
to
have
some
really
great
ideas
and
thinkers
there
for
that
so
secure
the
web
forward
and
then
other
kind
of
fun
thing
to
celebrate
the
30th
anniversary
of
Tim
berners-lee,
releasing
the
the
web
platform
effectively
as
royalty-free
platform.
It
was
yesterday
or
day
before
yesterday.
It's
just
something
fun
to
to
acknowledge,
because
I
think
we
can
all
agree
that
royalty-free
standards
have
changed
our
lives.
A
C
A
A
D
The
first
thing
is,
we
agreed
that
we
have
a
lot
of
work
and
we
need
more
input
from
more
people.
Sometimes
we
lack
experts
on
all
the
topics
that
matter
in
a
design
review,
for
example,
right
now
we
don't
have
an
accessibility
expert,
we
don't
have
a
security
expert
and
so
on.
We
have
very
few
API
design
people
and
so
on.
So
we
are
going
to
ask
the
AC
for
three
more
seats
and
we
actually
had
Florian
from
the
AC.
In
the
from
the
a
b
sorry
I
meant
a
b.
D
D
We
are
considering
like
10
different
names
for
this,
like
liaison
or
associate
or
whatever,
like
there's
many
different
names,
but
basically
these
were
sort
of
this.
This
will
sort
of
be
lightweight
tag,
members
that
we
can
appoint
to
also
to
to
fill
in
gaps
and
there's
multiple
reasons
for
the
for
these,
like
what
came
up
was
one
of
the
one
of
the
members.
D
One
of
one
of
the
members
in
the
tag
today
wants
to
retire
at
some
point,
he's
been
in
the
tag
for
way
too
long,
but
he
he
wants
to
sort
of
train
his
successor,
but
right
now
nobody
really
gets
exposure
to
how
the
tag
works
on
the
inside
until
they're
actually
elected
to
it.
So
part
of
part
of
this
would
be
to
like
train
people
that
might
eventually
make
it
to
the
tag
or
as
an
additional
mechanism
to
get
wider
input
to
get
more
eyes
on
design
reviews,
and
this
will
be
for
a
year.
D
It
will
end
either
after
the
year
passes
or
if
they
get
elected
to
the
tag
each
tag
member
can
sponsor
and
I
put
sponsoring
quotes
because
it's
not
Financial,
but
each
tag.
Member
can
sponsor
one
Deputy
tag
member,
but
of
course
that
can
change
like
I
might
sponsor
someone
next
year,
someone
can
sponsor
them
and
so
on
and
the
other
thing
we
discussed
quite
a
lot.
D
So,
as
you
may
know,
I
recently
joined
tc39
and
one
of
the
reasons
that
I
that
I
joined
was
to
facilitate
closer
collaboration
between
tag
and
tc39.
I
feel
that
today
we
have
multiple
standards,
groups,
designing
JavaScript
apis
for
the
web
platform,
and
they
are
they're
not
really
working
together
very
much.
They
have
they
operate
under
entirely
different
design
principles
and
so
far
we've
had
a
lot
more
ywg
input
in
our
design.
D
Principles
than
we've
had
tc39
input
so
that,
like
there's
the
occasional
tc39
person
that
floats
by
but
like
it's,
it's
very
rare
and
you
can
actually
see
this
in
the
apis
like
they
are
they're
very
different,
like
you
can
look
at
the
design
of
an
API
and
you
can
tell
if
it
was
designed
by
ywg
or
tc39.
I
think
that
is,
that
is
wrong,
that
hurts
developers.
In
the
end,
this
lack
of
consistency.
D
So
one
of
the
things
in
general
in
the
abstract,
the
group
agrees
that
we
should
have
more
tc39
input,
the
devil's
always
in
the
details.
One
thing
we
agreed
to
do
was
to
have
a
tc39
Tracker
label
in
our
design
principles
repos
for
things
that
we
would
like
that
we
think
tc39
input
would
be
useful
on.
D
Another
thing
is
right:
now
our
design
principles
document
is
very
web-centric
and
JavaScript
is
more
broad
than
that
and
I
think
we
should
try
as
much
as
possible
to
be
inclusive
of
non-web
use
cases,
especially
like
we
have
a
lot
of
design
principles
that
are
around
designing
JavaScript
apis.
These
do
not
necessarily
just
apply
to
web-based
JavaScript
apis.
They
could
easily
apply
to
other
use.
Cases
such
as
node.js
apis,
so
I
suggested
that
we
can
reward
our
principles
to
make
them
more
inclusive
of
these
use.
Cases
like,
for
example,
right
now.
D
A
lot
of
principles
begin
with.
This
is
how
you
define
this
in
web
IDL
and
I
think
this
makes
them
a
more
less
comprehensible
to
developers,
because
developers
don't
know
how
web
ideal
works
and
these
these
kinds
of
API
design
principles
would
be
useful
for
developers
as
well
like
we
have
an
ongoing
project
to
create
a
subset
of
these
principles
for
targeted
to
develop
developers,
but
also
centering
them
around
web
IDL
means
that
people
designing
apis
that
don't
use
web
IDL
also
can't
really
follow
these
principles,
so
I
did
face
some
pushback
on
that.
D
D
Each
principle
like,
for
example,
I
I,
submitted
a
PR
as
like
an
example,
to
have
something
concrete,
rewarding
an
existing
principle
to
sort
of
replace
the
wording
around
web
ideal
attributes
and
convert
it
to
wording
like
JavaScript
accessors,
and
it
turned
out
that
even
people
in
the
room
were
not
familiar
with
the
term
JavaScript
accessor,
so
that
kind
of
fell
flat
because
then
they
were
like
well
browser
people.
Designing
apis
will
not
understand
this
so
yeah.
That
is
an
ongoing
effort.
D
E
Yeah
I
was
just:
why
are
people
that
don't
write
a
language
X
designing
apis
for
a
language
X?
That
seems
like
a
guaranteed
way
to
make
a
really
crappy
unimatic
API
like
if
they
don't,
if
they're
not
familiar
with
JavaScript,
they
are
not
qualified
to
make
JavaScript
apis.
What
I
would
I
would
say
and.
E
I'm
fine,
with
like
web
ideal
existing
as
a
system
to
codify
the
way
they're
written
but
like
familiarity
with
web
IDL,
is
like
shouldn't,
be
a
requirement
to
write
apis
familiar
with
JavaScript
should
be
I.
Don't
know
that
like
that,
like,
as
far
as
being
more
inclusive
like
I,
think
that's
a
big
point
that
needs
to
be
considered
and
I
think
another
one
is
that
a
lot
of
web
apis
seem
designed
from
a
mindset.
E
That's
that's
sort
of
inferable
from
the
discussions
of
the
web
is
the
most
important
thing
and
whether
this
is
true
or
not,
shouldn't
be
relevant
and
tc39
doesn't
tries
not
to
I,
think
have
that
mindset,
and
that
is
how
you
get
to
be
more
inclusive
and
so
there's
a
lot
of
web
apis.
That,
on
in
a
universal
mindset,
are
bad.
E
It
might
be
great
for
the
web,
but
like,
like
fetch,
made
a
few
decisions
that
could
have
been
made
differently
and
it
would
have
been
a
perfectly
Universal
tool
and
instead
it's
something
that
node
and
Deno
are
shipping,
but
it
can
never
match
the
web
one,
and
somebody
like
that
is
going
to
create
bugs
for
people,
but
like
I,
don't
know,
I
I
would
love
to
see
more
inclusive,
API
design.
I
just
think
that
it's
really
important
that
that
folks,
who
may
have
a
default
Assumption
of
their
correctness,
should
re-evaluate
that
assumption.
C
I
I,
don't
think
I
can
a
chart
on
here,
because
we
we
do
have
a
lot
of
implementers
in
the
tc.10
panel
to
who
definitely
understands
JavaScript
in
and
out,
and
they
are,
they
are
implementing
things
on
the
browser.
So
there
is
an
understanding
of
how
JavaScript
works
and
which
is
essential
and
also
like,
for
example,
times
even
folks
are
kind
of
confused.
Whether
this
is
part
of
tc39
or
is
this?
Is
this
part
of
w
what
WG
like
when
we
have
folks
putting
up
proposals
or
discussing
in
forums?
C
We
normally
tend
to
redirect
them
that
hey
this
is
this
APA
belongs
to
probably
what
WG
or
either
way
around
right,
but
I
I
think
we
should
have
Synergy
there
saying
that
we
work
together
and
and
we
might
implement
it
independently,
but
while
at
least
solutioning
or
coming
up
with
a
design,
if
we
work
together,
it
would
be
a
better
place,
for
example
the
URL
API
too
right.
Where
should
it
decide
or
what
are
the
like?
The
patterns
that
it
applied,
like
so
Mike
fetch
as
Jordan
mentioned?
A
But
let's
get
into
some
details
like
what
is
it
that
we
can
do
to
like
support
this
direction
for
the
tag
it
sounds
like
you
know,
there's
some
energy
I
hate
to
see
it
stall
because
we
don't
know
where
to
place
the
apostrophe
on
a
sentence
or
something
like
that.
So
yeah,
that's
my
my
follow-up
question.
D
That
is
an
excellent
question.
To
be
honest,
I
haven't
really
thought
about
this
I
mean
openjs
already
has
a
lot
of
tc39
members,
the
more
they
can
get
involved
the
easier
it
will
be
to
make
the
case
that
these
principles
should
be
more
inclusive
of
these
use
cases.
But
apart
from
that,
I'm,
not
quite
sure
I
will
think
about
this
and
post
with
ideas.
C
Right
I
just
want
to
add
this
example,
for
we
had
the
the
add
accessor
right,
which
got
influenced
more
from
how
what
WG
implemented
right
from
the
web
implementation,
which
we
took
the
good
parts
and
improvised
The
Proposal,
so
that
it
would
be
great
to
see
more
such
instances
where
we
are
taking
good
parts
from
what
the
the
web
platform
has
implemented
on
tc39
and
the
other
way
around.
That
would
be
really
great
to
see.
I
think
there
are
few
such
instances.
C
E
Right
yeah,
it's
not
that
they're
all
bad!
It's
just
like
there's
like
you're
talking
about
API
design
and
consistency
and
the
consistency.
That's
important.
That's
important
to
me
is
consistency
with
the
language
and
with
the
ecosystem,
and
that
is
something
that
far
eclipses
the
web's
built-in
apis
right.
But
to
your
point,
familiarity
matters
a.
D
I
completely
agree,
but
I'm
not
sure
how
we
could
reverse
that,
given
that
it's
it's
browser,
Engineers
doing
writing
these
apis
I
mean
we
do
stop
or
iterate
on
some
of
these
in
design
reviews
like
if
they
submit
a
review
for
a
JavaScript
API
that
is
totally
inconsistent
with
the
web,
then
you
know
they're
going
to
get
the
feedback.
That
here
are
some
ways.
You
can
change
this
to
be
more
consistent
with
the
way
the
web
works,
but
also
often
when
they
submit
a
design
review
for
an
API.
That
has
a
bunch
of
issues.
D
It
is
it's
easy
to
get
lost
in
some
of
the
issues,
especially
based
on
the
expertise
of
who
is
doing
the
review,
because
it's
not
usually
the
entire
tag,
doing
a
review.
It's
it's
certain
people.
So,
for
example,
there's
people
in
the
tag,
that's
that
that
specialize
in
security
and
privacy-
and
they
might
look
at
these
aspects
closer
and
sort
of
Miss,
any
API
design
issues
that
the
the
API
might
have-
and
this
happens
a
lot,
especially
since
we
have
so
much
workload.
Hopefully
getting
more
people
will
help
with
that.
A
bit.
E
D
I
agree
with
you
but
like
if
their
employers
are
assigning
them.
This
task
and
their
Employers
in
general
are
pretty
unwilling
to
pay
people
to
develop
standards
it.
So
a
lot
of
Standards
work
tends
to
fall
on
browser
developers
like
there's
very
there's
very
few
people
working
on
standards
full-time
even
at
the
big
companies.
A
A
It
was
just
I
was
gonna,
say
like
it
strikes
me
as
like
a
a
product
compatibility
problem
that
they're
solving
like
first
and
and
foremost,
and
then
sort
of
the
everything
else.
From
that
standpoint,
just
sort
of
is
is
like
Downstream,
where
what
we
are
advocating
for
in
our
our
position
is
more
like
a
user-centered.
You
know
approach,
which
is
not
always
the
way
that
big
product
companies
think
about
this.
So
at
this
level,.
E
D
E
E
D
E
D
Painful
the
API
is
is
something
that
hits
them
way
later
when
it's
too
late
to
change
it
at
that
point
also
true,
but
I
wanted
to
say
to
Jory
the
the
user.
The
user-centered
aspect
of
this
is
like
that.
That
is
one
of
the
things
that
we
are
trying
to
do
with
tag.
Reviews
like
this
is
a.
This
is
an
explicit
goal
that
we're
supposed
to
review
for,
like
what
are
the
user
needs?
Does
the
solution
satisfy
the
user
needs
well
or
at
all
like?
D
A
So
this
is
like
exactly
why
we
convene
is
to
tackle
this
kind
of
conversation
among
our
our
groups
among
our
projects,
I'm
thinking
about
just
the
timing,
because
next
week
is
also
the
advisory,
Council
or
AC
meeting
for
advisory
committee.
I,
don't
actually
remember
what
C
stands
for
anymore,
come
to
think
of
it.
A
There's
too
many
acronyms
the
the
AC
meeting
is
in
in
France,
and
this
is
a
kind
of
a
segue
to
one
of
our
other
agenda
items
which
is
sending
Kobe
as
an
alternate
next
next
week.
Is
there
anything
that
we
can
do
potentially
to
you
know,
help
Foster
and
move
that
conversation
along
in
person
next
week?
If
we
have
a
delegate,
there
present
that's
another
kind
of
question
in
terms
of
support.
F
F
The
user
I
mean
sort
of
jump
on
the
the
whatever
the
RFC
is
about
priority
of
users,
and
that's
that's
a
meta
conversation
going
on
at
w3c
and
and
making
it
more
operational.
What
it
means
to
pay
attention
to
user
needs
or
products.
Excuse
me,
prioritize
user
needs
over
the
you
know,
C
plus
plus
implementer,
who
is
looking
at
the
web.
F
I
mean
but
yeah
having
having
a
sort
of
you
know
mini
position
paper.
You
know
on
to
the
extent
that
we
do
we
well
either
you
or
whoever
goes
to
w3c
meetings,
says
here's
sort
of
the
list
of
issues.
The
top
three
issues
are
our
members
care
about,
and
here's
a
straw
man
proposal
for
how
we
could
do
better
I
mean
that
would
that
would
be.
That
would
be
great,
I.
Think
yeah.
F
Now
that
the
a
now
that
WGC
is
getting
out
of
its
sort
of
you
know,
you
know
staring
its
name
on
what
it
is,
so
that
it
can
figure
out
how
to
actually
get
organized
there.
That's
well
more
I
think
we're
we're
past
we're.
You
know
it.
That's
got
momentum
now
and,
and
hopefully
the
AC
and
the
a
b
can
focus
on
actually
improving
the
process
and
the
the
product
and.
F
B
You
know,
and
if
you
all
could
quantify
the
kind
of
feedback
you'd
like
to
get,
we
could
do
some
spot
surveys.
We've
been
doing
that
for
a
few
years
with
the
node.js
next
10
project,
we've
done
it
for
fastify,
we'll
get
up
to
like
2
000
responses
from
our
surveys
on
social.
So
if
you
knew
the
the
exact
kind
of
feedback
you'd
like
to
receive,
we
do
have
some
open-ended
questions,
but
a
lot
of
them
are.
F
F
Two
minutes
you
gotta
send
people
to
meetings
with
and
then
with
with
an
agenda
you
gotta
file
issues
in
GitHub,
you
gotta
rally,
you
don't
got
to
work
the
back
channels
to
make
sure
people
understand
what
the
what
the
concern
is
and
and
and
make
sure
that
proposals
you
know,
are
constructive.
So
yeah
there's
a
lot
of
work,
a
lot
of
work
behind
the
scenes
to
to
make
this
kind
of
stuff
happen.
It's
not
just
filing
issues
or
going
to
meetings.
F
D
A
I
I
think,
though,
I
think
one
of
one
of
the
points
that
Mike
Champion
is
making
which
I
really
agree
with
is
like
we
send
people,
but
we
we
don't
always
send
them
with
a
really
strong
point
of
view
to
like
advocate
for
or
a
really
strong,
well-defined
problem
to
say
this.
This
is
the
pain
it's
just
sort
of
like
we're
showing
up,
because
we
all
have
generalized
pain
and
we
go
to
the
doctor's
office
and
we're
like
come
my
knee
hurts
kind
of,
but
you
know
that
could
be.
A
A
That's
that's
where
I,
where
my
mind
goes
because
I
think
typically
there's
a
lot
of
alignment
with
what
we're
trying
to
what
we
idealize
and
what
we
want
to
accomplish,
but
not
a
lot
of
sensibility
about
like
what
the
facility
solution
is
or
really
what's
the
source
problem
is
that,
like
the
you
know,
first
order
problem
or
is
that
more
of
an
after
problem
of
something
else?
You
know
that
I
I
don't
know,
that's
the
way,
I
look
at
it.
That's
my
two
cents
that.
F
Makes
sense
yeah
exactly
yeah
I
mean
the
the
fact
that
you
know
we're
talking
about
the
the
tag
meeting
that
and
the
person
we
sponsor
on
the
tag
is
leading
that
discussion
and
you
know
I
think
the
next
step
would
be
for
us
or
you
know,
for
the
community
that
that
this
group
represents
to
you
know
help
you
know,
give
give
Leah
some.
You
know
some
bullet
points
talk
some
talking
points
some
examples,
some
strawman
proposals
for
how
you
know
how
this
could
work
work
better
and
yeah.
F
F
F
We
we,
the
community,
not
necessarily
open
Jos
foundations
anyway
I'm
just
kind
of
off
the
top
my
head,
but
there's
and
I,
wouldn't
wouldn't
at
all
minimize
the
importance
of
just
having
these
kinds
of
conversations
to
make
sure
that
the
people
in
the
TC
939
world
and
the
w3c
world
are
talking
to
each
other
and
understanding
points
of
view.
And
aren't
you
know
getting
into
turf
wars
about
silly
things.
A
I
need
to
kind
of
segue
us
to
the
other
agenda
topics,
but
this
has
probably
been
the
the
most
valuable
use
of
our
time.
I
will
say
on
the
point
that
you're
just
making
my
Champion
that's
what
makes
this
group
this
this
group
so
unique
and
I
think
very
potentially
important
and
and
helpful
here,
because
we
are
bringing
w3c
developers
and
tc39
developers
into
just
giving
them
the
space
here
through
our
projects.
A
To
talk
about
these
kinds
of
things
is
a
great
start
to
the
problem,
and
we
should
really
highlight
that
for
all
the
for
these
communities.
Let
me
ask
really
quickly
if
there
were
any
other
updates
from
any
of
our
other
Liaisons
this
week.
Was
there
any
any
news
from
tc39
to
share
Jordan
or
Richard
or
Joe
I.
E
E
A
That
so
to
the
point
about
sending
people
to
participate
and
and
raise
our
concerns,
we
have
a
couple
of
issues
for
for
w3c
and
Toby.
Toby
had
opened
an
issue
and
a
pull
request
to
be
designated
as
the
IAC
alternate
for
next
week's
face-to-face
meeting.
After
some
like
spelunking
through
the
w3c's
member
portal,
we
figured
out
how
to
do
that
and
he's
been
tapped
as
the
the
alternate
AC
rep
and
now
I
think.
A
A
F
I
didn't
see
anything,
you
know
the
obvious,
but
I
think
that
going
forward,
you
know
whoever
wants
to
represent
and
possibly
including
you
really
should
have.
You
know
at
least
three
things
they're
trying
to
accomplish
I
mean
that's
what
I
had
to
do
when
even
when
I
was
a
AC's
Tech
rep
for
a
big
tech
company,
I
had
to
say
here's,
here's
what
I'm!
F
It
doesn't
mean
you
know,
I
can't
you
know,
but
but
anyway,
that
that
that's,
what
makes
sense
to
me
is
going
forward.
People
who
want
to
represent
us
take
the
leadership
of
coming
up
with
say
at
least
three
things.
They're
trying
to
accomplish,
which
might
be
information
might
be,
advocacy
might
be.
F
A
I,
like
the
framing
of
like,
what's
our
engagement
plan
for
this,
you
know
like
clearly
and
that's
applicable
to
to
everything,
and
we
should
work
that
into
our
our
terms.
For
SME
participation
is
like
the
engagement
plan,
so
I
I
think
that's
a
great
framing,
because
it
could
be
three
small
things.
It
could
be
one
big
thing:
it
could
be
one
big
proposal,
I
I,
think
that's
great!
That's
the
pattern.
A
F
A
F
A
A
Evidently,
not
so
I
guess
the
I'll
close
this
issue
and
we
will
open
a
new
issue
for
the
the
nominees
and
discussion
on
on
our
ballot.
For
that
particular
vote,
cool
all
right.
So
then,
then,
the
next
thing
that
Toby
had
opened
on
the
repo
was
for
the
open
source
initiatives
rep,
which
was
a
liaison
relationship.
We
established
in
20,
like
20
or
somewhere
around
there
with
Miles,
as
our
first
representative
miles,
has
taken
a
step
back
from
his
open
source
engagement.
A
To
do
many
other
important
things
like
raise
small
human
beings.
So
we
have
a
opening
there
and
he's
he's
resigned
in
a
in
a
previous
previous
issue.
So
I
guess
the
question
here
is
like
what
do
we
I
mean
I'm,
not
on
principled,
on
the
face
of
it,
like
opposed
to
say,
yeah,
we'll
put
someone
new
in
as
our
designate
to
to
represent
us,
but
is
there
anything
that
we
are
to
to
your
point
about
engagement?
Is
there
anything
that
we're
actively
wanting
to
engage
with
the
OSI
on
today.
A
A
So
I'm
going
to
take
silences
and
negatives
I'm,
not
sure
that
this
has
been
an
acute
problem
for
us
that
we
haven't
had
somebody
representing
us
or
reporting
back
I
will
say
that
that
probably
we
could
do
a
better
job.
You
know
surfacing
any
relevant
Communications
from
The
OSI
to
our
projects,
but
honestly
I'm
not
sure
what
those
would
have
been
in
the
last
couple
years
beyond
the
usual
kind
of
organizational
stuff.
F
F
A
And
I
I,
don't
think
you
know,
there's
anything.
You
know
wrong
with
us
as
a
foundation
saying
you
know
we
want
to
as
because
it's
it's
fairly
easy
to
show
support
for
a
like
a
sibling
or
cousin
org.
That's
also
trying
to
uplift
open
source
uplift
developers,
like
you
know
it's
nice
to
kind
of
do
a
little
co-market
thing
right
there,
but
like
that's
different
from
and
we're
going
to
send
a
representative
to
go
like
engage
with
policy
or
engage
with
your
organization
in
a
in
some
kind
of
meaningful
way
and
I.
A
A
We
will
do
a
couple
things
at
openjs
world.
Next
week
and
I
welcome
your
input
on
the
issue,
if
you
have
anything
that
you'd
like
to
to
highlight
in
particular,
but
one
is
at
the
collab
Summit
a
session
on
just
our
our
working
group
and
a
little
bit
of
just
news,
how
we
work
like
things
that
will
be
that
we
champion
and
how
we
support
the
projects.
A
We've
totally
out
of
time
to
talk
about
what
173,
but
that's,
okay.
The
last
thing
is
just
we've
got
the
minutes
from
the
previous
meeting,
also
up
as
a
pull
request.
If
you
haven't
had
a
chance
to
look
at
those,
please
do
so
and
and
plus
one
and
then
we'll
get
those
merged
in
so
really
full
session
today.