►
From YouTube: SIRT - Education SIG (August 16, 2022)
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).
B
Let
us
start
today:
do
we
have
any
new
folks
that
wanted
to
say
hello,
don't
see
any
new
friends.
C
B
Both
appreciate
that
does
anyone
have
any
opens,
they
want
to
add
to
the
call
before
we
jump
into
our
exciting
topic,
staffing.
B
F
I
got
it,
but
I
wanted
to
use
the
opportunity
to
remind
everyone
that
we
have
and
like
a
github
setup,
so
you
can
use
it
to
file
issues
on
things,
we're
working
on
and
put
your
stuff
there,
so
that
we
increase
transparency
even
further
on
top
of
recording
everything
and
putting
it
on
youtube.
F
So
this
is
what
we
tried
so
emily
and
I
basically
filed
an
issue
against
ourselves
a
little
bit
of
what
we
wanted
to
tackle
here
and
today.
F
If
you
go
in
the
issue.
Sorry,
like
just
to
be
explicit,
I
know
krobe
actually
put
the
link
on
it,
but
it's
on
our
open
ssf,
like
as
irt
issues.
F
So
staffing
and
estimates
essentially
emily,
and
I
thought
we
should
probably
have
a
little
skeleton
document
to
get
us
started
on
like
you
know,
it's
okay,
to
be
to
disagree
with
what
we
have
here,
but
at
least
we'll
have
a
place
to
start
to
understand
the
conversation,
and
we
approached
it
from
two
main
angles
essentially
like
how
do
we
define
the
personal
itself
like
what
kind
of
personal
do
we
expect
you
have
to
need
and
on
the
intake,
so
requests
for
the
cert
of
the
cert?
Essentially,
how
do
we
get
intake?
F
How
do
we
receive
it
from
like
stuff?
We
also
have
a
little
bit
here
about
the
services
and
offerings
and
how
we
want
to
handle
escalations
and
handoffs
their
emergencies
and
conflicts.
A
bit
is
kind
of
like
I
don't
want
to
say
like
secondary,
but
it's
essentially
going
to
require
a
lot
more
thought
than
just
in
discussions.
B
Discuss,
let's,
let's
review
it
with
the
team
here
and
start
talking
through
it,
get.
C
G
Yeah
or
five
seconds
of
quiet
means
people
haven't
seen
the
document
yet
so
they
haven't
formed
an
opinion,
so
I
think
walking
through
it
will
give
people
the
chance
to
really
form
that
opinion,
but
I
suspect,
considering
who
has
written
this.
It's
probably
pretty
good.
E
So
there's
a
lot
of
work
that
still
needs
to
be
done
on
this,
but
we
can
certainly
start
walking
through
it.
One
of
the
things
that
we
had
initially
talked
about
at
various
of
the
meetings
was
about
what
kind
of
individuals
would
be
participating
in
the
cert
based
off
of
those
discussions.
Francis
and
I
are
proposing
that
there's
two
primary
or
two
types
of
primary
responders,
who
are
the
individuals
that
are
responsible
for
actually
executing
the
work
of
the
cert?
There
are
community
volunteers,
and
then
there
are
direct
staff.
E
The
difference
between
the
two
of
them
is
primarily
the
direct
stuff,
have
access
to
the
foundation's
resources
and
can
better
facilitate
the
the
needs
of
the
cert
back
to
the
foundation,
so
they
act
as
a
liaison
between
them
and
it
gives
us
a
better
line
of
access
to
any
kind
of
legal
support
or
tooling
support
or
other
kind
of
licensing
support.
That
would
be
necessary,
but
we
suspect
a
lot
of
the
incident
response.
Activities
themselves
will
probably
largely
come
out
of
volunteers
that
determine
that
they're
interested.
E
We
didn't
provide
any
time
lines
or
time
obligations
associated
with
this.
At
this
time,
because
we
just
wanted
to
get
a
good
understanding
of
the
structure,
we
also
have
a
concept
of
support
staff,
and
these
are
contracted
personnel
who
perform
ancillary
functions
to
the
primary
incident
response
team,
those
primary
responders.
They
can
be
any
number
of
things.
B
A
B
As
we
go
through
and
start
to
flesh
out
the
plan,
those
support
roles
may
come
into
better
clarity.
As
we
start.
E
Yep
next
was
figuring
out
the
intake
process
or
how
folks
make
requests
of
the
cert
we
talked
through.
What
does
that
intake?
Look
like,
for
instance,
had
a
brilliant
idea
of
doing
a
robot.txt
file
within
repos
that
allows
us
to
pull
some
information
together,
so
maintainers
or
reporters
or
requesters,
don't
have
to
keep
regurgitating
the
same
content,
that's
already
available
within
a
repository,
so
kind
of
help,
automating
and
lowering
the
barrier
to
entry
for
that
process
and
make
it
as
frictionless
as
possible.
E
We
started
with
a
limited
set
of
metadata,
that's
just
essential
for
us
to
understand
more
about
the
project.
Obviously
this
is
incomplete,
but
it's
a
good
starting
point.
So
what
is
the
project
name?
What
is
the
requester's
relationship
to
the
project
because
it
could
very
well
be
likely
that
they
are
a
maintainer?
They
could
be
a
security
researcher
that
has
no
relationship
to
the
project.
They
could
be
a
active
community
contributor,
any
number
of
things,
understanding
who
the
maintainers
are
or
where
that
file
is
kept.
E
So
we
know
who
to
contact
and
the
specific
contact
information
beyond
just
a
mailing
list,
because
sometimes
mailing
lists
get
set
up
and
forgotten,
and
it's
a
lot.
It's
a
lot
better,
just
to
reach
out
to
an
individual
that
doesn't
preclude
us
from
also
adding
that
mailing
list
to
an
email
notification
that
goes
to
them,
but
something
worth
considering
here
also:
where
is
the
project
located?
E
That
can
be
any
number
of
things?
It
could
be
a
github
repo.
It
could
be
good
lab
revo.
It
could
just
be
some
file
directory,
that's
accessible
on
the
internet,
any
number
of
things
we
we
don't.
We
don't
have
a
preference
necessarily,
but
also
if
the
project
could
potentially
be
part
of
a
different
foundation,
it
could
be
an
open
core
project
of
a
of
a
commercial
company.
F
Yeah
this
is
like
this.
This
kind
of
line
of
questioning
is
really
to
help
us
determine
the
maturity
of
like
the
project
that
we're
dealing
with,
and
it
will
help
us
also
like,
for
the
second
part
here
about
the
vulnerability
like
essentially,
what
kind
of
tiers?
What
kind
of
engagement
are
we
getting
ourselves
into
of
sorts.
B
Good
question:
would
you
is
your
proposal
to
put
this
metadata
into
your
robot
text
file
so
that
we
could
potentially
automatically
pull
that
as
part
of
a
request.
E
Yeah,
it
could
be
this
set
of
information
minimally,
it
could
be
less,
it
could
be
more.
The
idea
is
just
like
I
imagine,
whenever
you're
filing
an
issue,
it's
always
the
same
information
every
time
and
you'd
wish.
You
could
just
be
like.
Remember
me,
please,
remember
all
of
these
fields
very
similar.
F
Yes,
let
me
open
up
the
chat
room,
because
I
think
people
have
commented
okay,
so
for
vulnerability
stuff
like
on.
Basically,
we
don't
know
what
it
looks
like,
but
we
wanted
to
basically
separate
the
project
information
from
the
vulnerability
information
and
on
the
vulnerability
side.
We
basically
looked
into
okay,
like
what
is
the
impact
according
to
yourself,
like
as
a
subjective
evaluation
like
negligible
low
medium
and
so
on,
to
the
project
and
versus
the
community
itself,
because
sometimes
these
will
have
different
scopes,
different
impacts
as
well.
Is
this
public
or
under
embargo?
F
How
how
was
it
reported?
How
was
it
discovered?
I
see
martha
here?
Oh
okay,
sorry
and
moving
on
to
how
was
it
reported
like
basically
the
discovery
method
here
and
then
under
that,
please
provide
a
report.
We
opted
for
something
that
most
likely
will
offer
like
no
formatting
of
sorts,
maybe
maybe
anything
later
on,
but
we
don't
want
people
to
upload
files
just
for
simplicity's
sake
and
also
remove
some
infrastructure
on
our
end,
did
you
receive
a
proof
of
concept?
F
Have
you
confirmed
if
it
is
true?
Essentially,
this
is
something
that
we
have
talked
about
in
the
plan
as
well
to
help
folks
confirm
or
like
offer
some
kind
of
like
sme
stuff.
Is
there
a
cv
already?
Do
you
need
one?
Maybe,
and
do
you
agree
or
con
and
consent
to
using
our
responsible
disclosure
processes?
F
This
point
here
is
really
to
like
protect
us
a
little
bit,
but
at
the
same
time,
if
folks
refuse,
because
they
have
their
own
processes
or
they
have
their
own
approach
or
to
disagree
with
the
90-day.
F
Whatever
proposal
that
we
have
publicly
available,
this
also
clarifies
and
like
simplifies
our
engagements,
because
we
won't
be
able
to
move
forward
with
like
the
classic
processes
that
we
would
be
using
and
then
there's
a
short
conversation
about
the
idea
for
the
robot,
the
txt
or
equivalent
file
on
this
one
side,
martha
here
as
an
additional
question
to
ask
researchers.
When
do
you
want
to
release
information?
F
F
B
Yeah,
let's
pause
here
for
a
second
francis.
What
does
the
group
think
what
do
we?
What
do
we
like
about
this?
What
do
we
have
questions
about?
What
would
we
suggest
to
change.
G
So
I
think
this
is
a
a
good
start.
I
suspect
we're
going
to
have
rather
a
lot
of
iteration
once
we
start
working
on
things
and
seeing
what
works,
what
doesn't
what
we
need,
what
we
don't
need,
but
this
is
still
rather
a
lot
of
information
and
so
making
sure
we
have
a
method
not
only
of
collecting
it,
but
also
tracking
and
reporting
on
it
so
having
it
in
some
sort
of
standardized
form
where
we
can
ingest
it
into
some
sort
of
tracking
mechanism
or
start
in
some
sort
of
form.
G
That
can
be
a
tracking
mechanism
where
we
can
slice
and
dice
the
data,
because
we
will
need
that
for
budgets
and
various
things,
and
just
so,
I
think
that's
something
we
need
to
make
sure
is
if
it's
not
represented
in
our
overall
plan.
Yet
we
should
ensure
that
it
is
because
it's
obvious
that
we're
collecting
some
good
data.
G
And
as
marta
pointed
out
also
making
sure
that
we
can
keep
the
data
secure
because
it
can
be
kind
of
you
know
showing
who
has
asked
for
help
is
kind
of
also
showing
who
has
had
security
problems.
G
So
how
can
we
keep
this
data
secure
enough
from
people
or
at
least
wait
until
we've
got
so
much
data
that
nobody
will
care
regardless?
G
That's
something
we
need
to
make
sure
we
cover
and
it
looks
like.
D
F
So
the
tooling,
the
tooling
aspect
of
it
is
definitely
critical
and
we've
explicitly
not
discussed
it
in
this
document
before,
like
I
know,
kroger
and
I
had
a
like
shorter
conversation
off
band
about
it,
but
this
is
something
indeed
that
we
will
need
the
group
to
actually
look
into
as
well.
G
B
As
part
of
our
final
plan,
we
will
need
to
have
a
proposal
for
pooling
and
people
and
infrastructure
and,
as
francis
alluded
to,
we
had
a
brief
conversation
about
it.
This
group
and
we
need
to
decide
you
know,
is
it
full-time,
volunteer
staff?
Can
I
see
what
that
mix
is?
This
group
will
need
some
type
of
tool
to
help
manage
these
incidents?
B
There
are
a
handful
of
commercial
offerings
and
there's
also
a
tool
like
vince,
and
you
know
if
we
would
like
to
if
we
like
vince,
and
we
think
that's
a
good
move
forward.
We
potentially
could
apply
people
towards
improving
it
and
changing
it
to
meet
the
needs
of
this
group
and
that's,
I
need
to
have
some
kind
of
offline
conversations.
If
that's
a
route,
we
want
to
think.
B
What
what
does
the
group,
what
other
thoughts
do
you
have
before?
I
ask
another
question.
B
What
does
the
group
think
about
the
idea
of
advocating
for
that
robot.txt
file
devoting
some
time
and
energy
towards
promoting
this,
getting
projects
to
start
to
build
that
out
and
have
that
in
place
so
that,
once
this
team
comes
online,
that
work
will
be
easier?
What
does
the
group
think
about
that.
E
I
had
a
good
question
about
whether
or
not
it's
significantly
different
than
the
security.txt
file.
I
think
the
the
key
difference
here
is
that
the
security.txt
files
or
security.markdown
is
not
always.
It
doesn't
always
contain
the
same
fields
of
information,
so
having
a
dedicated
file
with
a
minimum
set
of
fields
in
a
standardized
format
certainly
makes
things
a
lot
easier.
E
F
The
name
itself
is
just
we,
we
wrote
robot.txt
or
security.txt,
just
as
like
people
know
what
this
means,
but
yeah
it
either
could
be
its
own
independent
file
or
a
new
file
or
like
merge
into
something
else.
As
long
as
structured
data
is
somewhat
available
because,
as
emily
pointed
out
right
now,
there's
no
structure
really
in
these
files,
it's
kind
of
meant
to
be
very
lightweight
and
free
form.
So
yeah.
We
wanted
to
see
what
the
group
thought
about
it.
F
B
Yeah,
definitely
something
that,
as
we
start
to
split
up
into
small
groups,
focusing
in
on
specific
parts
of
the
plan
and
building
up
those
details,
do
we
think
the
proposal
here
for
the
staffing?
Do
we
think
that's
a
the
model?
We
should
use
and
kind
of
use
that
lens
as
we
are
requesting
resources.
B
We
like
that
enough
to
temporarily
ratify
that
to
move
forward
and
then
think
about
things
like
the
robot
text
as
a
supplementary
as
we
move
along.
B
B
B
Any
any
alternative
suggestions
before
we
kind
of
decide
that
that's
the
lens,
we'll
use.
B
B
E
Yep,
so
I
want
to
talk
a
little
bit
about
the
significant
critical
concern,
so
we
talked
a
lot
about
an
intake
and
that
there
is
an
individual
that
is
requesting
the
services
of
the
cert.
E
One
factor
that's
worth
considering
is
the
concept
of
self-promotion
or
barging
in
on
our
project
that
we
need
to
be
very
sensitive
about,
because
there
may
be
occasions
within
the
community
where
a
high
impact
vulnerability
is
reported
and
it,
for
all
intents
and
purposes
it
doesn't
appear
that
the
project
is
managing
it
well
or
managing
it
at
all
or
isn't
even
aware
about
it.
E
So
this
significant
critical
concern
area
we
had
started
roughing
out
as
a
way
for
us
to
capture
those
occasions
where
we
may
have
access
to
some
information
and
need
to
engage
with
a
project
or
would
like
to
engage
with
the
project.
How
do
we
go
about
doing
that
in
a
delicate
manner,
because
there
are
a
number
of
factors
that
have
to
be
considered
in
that
kind
of
engagement.
F
Yeah
there
will
be,
and
there
will
be,
a
lot
of
human
subtleties
that
come
into
play,
especially
if
you
know
like
we
don't
have
to
imagine
too
far
to
imagine
scenarios
where
not
every
developer
agrees
to
escalate
to
us
or
not
every
owner
wants
us
to
be
involved.
How
do
we
handle
that,
like
these
conversations
should
be
held
before
we
even
start
these
engagements
internally
to
us
right
so
yeah.
D
E
So
next
is
the
services
and
offerings-
and
this
was
our
initial
pass
based
off
of
the
existing
discussions
within
this
group
around
the
various
kinds
of
there
will
be.
A
lot
of
human
subtleties
should
be
our
model.
Yes,
there
are
various
types
of
engagement
that
we
could
potentially
participate
in
so
francis,
and
I
talked
through
a
few
of
them.
E
Some
of
them
are
new
in
concept
to
this
group,
so
we
wanted
to
kind
of
go
through
it
a
little
bit
more
in
depth,
so
the
first
one
is
around
just
a
coordination
to
help
them
manage
the
vulnerability
to
overcome
it
very
quickly
and
have
a
positive
outcome.
So
that's
just
a
top
level
kind
of
engagement,
very
simple,
we've
also
talked
about
reviewing
the
overall
project
is
part
of
that
level
of
engagement,
but
this
is
a
little
bit
simpler
and
that
it's
a
introductory
review.
What
is
the
project?
What's
the
current
posture?
E
Do
you
have
the
processes
in
place
kind
of
like
a
an
initial
evaluation
of
what
is
their
security,
health
and
their
security
posture?
A
much
deeper
dive
for
that
is
a
security
design
review,
which
is
more
in-depth
involvement
with
the
project.
It's
a
higher
ask
of
them,
but
the
value
that
they
get
out
of
that
potential
review
is
much
stronger.
So
the
idea
being,
rather
than
just
responding
to
the
incidents
all
of
the
time
and
going
through
the
same
motions
of
the
process
of
coordination
and
responsible
disclosure
and
assisting
them
in
that.
E
It
would
also
be
beneficial
for
doing
anything
that
we
can
to
assist
them
and
removing
the
likelihood
of
vulnerabilities
by
reducing
the
attack
surface,
ensuring
that
they're
calling
the
libraries
correctly
all
of
those
kinds
of
things,
so
that
that
those
two,
the
reviews
and
the
security
design
review
were
the
two
primary
areas
of
introduction
that
we
wanted
to
really
highlight
here.
And
what
does
that
mean?
E
We've
also
talked
in
the
past
about
patching
whether
or
not
their
group
has
the
technical
skill
set
to
be
able
to
perform
that,
and
we
did
write
that
into
the
plan
as
well
as
the
mitigation
portion,
because
not
everything
is
necessarily
going
to
be
fixed
with
a
patch
we
may
have
to
provide
or
assist
in
providing
recommendations
about.
How
do
you
work
around
the
vulnerability?
Is
it
a
configuration
file?
E
Is
it
putting
a
load
balancer
in
front
of
it
all
of
these
kinds
of
things
that
can
just
better
assist
with
the
more
immediate
response
while
a
patch
is
still
being
developed,
and
then
communications
and
advisories
just
assisting
them?
In
writing
it
making
sure
that
they
have
the
right
content
for
their
users
or
for
anybody
that
is
consuming
vulnerability,
advisory
information
for
them.
E
B
We
probably
should
have
some
type
of
education
outreach
and
that
might
link
into
the
education
sig,
but
we
should
make
it
part
of
our
mission
to
provide
materials
and
training
and
assistance
to
help
teach
people
that
aren't
in
crisis
mode.
Yet.
F
So
yeah
these
services
and
offerings
right
like
they're
all
right.
Let
me
turn
on
video.
F
F
F
B
A
You
vicky
hey
quick,
quick
comment.
I
put
this
in
the
google
doc,
create
a
great
idea
to
right
integrate
improvement
along
with
just
responding
fighting
the
fire
over
and
over
again.
So
no
argument
there
whatsoever,
and
I
think
there
are
at
least
parts
of
that
that
I
wouldn't
hesitate
to
put
in
right
from
year
one
right
from
the
beginning.
I
did
put
a
comment
in
though,
to
take
some
care.
A
You
know
there
could
be
situations
where
there's
not
time
or
resources
to
do
everything
and
do
a
full
review
or
or
do
to
do
an
improvement
even
when
there's
clearly
one
being
requested
or
called
for
so
we
might
want
to
have
some
language
that
just
says.
Look
if
it's
nothing
else
is
available,
responding
to
the
vulnerability,
we're
going
to
fix
that
we're
going
to
put
out
the
fire.
A
We
strongly
want
to
do
more
things,
but
if
it
comes
down
to
it
right
firefighting
is
the
primary
goal.
Now,
that's
not
true,
but
we
don't
agree
with
that.
That's
perfectly
fine,
but
mostly
a
sort
of
a
scoping
thing.
So
we
don't.
We
don't
put
ourselves
in
a
situation
of
doing
right.
Full
security
support
for
everything
we
get
kind
of
every
time,
especially.
B
F
Yes,
very
true,
and
one
of
the
things
I
don't
know-
which
section
was
which
section
it's
in,
but
we
we
did
write
down
explicitly
to
define
when
we're
done,
like
as
part
of
any
engagement
like
and
depending
on
our
current
resources.
Again
like
this
is
going
to
be
probably
a
mixed
volunteer
paid
staff,
we
will
be
constrained
assuming
we're
very
popular,
so
we
will
have
to
be
very
explicit
about
okay.
We
only
have
so
much
time
right,
yeah!
That's!
F
E
And
I
I
captured
that
down
below
underneath
of
the
service
tears
art
so
that
we
have
that
as
a
callout
that
needs
explicit
work
so
next
and
that
we
had
mentioned
it
previously
further
up
about
the
group
needing
to
define
slos
and
service
tiers
associated
with
some
of
that
work,
we
kind
of
broke
it
down
into
two
areas.
F
I
guess
sorry
one
small
note
here:
this
list
will
need
to
be
made
public
as
in
like
what
criteria
we
use,
but
the
evaluation
of
set
criteria
will
definitely
be
internal
to
us.
At
this
point
yeah
we
may
you
know,
maybe
we
decide
to
be
transparent
about
it,
but
this
is
definitely
for
an
internal
assessment
of
the
situation.
E
What
could
be
really
bad
for
some
teams
and
organizations
could
actually
not
be
as
significant
to
others
so
trying
to
understand
a
little
bit
more
about
what
is
the
size
of
the
community
that
they
have
for
the
country
for
the
contributors,
but
also
whether
or
not
they
know
who
their
adopters
are,
because
in
some
cases,
projects
don't
and
that's,
okay,
but
in
other
occasions
they
do,
and
they
may
have
a
very
large
adoption
rate
from
various
companies
in
various
industry.
Verticals
that
can
help
in
us
understand
a
little
bit
more
about
the
impact.
E
Also
the
maturity
of
the
project.
Is
it
just
a
few
days
old?
Has
it
been
around
for
a
really
long
time
and
they've
been
doing
this
forever?
This
is
just
their
first
security
vulnerability,
so
kind
of
understand
like
what
they
could
potentially
be
exposed
to
or
how
robust
their
code
base
is
and
whether
or
not
they
have
the
history
with
vulnerability
disclosures.
Are
they
familiar
with
the
process?
Have
they
had
a
bad
experience
in
the
past?
What
does
that
actually
look
like.
F
So
I
see
a
lot
of
typing
still
happening
in
there
like
the
full
list.
Please
feel
free
to
expand
and
like
modify
and
update,
as
you
see
fit,
just
try
to
leave
these
things
as
either
suggestions
or
like,
especially
if
you're
deleting
them
make
it
explicit
that
it
was
removed,
but
yeah
feel
free
to
just
go
about
and
change
that
list.
But
really
the
question
is
about
these
two
tiers
like
do
we
need
another
one?
Is
there
something
we
haven't
thought
about.
B
E
Yeah,
so
we
had
talked
at
the
day
two
of
the
may
meeting
about
this
concept
of
the
third
of
last
resort,
and
I
I
believe
I
had
mentioned
it
here
previously
about
escalations
and
handoffs
between
various
cert
teams
or
even
just
security
teams,
of
a
given
project.
E
What
does
that
look
like
there's,
obviously,
a
lot
of
coordination
for
reach
out
and
engagement
with
existing
foundations
and
entities
to
determine
whether
or
not
they
have
an
appetite
to
set
up
their
own
cert
for
those
projects.
However,
there
are
some
things
that
we
do
need
to
understand
how
many
other
groups
are
involved.
What
are
they
currently
working
on?
E
What
are
our
thrust
thresholds
for
disengaging,
because
at
some
point
we're
not
going
to
be
doing
all
of
the
work
of
the
project
they
they
should
be
stepping
up
and
taking
a
lot
of
ownership
of
their
own
processes,
and
we
want
to
empower
them
to
do
so.
So
there
is
some
kind
of
requirement
for
us
to
evaluate
whether
or
not
they
we
believe
that
they
are
set
up
for
success
with
the
kind
of
engagement
that
we've
already
had.
E
Unfortunately,
the
vulnerability
space
and
just
general
incident
response
is,
unfortunately,
laden
with
a
lot
of
potential
problem
areas
that
need
to
be
avoided,
and
we
want
to
ensure
that
we
have
a
defined
process
for
when
they
show
up,
rather
than
figuring
it
out
for
when
they
do
on
the
fly
and
then
kind
of
what
are
those
handbags,
and
should
we
check
back
in
with
the
project
after
we
choose
to
disengage?
Is
it
a
phase
disengagement
where
we
just
periodically
check
in
with
them
and
say:
hey?
Have
you
run
this?
F
Yeah
krob's
comment
on
this,
I
think,
is
very
relevant
as
well
like
some
communities
will
have
very
specific
processes
around
how
to
communicate
even
with
them
or
like
using
their.
You
know
their
protocols
and
mailing
lists,
as
we've
all
been
witnessing
very
concretely,
so.
B
B
F
And
same
for
emergencies,
right
like
we
have
not
defined
like
the
rest
of
the
the
rest
of
the
document,
was
not
defined,
not
because
we
didn't
have
words
for
them,
but
we
ran
out
of
time,
and
we
wanted
to
still
leave
some
room
for
for
an
open
discussion
here
in
this
group
as
well.
So
how?
How
do
we
handle
emergencies
as
a
certain,
as
in
like
zero
days?
And
things
like
this
yeah
like?
Do
we
want
hamburgers.
F
Yeah
correct,
you
know
like
these
little
scenarios
that
tend
to
be
very
fun
to
write
down
but
still
happen
so
yeah
food
for
thoughts
here.
If
folks
have
ideas,
feel
free
to
just
populate
this
live
or
we
can.
F
Second
big
thing:
we
wanted
well,
it's
kind
of
a
big
thing,
but
we
glossed
over
it
earlier,
which
is
how
do
we
handle
conflicts
and
that's
meant
mostly
mostly
for
community
community
level
or
like
a
project
level,
conflicts,
internal
conflicts
or
not.
F
This
is
what
the
people
section
would
be
and
on
the
legal
on
the
legal
side,
we
definitely
need
to
start
making
a
lot
of
really
good
friends
around
the
legal
team
that
we
have
here
at
openssf,
because
they
will
hear
about
us
and
we
should
hear
from
them.
So
this
is
for
the
area
here
and
on
processes
prerelease
embargoes.
All
that
we
should
be
explicit
about
what
it
is
that
they
mean
for
us
as
assert,
so
that
folks
are
not
getting
any
surprises
along
the
way
of
coordinating.
B
C
F
I
see
two
two
big
approach
here.
First
is:
is
there
any
major
gap
we
forgot
like
if
the
room
here
is
like?
Oh,
why
didn't
we
talk
about
x?
Now
is
a
really
good
time
to
mention
it
and
the
second
question
question:
I
think
we
should
answer
as
a
group
is
who
wants
to
work
on
this
further,
because
this
is
definitely
just
a
skeleton
there's,
a
number
of
like
fan
out
documents,
and
maybe
even
websites
that
need
to
be
looked
into
to
be
created
and
so
on.
F
F
B
So
I
might
suggest
that
we'll
be
able
to
move
more
quickly
if
we
take
this
particular
artifact
and
anyone
that's
interested
in
collaborating
on
this
right
now.
We
schedule
a
special
session
where
we
get
together,
either
virtually
or
on
a
call
to
focus
on
this
particular
document
and
that's
the
technique
I'm
going
to
use
as
we
look
at
the
whole
plan.
F
So
yes,
emily,
thank
you
for
pointing
it
out.
We
do
have
a
github
issue
feel
free
to
just
chime
in.
If
you
do
want
to
throw
your
what's
the
expression
again.
F
Yeah
I
had
in
the
ring
there
you
go
so
feel
free
to
use
that
as
well
yeah.
Otherwise,
if
if,
if
there's
no
major
gap
that
we
can
identify
right
here,
I
think
we're
off
to
start.
B
I
think
so
so
moving
forward
what
francis
and
I
are
going
to
be
doing
is
we're
going
to
be
taking
all
of
our
notes
in
regards
to
the
plan,
not
this
doc.
This
document
will
continue
to
work
in
parallel,
but
he
and
I
are
going
to
take
the
plan
and
get
that
into
github
as
a
file
that
we
can
start
to
issue
comments
and
pr's
on
our
next
step
is
going
to
be
trying
to
chop
it
up
into
logical
groups.
B
B
So
if
anyone
has
any
feedback
on
how
we
might
logically
organize
ourselves
to
focus
in
on
specific
parts
of
this,
but
he
and
I
are
going
to
move
it
to
git,
and
that
way
we
can
start
having
a
more
transparent
conversation
there
and
start
to
focus
in
on
the
things
that
will
move
us
towards
that
final
business
proposal.
Up
to
the
governing.
E
So
I
did
want
to
like
put
it
out
there
that
there
may
be
something
that's
worth
considering
as
we
write
this
up
is.
I
can
foresee
there
being
an
occasion
where
funding
or
budget
is
not
available
to
hire
some
of
these
staff
members
or
some
of
the
support
or
for
the
tooling.
So
as
we're
think
going
through
and
writing
this
document.
G
I
totally
agree
that
we
should
be
considering
failure
state
so
to
speak
in
in
these
plans,
but
we
also
have
to
be
careful
because
a
lot
of
folks
will
look
at
and
go
oh
well.
If
you
could
do
that
with
mvp,
then
do
you
really
need
more?
G
G
B
What's
required
what
we
have
to
have
and
then
I
don't
know
that
we're
proposing
anything,
that's
really
fluff,
but
there
are
things
we
should
be
willing
to
negotiate
or
potentially
push
down
to
year.
Two
or
three
you
know
ultimately.
B
Down
to
a
group
of
people
that
are
interested
in
putting
money
up
to
help
support
this.
G
Yeah,
I
do
think
that
framing
it
more
as.
G
If
you
want
it
to
grow
more
quickly,
we'll
need
more
fertilizer,
be
that
or
money
we
prefer
money
and
to
make
that
go
right,
and
so
you
know
really
framing
it
in
that
way,
I
think
will
help
to
dodge
that
kind
of
mvp
question
that
I
mentioned
earlier.
G
So
as
far
as
a
document,
I
don't
believe
I've
looked
at
it
today,
but
last
time
I
did
there
were
still
all
sorts
of
edits
and
comments
and
stuff,
and
I
was
going
to
wait
to
make
another
pass
on
it
until
you
and
francis
had
a
chance
to
go
through
it
and
that
would
really
inform
the
you
know
different
groups
question,
because
right
now
things
are,
as
we
all
know,
just
a
little
influx
shall
we
say.
B
I'll
see
if
we
have
time,
but
I
will
make
the
initial
commitment
that
next
week
we
will
have
the
comments
adjudicated
and
have
the
stub
of
the
plan
put
together.
It
took
me
about
an
hour
to
do
the
education
one,
so
I
don't
anticipate
it
will
take
a
lot,
and
I
did
that
alone.
I
didn't
have
an
expert
like
francis
helping
me
out,
so
I
hopefully
just
a
couple
hours
of
work.
B
F
What
saturdays
are
for
yeah,
so
I
mean
at
this
point
just
like
to
like
reiterate
one
last
time.
I
guess
we
will
like
probe,
and
I
will
definitely
look
at
this
again.
This
is
the
first
pass
at
the
final
version,
but,
as
vikki
pointed
out,
we
do
have
a
ton
of
open
comments
still
and
that's
fine
of
sorts
right
now,
but
we
will
need
to
definitely
figure
these
out
figure
these
out
together
at
some
point,
what
we
commit
to
doing
rob
krogan.
F
I
is
yeah,
we'll
try
to
shorten
this
make
this
brought
like
broad
categories
so
that
we
can
define
either
owners
or
see
how
we
want
to
go
and
move
forward
with
this.
G
If
there
are
comments,
I
mean,
if
you
need
help
transferring
comments
to,
for
instance,
issues
for
this
document,
so
we
can
at
least
document.
This
is
something
we
acknowledge
that
we
need
to
work
on
in
the
future.
G
F
Yep
and
to
echo
emily
again
feel
free
to
create
issues,
and
we
one
thing
that
we
wanted
to
avoid
of
sorts
is,
you
know,
francis,
creates
all
issues
so
go
ahead
and
create
them
on
your
own.
Even
if
they're
not
perfectly
worded,
it's
fine,
we
can
re-edit.
Those
surprisingly
github
actually
is
nice
for
that.
So
yeah
do
go
ahead
and
file
issues.
If
you
think
it's
relevant
stuff
that
we
need
to
work
on
in
the
future
as
well.
F
B
My
and
as
we
have
the
the
next
draft
of
the
final
plan
put
together-
and
we
start
to
divide
this
up
into
more
logical,
smaller
working
groups-
I'm
going
to
look
to
the
team
here
to
a
volunteer
to
take
leadership
of
certain
sections
to
help
us
more
paralyze
paralyze
the
work,
not
that
we
want
to
exclude
anyone
to
participate.
But
I
would
like
to
break
this
up
into
smaller
pieces.
So
we
can
have
more
focused
conversations
and,
ideally
move
a
little
more
quickly.
B
G
And
just
a
quick
reminder
to
everyone:
you
know:
you've
got
colleagues,
you've
got
friends,
they
might
be
concerned
about
these
sorts
of
things
as
well.
This
is
a
really
great
way
for
them
to
get
started
without
necessarily
having
a
ton
of
knowledge
about
how
to
operate
a
cert
and
how
they
can
learn
this
sort
of
stuff,
so
you
know
invite
them
bring
them
along.
Everyone
is
welcome.
B
All
right,
thank
you,
everybody.
I
really
appreciate
your
feedback.
I
think
we're
in
a
really
great
spot,
I'm
happy
with
how
we're
progressing
thanks
to
francis
and
emily
for
that
excellent
conversation,
framing
tool
and
looking
forward
to
working
with
y'all
we'll
talk
soon
cheers.