►
From YouTube: SLSA Specifications Meeting (June 26, 2023)
A
B
A
D
D
All
right
so
yeah
so
got
a
little
bit
of
more.
You
know
just
talking
to
folks
and
and
and
been
in
some
meetings
regarding
sort
of
salsa,
V1
I.
Think
generally,
you
know.
Some
of
this
is
obviously
stuff
that
we're
talking
about
in
the
SEI
positioning
group,
but
some
of
it
I
think
is
related
to
some
of
the
things
that
we're
doing
here,
largely
folks,
I
think
are
very
they
like
the
they
like
how
mostly
straightforward
salsa
V1
is.
D
It
seems
very
understandable,
very
clear
and
so
on.
The
the
areas
where
folks
seem
to
be
most
confused
by
is
just
okay,
but
but
how
do
I
actually
implement
this
now,
even
if
there
is
some
like
you
know,
obviously,
there's
there's
more
than
enough
companies
out
there
that
can
help
folks
implement
it,
but
from
a
representative
example,
standpoint,
I
think
folks
are
trying
to
look
at
stuff
Beyond.
D
Just
purely
the
you
know,
the
the
other
feedback
I
got
was
like
hey
if
I'm
not
looking
at
a
SAS,
if
I'm
some
giant
company
who
has
a
Jenkins
or
a
team
City
or
you
know
whatever
else
right
what
what?
What
sorts
of
things
like
you
don't
have
to
tell
me
exactly,
but
what
sorts
of
things
are
folks
doing?
A
D
So
is
the
a
question
I
have
is:
is
the
issue
here
that,
like
npm,
has
built-in
support
for
public
packages
and
you're
looking
for?
Is
there
going
to
be
built-in
support
for
like
Upstream
Maven,
to
support
salsa,
or
is
the
thing
here
that
may
even
like
building
a
package
in
Maven
is
difficult
to
do
via
salsa.
E
D
On
that
second
part,
I
think
that's
nobody
has
to
the
idea
here
is,
is
it's
if
you
trust
you
know
Google,
let's
say
then
you
TR,
you
know
if
you
I'm
just
saying
like.
If
you
trust
cloud
provider
XYZ
with
a
salsa
build,
then
you
are
trusting
the
underlying
infrastructure.
You
don't
need
to
know
everything
about
that
infrastructure
and
in
fact,
like
I
I'm,
pretty
sure
it's
also
isn't
clear
enough
about
it.
I
I
don't
know.
D
Maybe
we
could
be
even
clearer
just
to
kind
of
really
hit
that
home,
but
I
I
do
believe
that
you
know
and
correctly,
if
I'm
wrong,
there's
there's
the
idea
here.
Is
we
have
that
idea
of
the
trusted
control
plane
and
as
long
as
you
know,
you,
as
the
end
user,
are
saying:
yes,
I
trust
this
control
plane,
then
then
I
don't
necessarily
care
about
the
underlying
infrastructure.
D
Like
you
know
the
details
on
how
all
that
stuff
is
done,
that's
one
bit
as
far
as
the
maven
piece
I
think
it's
worthwhile,
obviously
to
sort
of
pull
in
other
folks
who
might
be
interested
in
building
out,
Maven,
tooling
and
and
so
on,
but
I
I
believe
you
know.
This
is
where
some
of
this
here
might
be
worthwhile
to
to
you
know:
I.
You
know,
based
on
I,
think
some
recent
conversations
I
think
it's
up
to
the
industry,
to
you
know
build
Maven
tooling.
D
C
E
You
know
internally,
we
use
GitHub,
Enterprise
and
the
way
the
GitHub
Enterprise
Works
internally,
it's
behind.
What's
on
public
GitHub
Enterprise,
not
because
of
our
choosing,
and
so
it
doesn't
have
GitHub
actions.
So
we
can't
even
have
that
as
an
option,
so
it
does
help,
but
it
would
be
good
like
npm
right
if
Nathan
was
able
to
kind
of
do
this,
for
the
industry
versus
everybody
having
to
come
up
with
something
on
their
own.
G
On
our
side,
we
have
our
own
build
system,
and
what
we
do
is
that
we
are
going
to
distribute
only
the
things
and
our
customer
needs
to
reproduce
the
bills,
but
nothing
about
the
control
plane
itself
and
basically
the
control
plane
does
not
impact
the
output
of
the
build
it.
Just
it's
an
automation
for
us,
but
it
doesn't
impact
the.
So
that's
where
we
stop
the
provenance
for
us,
I,
don't
know
if
it's.
E
E
B
E
C
H
D
So
I
think
some
of
my
confusion
because
I
think
there's
there's
two
separate
problems
here.
One
is
making
a
generation
of
the
provenance
easy
when
you
run
something
like
Maven,
because,
like
npm
itself
also
is
probably
worth
pointing
out
that
npm
uses
the
GitHub
generator
for
the
provenance
and
currently
doesn't
support
anything
outside
of
that
I
mean
they
do
plan
to
support
potentially
other
SAS
Runners
for
sort
of
the
npm
side
of
things.
So
so
that's
actually
something
separate
as
well,
which
is
like
yeah.
D
But
because
you
need
to
so
in
this
case,
it's
it's
for
open
source
projects,
mostly
for
open
source
projects
here,
and
the
idea
here
is:
if
I'm
an
open
source
provider,
I
can
go
and
say:
hey
I
am
using
I
am
using
something
and,
and
that
thing
is
generating
salsa
Providence
and
it
gets
pushed
to
npm.
But
npm
has
said
they
will
only
take
provenance
from
approved
Services
right
because
got
it.
D
It's
now
on
npm
to
say
who
do
I
trust
from
a
salsa
build
perspective
and
in
this
case
obviously
npm
Microsoft
everything
else.
It's
very
easy
for
them
to
save
right
now,
at
least
that
for
for
GitHub,
but
I
do
believe
that
they're
planning
to
support
git
lab
and
other
Circle,
CI
and
and
others
as
well.
But
but
at
that
point
I
believe
the
idea
is
and
in
fact
they've
pretty
Str.
They
pretty
much
said
like
there's
no
way
for
them
to
just
sort
of
take
a
random
person.
D
E
F
It
would
be
good
to
have
provenance
even
if
it's
not
signed,
because
if,
if
other
people
can
then
verify
that,
maybe
when
they,
when
they
run
the
build,
they
get
the
same,
the
same
content
or
maybe
they
they
just
want
to
rebuild
and
decide
that
they
don't
want
to
use
the
Upstream
package
that
could
also
be
you
know,
having
unsigned
provenance
can
basically
provide
some
hints
on
how
to
build
the
package.
Basically,
if
some
people
don't
feel
comfortable,
you
know
using
the
Upstream
package
or
something
like
that.
E
E
A
For
example,
what
is
the
relationship
between
external
parameters
and
resolved
dependencies?
There's
been
a
lot
of
back
and
forth
discussion
about
that,
for
example,
trying
to
write
those
real
quick
like,
for
example,
if
you
take
a
git
repo
as
a
parameter,
and
you
accept
like
a
a
URL
and
a
branch
name.
Ultimately
that
gets
resolved
to
some
sort
of
commit.
A
Where,
like
do
you
just
record
those
as
two
separate
fields
and
then
normalize
it
in
resolved
dependencies?
Do
you
just
record
and
resolve
dependencies?
Because
it's
only
like
it's
kind
of
duplicate
information?
Do
you
normalize
it
into
a
URL
in
external
parameters,
so
that
way,
it's
in
kind
of
a
standard
format?
A
Do
you
put
the
commit
in
external
parameters?
I
mean
I,
have
opinions
and
I've.
You
know
interpreted
that,
but
I
don't
think
it's
at
to
the
point
where,
like
I,
feel
like
we
need
documentation
and
kind
of
like
sort
of
like
applied
rulings
or
almost
something
like
that
where
we
say
you
know,
these
are
our
suggestions.
It
kind
of
looks
like
this.
A
A
There
is
possibly
as
separate
thing
of
the
thing
to
be
built
in
GitHub
actions,
for
example.
That
is
not
a
parameter.
It's
a
two
are
the
same,
but
in
other
systems
like,
for
example,
Google,
Cloud
build
or
tecton,
you
could
have
I'm,
not
sure
about
technology,
but
Google
Cloud
build.
You
could
have
it
as
two
different
parameters
and
then
like
a
bunch
of
additional
stuff
in
some
sort
of
schema,
usually
key
value
pairs,
but
not
always
so
that
might
be
some
value
in
in
just
because
they
all
kind
of
represent
the
same
stuff.
D
Yeah,
so
on
on
the
two
things
you
put
put
out
there
so
on
the
first
one
I
think
yeah,
so
we
we've
heard
similar
and
and
one
of
the
things
that
I
think
we
at
least
initially
came
to,
and
obviously
you
know
be
interested
in
feedback
is
having
duplicate.
Information
is
better
than
not
having
the
information
at
all,
so
at
least
to
start
off
with
I.
D
So
that's
that's
one
thing
and
then
to
the
other
point
you
brought
up
so
one
of
the
things
we're
working
on
and
you
know,
we'd
love
to
open
source
soon
is
we're
starting
to
poke
around
with
the
idea
of
almost
like
a
salsa
API.
So
the
idea
is
I
have
a
salsa
Builder.
The
salsa
builder
takes
in
some
parameters
and
an
output
is
a
is,
is
a
salsa.
D
It
is
a
is
a
salsa
attestation
and
then
the
idea
here
would
be
whatever
the
implementation
is
is
obviously
you
know
you
need
to
from
a
conformance
standpoint,
but
the
actual
API
should
be
pretty
straightforward
of
like
what
are
the
expected
inputs
and
then
what
are
the
expected
outputs,
and
so
that's
something
that
I
think
we've
also
been
poking
around
with,
but
I
think
yeah
on
that
end,
I
think
it
would
be
worthwhile
to
kind
of
talk
about
maybe
some
best
practices
at
some
point
around
like
yeah.
What?
D
What
do
folks
normally
expect
from
an
input?
Sorry
normally
expect
for
like
a
salsa
build
to
require
as
far
as
inputs,
and
what
should
you
know
and
and
what
are
the
sort
of
conditions
for
the
API
and
then
what
would
the
expected
outputs
be
and
then
obviously
the
implementation
itself
is
is
very
clearly
defined
in
some
of
the
salsa
pieces,
salsa
levels.
A
Yeah
that
makes
sense
and
I
I,
think
yeah
I
think
something
to
make
this
easier.
Another
piece,
I've,
also
I'm
running
into
like
repeatedly
is
foreign
I,
think
we
have
an
open
Bug
for
this.
Our
issue,
like
the
need,
maybe
I,
think
we
need
to
be
more
upfront
about.
The
idea
is
that
you
model
the
build,
like
you
define
some
interface
like
you,
draw
a
box
around
the
build
and
say
the
external
parameters.
A
A
That
information
could
be
useful,
and
so
you
kind
of
get
off
in
I
I
feel
like
a
misleading
track
like
that,
you
know,
I
feel
like
those
that
information
is.
We
should
be
thinking
about.
What
is
the
use
case
for
why
you're
doing
that,
and
like
s-bomb,
for
example,
is
designed
to
have
that
level
of
detail,
and
so
I
think
that
we
probably
need
more
guidance
around
like
what
information
recording,
how
we
model
it
and
why
and
to
limit
the
amount
of
work.
A
D
Yeah
I've
actually
heard
similar
feedback.
A
lot
of
the
feedback
I've
heard
is
that
hey
I,
don't
necessarily
need
provenance
for
these
QA
tests.
That
I'm
running
that
are
other
steps
in
my
CI
CD
pipeline
I
only
really
care
about
getting
it
for
the
the
actual.
You
know
my
package,
the
the
whether
it's
like
I
built
a
container
and
here's
how
I
built
it
or
I
built
this
go
app
and
and
here's
what
how
it
here's
the
inputs
of
the
go
app.
D
All
these
other
pieces,
though
maybe
long
term,
are
important
for
something
like
a
salsa,
maybe
not
super
important
right
now,
where
the
the
bigger
thing
you
know
to
kind
of
go
back
to
a
little
bit
of
what
melbo
is
saying
is
like
Hey:
how
do
I
just
get
it
from
my
War
file?
That's
the
thing:
I
care
about
yeah
yeah,.
C
H
Yeah
so
I
I
think
I
understand
the
question
a
bit
differently
and
I
tried
to
answer
and
see
if
it's
recorded
what
you
were
asking
so
in
my
own
Providence
creation
and
actually
in
all
of
my
evidence,
creation
not
only
like
results,
are
provenance.
One
I
find
it
useful
to
like
normalize
I
call
these
like,
like
it's
groups
of
fields.
H
Define
it
a
bit
better
for
my
for
all
my
evidence
and
I
basically
use
it
mostly
for
indexing
like
the
subject
is
not
enough
in
the
Intel
attestation.
For
me,
it's
like
it's
not
enough
for
me
to
know
the
hash
or
the
name
of
an
attestation.
I
would
like
to
query
at
the
stations
connected
to
a
git
commit
or
at
the
station,
connected
to
a
specific
build
on
a
specific
CI.
So
that's
how
I
find
this
this
one.
This
in
my
application.
A
Thanks
so
so
yeah
I
feel,
like
you
know,
we
already
have
the
open
issues.
I
I,
don't
want
to
open
another
issue,
but
I
think
these
these
kinds
of
things
that
we're
talking
about
it's
probably
useful
to
kind
of
regularly
talk
about
and
see
what
are,
the
the
most
important
and
and
try
to
improve
the
docs
I'm.
A
Be
in
the
coming
weeks,
spending
more
time
on
on
kind
of
getting
through
the
backlog,
and
so,
if
folks
want
to,
you
know,
obviously
any
contributions
to
trying
to
figure
out
how
to
better
address
this,
either
with
existing
docs
or
like.
If
we
need
larger
changes.
Ideas
on
you
know
for
like
a
V2
type
of
thing,
not.
I
A
D
So
it's
sort
of
related
to
the
the
feedback
actually,
but
so
speaking
to
a
couple
of
different
folks
actually
about
some
of
the
feedback
and
one
of
the
things
that
kind
of
came
up
as
a
key
piece
was:
there's
actually
a
lot
of
interest
in
aipac.
You
know
countries
and
and
organizations
that
are
out
there
that
are
very
interested
in
salsa.
D
They,
a
lot
of
them,
have
a
lot
of
very.
They
have
a
lot
of
open
questions
and
stuff
like
that,
and
there
seem
to
be
interest
around
like
hey.
What
can
we
do
to
start
like
building
out
a
community
out
there,
because
I
know
that,
for
example,
you
know
Samsung
had
contributed
to
Jenkins
plug-in
to
to
us
to
the
to
the
salsa
Community.
They
also
have
a
bunch
of
stuff.
D
So
I'm
sorry
cat
bit
me
so
anyway.
So
this
from
the
the
salsa
side
of
things
interest
in
the
APAC
stuff
we
have
like
Samsung
and
some
other
groups
out
there,
because
I
know
the
the
folks
from
Oracle
have
built
out
some
stuff.
There
also
just
seems
to
be
interest
over
there.
They
also
seem
to
be
interest
in
something
like
some
recorded
content
coming
from
us
beyond
the
blogs,
whether
it
is
something
like
a
salsa.
D
You
know,
but
but
but
but
like
here's,
just
some
general
ideas
stuff
like
a
webinar
stuff
like
even
you
know,
myself,
I
I
might
be
recording
some
stuff
on
behalf
of
the
the
LF
to
to
send
out
to
some
of
those
folks
out
there,
but
there
seem
to
be
some
interest
to
see.
If
also
there's,
maybe
we
can
extend
the
community
a
bit.
I
know
it's
a
little
difficult,
especially
with
a
meeting
like
this.
D
Where
this
you
know,
a
lot
of
the
folks
who've
been
working
on
the
specification
for
so
long
are,
are
mostly
working
at
these
hours,
but
it
might
still
be
useful
to
at
least
get
some
sort
of
meetings
going.
So
we
can
also
maybe
collect
that
feedback
on
an
ongoing
basis
and
and
make
sure
it
kind
of
comes
back
here.
So
we
get
a
better
idea
of
like
how's
the
rest
of
the
world
using
salsa.
Are
there
any
issues
they're
running
into
and
yeah.
E
D
D
Same
here
but
I
so
at
least
me
personally,
I'm
I'm
out
in
Asia
once
or
twice
a
year,
so
I
might
be
able
to
still
be
able
to
at
least
help
out
there.
But
it
does
sound
like
the
the
LF
is
interested
in
even
from
you
know
the
LF
side,
helping
organize
that
if
they
can,
you
know
so,
whether
it's
you
know
making
sure
those
meetings
get
recorded
and
the
notes
get
put
somewhere
that
we
can.
D
You
know
and
helping
facilitate
the
cross-pollination,
because
yeah
I
I
agree
that
that
sort
of
stuff
can
often
get
lost
because
we're
seeing
that
in
a
lot
of
the
other
groups
where
it's
like
hey
the
Europe
folks,
were
discussing
the
same
exact
thing
and
came
into
slightly
different
conclusions.
And
how
do
you
reconcile
and
and
that
sort
of
thing.
J
E
E
E
No,
it
wouldn't
be
U.S
West,
Coast
friendly.
There
won't
be
any
time
that
would
be
U.S,
West,
Coast,
friendly
and
Asia
Pacific
frenzy
with
the
rest
of.
So
that's
why
I
was
recommending.
Maybe
if
there
was
like
a
a
Europe,
APAC
friendly
time
like
once
a
month,
then
that
would
help
you
know
at
least
get
some
more
coverage
and
it
could
just
be
an
additional
meeting,
or
maybe
one
of
the
four
meetings
a
month
would
be
APAC
friendly.
A
A
A
No
way
that
everyone
will
be
able
to
participate
just
because
people
are
distributed
all
around
the
globe
and
there's
correct
non-overlapping
working
hours,
and
so
it
seems
like
that's
will
have
the
case
that
some
subsets
go
to
different
meetings
and
that's
what
we'll
live
with
so
I
think
if
anyone
wants
to
organize
that
we
could
just
go
ahead
and
just
propose
a
particular
time
or
if
we
do
some
sort
of
alternate
alternation.
I
think
that
represents
I
didn't
hear
anyone
opposed
to
that
idea
like
once
a
month
or
something
like
that.
D
Yeah
yeah
so
on
that
in
in
that
case,
can
definitely
get
back
to
the
LF
on
on
that
one
and
I
think
at
least
probably
you
know
and
I
have
no
problem
doing
this
once
or
twice,
but
I
I
have
no
problem
sort
of
helping
facilitate
the
initial
sort
of
meetings.
Just
so
that
folks,
like
understand,
like
hey
here's
somebody
from
the
salsa
Community,
as
opposed
to
it
just
being
a
bunch
of
folks
who
are
probably
going
to
have
questions
and
then
be
like
wait.
A
second
there's.
D
Who
might
be
able
to
help
like
I
know
also
the
Oracle
folks,
but
I
know
that
at
least
from
the
the
LF
side,
they're
they're
interested
because
they've
been
getting
feedback
from
some
organizations.
Saying
hey.
We
want
to
learn
more
about
salsa,
but
the
only
times
that
you
know
the
only
times
where
that
seems
to
be
available
is
at,
like
you
know,
12
a.m
or
2
A.M
their
time.
D
E
E
So
one
of
the
meetings
there
was
a
Google
person
that
talked
about
salsa
I,
don't
know
if
they
work
with
you
all
Mark
and
I.
Think
I
forget
who
else
is
from
Google
on
here,
but
there
does
seem
to
be
some
people
that
are
tuned
in
in
in
China
and
so
potentially
those
could
also
be
folks
since
they
presented
on
it.
They
could
help
facilitate
as
well.
B
B
Then,
moving
on
to
the
issue
backlog,
there
is
there's
a
giant
backlog
here.
So
I
grabbed
was
this
four
issues
that
I
think
we
can.
We
can
clear
off
relatively
easily.
The
first
is
trustlessness
of
provenance
using
public
dlts.
This
is
this
is
an
issue,
a
drive-by
issue
from
someone
who
is
is
interested
in
putting
salsa
on
the
blockchain
I,
don't
see
it
as
actionable
and
I
think
we
should
close
it.
B
D
I
Grace,
when
you
close
the
issues
like
this,
it's
good
to
put
a
little
comment
saying
you
know,
protocol
decision
on
the
call
put
a
reference
just
date
so
that
you
know
the
one
you
just
closed
before.
I
was
like
if
somebody
just
looks
at
the
git
and
they're
like.
Oh,
it
was
closed,
no
explanation.
So
it
looks
a
bit
weird.
J
B
A
B
B
E
Yeah
so
866
I
remember
this
being
talked
about
by
Jay
a
while
ago
that
there's
mention
throughout
the
either
the
website,
or
maybe
the
FAQs
there's
difference
between.
Like
you
know
what
a
security
framework
is
versus
compliance
requirement
versus
the
maturity
model,
so
I
think
he's
requesting
that
there'd
be
more
clarity
on
what
social
truly
is.
If
it's,
if
we're
trying
to
go
for
a
security
framework,
let's
call
it
that
consistently
but
I
don't
believe
he
thinks
it's
a
security
framework.
I
D
D
But
if
there's
a
glossary
that
says
hey
when
we
say
attestation
we
are
making.
We
are
specifically
talking
about
this
this
and
this
especially
in
a
glossary,
so
that
somebody
who
is
you
know
just
unrel,
you
know
who
is
coming
at
it
from
a
different
context,
can
understand
what
context
we're
talking
about
it.
J
Yeah
I
remember:
we
had
a
a
like
fairly
healthy
discussion
about
this
a
few
weeks
back
and
I.
Think
one
of
the
conclusions
was
that
many
of
us
working
on
cell
so
didn't
have
the
context
to
be
able
to
make
the
clarification
that
was
being
requested.
Specifically
with
regards
to
the
question
the
initial
question.
In
the
the
issue
like
but
I,
I
can't
tell
you
what
the
distinction
is
between
a
security
framework,
compliance
requirements
and
a
maturity
model.
J
We
do
have
a
terminology
page
where
we
try
to
make
some
of
the
other
things
clearer,
so
I
I'm
wondering
if
it
makes
sense
instead
of
saying
like
we
should
be
clearer
about
x.
If
we
have
like
a
a
blog
post
or
a
document
that
is
like
salsa
for
I,
don't
know
people
who
understand
sucks
or
whatever
or
salsa,
for
people
that
have
this
kind
of
job
function
and
instead
of
trying
to
make
the
text
like
the
spec
over
all
of
these
different
things
or
a
glossary
cover.
B
J
Yeah
I'm
not
even
yeah
in
some
ways
it
feels
like
punting,
because
I'm,
not
a
compliance
officer,
so
I
still
can't
do
that
but
like.
If
can
we
can
we
make
this
a
more
tractable
issue
so
that
people
with
those
skills
can
can
help
us
to
offer
something
because
I
I
don't
feel
like
trying
to
disambiguate
the
terminology
in
respect
is
going
to
be
something
I'm
struggling
to
see
how
we
would
be
able
to
do
that
and
still
satisfy
for
the
multiple
different
audiences.
J
Ultimately,
you
know
there's
lots
of
efforts
happening
within
security
and
software
supply
chain
security.
More
specifically,
where
these
terms
are
very
loaded
depending
on
what
context
you
come
with,
and
so,
instead
of
trying
to
disambiguate
the
terms
I'll
find
the
alternative
terms.
I'm
wondering
if
providing
focused
documentation
for
those
specific
audiences
is
the
easier
way
to
make
things
clearer.
B
That
sounds
good
to
me.
I'll
I
can
update
the
bug
with
that
suggestion
or
sorry
the
issue
with
that
suggestion.
It
also
occurs
to
me
now
that
the
dashboard
does
not
have
an
untriaged
portion,
so
everything
old
got
stuck
in
backlog.
I
think
it.
This
issue
does
truly
belong
on
a
backlog
which
is
different
to
being
untriaged,
so
I'll
make
that
change.
B
B
The
last
issue-
I
I
picked
up
is
727.
Let
me
drop
it
in
the
chat.
This
one
I
believe
is
pretty
much
shovel
ready
is
declare
a
preference
for
signing
methodologies
that
rely
on
transparency
logs.
This
came
out
of
a
REV
of
the
review
for
the
verifying
artifacts
page
and
provided
the
change
is
not
controversial.
It's
pretty
straightforward.
If
somebody,
for
example,
were
looking
for
a
first
issue
in
the
spec.
J
Yeah
I
think
the
anything
that
that
prevents
this
from
being
shovel
already
well
yeah,
maybe
Shuffle
ready
for
existing
contributors.
But
the
issue
lacks
some
context,
short
of
bouncing
you
to
read
through
the
the
conversation
in
the
in
the
pr
so
yeah
sorry
bit
of
a
tangent,
I
guess
but
I'm
trying
to
see
if
we're
drawing
a
distinction
between
contributions
that
are
good
for
new
contributors
or
contributions
that
are
kind
of
work
was
ready
to
do
for
existing
contributors
and
I.
Think
you
probably
meant
the
latter.