►
From YouTube: Scorecards Biweekly Sync (January 12, 2023)
A
B
C
C
C
C
F
Yeah
sure
so
a
structured
result
is
something
I
brought
up
in
the
past
maybe
a
month
ago.
So
the
idea
here
is
that
the
current
Json
results
that
we
we
have
are
basically
a
list.
So
you
have
the
checks
and
then
you
have
a
list
of
results
which
are
strings,
and
that
makes
it
difficult
for
people
to
write
automated
tools
to
act
upon
those
results,
because
it's
not
very
structured.
F
F
F
That's
basically
the
so
every
check
is
basically
divided
into
rules
and
each
rule
is
defined
with
a
yaml
file
which,
with
all
the
all
the
information
about
the
rules
such
as
you
know,
its
risk,
its
remediation
and
so
on
and
so
forth.
So
you
can
think
of
a
rule
as
like,
a
more
granular
version
of
a
check
and
we're
hoping
that
those
rule
can
explicitly
tell
people
what
what
the
result
is
about.
F
So
in
this
case
here
the
rule
is
called
GitHub
workflow
permission
top
no
right,
which
means
that
it's,
the
the
the
token
permission
in
the
workflow,
are
not
defined
at
the
top
level
of
the
workshop
or
nothing.
Maybe
after
we
can.
We
can
look
at
the
the
yaml
file.
I'll
continue.
I'll
continue
on
this,
the
the
finding
also
has
so
it
has
a
risk.
It
has
an
outcome
which
is
either
negative
positive
and
maybe
it
could
also
be
like
not
supported
or
yeah,
maybe
not
supported.
F
F
The
remediation
section
is,
as
you
can
imagine,
the
remediation
it's
supposed
to
be
granular
enough,
so
that
you
have
the
exact
step
to
remediate.
This
is
something
today
that
we
don't
have.
For
example,
if
you
look
at
the
pin
dependency
check
depending
on,
if
it's
a
python
result
or
dockerfi
results
or
I,
don't
know
an
npm
result,
users
need
to
need
different
remediation
steps,
and
we
don't
have
that.
You
know
that
level
of
accuracy
or
like
that
level
of
detail
in
the
in
the
in
the
remediation
section
of
the
check.yaml.
F
The
risk
levels
also
is
something
that
we
think
can
help
visualize
visualization,
so
you
can
imagine,
for
example,
Michael
who
works
on
depths.dev
could
maybe
show
all
the
critical
results.
All
the
I
don't
know
medium
results
and
and
use
that,
in
combination
with
the
effort
to
to
help
users
prioritize.
F
The
reason
that
we
have
a
risk
per
rule
is
because,
in
the
past
we
had,
you
know
the
risk
was
at
the
level
of
a
check,
but
often
time
in
the
check.
You
know
some
some
part
of
the
check
of
the
chicks
were
you
know,
maybe
critical
or
like
high
risk
results,
and
other
thoughts
were
like
low
results.
So
we
were
not
able
to
adjust
the
the
level
of
the
risk
when
we
reported
the
results.
F
C
F
C
F
F
F
I
might
actually
remove
the
shot
on
the
in
the
description
field
and
keep
just
one
because
they're,
basically
the
same
I
added
like
a
motivation
field,
to
explain
what
the
what
the,
what
the
check
actually
does
and
why
it's
important
a
field
for
implementation
to
explain
how
we
implement
it.
If
it's
relevant
to
users
and
then
under
the
remediation
field,
you
can
see
the
effort
and
the
text.
F
F
F
You
know
what
a
rule
should
be
so
that
it's
kind
of
stable
over
time.
For
example,
here
I
called
the
role
you
know
no
top
level
permissions
defined,
so
I
think
I
could
also
have
called
it
default
permissions,
but
I
took
the
view
that
later
on,
we
might
want
to
have
another
rule.
That
says:
does
the
org
level
default
permission?
F
G
The
results
so
I
think
that
that
is
maybe
that's
maybe
like
implementation
detail
for
like
per
Org,
the
the
rule
I
mean
maybe
has
a
name
that
is
some
concatenation
of
like
rule
outcome,
risk
or
whatever
fields.
We
want
to
add
and
right.
So
it's
like
permissions.
You
know
top
level
the
high
blah
blah
blah
right,
but
yeah
we
should.
We
should
decide
on
what
the
schema
looks
like
before
before
sliding
it
in.
C
A
C
A
C
B
F
C
But
if
you're
writing
automation,
numbers
are
easier
to
because
nobody's
going
to
manually,
look
at
this
yaml,
my
two
cents.
Oh
it's
a
Json
people
are
going
to
write
some
automation
to
oh.
If
it's
four
I
need
to
go,
do
this
into
writing
strings
hello.
Do
I,
need
the
uppercase
it
if
we
change
our
casing,
for
whatever
reason
that
breaks
somebody
else.
So
numbers
are
easier.
My
two
said
foreign.
G
Beat
me
to
it,
but
yes,
plus
one
to
the
whole:
it's
a
breaking
change.
It's
a
it's
a
reasonably
large
breaking
chain
for
dropping
we're,
dropping
Fields
out
of
trucks,
we're
adding
new
Packages,
Etc
I.
Think
there's
a
way
to
reason
about
this,
where
we
bring
it
into
I.
Think
we
need
a
larger
discussion
about
I.
Think
we've
brought
it
up
in
the
past,
but
like
what
do
we
respect
semper
like?
Do
you
like
what
happens
when
an
API
changes?
How
do
we
message
that?
G
You
know,
you're
gonna
have
the
task
of
trying
to
continually
make
sure
that
the
pr
stays
up
to
date
until
you
can
land
it
for
a
V5.
So
like
that
suggests,
is
it
a?
Is
it
an
experimental
package?
Is
it
a
V5
tracking,
Branch
future
Branch,
whatever
you
want
to
call
it?
How
do
we?
How
do
we
talk
about
that?
Because,
because
I
imagine
that
we'll
have
we'll
have
more
large
PRS
that
we
don't
want
to
that?
We
don't
want
to
become
stale.
C
G
So,
let's,
let's,
let's
simplify,
hold
on,
let's,
simplify
because,
like
this
anything
that
is
anything
that
we
have
exposed
is
the
API
right.
So
anything
that
is
in
this
repo,
that
is
an
exported
method.
Type
Etc,
is
part
of
our
API.
However,
people
consume
it
whether
it's
in
bigquery.
What
have
you
if
someone?
If
someone
is
writing
a
package
built
on
top
of
scorecard
like
scorecard
action?
That's
part
of
their
API.
F
All
right,
okay,
so
I'll
start
with
the
rest.
Api
I,
don't
see
this
format.
Replacing
the
old
one
I
think
would
be
a
different
one
and
the
API
would
just
I
haven't
chatted
with
your
azim
or
how
it's
done
now,
but
I
don't
think
we
would
deprecate
the
old
the
old
results
simply
because
I
think
some
users
might
actually
prefer
when
they
run
on
the
CLI,
but
it
gives
them
strings
rather
than
this
Big
Blob
of
data,
because
that's
a
lot
harder
to
read
for
a
human.
C
F
D
C
F
That's
how
I
see
it
for
the
API
that
scorecard
has
so
in
terms
of
stale.
You
know
a
different
branch.
What
Stefan
said
I
think
once
this
PR
is
merged,
it
should
be
pretty
easy
to
it's,
not
gonna
break
like
the
rest
of
the
code.
I
think
it
can
live
in
the
same
code
base.
I
know
it's
not
very
explicit
on
our
readme,
but
I.
Don't
think
scorecard
guarantees
anything
similar
like
somewhere
wise
for
the
API
that
we
have
like
the
the
go.
F
G
F
B
F
H
F
H
F
H
One
of
the
patterns
that
I've
seen
is
like
you
know,
for
example,
in
the
GitHub
starter
workflows.
There
is
the
whole
code
scanning
section
and
I.
Think
scorecard
is
also
there
and
I.
Think
they're
probably
require
tools
to
upload
the
results
to
the
GitHub
code
scanning
API,
which
I
think
accepts
only
sorry
for
I,
don't
know
if
it
accepts,
because
that's
how
it
actually
gets
scorecard
results,
get
shown
in
the
getter
action
right.
F
F
G
H
H
So
you
know
so
I'm
just
wondering
like
if
there's
already
work
done
in
terms
of
you
know
whatever
problems
this
is
trying
to
solve.
Maybe
it's
sad.
If
you
know
group
has
done
done,
work
to
solve
those
problems,
and
so
just
wondering
if
in
fact,
I
didn't
even
know
whether
it's
sorry
for
not
so
I
was
just
trying
to
understand.
F
No
I
mean
that's
a
good
question.
I
think
serif
is
a
standard.
It's
a
huge
standard.
Virtually
nobody
actually
implements
it
fully.
So
GitHub
only
implements
and
understands
a
subset
of
serif
and
I
think
because
it's
so
big
and
so
complicated
that
no
one
I
mean
there
are
very
few
tools
that
actually
read
it
and
that's
my
understanding.
F
G
G
You
know
if
if
we
have
Concepts
that
overlap
it
if
it's
a
yeah,
if
it's
a
even
if
it's
a
subset
of
of
the
serif
implementation,
I
think
I
think
it'd
be
worthwhile
to
consider
doing
that
instead
of
the
because
I
I,
like
even
when
we
reference
extended
Json
extended
Json
is
defined
in
other
places
as
well
as
as
not
being
this,
so
we
should
so.
Where
are
there
respects
defined?
Let's
try
to
to
adhere
to
them
and
care
be
being
careful
with
the
nomenclature
because
extended
Json
is
a
thing
also.
H
Had
was
go
ahead,
the
only
other
thing
I
had
was
about
the
rule,
ID
that
you
know
I've
seen
that
the
rule
ID
doesn't
necessarily
have
to
be
a
number
as
long
as
it.
You
know
it
sort
of
stays
the
same
and-
and
you
know,
because
sometimes
it's
also
intuitive-
for
someone
to
be
able
to
see
a
rule
like
like
here's
an
example
from
code,
ql
and
I.
Think
some
of
the
other
tools
use,
like
you
know,
alphabets
Dash
number
so
just
wanted
to
mention
that.
A
F
F
C
Right
thinking
a
little
further
down,
if
we
intended
the
example,
we
intend
to
replace
our
standard
Json.
What
does
extended
Json
then
bringing
that
feeling
is
better
but
having
the
score
should
not
cause
any
any
major
storage.
It's
not
that
it's
going
to
blow
up
I
rather
have
it.
Oh
then
I
can
get
this
Json
and
then
I
can
figure
out
what
my
scorecard's
score
and
then
decide
what
do
I
need
to
do
so.
That
would
be
a
good
addition
to
have
my
do
since
on
that.
H
F
I
think
Michael
on
the
call
would
be
the
first
consumer
yeah,
so
Michael
works
on
the
devs.dev
project
and
they've
had
issues
on
you
know,
making
the
stroke
out
results
like
they've
had
a
hard
time
showing
users
their
results.
Besides
the
just
just
dumping
the
details
of
the
current
results.
So
so
this
is
supposed
to
help
them
We've.
We
had
discussion
with
them
about
what
they
would
need.
What
would
help
so
yeah
I
think
Michael
would
be
the
first
consumer
I,
don't
know
if
you
have
anything
to
add
Michael.
E
I
mean
I
do
think
that
it's
good
in
general
to
have
a
little
bit
more
structure
to
it,
because
it
does
make
it
easy
to
reason
about
it
and
yeah.
Yes,
short
version,
certainly
in
terms
of
compatibility,
I,
think
that
that
transition,
depending
if
it's
a
major
version
bomb,
just
handling
it
appropriately.
We
haven't
looked
too
much
at
serif
yet,
which
is
something
I,
will
be
looking
a
bit
more
at
so.
G
And
I'm
sorry
go
for
it.
Sorry,
I'm
done
and
I'm
looking
at
the
the
page
that
Spencer
shared
towards
the
bottom
is
as
a
serif
output
examples
and
the
example
with
minimum
required
properties
and
I'm
sure
that
we
get
to
a
format
like
that,
because
our
our
results
are
displayable
and
GitHub,
but
like
looking
through
that,
that
seems
that
seems
reasonable
and
I
think
we're
we're
pretty
close
there.
If
we,
if
we
were
to
adopt
the
format.
C
C
C
The
next
topic
is:
if
I
get
okay,
wait
action
to
use
the
API
to
get
comments
and
updates
on
difficult
to
see
changes.
This
is
something
that
I
have
been
working
on.
A
Mona
share
demo,
what
it
is
so
right
now
again,
this
came
up
in
in
couple
of
by
speaking
a
couple
of
customers
in
the
summit.
People
are
people
are
flying
blind.
If
there's
a
new
independency
change,
people
are
like,
but
I,
don't
know
how
great
the
dependency
is
and
Lauren
had.
C
Somebody
forgot
the
name
in
tone
work
on
this
specifically
for
their
project,
so
I
took
that
took
that
idea,
but
I
couldn't
reuse
any
of
the
code.
The
whole
goal
is
to
if
there's
any
dependency
change
to
your
project,
wouldn't
be
nice
to
get
a
scorecard
score
on
the
dependency
change.
So
it
makes
people
warm
and
fuzzy
to
say:
okay,
now
I'm
bringing
this
new
dependency.
What
happens?
C
C
It
makes
him
dependency,
change
and
I'm.
Also
a
specific
claim
brought
it
up
a
blank
import
on
go
because
this
dependency
has
a
vulnerability
so
and
this
dependency
is
not
scanned
by
scorecard,
because
this
is
an
older
repository
and
the
scorecard
does
not
scan
this.
So
this
is
a
common
use
case.
People
want
to
bring
in
update
few
dependencies.
People
want
to
bring
in
an
existing
repo,
but
it's
not
scanned
by
scorecard.
So,
ideally,
we
would
want
to
know
if
I
was
trying
to
consume
scorecard
I,
don't
want
all
the
checks.
C
I
could
be
picking.
Hey
I
just
want
two
checks
to
know
what
that
what
the
data
is
about
this
and
if
there's
no
scorecard
data,
but
if
there
is
any
volatility,
I
want
to
know
that
information,
and
all
of
this
is
used
only
one
API
call
to
GitHub,
which
gives
dependency
def.
So
by
calling
that
API
providing
between
two
common
shares.
A
C
So
here's
here's
the
example
so
this
this
is
how
so
I
can't
figure
the
API
check
or
to
only
two
two
checks:
binary,
artifacts
and
Independence,
because
I
don't
want
everything
so
just
to
show
this
is
configurable.
So
just
those
two
and
here's,
the
actual
API
call
to
score
guys
that
somebody
can
click
and
look
at
the
result
and
do
they
wear
changes
to
adding
robots
and
pencils.
Go
saml
that
one
didn't
have
any
scorecard
API
results
because
it's
not
being
scanned
and
that
repository
is
not
being
updated
in
the
last
four
years.
G
C
Is
an
example
of
somebody
can
configure
what
checks
they
are
interested
in
to
show
their
score
and
I.
Don't
wanna
my
thought
process
I'll
wait
for
to
not
to
dump.
We
can
obviously
configure
what
we
want
to
show
and
what
we
don't
want
to
show,
but
showing
this
highlight
the
reason
why
I
just
showed
this
is
I
opened
the
pr
to
for
that
one
of
the
dependency
update
tools.
Lauren.
Do
you
know
which
tool
what
that
was
it
wasn't
dependent
about?
It
was
the
other
one.
C
C
G
G
C
And
so
the
dependency
review
API
just
gives
the
it
gives
two
information.
It
says
what
are
the
new
dependencies
that
have
changed
and
it
also
gives
vulnerability.
So
that's
why
I
was
able
to
use
that
to
pull
that
information
it's
up
to.
Obviously
it
doesn't
not
set
in
stone
I'm,
just
showing
what
can
be
but
dependency
review.
Api
does
not
query
the
scorecard
API
to
get
results
and
we
I'm
just
teaching
both
these
things
together.
To
provide
this
information.
C
C
G
Be
stressful,
I,
I'm,
yeah
I
have
I
would
have
mixed
feelings
about
it,
especially
if
it's
related
I
mean
if
it's
only
supportable,
potentially
only
supportable,
on
a
platform
that
everyone
might
not
be
on
because
I
I
know
I,
know,
there's
support
being
built
for
git
lab
as
well.
Are
it's
in
experimental,
yeah.
C
It's
an
experimental
so
so,
so
that's
why
keeping
this
code
base
only
in
action,
not
in
scorecard.
So
essentially,
if
we
decide
to
add
this
to
get
lab
and
XYZ
then
potentially
move
that
into
scorecard,
but
keep
this
simple
enough.
This
is
not
pretty.
This
is
not
extremely
large
code
base,
so
this
is
about
probably
I
would
say
about
500
600
lines
of
code,
but
my
thought
process
to
keep
this
only
in
scorecard
action.
G
H
C
It's
not,
we
are
not
parsing.
We
like
like
scorecard,
does
not
parse
it.
That's
what
dependency
API
provides
that
out
of
the
box,
so
I
give
cool
to
comment
shots
for
the
repository
it
says:
hey.
Are
there
any
other
dependencies
updated?
If
it's
updated
tells
me
what
those
dependencies
are
I?
Take
those
lists,
I
go
to
I
parse
that
out,
go
to
scorecard
API
and
say:
hey.
A
C
Yes,
it
keeps
the
ecosystem,
it
gives
the
what
was
added.
What
was
remote
everything
it
gives
all
that
so
essentially,
and
what
the
source
repository
we
take
the
social
repository
we
four
bits
get
up.
We
just
think
if
it's
get
out
hey,
then
we
take
that
go
look
at
the
API.
If
you
can
find
it
nothing
in
the
API
you're
not
going
to
dump
anything.
B
C
G
C
If
we
are
thinking
of
even
code
QRS
for
the
manner
you
need
to
have
paid
Advanced
security
for
you
to
run
code
QR,
which
scorecard
goes
in
dings.
If
you
can
use
that
so
so
we
can
go
down
this
Rabbit
Hole
of
trying
to
say,
which
is
and
which
is
not,
but
I'm
not
saying
that
we
should
not
look
for
that,
but
we're
gonna
make
this
configurable.
We
can
turn
on
and
turn
off
so
that
it
does
not
error
out.
Somebody
can
and
want
this
video.
C
H
C
If
you
see
this,
somebody
has
to
now
you
now
adding
more
dependency
on
whether
they
are
maintaining
those
packages.
Those
things
become
problem
is
an
Enterprise
getting
they
have
a
revenue
model
to
maintain
this
because
they
wanna
they
wanna,
add
new
features,
make
it
stable.
Now
we
depending
on
someone
else,
brings
oh,
are
you
having
support
for
python?
Are
you
having
support
for
x,
Pi
Pi?
Do
you
have
support
for
this,
but
you
have
as
a
revenue
model.
This
is
what
they're
building
on,
obviously
swapping
that's
only
one
function.
G
Let
me
let
me
interject
a
little
bit
because
Veron
before
you
you
jumped
in
I
was
going
to
kind
of
touch
on
this.
There
is
a
bit
of
an
incentive
towards
open
source
or
public
repositories
right
so
for
code
ql,
you
can
use
codeql
without
the
license.
As
long
as
the
repo
is
is
public
right
you,
if
you
have
a
private
repository,
that's
when
you've
got
you
that's
when
you've
got
to
get
the
advanced
security.
G
You've
got
to
click
the
buttons
you've
got
to
pay
the
money,
so
there
is
some
incentive
towards
having
publicly
available
open
source
code
and
and
getting
some
of
this
additional
functionality
out
of
GitHub.
As
a
result,
I
think
that
that
is
a
reasonable
model
and
I
think
that
you
know
at
least
by
restricting
this
in
in
within
the
context
of
the
scorecard
action,
it
means
you're
likely
running
through
the
same
workflow
right.
G
There
are
things
in
in
scorecard
that
you
won't
necessarily
need
to
be
able
to
do
if
you're
or
you
won't
get
as
robust
results
if
you're,
if
you're
dealing
with
a
private
repository
already
right.
So
as
long
as
we're
setting
the
expectation
of
like
what
needs
to
be
what
what
buttons
need
to
be
turned
on
or
what
things
need
to
be
paid
for,
I
think
it's
fine,
especially
given
that
it's
restricted
into
this
kind
of
scorecard
action,
namespace
as
it
were,
yeah.
C
H
One
of
the
one
of
the
suggestions
I
had
is,
for
example,
you
know
this
osv
scanner,
you
know
which,
which
recently
from
Google,
which
is
open
so
I,
think
that
also
does
parsing
off
a
lot
of
these
package
manager.
Files
and
I'm.
Just
I
was
just
wondering
if
that
is
actually
being
used.
In
fact,
that
is
sort
of
mentioned
here,
but
I
don't
know
if
it's
a
dependency
or
is
it
a
because
that
you
know
if
you
take
a
dependency
of
that
and
it
it
is
parsing
a
lot
of
these
package
managers
advantage
correct.
C
But
I
it's
a
battle
point
I'm,
not
saying,
but
probably
for
V1
we
can
think
of
using
using
the
GitHub,
but
probably
for
we
too.
We
can
see
like
okay,
let's
how
can
we
replace
this?
That's
my
take
because
scorecard
action
cannot
be
run
on
a
private
people
if
you
don't
have
advanced
security
so
especially
nowadays
being
namespace
too.
That's
my
take
because
now
adding
another
dependency
and
coming
back
at
what
to
rather
giving
this
as
a
feature.
G
F
I
think
there's
one
limitation
of
OSB
scanner
that
it
understands
packages,
but
it
doesn't
understand
the
mapping
between
a
package
and
a
repo
unless
it's
for
maybe
golang,
because
we
can
infer
the
repository
from
the
like
username
and
I.
Think
that's
what
that
GitHub
API
is
providing
right.
I!
Think
Deb
is.dev
also
has
a
similar,
API
I.
Think.
F
Some
love
behind
where
they
look
at
stars
and
downloads
and
they
say
okay.
This
is
coming.
This
repo
seems
to
be
the
source
of
Truth,
because
I
think
sometimes
people
also
Fork
projects
and
they
don't
change.
The
Source
hints
that
they
have
in
their
npm.
So
you
end
up
with
a
lot
of
packages
that
are
supposedly
from
the
same
repo
I
mean.
This
is
just
something
to
be
aware
of
that.
The
mapping
is,
is
what
I
think
that
API
is
giving
us
that
maybe
OSD
doesn't
support,
but
I
haven't
looked
in
detail.
C
C
So
first
of
all,
next
thing
is
I
want
to
keep
it
as
a
comment,
so
that
it's
one
comment,
so
people
can
keep
it
easy
simple:
they
can
Squish
and
they
can
see.
Oh
what
it
is.
Each
one
is,
instead
of
it
being
hundreds
of
comments.
So
if
they
don't
like
it
and
one
of
the
things
Lauren
do
you
want?
Do
you
think
this
should
be
part
of
the
existing
action,
or
should
it
be
because
that
means
you
got
to
run
this
in
vrs
and
scorecard
if
it
runs
on.
F
Yeah
I
think
I.
Let
people
discuss
what
they
think
if
I
understand
correctly.
If
this
runs
on
PRS,
the
only
API
request
is
to
the
that
GitHub
API
about
the
dependencies,
but
everything
else
will
be
pulling
out
from
the
bigquery
or
right
now
from
the
rest,
API,
okay,
so
so
the
only
right
limiting
problem
would
be
from
from
that
additional
apir
you're
also
saying
that,
oh
maybe
the
running
scorecard
to
the
NPR
as
the
limitation
and
people
are
already
running
into
that
problem.
Yes,
yes,.
C
Because
now,
if
scorecard,
is
usually
configured
for
on
a
like
on
a
merge
or
something,
but
it's
now
we're
going
to
enable
with
PRS
it's
gonna,
they're
gonna
head
into
great,
limiting
scorecard
costs
and
leave
rate
limiting
issues,
and
so
that's
why
I
want
to
avoid
that.
Keep
this
simple!
Keep
it
clean
get
in
the
one
downside
is
now.
We
need
to
request
a
lot
more
people
to
go
install
this.
That's
the
only
downside
to
that,
but
in
the
long
run,
it'll
avoid
rate
limiting
issues.
C
G
G
C
H
For
the
GitHub,
actually
one
of
the
other
things
to
consider
is
that,
if
you're
planning
to
create
the
pr
comment
using
the
GitHub
token,
then
I
think
it's
also
going
to
need
the
pr.
The
pull
request
right
permission
for
that.
So
that's
another
thing
to
consider:
okay
with
some,
so
if
someone
wants
to
opt
into
this,
then
the
documentation
will
have
to
say
that
yeah.
C
H
D
G
C
And
Laurent
I'm
sorry,
we
are
three
minutes
into
it.
If
we
merge
I
know,
these
are
like
one
of
the
things
that
we
I
was
also
talking
about
is
I,
don't
I,
don't
really.
We
should
probably
talk
about
awareness
that
you
want
to
release
like
all
of
these
things
together,
as
we
were
talking
about
in
the
last
meeting,
is
we
probably
won
in
q1
set
a
date
and
try
towards
it,
because
it
makes
it
easier
as
to
what
we
want
to
release
and
put
that
together.
F
F
C
B
I
don't
know,
I
think
it
would
help
if
we
could
specify
in
the
action
I
don't
think
we
can
so
correct
me
if
I'm
wrong,
but
if
we
can
specify
the
checks
that
run
in
the
scorecard
action,
because
some
are
a
lot
worse
than
others.
There
are
some
that
hit
30
API
requests
for
a
certain
check,
but
a
lot
of
them
use
the
graphql
API.
So
if
it's
one
graphql
API
and
we
get
you
know,
the
majority
of
the
checks
is
that
good
enough,
so
I.
G
F
So
if
somehow
we
are
hitting
those
rate
limiting
because
of
the
API
calls,
it
means
that
we
are
basically
not
being
very
smart
on
how
we
query
graphql
and
we
basically
querying
everything
even
things
that
we
don't
need.
So
maybe
we
can
make
it
a
bit
more
granular
so
because,
like
scorecard,
should
only
need
the
you
know,
cloning,
the
repo
and
then
basically
looking
at
the
code.
That's
that's!
Those
are
the
only
checks
that
we
turn
on
on
pull
requests
for
the
whole
problem,
at
least
right
now,.