►
From YouTube: Scorecards Biweekly Sync (October 20, 2022)
B
A
C
A
A
A
C
I
wrote
a
design
doctor
that
it's
purely
for
I
shared
the
design
that
probably
on
Tuesday
a
team
and
I
have
been
discussing
about
that,
at
least
in
the
Design
Lab,
which
is
open,
would
appreciate
people
to
look
at
it
give
feedback
to
it.
The
whole
idea
is
digital
for
this
right
now
we
store
every
different
combination
in
each
each
subjective
within
the
bucket.
That
becomes
extremely
extremely
complicated,
as
we
maintain
the
whole
idea
as
to
hey
now.
C
C
The
second
thing
on
that
is
also
we
goal
is
to
extend
if
we
want
to
extend
our
API
to
add
query
capabilities,
not
just
straightforward,
with
any
kind
of
credit
capability
that
we
want
example,
very
simple
example
that
I
can
think
of
as
I
want
to
get
all
the
repositories
of
eclipse
Foundation.
That's
the
simplest
because
me
I
want
to
know
how
is
Eclipse
Foundation
doing
right
now.
C
Also
another
critical
reason
is,
like
people
have
started,
utilizing
our
API,
because
there
was
an
issue
that
came
up
and
scorecard,
which
essentially
said
hey
we
want
to.
We
want
to
run
2,
000,
2000
plus
scans,
using
the
API
and,
and
those
are
the
motivation
to
go.
Do
that
and
I
got
feedback
from
azim,
at
least
on
a
couple
of
things.
One
is,
if
you
don't
mind,
can
you
open
the
dock?
There's
a
on
that?
If
you
go
back
to
the
yes,
oh.
C
Yeah,
the
Google
Doc,
please
I
I
wrote,
as
you
can
give
specific
feedback
as
to
we
need
a
plan
of
action
of
how
to
move
whatever.
If
you
scroll
down
a
little
bit
further
down,
please
yes
on
this,
specifically,
how
do
we
move
the
existing
historical
data
into
firestore?
That's
one
action
item
that
I
do
have
on
that
to
update
what
are
the,
what
are
the?
What
are
the
game
plan
to
do
that?
C
This
is
essentially
saying
why,
where
the
code
changes
for
this
to
essentially
say
hey
this
Revenue
changing
the
Quran
job,
we
need
to
change
and
get
a
badges.
Where
do
we
have
to
change,
and
also
where
do
we
have
to
change
on
the
API?
This
is
essentially
this
not.
My
proposal
is
not
to
have
a
discussion
in
this
meeting
in
depth,
but
the
whole
idea
is
to
get
more
people
to
read
that
and
give
feedback
to
it.
C
A
C
D
D
Yeah
I,
don't
think,
saying:
hey,
let's
move
to
firestore
and
then
figure
out.
What
is
the
usefulness
of
it
is
is
worth
doing
because
just
moving
to
fire
store
itself
is
a
you
know:
it's
a
lot
of
work.
So,
let's,
let's
figure
out
what
exactly
is
the
thing
that
we
are
solving,
because
that's
the
only
way
we'll
know
if
moving
to
firestore
solves
our
problem.
The
way
we
want
to
solve
it
right,
like.
C
C
That's
one,
like
example:
I
want
to
add
the
release
information
now
that
has
to
coming
back
to
a
little
history
behind
that
is
like.
If
you
want
to
go
say
one
of
the
issues
in
scorecard
is
go,
get
release
information,
so
essentially
people
can
go
say:
hey
I
have
discriminaries
1.23.
What
was
its
state
at
that
time
so
for
doing
that
right
now.
C
What
would
happen
is
we
would
be
it's
very
easy
to
extend
scorecard
to
go
fetch
the
data,
and
now
we
need
to
make
a
copy
of
the
same
results
with
that
with
that
path,
being
tagging
within
the
scorecard
results
to
go,
add
this
relationship
information
and
an
API
to
go
say
if
I
want
release
information.
I
need
to
go
look
at
this
path,
so
essentially
we
can
do
only
one
to
one.
We
cannot.
We
don't
have
the
capability
of
one
to
many
to
say.
C
D
Yeah
I
I
I
get
that
right.
I
think
my
point.
So,
let's,
let's
take
the
release
information,
for
example,
I,
don't
think
moving
to
firestore
is
going
to
solve
the
release
information
issue
by
itself
right
like
if
the
release
information
thing
is
the
use
case.
We
want
to
solid,
then
there's
a
bunch
of
things
that
need
to
be
done
to
actually
solve
that
and
not
just
move
to
firestore
right.
A
C
C
D
Yeah
I
mean
sorry
I'm,
just
using
the
release
information
as
an
example
right,
so
what
I
mean
is
if
we,
if
we
know,
if
you
start
with
what
what
is
the
exact
API
that
we
actually
want
to
Sure
expose,
then
it's
easier
to
build
a
solution
to
say:
hey,
here's
what
the
database
is
going
to
be,
it
might
actually
be
firestore
right,
like
firestore,
might
be
the
right
solution,
but
allows
us
to
go
and
say:
hey,
here's,
here's
the
thing:
here's
the
schema!
That's
going
to
look
like
here's!
What
we're
going
to
index!
D
We
are
we're
going
to
have
a
much
more
cleaner
design
to
say
what
exactly
are
we
solving,
and
we
also
know
that
the
solution
actually
solves
the
problem
that
we
are
looking
for
right
now.
We
are
purely
saying:
let's
move
to
firestore,
because
it
gives
us
these
indexing
capabilities
and
then
we'll
figure
out
what
extra
apis.
We
can
add
on
that
right.
C
C
What
happens
which
one
overrides
which
one
right
now,
because
we
stored
in
two
different
buckets:
it's
not
a
problem.
That's
about
valid
question,
I'm
I'm,
going
with
that,
whichever
is
the
latest
is
going
to
override
the
other
one,
but
we'll
have
to
figure
out
why
and
what
are
the
implications
of
doing
that?
But
but
that's
a
valid
point
on
that.
But
I
will
answer
those
questions,
I'm
hoping
by
next
bi-weekly.
We
should
have
these
answers,
so
we
can.
A
C
This
is
on
the
rate.
Limiting
this
is
somebody
who
came
from
the
community
and
say
hey.
We
would
need
some
regular.
Is
that
a
rate
limiting
this
is
great.
We
don't
have
any
specific
docs
as
to
say
any
weight.
Limiting.
Is
there
I
by
the
time
machine
answered
that
question
and
close
that
issue,
but
I
also
added
a
specific
item
on
that?
C
C
C
A
D
D
That's
necessarily
true
I
think
projects
can
choose
to
do
releases
in
various
ways
like,
for
example,
kubernetes
is
a
pretty
good
example.
So
the
way
they
do
their
releases
is
each
major
version
has
a
separate
branch
and
they
make
a
new
commit
to
it
every
time
they
want
to
patch
it
or
have
a
minor
release
to
it
right.
D
So
I
think
my
only
like
comment
here
would
be
that
the
the
concept
of
a
release
based
on
a
git
tag-
I
I,
don't
think-
is
generic
enough
to
be
applied
across
the
open
source
ecosystem.
Like
that,
that's
that's
one
of
the
reasons
we've
been
sticking
with
commit
Shah,
because
that's
something
that
no
matter
what
you
do,
you
have
to
have
a
commercial
and
that's
what
we
honor
so
yeah
that
just
the
first
comment.
A
Okay,
yeah,
that's
a
interesting,
that's
a
good
example,
but
I
would
argue
that
for
GitHub
using
the
GitHub
features,
the
release
tag
is
a
GitHub
feature.
Everything
we're
utilizing
is
like
using
the
GitHub
API.
So
if
they're
choosing
not
to
use,
do
perform
releases
like
with
the
GitHub
standard,
that's
it
wouldn't
be
captured
in
this,
but
I
think
it
still
would
be
helpful
for
the
projects
that
do
utilize
release
tags.
C
Catalina
I
have
a
comment
on
that.
There's
recently
a
PR
or
somebody
bought
it.
Somebody
did
a
br
for
gitlab,
which
specifically
solves
get
lab
problems
like
for
gitlab,
not
just
GitHub
I
know
we
are
primarily
owning
GitHub
I
have
a
similar
consensus
like
what
azim
has
when
we
extend
this
to
gitlab
and
other
repositories,
then
this
then
we
need
to
have
feature
flag,
saying
if
GitHub
do
this,
if
not
get
up
don't
do
this
is
extremely
cumbersome
to
maintain.
C
A
Yeah
I
haven't
looked
too
much
at
git
lab,
so
I'm,
not
sure
if
they
have
the
concept
of
release
tags
as
well,
but
if
they
do,
it
could
be
like
the
get
get
lab
version
of
releases
as
well.
But
that's
a
good
point,
I
think.
If
we
do
want
to
stick
with
commit
shop,
perhaps
we
could
have
a
flag
that
lets
you
scan
from
one
commit
to
another,
but
essentially
it
would
be
the
same
as
the
commit
and
commit
depth
go
ahead.
Azine.
D
B
D
On
top
of
it,
like
basically
to
say,
hey
I
can
give
your
git
tag
and
then
we
internally
figure
out
what's
a
commit,
or
we
give
you
two
git
tags
and
we
figure
out
the
commit
that
but
yeah
I
I
would
say.
Maybe
the
first
step
really
is
to
have
this
implemented
and
then
once
you
have
that
stack,
we
can
build
wrappers.
On
top
of
it.
A
So
what
I
had
a
follow-up
on
that,
since
we
were
on
the
discussion
of
releases
so
because
I
had
been
working
on
Gage,
one
of
the
features
in
gauge
that
was
helpful
was
if
you
were
scanning
a
release
that
wasn't
the
latest.
It
would
give
some
information
on
how
many
versions
it
is
away
from
the
latest
the
time
away
from
the
latest.
It
is
like,
oh
you're,
your
release
that
you
have
it's
like
three
months
older
than
the
latest
release
and
the
number
of
major
versions.
A
A
D
A
Yeah,
so
for
this
it's
it
would
be
built
on
the
scan
between
two
releases.
So
if
you're
scanning
like
4.0.1
to
4.8.0,
then
there
would
be
a
separate
check,
saying
I,
don't
know
three
out
of
ten,
because
this
is
months
older
than
the
latest
release
and
it
is
yeah.
It
can
make
a
determination
based
on
how
many
major
versions
away
it
is
from
the
current
release.
D
I
see
yeah
I
I
can
give
my
very
high
level
to
sincere
rate.
I
think
this
is
not
a
technical
answer.
More
of
a
philosophical
answer,
which
is
that
so
far,
we've
been
developing
scorecard,
aimed
at
like
the
maintainers
or
basically
aimed
at
the
repository
itself
like
scorecard,
is
actually
checking
this
posture
of
a
repository,
so
I
think
with
the
release
lag
thing,
it
seems
like
it's
a
more
consumer,
focused
thing
to
say:
hey.
A
A
C
C
C
Go
for
that
yeah
I,
just
called
action!
Reposites
and
I'll
walk
you
through
because,
like
the
whole
idea
is
like
I
released,
two
of
the
205
and
it
broke
I,
just
I
just
fixed
that
and
I
I
want
to
be
transparents
to
what
went
wrong.
So
a
lesson
learned.
If
you
don't
mind,
can
you
go
to
scorecard
like
on
the
same
URL,
hyphen
action?
Oh.
C
C
C
C
Yeah
right
on
this,
can
you
click
on
the
issues?
Please?
Yes,
azim
I'm
surprised
that
we,
it
should
have
failed
on
Maine.
We
have
an
end
to
end
on
the
ossf
test,
R
for
people
who
don't
know
we
have
an
end-to-end
test
for
the
action
on
the
main
tag
on
the
main
on
the
main
tag,
which
would
essentially
pull
the
docker
container
down,
run.
It
make
sure
it's
all
fine
and
dandy,
and
if
it
fails
it'll
create
an
issue
to
say:
hey.
It
failed
in
the
automated
test.
C
C
B
C
You,
if
you
see
we,
we
do
I'll,
do
it
a
main
okay
yeah
we
can
do
latest.
We
do
a
main.
So
essentially
it
should
pull
that
down
and
should
still
run
a
Docker,
because
it
runs
only
because
it's
a
it's
a
gold
project.
It's
naughty!
That's
the
last
one,
only
a
Docker
build
and
do
that
and
somehow
why
I'm,
bringing
this
up
is
in
retrospective
to
make
sure
that
going
forward
anytime
we
release.
One
is
hey
we
want
to.
C
C
I
will
I
will
take
this
up
and
I'll
write
an
issue.
What
I
figure
out,
but
I
would
like
somebody
else
to
have
some
pairs
of
eyes
to
say,
hey.
This
is
where
we're
missing,
instead
of
just
one
person.
Looking
at
that,
that's
that's
the
whole
idea,
especially
an
action
that
you
could
utilize
a
lot
of
people.
We
don't
want
to
be
a
project.
Oh
my
God!
This
is
broken
second
time
we
want
to
widen.
That's
the
whole
idea.
D
C
C
And
I'm
going
to
write
an
issue
and
like
that's,
why
I
put
in
a
guardrail
to
make
sure
the
docker
build
is
working,
but
that's
only
one
guard
rail.
We
need
a
guardrail
to
say
it's
gonna
run
that
test
like
how
only
then
we
get
warm
and
fuzzy
to
say
we
can
release
and
nothing
is
the
basic
tests
aren't
failing.
C
C
But
for
now
I'm
thinking
we
at
least
had
a
every
time.
We
don't
just
do
a
release.
We
do
a
pre-release
make
sure
we
pull
that
into
another
PR
like
how
we
have
a
release
notes.
What
are
the
steps
there's
a
little
cumbersome
manual,
but
at
least
that
gives
us
guarantee
we're
not
releasing
every
day
we
are
releasing
only
once
a
month
or
something
of
that,
so
it's
a,
but
it
at
least
gives
us
not
having
to
go
through
this
again.
D
C
C
Because
if
you
scroll
down,
this
is
recore
azim
I
think
this
is
really
cool,
having
some
kind
of
thing
where
then
it
failed.
That's
why
I
don't
know
if
this
is
the
2.05
I.
Don't
know,
I
didn't
spend
time
in
looking
at
this,
but
this
is
another
one
issue,
so
we
just
we're
just
having
some
reliability
issues
for
us.
D
Yeah
I
think
some
of
this
is
actually
we
can't
really
help
it,
because
I
think
we
do
depend
on
record.
So
sometimes,
if
require
is
unable
to
like
verify
our
certificate,
then
yeah,
then
we
end
up
with
this
500
error
yeah,
and
that's
actually,
why
you
see
it
happening
only
on
one
of
the
Matrix
runs
and
everything.
B
A
C
A
A
A
C
B
A
A
C
Azim,
we
would
need
some
help
with
that.
I've
already
hit
you
up
with
that
weight,
limiting,
especially
on
that
on
that,
keep
forgetting
what
it
is
sorry
I'm
going
blank
on
that
PR
runs
especially
for
the
producy,
if
not
the
the
Dependable
PRS
are
going
to
pile
up
more
and
we're
going
to
see
a
lot
more
failures,
I'm
going
to
close
some
of
them
just
so
that
we
don't
see
failures.
D
C
C
C
I'll
start
an
issue
so
or
else
also
it's
going
to
be
okay,
it's
all
everything
is
going
to
get
backlogged
it's
going
to
become
harder.
Only
one
one
minute,
one
or
two
maintain
is
always
going
to
be
part
of
so
I'm
gonna
start
an
issue.
Spencer.
If
you
don't
mind,
can
you
start
an
issue
on
and
two
upwards
should
be
good,
azim
and
I?
Should
we
should
have
consensus.