►
From YouTube: Scorecards Biweekly Sync (December 15, 2022)
A
A
C
A
B
A
A
D
C
Have
a
contact
us
sort
of
link
and
we
do
get
you
know,
hey
my
projects
scorecard
result.
Has
these
things
that
I'd
like
to
see
better,
so
we
try
and
pass
that
along,
but
certainly
also
interested
in
scorecard
badges
and
and
for
any
of
the
particular
checks
ways
that
we
see
that
across
the
ecosystem.
So.
D
D
D
So
if
you
have
it
as
another
sub
action,
it's
it's
not
going
to
do
any
of
scorecard
things,
but
it's
just
going
to
take
the
dependency
differences
and
go
hit
the
API
and
get
the
score
for
them,
and
it
should
be
more
configurable.
So
essentially,
I
can
say:
hey
ignore
this.
This
dependency,
because
I
know
it's
bad,
but
I
do
know
that
or
I'm
only
interested
in
this
in
this
area
of
score,
I,
don't
care
about
fuzzing.
D
A
D
But
the
second
point
is
like:
if
we
enable
with
pull
requests
because
scorecard
runs
for
uses
tokens,
we
there's
a
throttling
of
the
tokens
we.
The
idea
of
this
is:
they
should
not
have
to
use
any
of
those
things,
because
we're
just
going
to
get
the
difference
in
dependencies
and
go
hit.
The
scorecard
API
for
just
the
score
of
that
was
what
are
the
new
Divinity
that
came
in
and
what
to
score
on
them.
That's
all.
It
is,
and
at
least
my
thought
process
not
to
have
any
failure.
D
Success
have
them
have
that
as
a
message
in
the
in
the
pull
request,
so
people
get
to
decide
and
later
based
on
response.
We
designed
without
all
that's
my
initial
thought
process
just
to
do
a
demonstration
for
this
group,
so
that
then
we
can
get
feedback
as
hey,
which
way
do
we
want
to
go
blah
blah
blah.
That's
what
I'm
working
on.
A
A
D
A
A
A
A
B
D
D
A
D
I,
don't
know
the
answer
to
be
honest
right,
but
they
said
hey.
We
don't
want
you
giving
us
scores
like
like
we
take.
We
ding
somebody
for
negative
two
for
here
negative
four,
for
here
we
decide
that
and
they
don't
want
that.
And
ideally
that
means
whatever
we
we
do,
plus
or
minus.
We
need
to
be
in
two
different
buckets
what
we
come
up
with
and
then
they
decide
whether
is
this
a
plus
or
a
minus.
A
Yeah
so
I
think
we
have
so
we
have
a
a
document
that
we
we
want
to
share.
Broadly
I.
Think
we'll
do
that
in
January,
where
we
basically
want
to
give
more.
You
know
more
information
about
criticality
and
things
like
this,
so
that
people
could
maybe
look
at
the
critical
alerts
like
the
medium
alerts
and
make
this
more.
You
know
easy
to
to
display
and
I
think
that's
something
that
devs.dev
team
also
told
us.
A
They
would
like
to
see
because
score
are
too
like
it's
hard
to
it's,
how
to
make
sense
out
of
scores.
It's
not
always
clear
what
they
mean.
So
do
you
think
that's
something
that
would
help.
Maybe
we
should
share
the
we
need
to
share
the
document
first,
but
it's
basically
a
way
to
to
make
the
results
that
we
have
today
more
structured.
D
A
D
A
A
B
Yeah
so
I
just
wanted
to
relay
a
concern.
I
haven't
talked
to
Caleb
yet,
but
essentially
I
think,
there's
they're
getting
some
more
contributors
on
that
project
and
they're,
mostly
in
like
Australia
time
zone.
So
I,
don't
know
if,
like
yeah,
like
I,
know
like
Lauren,
you've
helped
out
on
reviewing
All-Star
PRS,
like
you
know,
for
all
the
go
projects
that
we
have
here
in
openssf
I
feel
like
we
can
help
out
with
reviewing
PRS
from
other
projects.
Even
if
we're
not
maintainers
so
I
was
just
thinking.
B
D
I
think
it
makes
sense
the
only
problem
with
this.
Unless
you
you
know
what
are
the
nuts
and
or
you
have
to
know
to
an
extent
before
you,
you
can
point
out
basic
stuff
yeah,
but
the
intricacies
of
why
somebody
made
a
decision
unless
you
have
some
in-depth
knowledge
and
becomes
harder.
My
two
cents
on
that.
D
B
B
Can
be
yeah
but
like
just
for
code,
yes
type
of
view,
I,
don't
know
so
I'll
chat
with
Caleb,
because
this
was
in
our
criticality
scores.
Part
of
this
critical
reporting
Group,
which
happened
this
morning.
So
I'll
chat
with
Caleb
and
see
what
he
thinks
too,
and
maybe
we
can
have
some
kind
of
you
know,
sharing
pool
in
the
future,
but
just
wanted
to
throw
that
out.
You
out
there
to
see
if
anybody's
interested,
yeah.
D
A
D
A
D
One
thing
that
we
also,
we
should
probably
plan
for
like
q1
release
or
like
whatever
we're
working
on
we'll
be
having
a
degree.
State
I
spoke
about
this
last
last
last
meeting
having
a
release
date
helps
and
figuring
out
what,
like
example,
if
and
that
what
I'm
going
to
demonstrate
next
week
it'll
be
nice.
If
we
decide
hey
it'll,
be
nice.
If
we
skip
pulling
all
these
changes
and
do
a
One
release,
it'll
be
nice.
We
should
probably
talk
about
this
in
the
next
meeting.