►
Description
Meeting notes: https://docs.google.com/document/d/1ttqkcYPmYZyqvtkaHs92bx2UeVUiXDhuzP-0WbP11Fw/edit#heading=h.7o2ubzl5z39r
A
B
A
A
A
A
A
C
B
Idea,
I
know
that
there
was
some
feedback
that
you
had
gotten
from
the
end
users
group
for
the
SCM
guide,
and
there
was
some
feedback
that
I
had
gotten
from
sharing
it
with
the
to-do
group.
I
believe
we
wanted
to
talk
about
that.
We
also
wanted
to
talk
to
Norm
if
he
joined
about
any
changes
related
to
the
structure
like
regenerating
in
I
have
to
remember
exactly
what
but
I
remember
that
there
was
some
like
little
things
that
are
in
the
guide
right
now
that
we
may
or
may
not
want
in
there.
B
We
also
wanted
to
talk
about.
There
was
some
links
that
in
the
documents
that
I
created
that
didn't
really
go
to
any
new
material
because
we
didn't
have
them,
for
example,
the
operations
there
are
some
things
that
don't
link
to
actually
don't
have
any
links,
actually
any
content.
So
we
wanted
to
talk
about
that
and
I
think
we
may
also
want
to
talk
about
the
roadmap
in
general.
C
C
C
A
B
B
If,
because
one
of
the
main
concerns
is
that
there
might
be
some
drift
like
some
policies
could
be
like
put
together
and
applied,
but
over
time
there
would
be
some
drift,
so
they
were
really
more
interested
in
a
framing
around
why
it's
important,
but
also
how
to
kind
of
continually
enforce
those
policies.
So
they
were
looking
for
advice
around
tooling
or
anything
that
might
actually
help
with
that
effort,
and
they
mentioned
some
gaps
that
might
exist
in
GitHub
that
don't
allow
you
to
do
things
like
policy
as
code.
D
B
D
B
Yeah
they
were,
they
were
they
they
actually
specifically,
it
could
be
like
something
like
run,
those
continuously
but
I,
guess
that's
not
really
mentioned,
or
if
there
was
like
any
tools
that
help
people
do
this
easily.
They
were
also
looking
at
things
like
safe
settings.
Let
me
see
if
I
can
drop
the
links.
Let
me
just
drop
my
notes.
Yeah.
B
B
A
What
you
said,
I
was
just
gonna,
say
or
I
said.
Maybe
we
need
to
first
of
all
explicitly
mentioned
legitify
considering
the
best
practice
info
is
coming
from
there,
and
also
maybe
we
need
a
the
section
of
the
intro
which
is
talking
about
tools.
We
could
talk
about
legitify,
we
could
talk
about
scorecard
because
I
know
scorecard
is
planning
to
add
or
they
have
their
their.
A
B
A
B
B
They
said
that
would
be
helpful
like
and
right.
The
the
example
they
actually
said
is
that
when
license,
compliance
was
sort
of
like
kicking
off
and
people
talk
about
that.
A
lot
of
best
practices
would
be
shared
because
that's
usually
the
best
first
step,
but
now
a
lot
of
those
groups
that
I've
been
working
together
have
been
actually
sharing
data
in
terms
of
how
are
they
using
it
internally
at
their
companies
and
actually
sharing
not
just
the
best
practices
but
actually
data.
But
this
is
how
you
should
set
things
up.
B
It's
a
little
bit
more
opinionated,
but
in
the
beginning
it
might
have
been.
People
were
a
little
bit
more
reluctant
to
share
like
the
posture
for
how
they're
doing
compliance
good
reasons,
but
now
they've
kind
of
gotten
over
that
that
Hub
and
they
think
that
we
should
probably
also
move
towards
that
direction.
C
D
A
I
mean
because
I
was
thinking
you
know,
simplistically
speaking,
we
could
have
a.
We
could
set
up
a
discussion
in
the
GitHub
that
and
encourage
people
to
ask
questions
and
then
use
that
as
a
way
to
to
oh
hey,
we
didn't
address
that
issue.
That's
to
you
know
to
prompt
us
or
in
general
to
to
add
things
or
or
be
clearer
about
something.
B
Yeah
that'll
be
useful.
I
know
that
the
reason
why
some
of
the
feedback
was
coming
because,
within
the
2D
group,
they
also
have
like
a
GitHub
area
for
a
to-do
group.
So
if
they're
discussing
things
like
job
descriptions,
you'll
see
a
bunch
of
companies
will
drop
like
a
markdown
file
in
the
job.
Description
is
very
opinionated
for
them,
or
or
for
other
ways
that
they
set
up
certain
things
how
they
do
policies,
how
they
do
things
like
contributing
guidelines
and
those
are
really
useful
for
somebody.
B
Who's
new
and
trying
to
set
up
something
similar
have
an
example
to
look
at
so
that's
kind
of
like
where
they're
coming
from,
like
a
lot
of
people,
share
these
so-called
case
studies
and
because
somebody
could
come
and
say:
oh
yeah.
This
is
the
case
study
for
how
say
F5
set
up
their
sem
best
practices
guidelines,
and
it's
just
it's
more.
A
Good
feedback,
positive
feedback
I
mean
I'm.
Looking
at
the
notes
from
the
end
user
working
group
call
right
now
and
one
of
the
things
that
came
up
was
somebody
Jacques
asked
about
the
relationship
with
other
open
ssf
work
and
is
there
into?
Is
there
an
intersection
with
salsa
and
scorecard,
and
I
did
mention
that
we'd
already
talked
to
scorecard
folks,
so
that
was
in
hand,
but
I
don't
have
enough.
A
D
So
you
have
the
source
code,
the
the
build,
the
CI,
the
artifactory
registries
and
the
deployment
and
and
this
documents
like
checks,
many
of
the
requirements
for
the
source
code
part
because
they
require
that
you
have
a
code
review.
So
we
have
a
policy
for
that
and
they
require
that.
You
have
a
SSO.
B
B
A
A
Open
source
program
office-
wow
right,
sorry
so
like,
and
because
this
is
the
end
user
group
we
were
talking
with
end
users
in
the
in
their
in
their
language
means
big
companies
that
that
are
using
open
source,
so
are
likely
to
have
something
like
an
open
source
program
office,
but
but
are
less
contributory
than
technology
companies
right.
So
the
example,
the
main
example,
or
not
the
main
example,
but
one
example
is
Citibank
Jonathan
who
chairs
the
group
is
from
Citibank.
A
So,
but
you
know
so,
banks
are
an
example:
Health
Care,
that's
the
kind
of
company
that
we're
talking
about
and
a
lot
of
them
have
open
source
program
offices
that
that's
not,
and-
and
also
it's
not
it's
a
very
as
discussed
many
times
in
this
group.
It's
a
very
kind
of
fuzzy
definition
of
what
an
end
user
is,
and
also
it's
not
an
end
user
in
terms
of
like
the
person
walking
along
on
the
street
with
their
phone,
which
is
my
definition
of
an
end
user.
A
So
we
heard
from
somebody
who
said
that
there
was
that
they
were
part
of
a
financial
related
osbo
community
and
that
they
would
raise
and
raise
awareness
of
this
work
there.
And
then
we
might
get
some
feedback
from
that
channel
and
basically
I
just
offered
myself
up
to
funnel
any
feedback,
and
so
far
I
haven't
received
much
additional
feedback.
But
that
was
just
last
week.
So.
E
I
actually
also
started
presenting
that
internally
at
Microsoft
and
did
get
a
number
of
kind
of
technical
questions
about
the
scalability
of
some
of
those
of
the
rules
and
I.
Think
that
brings
back
to
the
difference
between
organizations
which
have
many
open
source
activity
and
both
as
maintainers
and
that
consumers
versus
those
that
consume,
like
specifically
I
was
asked
about.
Things
like
Enterprise,
should
not
allow
members
to
create
public
proposal.
Invite
outside
collaborators,
which
is
for
us
at
Microsoft.
E
B
Yeah
and
that's
that's
actually
useful,
because
even
within
us,
as
we're
kind
of
like
going
in
and
trying
to
implement
this,
we
are
certain
orgs
will
sort
of
have
different
styles
of
doing
things,
and
this
is
where
like
I
was
saying,
the
case
studies
could
help,
because
even
internally,
if
something
is
like
the
samples
we
may,
we
may
allow
them
to
do
more
or
and
I
think
that
actually
did
come
up
for
that.
That
did
come
up
in
our
discussions.
B
They
said
that
different
orgs
might
have
different
security,
setups
or
so
even
just
kind
of
like
knowing
that
if
she
had
like
a
case
study
or
something
like
if
you
have
like
a
main
or
which
is
like
your
crown
jewels,
you
probably
want
to
be
a
lot
more
stricter
about
it.
But
if
you
have
something
that
is
more
like
experimental
or
demos
or
something
that's
accordingly,.
A
C
D
Yeah
I
I
think
like
we
propose
a
best
practices
document,
it's
not
mandatory
for
everyone.
You
know
to
apply
all
the
policies,
but
I
I
think
we
we
see.
This
is
in
one
of
the
meeting
that
we
we
tag
each
policy
with
with
the
audience
it's
it's
related
to.
So
maybe
some
policies,
and
maybe
we
can
like
all
this
Enterprise
policies
to
tag
them
that
only
for
like
closed
Source
organizations
and
or
something
like
that
or
just
in
the
in
the
beginning,
to
be
more
precise
on
with
the
audience
or
how.
D
D
E
A
Okay,
make
sure
that
if
you
gotta,
if
you're,
to
take
care
of
private
thing
and
make
it
public,
then
make
sure
that
it
has
a
a
license,
make
sure
that
it
has
this
and
that
and
that
you've
done
all
these
checks
and
stuff,
like
that.
That's
another
kind
of
best
practice
use
case
type
study
that
I'm
sure
might
be
useful.
Actually
for
many
organizations.
B
Yeah
I
did
have
a
section
in
in
my
our
internal
document
that
talked
about
with
the
context
of
this
when
you're
going
from
private
to
public.
What
are
the
checks
that
you
want
to
make
sure
that
are
in
there?
It
was
in
the
operations
section,
but
I
didn't
like
pass
out
the
operations
into
all
of
these
different
types
of
things
that
you
could
be
doing.
C
D
A
B
A
B
B
A
D
D
A
C
A
B
A
A
A
A
Perspective
I
know
no
one's
always
talking
about
red
map,
and
that's
very
that's
really
good.
We
should
right
now
this
data
is
only
available
it,
but
the
URLs
for
these
data
for
these,
for
everything
is,
you
know,
github.com
ossf,
slash
blah
blob,
slash
this
slash
that,
where
it
has,
it
probably
should
be
had
a
more
like
published
out
of
more
friendly
URL.
A
A
B
B
Another
meta
question:
maybe
for
Gnome
like
for
some
of
these
things
that
I
would
say
like
Azure
or
some
of
the
new
things:
do
they
get
added
as
one
off
separate
markdown
files
or
do
they
kind
of
go
through?
It
gets
added
to
legitify
and
then
from
legitify
gets
regenerated.
What's
the
best
way
to
do
this.
D
D
B
I
think
that
might
be
also
useful
is
I'm.
Just
gonna
drop
a
link
for
an
example
of
what
one
of
the
legitify
as
actions
can
approve,
pull
request
dot
MD.
If
you
look
at
that,
it
seems
like
there
is
some
sort
of
like
structural
format
to
how
you
name
certain
things,
including
like
the
for
this
particular
link.
I
have
policy
name
actions,
understood
kind
of
food
like
that
is
actually
listed
in
there.
Is
there
something
that
you
want
to
for
the
new
stuff
to
have
some
kind
of
similar
format
or
a
proof,
format
or
yeah.
B
E
F
Is
there
any
acceptance?
Criteria
for
like
which
you
know
obviously
GitHub
is
is
very
huge
in
open
source
right,
I
I
I'm,
not
my
intention
isn't
to
gatekeep
what
sem
services
are
being
allowed,
but
I'm
just
asking
the
question
is:
is
this
meant
to
be
all-encompassing?
Just
if
ever,
if
something
is
out
there,
people
are
using
it.
There
should
be
some
tailored
best
practices
for
that.
A
I
think
the
idea
was
when
we
started
off
with
GitHub
and
gitlab
is
to
be
able
to
say:
okay
well,
let's
start
with
those
and
then
and
then
expand
to
other
sem
platforms
as
appropriate
and
I.
Don't
know
what
the
acceptance
criteria
should
be.
I
think
it's
up
to
us
to
figure
out
what
the
acceptance
criteria
should
be.
A
B
B
E
Can
I
also
offer
Maybe
impact
on
open
source
supply
chain,
because
I
guess
open
source
like
ossf
is?
Its
intention
is
not
to
provide
open
source
security
tools
right
to
to
increase
the
level
of
security
in
open
source
like
software,
so
maybe
one
metric,
which
we
can
add
new
scms
is
based
on.
Does
it
allow
for
open
source
projects.
A
F
F
F
C
B
A
C
A
B
D
B
C
D
A
A
Okay
and
I
and
I
went
through
the
minutes
just
now
and
I
I
folded,
some
some
things
that
we
talked
about
doing
so
I
think
we've
got
enough
to
Do's
out
of
this
meeting.
That
was
quite
useful.
Actually,
so
what
I
was
going
to
suggest
is
that,
if
possible,
so
when's,
our
next
best
practices
I
think
our
next
best
practice
is
full
working
group
call
is
next
Tuesday
and
what
I
will
try
to
do
is
get
some
PR's
some
of
these.