►
From YouTube: OpenSSF Vulnerability Disclosures WG (March 22, 2023)
A
A
A
C
C
A
A
All
right
friends,
yeah
clock
on
the
wall
says
it's
three.
After
the
top
of
the
hour.
Welcome
to
the
March
22nd
edition
of
the
vulnerability
disclosures
working
group,
Happy
Spring
to
those
of
you
that
are
in
Spring
season,
do
we
as
we
start
off,
do
we
have
anyone
that
is
interested
in
helping
us
take
notes
today,
please
I
can
take
notes.
Oh
thank
you.
Nicole
appreciate
that
all
right
now.
B
A
A
E
A
G
G
For
this,
this
call
is
to
go
through
the
the
remaining
open
comments,
concerns
and
resolve
them,
and
so
we
can
get
this
into
a
final
shippable
State
and
submit
it
to
other
higher
bodies
to
to
to
review.
So,
let's
see
the
first.
So
the
first
comment,
that's
still
outstanding
is:
when
does
the
openness
to
plan
to
implement
this
and
I
responded
that
this
needs
to
get
past
legal
and
the
tap?
So
that
is
taken
care
of
the
next
comment.
Someone
responded
here
stating
or
Chris
you.
D
G
G
The
policy
states
that,
if
you,
if
the
maintainer
lets
us
know
that
the
patch
is
scheduled
to
be
released
within
on
a
day
that
falls
within
14
days
following
the
deadline,
then
they
we
will
delay
public
disclosure
until
the
patch
is
available,
so
they
have
a
14-day
buffer
Beyond.
If
they
say
we
just
need
two
more
weeks.
A
I've
been
doing
this
for
a
decade
and
it's
nice
to
have
an
ideal,
Target
state,
but
reality
kind
of
gets
in
the
way.
Sometimes
so
I
again
would
suggest
the
alteration
to
timeline,
it's
a
little
friendlier
and
it
gives
the
impression
of
a
little
bit
more
flexibility
But.
Ultimately,
it's
up
to
you,
legal's
gonna
Redline,
this
Beyond,
whatever
we
agree
upon
and
and
they
will
tell
you
what
to
do
as
opposed
to
me-
asking
you
something.
D
F
I
kind
of
wanted
a
plus
one.
What
probe
said
because
I
know
that
lately,
a
lot
of
people
have
been
saying
that
90
days,
sometimes
it's
not
enough
time
and
I
know
at
some
point,
you
got
to
draw
the
line.
I
get
it,
but
I
know
that
right
now,
certain
actors
that,
like
are
just
using
that
timeline
to
their
favor,
to
do
things
that
are
not
that
are
naughty.
Let's
just
put
it
that
way.
G
So
it's
intended
to
be
a
a
slightly
flexible,
hard
deadline.
Right
like
there
is
some
flexibility
built
into
the
to
this
this
policy,
but
at
the
end
of
the
day
you
need
a
deadline
and
one
of
the
things
that
Google.
If
you
look
at
Google's
FAQ
from
their
project
zero,
they
have
a
long
history
of
doing
vulnerability,
disclosure
and
they
said,
if
you
don't,
have
a
deadline
and
you
don't
enforce
that
deadline,
then
then
these
you
know
vendors
continue
to
to
to
move
forward
with
not
fixing
these
things
in
a
timely
manner.
G
A
Google
is
a
commercial
Enterprise
and
your
target
is
going
to
be
open
source
developers
who
are
not
necessarily
commercial
employees
and
are
not
necessarily
beholden
to
slas
and
timelines.
So
again,
I
would
just
encourage
a
little
more
softening
of
the
language.
But
again
whatever
we
decide,
other
people
will
ultimately
weigh
in
with
more
Authority.
G
G
A
G
Of
everywhere
yeah,
so
again
the
the
the
rationale
here
is
currently
the
so
the
developers
are,
but
the
people
that
are
currently
going
to
be
disclosing
the
vulner
realize
are
us-based
the
the
the
thing
that
that
you're
comment
about
holidays
would
still
fall
within
this.
This
sub
policy
right.
So
if,
if
an
if
a
maintainer
comes
forward
and
says,
hey,
we've
got
a
holiday
on
this
deadline,
can
you
push
it
out?
We
will
be
releasing
on
X
day
that
still
Falls
within
the
14-day
push,
so
they
can.
A
G
H
F
Just
wanted
to
say,
Jonathan
I,
don't
want
you
to
think
that
we're
like
trying
to
like
take
away
from
what
you're
doing
I
think
that,
like
it's
very
good
and
I,
think
that,
like
as
time
increases,
we
can
move
in
that
direction.
But
yeah
I
think
that
that,
like,
as
a
packager
I,
know
some
of
these
things
all
too
well.
A
Yeah
and
again,
I
I
provide
feedback
based
off
of
my
experiences
and
perspective.
This
isn't
a
criticism
this
it's
much
easier
to
have
productive
work.
If
somebody
give
you
gave
you
something
to
start
from,
as
opposed
to
us
working
off
a
blank
page
yeah
and
it's
not
critiquing
the
idea,
it's
just
providing
some
feedback
on
how
you
might
want
to
massage.
G
It-
and
so
you
know
a
lot
of
this-
is
so
the
way
that
this
document
started
out
with
it's,
it's
Google's
policy
copied
and
then
heavily
modified
to
focus
on
the
lssf
right,
so
a
lot
so
that
some
of
this
wording
is
is
is
is
originally
from
their
policy,
but
you
know
I
I,
you
know,
I
I
I,
see
the
the
reason
and
rationality
that
you're
coming
forward
with
this
on
this
one.
Okay,.
F
G
F
A
A
A
I
I
think
acts
of
God
actually
is
a
fairly
acceptable
thing.
What
if
there
is
an
earthquake
and
that
destroys
a
lot
of
infrastructure
and
the
developer
can't
respond,
or
you
know
again,
documented
widespread
public
exploitation,
those
types
of
things
it
doesn't
need
to
be
addiction.
You
know
a
whole
encyclopedia
just
needs
to
be
got
a
sentence.
G
G
G
A
A
G
Mean
ultimately,
if
the
maintainer
wants
to
accelerate
the
disclosure
Ted
deadline,
they
can
right
if
they
want
to
do
it
faster
than
the
90
days
right.
We're
setting
the
outer
bounds
of
what
what
is
causing
us
to
disclose,
and
it's
the
patch
right.
If
they
want
to
put
out
a
remediation
guide
beforehand,
then
that's
not
going
to
be
not.
A
G
D
H
Yeah
we
usually
work.
Yeah
use
remediation
versus
mitigation,
where
mediation
means
that
you're,
not
the
vulnerability,
is
no
longer
applicable
under
any
situation
and
mitigation
is
kind
of
like
what
Corb
was
mentioning.
Workarounds
configuration
changes
that
vulnerability
is
still
there,
but
you,
you
know,
compensating
controls
that
make
it
inapplicable.
H
G
G
I
Remediation
remediation
steps
have
begun
for
media
States
is
not
even
not
specific;
their
remediation
steps
have
begun
that
will
fall
within
14
days
following
following
the
time
limit.
So
when
we
think
about
remediation
remediation
is
it
could
be
a
set
of
steps.
It's
not
it's
not
a
one
thing
or
another.
I
It's
a
set
of
steps
of
remediation
that
could
include
a
hot
fix
towards
a
potential
patch
that
gets
released
right,
but
those
are
remediation,
steps
and
and
or
immediation
steps
can
begin
and
that
can
be
can
fall
Within
that
14
days
following
the
time
limit
right.
So
so
what
you?
What
you're
saying
here
now
is
you're
going
to
begin
remediation
steps
within
four
within
14
days,
and
that-
and
that
gives
you
I
mean
that
hell
that
even
gives
you
a
bit
of
schedule
creep
in
there
as
well
right
within
14
days.
G
Er,
who,
instead
of
publishing
a
release,
is
going
to
publish
a
remediation
which
may
be
a
patch
which
may
be
instructions,
and
it's
not
going
to
allow
for
a
dependency
update
to
fix
this.
They
can
publish
or
meet.
They
can
publish
a
remediation
and
then,
at
that
point
at
the
point
they
just
they
disclose
the
remediation
the
full
just
details.
The
vulnerability
will
go
public.
I
Well,
the
the
thing
about
the
thing
about
remediation
steps
is
that
you
well
that's
up
to
the
maintainer.
If
it
were
me,
I'm
not
going
to
publish
my
remediation
steps
without
end
up
publishing
is
what
we
decide
to
do
as
a
hotfix
towards
remediation
right.
Like
I,
think
you
know,
your
remediation
steps
should
be
your
own.
That's
that's
like
that's.
Like
a
that's
like
telling
somebody
how
you're
making
the
donuts
you
don't
want
to
tell
somebody
how
you
make
donuts.
I
You
know,
I
mean
you,
you
make
the
donuts
and
the
donuts
taste
good,
but
if
you're
in,
but
if
you
use
stevia
as
a
substitute
for
honey
or
something
like
that.
Well,
nobody
needs
to
know
that
right
away,
you
had
to
do
a
hotfix
which
was
Stevia
until
you
got
some
more
money.
Nobody
needs
to
understand
that
you're
using
honey.
I
D
Am
not
I
understand
what
you're
saying,
but
I
don't
get
how
it
relates
to
this
terminology,
because
to
me
they're,
informing
us
that
they're
doing
remediation
we're
not
obligating
them
to
provide
full
detail
in
the
way
that
I'm
reading
it.
Whereas
what
I'm
hearing
you
say
and
maybe
I'm
hearing
it
wrong,
is
that
your
expectation
is
that
they're
providing
Us
full
details
of
how
they're
remediating.
I
I
Yes,
that
could
include
a
hot
fix
in
the
interim.
While
you
begin
remediation
steps
towards
remediating
towards
a
remedy,
I
mean
like
you,
a
hot
fix
is
just
a
hopper.
Is
a
Band-Aid.
That's
not
a
that's,
not
a
remedy
right
so
so,
and
if
you're
saying
that
it
needs
to
be
done
begin
within
14
days
in
which
you're
notifying
them
is
that
within
14
days,
we
will
notify
you
that
remediation
has
begun.
I
G
A
Ultimately,
we
would
love
to
have
that
software
fixed,
but
sometimes
it's
not
possible
or
not
possible
within
the
time
frames
you
know
requested
from
the
researcher,
so
we
was
again
we
were
trying
to
stress
flexibility
and
you
know
sets
we
want
to
be
strong,
that
we
know
we.
We
have
this
process
and
we're
working
towards
these
timelines,
but
sometimes
if
we
get
that
hot
fix
that
might
be
or
configuration
change,
turn
the
thing
off.
A
That
might
be
just
as
good
as
that
ultimate
fix,
because
you
know
the
downstream
Community
might
not
be
able
to
take
that
patch.
Potentially
there's
regressions
that
they
there's
some
API
API
compatibility
problems
that
they
can't
take,
that
new
fix
and
the
hotfix
are
disabling
the
services,
the
preferred
solution
for
them,
so
yeah
I'm
just
trying
to
provide
you
flexibility.
If
you
say
we
have
to
have
a
patch,
not
everything
gets
fixed
at
the
patch.
G
A
All
part
of
the
negotiation-
again
you
need
to
understand
is
how
much
of
that
risk
is
treated
or
mitigated.
What's
the
residual
risk
left
over
and
you
know
that's
kind
of
part
of
the
negotiation
process.
Yes,
we
would
love
to
have
the
thing
completely
fixed,
but
sometimes
like
with
old
code
bases
or,
if
there's
a
very
complex
Downstream
ecosystem,
or
you
know
the
fact
that
the
event
the
developers
part
of
a
commercial
entity
and
that
there
is
a
hard
product
schedule
that
they
just
they
can't
make
that
timeline
again.
A
We
just
need
to
understand
what
our
options
are
and
don't
close
yourself
off
yeah.
We
want
to
try
to
hit
the
date.
That's
our
goal,
but
don't
box
yourself
in
that.
The
only
way
to
close
this
off
is
a
patch
we're
ultimately
looking
at
the
downstream
consumer,
we're
trying
to
help
them
manage
their
risk,
and
how
best
can
we
do
that.
G
There
is
a
comment
here
on.
We
expect
maintainers
to
respond
within
21
days
to
let
us
know
how
the
issue
is
being
mitigated
to
protect
impacted,
end
users
if
we
have
either
so
there's
a
Jason
kurtstead
is
asking
that
we
add
if
we
have
either
direct
confirmation
or
reasonable
confidence
that
our
report
has
been
received
and
do
not
receive
engagement
from
the
pro
project,
affirming
intention
to
fix
the
vulnerability
within
21
days
after
reporting
the
openness
reserves.
B
G
G
and
then
the
other
comment
is
about
only
disclosing
at
21
days.
If
we
have
confirmation
and
reasonable
conferences
that
the
report
has
been
received,
so
the
first
part
is
having
confidence
that
a
report
has
been
received
is
really
hard,
because
if
basically
this,
this
Clause
that
Jason's
proposing
allows
a
vendor
or
maintainer
to
ghost
you
and
then
you
can
never
have
the
21
Day
timeline
of
confirmation
like
at
like.
G
G
E
Yeah
and
a
lot
of
critical,
especially
in
the
PM
ecosystem,
I
guess
I
have
no
date
at
the
moment,
but
there
was
a
research.
That
said,
that's
a
lot
of
critical
dependency
or
at
least
dependencies
that
are
very
popular,
are
maintained
by
one
person,
and
this
means
that
if
this
person
is
on
vacation,
because
this
special
can
have
four
weeks
off,
we
have
a
problem.
E
E
E
Yeah,
usually
five
weeks
is
enough,
at
least
to
check
something
in
particular.
If
we
think
that
is
super
urgent
or
critical,
we
can
find
also
other
way
to
communicate
with
the
maintainers
I
mean.
One
thing
is
try
to
open
an
issue,
and
maybe
you
miss
the
notification.
One
thing
is:
if
you
try
to
send
an
email
tag
you
on
Twitter,
and
so
it's
different
level
of
communication,
so
five
weeks
and
more
attempts.
B
Is
there
a
being
that
open
source
projects
are
the
target
audience
as
krub
pointed
out,
and
this
is
the
vulnerability
disclosure
group,
how
do
how
do
you
guys
pinpoint
who
to
contact?
If,
if
you
want
to
discreetly
contact
someone
about
a
vulnerability,
is
it
there's?
Is
there
a
standard
way
or
is
that
kind
of
what
we're
working
on.
A
G
G
A
Yeah
I
would
strike
that
language
I,
provided
a
suggestion
on
how
you
could
reword
that,
like,
if
widespread
exploitation
of
the
vulnerability
discovered,
we
will
work
with
the
maintainer
And
the
reporter
to
accelerate
public
disclosure.
I
would
again
not
lock
yourself
into
seven
days,
especially
if
you
know
bad
guys
are
actively
doing
this.
A
G
F
G
G
It
gives
a
clear-cut
date
or
number
of
days
and
if
we
say
up
front
hey,
this
is
known
to
be
under
active
exploitation.
I've
never
actually
run
into
this
case
in
the
real
world,
where
I've
had
a
vulnerability.
I
have
disclosed
that's
under
active
exploitation,
but
I
don't
like
if
it's
under
you
have
yeah
yeah
and.
F
G
F
Would
encourage
you
Jonathan
I,
do
think.
Crobe's
wording
here
is
very
precise
for
like
because
you
gotta
account
for
a
lot
of
things.
Man
you
really
do
and,
and
the
other
thing
about
it
is
that
if
you
get
real,
precise
you're,
gonna
start
getting,
but
I
can't
do
seven
days
or
and
and
that
yeah
like
yeah,
you
don't
want
to
come
off
as
aggressive
is
all
I'm
saying
and
seven
days
starts
pushing
that
line.
A
B
A
There's
an
emergency
we
reserve
the
right
to
change,
so
I
would
again
suggest
I
I
gave
you
some
words
that
you
can
talk
through
and
then
I
would
tack
on
your.
You
know
we
reserve
the
right
to
move
forwards
and
backwards.
I
would
combine
those
two
thoughts
and
not
write
down
a
number
that
people
are
going
to
obsess
over.
E
Especially
in
the
first
period,
we
need
to
be
sure
that
people
follow
us
and
it's
quite
hard,
especially
in
the
non-commercial,
open
source
and
I,
totally
understand
them,
and
security
is
not
their
first
concern
for
a
lot
of
reason,
or
at
least
a
kind
of
security,
and
so
and
Company
were
quite
aggressive
or
are
quite
aggressive,
sometimes
with
open
source
maintainer
so
probably
give
the
possibility
to
be
elastic
or
just
in
the
document
write.
Something
a
sort
of
Escape
can
probably
help
us
to
achieve
better
results.
E
So
from
that
was
probably
the
99
of
people
will
fix
the
issue,
especially
if
the
the
fix
is
easy
in
90
days.
So
we
have
time
just
to
prevent
Community
discussion
on
Twitter
other
social
network
about
potential
implications.
That
probably
never
happened,
but
this
is
the
point
we
want
to
be
sure
to
to
have
a
good
communication,
so
we
can
start
to
work,
and
after
that
we
start
to
work.
Probably
we
can.
G
I'm
concerned
that
if
you
don't
set
a
solid
expectation
up
front
in
the
fine,
because
okay
most
disclosures
when
you
send
these
to
people,
you
want
to
be
like
this
disclosure
follows
this
policy
link
right,
they're,
not
you're,
not
going
to
include
this
entire
body
in
the
in
the
disclosure
in
the
email,
vulnerability,
disclosure
right.
So
this
puts
this
information
up
front
in
in
their
is
something
that
they
can
look
at,
but
they
don't
have
to,
but
at
least
they
can
go
back
to
that.
For,
if
you
say
hey,
this
is
under
active
exploitation.
G
E
Yeah
but
sorry,
no,
no
lose
you
go
ahead,
I'll
go
after
you
now.
The
point
is
that
I
mean
I.
Think
that
a
lot
of
people
don't
read
really
the
policies.
So
probably
they
just
try
to
find
the
the
the
deadline
in
the
policy
the
number,
and
that
is
so,
if
we
add
the
point
or
just
a
sentence
to
say
hey
if
there
are
particular
scenario,
we
can
add
this
particular
procedure,
even
if
there
is
not
specific
deadline
for
that
procedure.
E
But
people
read
that
usually
we
discussed
in
90
days
and
there
are
four
weeks
to
be
informed
or
we
to
have
the
first
Contact.
Probably
they
followed
this
kind
of
okay.
It
can
happen
that
you
can
find
someone
that
tried
to
exploit
the
policy.
It's
a
and
sometimes
entrepreneurs,
but
it
is
one
or
two
case.
Not
the
I
mean
not
the
majority
of
the
national,
the
typing,
so
I
think
it
is
an
acceptable
risk,
and
if
we
have
a
similar
scenario,
we
can
just
try
to
discuss
and
see
how
we
can
handle
it.
F
I
was
gonna
plus
one.
What
liji
was
saying
and
everything
I
was
going
to
say:
Jonathan
was,
if
you're
trying
to
go
for
like
widespread
adoption.
I
think
that
you
should
try
to
be
as
like,
less
rigid
as
possible
so
like
as
flexible
and
kind
of
understanding
and
I.
Think
as
time
goes
on,
you
can
Implement
a
lot
of
these
rules
because
in
an
ideal
world
you
are
correct.
F
Trying
to
help
you
and
I
think
if
we
stick
to
language
that
is
flexible
and
open
like
that,
you're
going
to
have
a
lot
more
people
willing
to
work
with
you
than
trying
to
point
out
that
one
project
that
can't
do
seven
days
because
they're
super
important,
but
they
have
no
maintainers
and
it's
like
yeah,
but
that's
an
edge
case.
So
yeah
right.
F
G
Which
is
what
we're
doing
right
here,
right
and
and
first
off
you
know,
active
exploitation
is
very
rare
right,
so
it's
very
uncon.
It's
very
uncommon
that
we're
going
to
run
into
this
and
second
off,
it's
not
very
con
like
again
we're
working
with
open
source
projects.
If
it's
a
one-person
project
right
like
when
you
see
active
exploitation,
it's
mostly
when
you're
dealing
with
big
projects
like
struts,
right,
Apache,
struts,.
H
G
Know
oh
database
orms
or
big
projects
right
so
I
I
mean
I,
recognize
that
we're
all
building
on
a
pile
of
sticks,
but
in
general
what
you're
seeing?
Is
it
impacting
these
big
bigger
projects
and
we're
not
dealing
with
this?
We're
not
we're
not
putting
this
deadline
on
those
smaller
maintainers,
necessarily
Carl
I
think
that
we
so
I
think
that
I'm
going
to
leave
this
conversation
open
I'm
going
to
think
more
about
this.
We
can
chat
about
it
at
the
next
call.
G
A
Thank
you,
everybody
for
your
attention
and
your
perspectives.
It's
valuable
to
have
these
different
perspectives
as
we're
trying
to
shape
this
is
theoretically,
is
going
to
have
a
very
broad
impact
for
the
foundation,
we'll
make
sure
that
it's
as
helpful
as
possible
and
not
hurtful
foreign,
so
look
forward
to
Jonathan's,
slack
and
email
request
for
call
Eamon
that
is
interested
in
collaborating
on
this
more.
Please
join.
A
E
A
A
C
A
Thank
you,
sir,
and
this
is
just
another
aspect
where
this
group
can
help
collaborate
on
something
that
is
important
for
the
industry.
Sharing
vulnerability.
Information
is
one
of
our
key
goals
for
this
working
group.
Yeah.
Just
like
we
talked
about
Jonathan's
policy.
This
is
another
means
of
us
communicating
and
sharing
vulnerability.
Information,
open
Vex
is
another
tool
that
we
have
the
opportunity
to
help
collaborate,
help
shape
standards
and
help
influence
things
like
s-bomb
and
csaf
and
other
important
industry
standards,
and
we
can
provide
that
open
source
perspective.
A
I
want
to
thank
everybody
that
participated
in
the
issue
for
your
time
and
attention
and
attendance
and
patience.
It
definitely
did
not
unfold
exactly
as
I
had
envisioned,
but
we
had
a
lot
of
good
feedback
from
both
sides,
both
Pro
and
against
the
argument.
Something
for
us
to
consider
as
we
move
forward.
A
A
E
Well,
I
am
working
on
security
insights
to
understand
if
it
is
a
good
if
it
can
be
a
good
format
to
share
some
information
about
security,
about
the
project
and
I've.
Seen
that
and
a
security
policy
or
and
a
security
contact
is
a
requirement
and
some
of
our
weapons
didn't
have
a
security
policy
or
security,
dot,
MD
or
a
way
to
communicate
with
the
maintainers,
and
so
I
would
like
to
propose
to
have
an
organizational
level
security
policy,
a
generic
one
that
give
up
to
the
material
enough
flexibility.
E
E
E
E
It
is
a
choice
because
I
don't
think
that
we
need
to
add
the
complexity
if
there
is
no
reason
and
I
have
bested
the
policy
on
the
or
your
working
group,
repo,
so
I
started
from
the
security
that
you
suggest
then
I
have
added
more
content,
especially
because
I
propose
yeah
I
mean
a
bit
more
on
context,
especially
the
main
change
I
mean
is
that
we
don't
use.
The
email
has
first
Contact,
but
this
private
security
that
we
need
to
enable
to
organization
level
on
Gita,
but
it
should
not
be
a
problem.
E
It's
not
perfect,
probably
in
the
future.
We
can
adapt
or
improve
it.
According
how
people
report
security
issue
and
I'm
quite
sure
that
some
wrapper
projects
that
are
more
popular
can
receive
more
wrapper
than
other
and
I
expect
also
a
lot
of
false
positive.
Initially,
it's
quite
common,
but
I
think
that
we
need
to
have
a
security
policy,
so
I'm
proposing
this
one
and
feel
free
to
add,
comment
or
suggest
an
edit
I
can
just
approve
them.
I
am
very
happy
if
you
suggest
edits,
especially
about
English.
G
Also
I
found
a
vulnerability
in
the
infrastructure
of
the
opennessf
GitHub,
slash
or
GitHub
GitHub
infrastructure,
and
that
prompted
us
to
actually
add
a
security
ad
open,
ssf.org
email
address.
So
there
is
now
one
that
is
forwarded
to
operations
currently,
but
there
is
an
email
address
that
exists
currently,
so
that
that
email
is
that's
listed
in.
That
document
is
valid.
A
So
personally,
I
think
this
is
important
for
us
to
do
for
consistency
and
also
to
kind
of
show
that
we
not
only
have
great
ideas,
but
we
follow
through
on
those
great
ideas,
so
I
would
love
personally
to
help
collaborate
on
this.
Any
other
thoughts
or
comments.
I
saw
a
whole
swath
of
thumbs
up
and
check
marks.
A
All
right
so
I
think
our
next
step
would
be
actually
to
create
an
issue
so
that
we
kind
of
formally
log
this
as
kind
of
a
project
for
us
and
Let's.
Keep
this
on.
The
docket
I
would
encourage
Us
in
as
we
get
that
issue
in
things
put
together.
Please
review
the
document
and
provide
comments.
Now
don't
wait,
but
let's
make
this
a
an
official
work
item
for
us
to
move
forward
on
Luigi.
A
Yeah
and
if
you
need
assistance,
don't
don't
hesitate
to
reach
out
to
us
and
slack
again
help
write
an
email
but
no
I
I
think
this
is
worthwhile
work
for
us
and
definitely
kind
of
is
in
line
with
our
goals
and
Mission
and
I.
Think
it's
something
that
it
will
require
some
review,
but
is
pretty
simple
for
us
to
do
and
commonsensical
okay,
so
plus
one.
G
A
You
would
create
an
issue
and
then
mail,
the
tech
mailing
list.
Dear
Tech,
please
look
at
this
issue.
Okay,
provide
feedback,
blah
blah.
They
just
had
their
call
last
week.
So
the
next
call
probably
won't
be
a
good
idea,
because
that
will
be
the
results
of
attack
election
of
FYI
there's
attack
election.
Hopefully
those
of
you
that
signed
up
to
participate
got
an
email,
so
please
participate
in
the
vote,
but
I.
Imagine
that
that
tech
meeting
will
be
consumed
with
getting
potentially
new
tech
members
up
to
speed,
but
don't
wait.