►
From YouTube: OSPO Working Group Meeting June 1, 2023
Description
Meeting summary from this meeting can be found here: https://chaoss.discourse.group/t/ospo-todo-working-group-meeting-june-1-2023/159/1
A
A
The
notes
are
in
the
chat.
If
you
still
need
them,
let
us
know-
and
you
can
add
yourself
to
the
attendee
list-
and
we
have
a
few
things
on
the
agenda.
There's
still
a
little
bit
of
room,
there's
a
couple
of
add
new
items
here
sections.
So
if
there's
anything
else,
you
want
to
add
to
the
agenda:
go
for
it
while
we,
while
we
get
started
so
Anna
I,
think
you
wanted
to
talk
about
the
to
do
book
chapter
and
give
us
give
us
some
updates
to
fill
you
in
so
I.
A
Think
you
weren't
in
this
last
meeting.
We
we
kind
of
had
some
questions
about
the
structure
of
the
book.
Overall,
you
know
outside
of
just
this,
the
the
metrics
chapter,
because
what
we,
what
we're
kind
of
wondering
is
you
know,
are
there?
Are
there
some
things
that
other
people
are
going
to
talk
about
that
we
should
just
take
for
granted?
Is
there
sort
of
a
framework
that
we're
using
for
the
book
how?
A
B
Yeah,
so,
regarding
the
other
chapter,
so
there
is
a
a
mailing
list,
like
a
hospital
book
working
group,
mailing
list,
I
think
many.
Some
people
from
here
are
also.
There
are
anywhere
all
the
notifications
happens,
and
so
the
structure
is
in
the
in
their
GitHub
repo
we
submit
like
PRS
and
the
PRS
have
like
a
review
period.
So,
for
instance,
maybe
it's
better
if
I
start
my
screen
for
you
to
to
take
a
look
on
on
how
the
structure
works.
Yeah,
please
and
if
any
questions
comes
during.
B
B
Or
are
you
ready
for
start
establishing
metrics
on
a
specific
topic
or
not
I'm,
just
giving
examples,
but
some
kind
of
assessment
that
makes
sense
with
the
topic
itself,
then
some
kind
of
sponsor
pattern
so
for,
for
instance,
in
this
specific,
but
the
topic
on
osmo
metrics?
What
are
the
anti-patterns
on
to
to
when?
B
When
comes
the
sign
of
a
stylus
in
metrics,
for
instance,
like
maybe
a
good
example
can
be
like
just
thinking
of
metrics
or
just
thinking
about
the
quantitative
side
on
the
on
the
reporting
or
making
a
set
of
metrics.
That
owns
is
only
available
for
the
hospital
team
and
not
for
and
not
easy
to
understand
for
all
the
teams,
just
giving
some
examples,
and
then
some
continue
here
resources.
B
Maybe
it's
not
here.
Well,
it's
a
working
progress,
because
it's
a
PR
for
this.
If
you
see
that
the
checks
haven't
not
passed,
it's
not
isn't
doesn't
mean
it's
not
working.
It's
just
that.
We
are
trying
to
convert
this
into
a
PDF
using
pandok
and
the
GitHub
access
are
not
working,
but
it's
it's
working
like
if
use
of
mid
PR's
is
is
gonna
work.
Well,
it's
just
that
the
the
GitHub
access
are
not
working,
but
coming
back
to
the
topic.
B
So,
for
instance,
we
are
now
having
a
review
for
chapter
two,
and
so
we
basically
the
processes,
I'm
basic,
sometimes
me
or
sometimes
the
other
person
to
meet
the
pr.
That
is
the
Baseline
content
and
then
all
the
community
starts
at
making
their
additions
and
contributions
to
that
PR.
And
then
we
have
like
a
final
version
and
we
merge
that
final
version
before
the
after
the
community
call.
B
We
usually
have
like
once
per
three
months
or
so
the
next
one
will
be
soon
and
it
is
intended
to
have
a
PR
that
contains
the
Baseline
for
chapter
two,
three
four
and
five,
and
but
if
you,
for
instance,
if,
on
the
other
hand,
this
team
is
working
on
chapter
seven,
you
can
go
ahead
and
start
working
on
such
chapter
seven
and
then
maybe
with
the
with
the
content
that
keeps
being
updated,
update
the
chapter.
Seven,
so
it
it
depends.
So
any
I
see
someone
said
something
in
the
chat.
A
B
D
D
A
B
A
Yeah,
a
short
description
for
each
each
of
the
chapters
would
be
would
be
really
helpful.
You
know
so
one
of
the
reasons
that
this
this
conversation
came
up
in
the
first
place
was
that
we
started
talking
about
what
we
think
a
metrics
chapter
should
have
and
I
know.
You've
heard
me
say
this
before,
because
I
say
this
all
the
time,
but
I
think
metrics
need
to
be
tied
to
the
overall
strategy
for
the
open
source
program
office.
A
So
what
we
were,
what
we
were
trying
to
figure
out
and
we
weren't
successful
at
figuring
out
is,
is
you
know
in
particular
for
this
this
question
there?
There
were
others,
but
this
question
is
there?
Is
there
a
chapter
that
talks
about
how
to
build
a
strategy
for
your
open
source
program
office
and
how
you
tie
the
open
source
program
office's
goals
back
into
the
overall
goals
of
the
organization.
B
A
Because
so
so,
I'll
give
you
a
bit
of
feedback.
I'll
just
give
you
a
recommendation
that
I
have,
which
is
that
this
appears
to
be
very
Bottoms,
Up
driven,
which
is
like
lots
of
PRS
with
people
with
a
opinions
for
how
things
are
going
to
how
things
are
going
to
evolve.
And
it's
it's
an
organic
approach,
but
that
makes
it
really
hard
for
the
rest
of
us
who
are
writing
chapters,
because
we
don't
know
what
information
we
have
to
rely
on
and
build
on.
A
So
if
I
don't
know,
what's
going
to
be
in
the
chapter
about
strategy,
it's
really
hard
for
me
to
write
a
chapter
about
metrics
because,
what's
going
to
happen
and
I
I
will
guarantee
that
this
will
happen
with
the
book.
Is
that
you
know
if
it's
done
on
kind
of
a
chapter
by
chapter
basis,
without
a
little
bit
of
direction
for
the
scope
of
those
chapters?
You
will
end
up
with
a
ton
of
duplicate
content
that
we're
going
to
have
to
merge
out
later.
A
C
I
mean
when
I've
edited
books.
We
really
tried
hard
to
lay
out
a
structure
for
for
the
chapter,
so
they
had
some
consistency
and
we
also
tried
to
be
clear
about
the
purpose
when,
when
soliciting
authors
for
chapters
and
and
I
think
I
have
an
open
issue
and
I
haven't,
checked
I
I
apologize
Anna
if
there's
been
a
comment
on
it,
but
my
question
is:
is
in
terms
of
the
scope
of
the
book,
what
what
is
the
are
there?
Is
it
kind
of
like
this?
C
B
So
I've
served
so
I
think
it
will
be
more
clear
once
we
merits
the
pr
that
is
related
with
the
chapter
on
a
strategy
based
on
Don's
comments,
although
we
we
already
have
something
that
can
act
as
a
baseline
on
expectations.
So
what
I've
said
is
the
chapter
zero
that
talks
about?
What
is
this
book
about
like
what
are
the
expectations?
What
people
might
be
finding
this
book?
B
But
it's
not
this
book
and
who
should
read
this
book
and
then
there
is
a
taxonomy
Marathon
file
that
serious
about
like
the
expected
structure
of
each
of
the
chapters
and
the
different
categories
that
we
might
find,
but
again
I.
This
is
like
the
Baseline
and
I
think
us
John
was
mentioning
if
you
want
to
Deep
dive
more
into
the
metrics
content.
B
What
I
see
clear
is
that
you
cannot
keep
moving
forward
until
the
strategy
chapter
is
merged
and
when
it's
Mercy
smears
like
we
might
have
like
slightly
small
comments
later,
but
once
it's
merged,
it
means
that
the
community
we
already
have
the
community
call.
The
community
had
plenty
of
time
to
leave
their
comments
to
serve
and
to
review.
So
that
will
happen.
I
hope
that
happens
during
this
month.
At
least
the
pr
opens
this
month,
and
it's
close
for
next
week
next
month
in
July.
If
that
can
help.
B
So
you
can
add
it
to
girls,
so
I
think
it
was
scare
the
one
that
added
that
that
a
specific
issue,
if
it's
something
related
with
the
recent
Trends
on
open
source,
it
makes
sense.
You
included
that
and
leave
a
comment
to
girls
issue.
If
it's
a
completely
different
suggestion
I.
My
suggestion
is
just
to
open
an
issue
and
the
maintainers
of
the
hospitality
repo.
What
they
will
do
is
suck
it
as
an
Oscar
book
issue
and
we
and
we
will
promote
during
the
mailing
list.
B
E
So
I
I,
thank
you.
Anna
for
I'm
I
mean
walking
us
through
this.
It's
my
first
time
on
this
call
and
in
this
meeting
so
I
also
did
realize
that
there's
a
contributing
markdown
like
documents
there,
which
I
mean
doesn't
have
enough
like
details.
So
if
I'm
not
sure
what
the
plans
are
for
that,
but
I
would
I
would
be
interested
in
learning
more
about
like
the
different
ways
that
people
can
contribute
to
this
like
there
yeah.
B
Yeah,
so
to
be
honest,
so
the
the
contribution
modern
file
needs
to
be
also
updated.
Like
we,
we
started
like
as
a
baseline
And
as
the
community
organically
grows.
We
might
need
to
be
like
more
specific
on
certain
topics,
so
I'm
glad
you
asked
and
I'm
glad
you
raised
this
issue,
because
it
means
that
maybe
we
need
to
add
more
documentation
to
the
contributing
file.
So
far
the
process
is
if
a
person
contributes
to
the
pull
request
and
it
sends
to
the
community
meetings
and
share
their
thoughts
and
contributes
in
the
mailing
list.
B
That
person
can
request
to
be
a
contributor.
They
can
request
it
through
the
mailing
list
or
opening
an
issue,
and
we
will
add
them
to
the
contributing
markdown
file.
If
we
we
will
ask
like
well,
where
were
your
contributions,
and
since
this
project
is
quite
recent,
it's
quite
easy
to
track.
That,
and-
and
that's
all
I
mean
everyone
is
welcome-
to
contribute,
and
if
you
have
any
issues
on
contributing
to
specific
topics,
just
let
us
know-
and
we
will
make
sure
that
you
have
all
the
access
and
rights
to
you
to
do
so.
A
You,
okay
well
in
the
interest
of
time
I'm
going
to
move
on
to
the
next
agenda
item.
So
we
talked
in
the
last
meeting
a
lot
about
project
viability
and
metrics
associated
with
it
and
I.
Think
Gary
has
done
some
some
work
on
this
at
Verizon
and
yeah
with
that.
I'll
turn
it
over
to
you
Gary,
and
you
can
tell
us
what
you
what
you've
learned.
A
F
People
have
chosen
to
make
a
lot
of
different
decisions
about
how
to
build
and
run
those
systems
and
we're
trying
to
figure
out
how
thin
that
can
really
get
and
how
much
overlap.
There
really
is
so
like
an
idea
of
viability
that
can
apply
more
generally
than
on
Java
projects.
This
makes
it
viable
or
on
this
particular
set
of
criteria,
makes
it
viable.
How
do
we
think
about
open
source
in
general
and
what
makes
a
project
usable
as
a
largely
regulated
entity?
F
I
wanted
to
do
this,
mostly
through
chaos,
because
I
think
that
this
working
group
in
previous
positions,
I've
always
noticed
that
the
metrics
focus
and
the
amount
of
rigor
that
goes
into
what
metrics
belong
in
ospo's
has
been
very
high
and
I
was
interested
in
in
kind
of
using
that
prior
art
to
help
build
this
model
and
I
haven't
actually
gotten
anywhere
coming
up
with
anything
that
that
hasn't
already
been
discussed,
which
was
also
part
of
the
exercise.
I
wanted
to
make
sure
that
I
I
wasn't
missing.
Anything
in
that
I.
F
Couldn't
think
of
anything
that
that
the
chaos
group
hadn't
thought
of
so
unfortunately,
I
don't
have
any
more
exciting
metrics
to
contribute,
but
I
do
have
a
model
of
metrics
that
I'd
like
to
share.
So
there's
plenty
of
nuance
and
overlap
between
these
buckets
of
like
what
makes
a
viable
product,
but
I
want
to
break
it
down
into
three
big
buckets
of
compliance,
security,
vulnerability,
reliability
and
governance,
and
then
community
and
Agility
I'll
wait
a
second,
because
I
can
see
that
you're
taking
notes,
so
compliance
vulnerability
and
security,
reliability
and
governance
and.
F
Vulnerability
and
security
all
together,
because
I
think
those
three
things
are
pretty
tightly
related.
The
second
bucket
is
reliability
and
governance,
and
the
third
bucket
is
community
and
Agility
all
right,
so
for
compliance,
vulnerability
and
security.
Oh
I'm,
sorry,
something
that
I
didn't
mention
before
I
get
in
the
buckets
as
a
consumer
of
Open
Source.
F
Many
of
the
metrics
that
are
available
on
chaos
pertain
to
running
events
and
how
to
measure
successive
community
and
those
aren't
things
that
I
think
are
hugely
important
for
large
consumers
of
Open
Source
and
are
more
important
for
maintainers
of
Open
Source
and
so
as
I'm,
going
through
kind
of
what
I
think
is
important.
I
want
to
keep
that
in
mind
that
I'm
not
right
now
looking
at
is
this
project
maintainable
I'm
looking
at?
Is
this
project
viable
to
use
so
all
right
for
compliance,
vulnerability
and
security?
F
Obviously,
openssf
has
a
set
of
best
practices.
They
have
scorecards.
They
have
a
lot
of
important
ways
to
measure
a
Project's
security
success
that
openss
best
practices
is
a
metric
that
I'm
very
interested
in
using
to
measure
the
security
of
a
product,
obviously
or
I'm,
going
to
stop
saying,
obviously,
because
I'll
say
it
over
and
over
again.
Licensing
is
another
important
part
of
compliance
for
us,
because
we
have
to
make
sure
that
we
can
actually
use
the
thing.
F
There's
a
lot
of
license
criteria
that
are
available
through
chaos
metrics,
including
the
license
coverage.
If
it's
an
OSI
approved
license
or
if
it's
even
got
a
license,
declared
on
the
dependency
and
then
lib
years
is
another
one.
That
I
think
is
going
to
be
very
useful,
being
able
to
see
how
old
a
dependency
or
how
old
the
dependencies
of
the
dependency
are
is
going
to
give
us
a
great
idea
of
like
do.
F
They
keep
up
with
security
patches
and
vulnerability
scanning
the
higher
the
libyer
gets
the
more
likely
that
they
are
not
keeping
up
with
it
and
upscreen
Upstream
code
dependencies
when
available
we're
very
interested
in
and
and
we
want
to
keep
track
of
so
I'll
pause.
There
I
said
a
whole
lot
of
things
and
say
see
if
anybody
wants
to
jump
in
and
kind
of
discuss
that
first
bucket
of
compliance,
vulnerability
and
security.
F
Going
once
going
twice:
okay,
I'm
going
to
keep
yammering
so
reliability
and
governance.
We
got
into
a
lot
of
different
metrics
here,
including
programming
language
distribution
issues
inclusivity
whether
or
not
the
issues
are
welcoming
and
giving
people
the
opportunity
to
contribute
felt
important,
because
if
there's
not
a
Community
Focus
with
how
we're
labeling
issues
and
putting
issues
together,
that
feels
like
the
governance
of
the
project,
needs
to
have
some
more
thought
put
behind
that
hello.
H
D
H
You
might
have
like
I
work
at
Google.
It's
probably
not
a
surprise
that
we
have
fairly
rigorous
compliance
office
around
what
we
expect
around
software
code,
Quality,
Maintenance,
quality
and
sort
of
other
characteristics.
That
might
not
just
be
these
sort
of
standard
metrics,
but
also
more
operationally
minded
metrics
that
are
aligned
with
your
own
compliance
and
policy.
So
I
didn't
know
if
you
wanted
to
account
for
that,
but
just
like
I
think
these
are
great
metrics
in
general.
F
Yeah
I,
that's
a
good
point
to
bring
up
because
I
think
one
thing
I
do
know
about
Google's
compliance
is
there's
no
agpl
whatsoever
for
any
reason
or
so
says,
open,
source.google,
I,
think
and
I
think
that
we
don't
have
like
a
lot
of
really
hard
and
fast
rules
like
that,
because
the
products
do
have
to
vary
as
much
as
they
do.
I
know.
F
Google
also
varies
widely
in
the
amount
of
products
that
they
create
because
they
have
probably
a
lot
of
the
same
constraints
with
their
five
product,
but
I
think
that
the
internal
context
is
is
definitely
wrapped
into
compliance,
vulnerability
and
security
right.
That's
a
really
good
point
to
bring
up
that
if
you
have
extra
context
to
bring
up
that
that
does
fit
there.
F
Documentation
usability
feels
really
important,
because
if
we
can't
expect
to
actually
learn
how
to
use
the
project-
or
it's
not
very
easy-
to
learn
how
to
use
the
project
I'm
thinking
about
this
in
terms
of
like
is
there
even
a
doc
site,
is
the
doc
site
even
regularly
updated?
Is
there
a
way
for
us
to
measure
that
that
feels
like
something
that
we
can
compare
between
projects?
F
F
They
largely
depend
on
the
governance
around
what
their
targets
are
for
being
able
to
resolve
issues
and
respond
to
defects,
especially
defects
in
particular,
because,
ideally,
a
vulnerability
is
disclosed
to
the
maintainers
of
a
project
before
it's
posted
to
any
kind
of
public
site.
So
their
resolution
is
dependent
highly
on
when
they
receive
that
that
defect
and
when
they
resolve
it
all
right.
F
Then
that's
interesting
and
important
to
know,
because
I
I
think
it
would
indicate
that
there's
not
a
whole
lot
of
transparency,
if
there's
only
contributions
that
are
coming
in
as
code
and
there's
not
issues
tied
to
them.
Change,
requests
kind
of
fits
that
same
Narrative
of
people
do
reviewing
and
evaluating
their
code
in
a
way:
that's
transparent
and
open
and
committers.
Just
counting
how
many
people
are
if
working
on
the
project.
F
I
think
can
be
useful
as
a
measure
of
popularity
over
time
to
say
that
the
committers
either
jumped
or
dropped
on
specific
times
or
regarding
specific
decisions
around
the
project.
So
I
plan
on
using
a
collection
of
these
metrics
to
make
determinations
about
how
these
buckets
score
and
then
give
recommendations
of
either.
This
is
something
that
Verizon
can
you
in
all
of
their
projects.
F
This
is
something
that
Verizon
can
only
use
in
some
projects,
or
this
is
something
that
Verizon
can't
use
at
all,
or
they
can
use
it
on
everything,
as
that
gets
more
and
more
nuanced
I'm
sure
that
I'll
have
more
interesting
discussions
to
bring
up
about
very
specific
parts
of
this
model.
So
that's
kind
of
my
Spiel.
That's
everything
that
I've
been
compiling
from
chaos.
F
F
But
if
we're
seeing
an
average
of
like
generally
higher
on
one
project
and
that
ecosystem
compared
to
another
project
in
the
ecosystem,
so
I'm
picturing,
two
projects
that
both
use
npm
and
both
stay
on
the
the
most
old
long-term
service.
Then
that
should
normalize
between
those
two
that
we
can
make
kind
of
an
Apples
to
Apples
comparison,
the
it
it's
like
a
difficult
problem
and
it
does
at
the
end
of
the
day,
kind
of
need
to
be
a
judgment
call
of
like
do.
We
think
that
this
project
is
viable.
F
Here's
some
metrics
that
we
have
and
here's
the
reasoning
that
we
used
with
those
metrics
to
make
this
choice.
I
think
that
this
Nuance
of
like
direct
dependencies
versus
secondary
or
tertiary
dependencies,
is
going
to
be
very
much
part
of
that
that
we're
trying
to
back
up
with
metrics
but
is
pretty
hard
to
make
as
a
call.
That
isn't
also
somewhat
like
a
determination
from
somebody
who
actually
works
in
the
open
source
program
office.
A
E
A
F
A
D
C
C
I
might
start
with
just
you
have
your
three
categories,
and
maybe
just
a
metrics
model
into
those
categories
is
one
way
to
think
about
creating
smaller
metric,
not
smaller
metric
models.
Just
because
large
metrics
models
are
sort
of
like
large
pull
requests,
they're
hard
to
hard
to
integrate
absolutely.
F
F
F
B
A
question
yeah
so
regarding
the
buckets
that
you
commented
and
as
a
way,
maybe
to
try
to
align
with
all
the
working
groups
that
I've
seen
that
there
are
somehow
like
working
on
on
the
wording
and
having
like
a
Common
Language.
So
one
of
the
things
that
were
discussed
when
creating
the
hospital
definition
next
release
was
to
define
the
hospital
in
like
what
is
the
hospital.
B
How
is
the
hospital
evolving
and
who
is
in
the
hospital
and
one
one
of
the
sentences
working
on
a
framework
on
compliance
and
security,
Community
governance,
so
developing
a
framework
that
has
these
three
buckets
and
I
think
there
was
a
missing
one,
but
maybe,
since
the
hospital
definition
might
have
that-
and
it's
like
a
broad
term
like
governance,
community
and
compliance,
and
the
same
that
scary
was
mentioned
in
these
three
brackets.
Maybe
When
developing
this
matrix
model
having
the
same
wording
might
be
useful
and
with
that
I
want
to
ask.
B
F
G
A
Okay,
well,
thank
you
so
much
Gary
for
for
all
of
the
the
updates.
This
is.
This
is
an
incredible
amount
of
work
and
thinking
about
something
for
in
a
relatively
short
amount
of
time,
and
we
we
appreciate
you
taking
the
time
out
to
to
share
this
with
us,
because
I
do
think.
It's
a
really
I
think
it's
a
really
interesting
way
of
looking
at
project
viability
for
sure
and
I
yeah
and
I
look
forward
to,
hopefully
collaborating
on
some
of
the
the
metrics
models
that
might
eventually
come
out
of
this.
A
A
A
Going
once,
okay,
that's
fine,
I
would
say
if
you
think
of
any
things
feel
free
to
start
the
agenda
for
next
week.
We
do
have
one
thing
that
is
already
on
the
agenda
for
next
week,
and
that
is
the
maturity
model
that
Matt
wanted
to
talk
about
so
I
I
punted
this
to
next
week,
because
Matt's
I
think
moving
a
kid
into
college.
So
it's
that
that
time
of
year,
so
he
should
be
around
for
the
for
the
next
meeting.
A
A
Anything
else
anyone
wants
to
wants
to
bring
up
in
the
remaining
eight
minutes
that
we
have
our
three
minutes
that
we
have
left.
I
can't
remember
how
long
these
meetings
are.
Elizabeth.
Keep
me
on
track.
Do
we
end
at
a
quarter
till
or
10
tell
I
know
I
asked
you
guys,
like
a
million
times
technically
a
ten
till,
but
if.
H
A
G
I,
don't
I
don't
have
any
questions
but
I
have
a
comment:
I
think
hearing
about
the
book
chapters
and
some
of
the
documentation,
along
with
Gary's
ideas
for
some
models.
I
think
this
is
exactly
what
ospo's
need,
and
so,
if
we
can
keep
those
conversations
going,
that'd
be
great
and
I
really
I
really
enjoyed
today's
meeting.
So
thank
you
all.