►
From YouTube: SLSA Specifications Meeting (October 17, 2022)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
everyone,
thanks
for
joining
as
a
reminder,
attendance
in
this
meeting
is
a
agreement
to
abide
by
the
Linux
Foundation
code
of
conduct.
Also,
please
register
your
attendance
and
the
meeting
notes
doc
with
Joshua's
pay,
sell
but
paste
again
for
the
folks
who
just
joined
since
you
can't
see
prior
chat
history.
A
We
have
one
thing
on
the
menu
which
is
just
a
salsa
V1
it.
If
there's
any
other
topics
to
discuss,
please
just
add
them
to
the
agenda
and
we'll
we'll
schedule
them
or
we'll
make
sure
we
have
time
I
guess
before
before
we
begin
talking
about
1.0.
Is
there
anything
any
other
topics
or
anything
people
want
to
say
beforehand.
A
A
As
always
like,
if
there's
particular
issues,
you
want
to
discuss
just
like
drop
it
in
the
agenda
and
we'll
talk
about
it
as
an
FYI
I
just
submitted
PR
number
502,
which
is
a
rewrite
of
the
levels
page
for
1.0.
A
A
So
for
folks
who
don't
want
to
read
every
single
pull
request,
but
this
one's
like
a
significant
rewrite
of
levels
and
and
it
reframes
the
levels
and
how
we
describe
them,
I
think
it's.
It's
certainly
not
done,
and
there's
like
a
bunch
of
to-do's
in
there.
A
I
just
also
sent
out
503,
which
shifts
the
emphasis
to
like
policy
and
verification,
which
is
something
that
we
had
discussed
in
Prior
meetings
this
one.
So
so
this
doesn't
actually
update
the
requirements
page.
Yet
I
just
haven't
done
it
yet,
but
it
in
terms
of
like
the
high
level
description
of
each
level.
It
adds
effectively
adds
a
requirement
that
we
set
an
expectation
of
how
a
package
is
supposed
to
be
built,
and
then
you
actually
verify
it,
which
we'll
then
have
to
translate
into
formal
requirements
for
implementation.
A
A
A
One
is
the
first
one
number
130
that
covers
like
the
difference
between
automatic
and
manual
verification,
which
is
something
that
we've
kind
of
talked
about
a
little
bit,
but
not
it's
not
formally
in
the
spec
and
something
from
Tom
hennen
really
stuck
with
me,
which
is
that,
like
we
try
to
automatically
verify
artifacts
but
have
to
manually
verify
systems,
and
so
I
suggest
that
we
kind
of
go.
A
You
know,
go
down
that
route
and
then,
assuming
that
we
want
to
do
that,
then
I
broke
it
up
into
two
other
issues
or
a
repurposed
existing
issues,
one
to
cover
the
automatic
verification
of
artifacts
and
like
what?
How
do
you
set
expectations?
Do
you
have
to
check
the
source
repository?
What
has
to
go
into
Providence?
Who
checks
what
signatures
Etc
and
that
I
think
would
also
Define.
A
We
have
to
figure
out
something
about
roots
of
trust
there,
not
not
just
from
like
a
cryptographic
perspective
of
you
know,
pki,
but
also
who
trusts
what
system.
At
what
level
we'll
have
to
have
some
sort
of
system
there
and
then
the
other
issues
around.
How
do
we
verify
that
systems
actually
meet
their
requirements
and
I
think
this
is
where
like
oscow
I'm
guessing
the
Oscar,
because
there's
another
issue
around
oscow
that
I
think
malpa
had
filed?
A
Oh-
and
we
also
talked
about
like
this
survey
of
evidence
of
security
claims,
so
I
think
that's
like
where
that
would
go,
because
that's
a
that's
a
missing
major
piece
from
the
1.0
proposal
that
we
haven't
done
yet
so
I
guess
I'll
stop
rambling
there,
but
that's
kind
of
an
update
from
my
side
of
of
for
request
issues.
B
And
Mark
for
the
for
the
one
pull
request
emerged:
I
think
it
was
this
morning
you
said
we
can
like
there's
still
some
open
items
in
there.
We
can
kind
of
you
just
wanted
to
get
it
in
there
for
now,
and
we
can
kind
of
reopen
some
of
that
right.
A
Yeah
yeah
feel
free
to
comment
like
if
you
either
want
to
open
a
separate
issue
or
just
comment
directly
on
the
pull
request:
either
either
works
for
me
I.
Just
because
it's
kind
of
a
big
change,
I
figured
it
was
easier
to
submit
and
then
we
could
make
diffs
off
of
that,
because
GitHub
doesn't
allow
you
to
have
like
chained,
pull
requests,
and
so
it
makes
it
really
hard.
If
you
have
one
open
one,
and
then
you
do
a
subsequent
one
on
that
right.
A
Like
at
a
minimum,
we
could,
if
there's
going
to
be
a
big
item
and
it's
not
the
top
priority.
I'd
rather
add
a
to-do
and
kind
of
work
on
the
top
priority
items.
First
and
then
you
know,
and
then
we
could,
we
could
work
on
that.
You
know
Whittle
that
down,
but
but
either
way
it
would
work.
B
For
the
mark,
my
thought
actually
is
around
kind
of
piqued
my
interest
when
you're
talking
about
you
know
like
the
theme
around
like
what
should
someone
look
for
when
they're
trying
to
verify
it,
artifact
right
and
that's
kind
of
like
what
should
you
look
for
in
the
provenance
talk
right
like
there's
a
lot
in
there
right
so
like?
Maybe?
Are
you
talking
about
kind
of
more
like
hey
like
these
are
the
three
things
that
are
probably
a
good
thing
to
look
for,
like
the
the
ref
from.
B
The
actual
repo
itself
like
that
would
be
helpful
for
me
right
as
a
consumer
I.
Imagine
to
have
that
pointed
quickly.
A
Yeah
yeah
I
think
that
covers
issue
46
and
if
you
click
on
the
issue,
Tom
hennen
had
like
posted
kind
of
like
a
long
initial
post
about
various
things
that
we
could
possibly
check.
I
I,
don't
think
we
have
any
sort
of
I
think
we
have
a
shared
agreement
that
we
want
to
check
something
I,
don't
know
if
we
all
agree
on
exactly
what
that
looks
like
Visa
had
presented
in
weeks
past
around
like
some
like
a
model
around.
A
A
I
in
in
I'm
guessing
what
what
we
may
want
to
do
is
kind
of
separate
into
there's
a
roots
of
trust
question
like
both
pki
and
then
also
who
you
trust
at
what
level
like
I,
trust,
GitHub
actions
and
I.
Think
it's
a
level
three
thing
versus
some
other
company
might
say:
no,
it
doesn't
meet
our
standards,
I
trust,
Circle,
CI,
ARA
or
whatever
that
one
I
don't
know
if
we
could
come
to
some
sort
of
universal
agreement,
but
it
probably
will.
It
also
relates
to
the.
A
If
you
remember,
there's,
if
you
saw
there's
a
presentation
a
couple
weeks
back
in
September
a
couple
weeks
ago
around
and
the
salsa
conformance
proposal
around
there's
like
that
two-tiered
system
of
like
self
attestation,
I
think
it's
related
there
around
like
you
could
have
some.
You
know,
I
trust,
anything
that
so-and-so
says
is
good,
so
there's
kind
of
like
a
roots
of
trust,
but
then
I
I
think
there's
probably
an
expect
like
a
current.
A
The
current
thing
that
was
just
submitted
I
would
call
it
expectation,
I,
think,
there's
a
draft
pull
request
for
a
pending
forward
around
like
expectations
for
about
the
artifact.
How
it
should
be
built
around
and
my
feeling
is-
we
want
to
keep
that
as
small
as
possible,
like
what
is
the
minimum
necessary
in
order
to
prevent
the
threats
that
we
want
to
prevent
like
you
know
that
and
upload
a
A,
maintainer
or
a
compromised,
maintainer
credential
is
used
to
upload
a
package
that
is
inauthentic
in
some
way
and
for
those
I
suspect.
A
Well,
let
me
actually
present
so
we
have
some
sort
of
visual
I
can't
oops.
A
And
so
like,
so
that
I
suspect
will
probably
want
to
be
like
the
source.
Repository
I
think
at
least
for
open
source
will
be
necessary.
I,
don't
know.
A
The
closed
Source
I,
don't
know
if
maybe
the
requirements
are
different,
but
for
open
source
like
the
source
repository
and
probably
something
how
it
was
built,
because
if,
for
example,
someone
takes
a
git
repo
but
then
runs
the
command
W
get
something
else
like
and
just
plopped
in
and
said,
that's
the
artifact
and
it
doesn't
actually
use
the
code.
We
have
to
protect
against
that
and
that's
like
not
exactly
divided
by
the
producer
or
the
consumer,
but
it's
almost
like
a
contract
between
them.
A
That,
like
the
producer
says
this
software
came
from
this
place
and
the
consumers
have
some
agreement
that,
like
future
versions,
are
going.
You
know
this.
One
and
future
versions
are
going
to
look
like
that
and
I've
made
my
decision
based
on
that
analysis,
and
so
you
kind
of,
but
there's
that
piece
that,
like
core
piece
and
then
there's
additional
things
that
either
the
producer
or
the
consumer
might
want
to
check
also
like
while
you're
at
it.
You
might
also
want
to
check
that
maybe
that's
tested.
A
It
has
an
s-bomb
that
it's
you
know
not
just
any
workflow
in
the
repo,
but
the
specific
one
well
or
like.
Has
this
Properties
or
something
those
I
think
are
kind
of
like
value-add
things
but
in
my
mind,
are
not
requirements
for.
B
A
And
because
I
feel,
like
we
kind
of
get
caught
up
in
that
a
bit
of
like
some
folks
like
well
I,
want
to
check
this
I
want
to
check
that
and
so
I'm
thinking,
maybe
it'll
be
helpful
to
split
out
like
what
is
required
by
salsa
in
order
to
prevent
these
specific
threats
versus
what
are
additional
things
that
people
could
want
to
do
and
that
maybe
we
recommend
allowing
people
to
do,
but
it's
not
strictly
required.
A
So
anyway,
that's
kind
of
where
I
me
personally
I've
been
thinking
lately.
C
Yeah
I
think
I'm
in
a
similar
space,
in
that
we
there's
kind
of
three
classes
of
of
like
documentation
required
here.
The
rules
of
trust
is
something
that
salsa
requires,
but
we
don't
want
to
mandate
like
who
you
trust
or
how
you
define
that
trust
relationship.
We
just
need
you
to
establish
that
trust
relationship
in
order
to
be
able
to
implement
salsa
the
expectations.
C
The
minimum
expectations
I
definitely
think
we
do
need
to
Define
as
part
of
salsa,
like
you
said,
Mark,
to
provide
the
protections
that
starts
designed
to
predict
and
then
the
final
two,
the
producer
and
consumer
additional
requirements
are
like
could
be
recommendations
or
implementation
guidelines
that
fall
into
like
some
supplementary
documentation.
Maybe.
B
And
I'm
I
think
I
also
agree
right,
like
the
salsa
provenance
is
kind
of
like
a
commodity.
All
right
so
like
the
spec
is
like
defining
what
the
commodity
should
be
and
what
the
specification
of
that
commodity
properties
it
should
have,
but
maybe
we
as
salsa
as
you're
kind
of
saying,
Mark
and
and
Josh
like
it's.
You
know,
there's
there's
a
benefit
to
what
someone
can
do
with
that
commodity
after
right
and
maybe
we'll
give
some
high
level
Benchmark
recommendations,
but
not
requirements
is
that
kind
of
where
you're
going
also
Josh.
C
Yes,
I
think
so
like
we
need
to
provide
some
guidance,
but
it
shouldn't
be
yeah.
We
we
don't
want
to,
and
we
don't
want
to
tie
people
to
certain
implementations
for
those
things.
I
think.
C
I'm,
mostly
just
happy
to
see
this
starting
to
get
like
defined,
because
we've
had
this
as
a
notion
from
early
on
and
we've
used
some
terms
that
have
caused
a
lot
of
distraction.
But
it's
nice
to
see
this
like
taking
form.
A
B
A
It's
like
a
thumbs
up
or
agreement
would
be
valuable
or,
if
anything
doesn't
look
good.
You
have
other
thoughts.
Certainly,
contributions
are
very,
very
welcome.
A
I,
I
think
in
particular
those
like
the
automatic
verification,
Mana
verification
need
quite
a
bit
of
work
of
like
thinking
through
the
details
and
like
how
we
phrase
it
and
what
the
requirements
are,
and
so,
even
if
you're
not
like,
don't
have
the
capability
of
like
writing
the
fully
fleshed
out
wording.
That
sounds
it's.
A
You
know
unambiguous
Etc,
just
adding
General
ideas
to
the
comments
is
really
useful
because
then
we
could,
like
you
know,
that's
kind
of
raw
material
to
form
into
like
the
actual
text
that
we
put
in
the
doc
like
most
of
what
I've
been
doing,
is
just
taking
other
people's
ideas
that
they've
written
in
the
comments
and
just
like
reformatting
them
and
trying
to
get.
You
know
the
consensus
that
was
spread
across
all
these
issues
in
writing
up
in
a
nicer
way,
and
actually
that's
maybe
a
good
segue.
A
Just
as
you
know,
there's
discussion
before
like
what
the
timelines
are
and
how
long
it's
it
you
know,
when's
it
going
to
be
ready.
I
think
at
the
current
case
is
not
look
like
we're
on
track
for
getting
this
finished
like
originally.
We
were
hoping
for,
like
this
month,
like
I,
don't
think
we're
at
all
on
track
for
that
I
think
we
need
more
contributors
to
actually,
you
know,
write
the
text
and
form
it.
B
I
would
love
to
get
it
out
Mark,
but
I
think
it's
much
better.
It's
much
more
important
to
make
it
good
than
make
some
arbitrary
deadline.
A
C
Yeah
completely
agree
with
that
and
I've
I've
rattled
the
same
well
I've
indicated
the
same
in
the
past
and
I'm
guilty
as
most
of
not
writing
stuff
and
I'm,
hoping
to
find
some
more
time
to
do
that
infusion.
But
the
question
I
want
to
ask
is
whether
there's
anything
we
could
do
from
a
process
standpoint
that
would
make
it
easier
for
folks
to
contribute
whether
it's
like
well
yeah
I,
don't
want
to
color
I'll
leave
the
question.
Open
start
so
folks
are
interested
in
contributing.
B
Right,
oh
sure,
thanks
yeah
for
me,
I
think
it's
just
not
having
a
clear
or
let
me
put
this
differently.
I,
don't
really
want
to
step
on
anyone's
toes
if
they've
already
start
started
working
on
something
and
so
I
think
having
a
clear
list
of
who
owns
Which
tasks
is
what
I've
been
missing
to
actually
yeah
contribute
something.
B
I
mean
aside
from
time,
which
I
don't
think
anyone
can
give
me
yeah,
I
I,
think
I.
It's
mostly
like
hey
here's,
a
task
but
I,
don't
I,
don't
typically
work
in
GitHub.
It's
not
something
I
do
daily,
and
so
it's
not
something
that
I
like
think
to
work
in,
but
I
think
I'm
used
to
like
jiras
and
project
management
of
like
here's.
Your
task
review
this
by
this
date,
okay,
cool
I,
can
do
that.
B
Like
not
necessary,
I
mean
I,
know
that
just
sounds
like
hey
I
need
to
be
spoon,
fed
my
work
but
like
it's
so
external
to
my
normal
work,
and
this
is
my
first
like
open,
ssf
group
that
I've
contributed
to
so
I
like
apologize
for
not
contributing
more
I'm,
just
kind
of
not
really
sure
where
to
where
to
be
honestly.
So.
C
I
mean
desperate
project
management
systems
is
definitely
a
like
a
problem
for
everyone.
I
think
so.
No
need
to
yeah
feel
bad
about
that.
Aaron
do.
B
You
wanna
yeah
I,
was
gonna,
say
well.
I
I,
just
started
contributing
right
like
in
this
spec
I've
started
to
actually
here's
a
tip
for
everybody,
put
on
a
block
of
time
on
your
calendar
to
dedicate
to
logging
into
GitHub
and
just
commenting
on
these
pull
requests
and
honestly
Mark
right
like
feedback
right.
The
pull
requests
that
we're
working
on
the.
B
What
is
this
502
was
pretty
massive
right
so
like
going
through
that,
like
I,
try
to
just
kind
of
go
through
and
find
pieces
that
I
felt
a
little
bit
passionate
about
and
like
I
just
commented
on,
there,
I'm
probably
going
to
try
to
open
a
new
plural
request
to
try
to
reword
some
of
that
authenticated
requirement.
So
that's
kind
of
how
I'm
planning
on
contributing
back
but
I,
think
maybe
like
if
we
have
smaller
blocks
right
of
things
that
we
want
to
tackle.
B
B
Yeah,
if
you
can
jump
in
for
a
second
sorry
if
I
can
jump
in
for
a
second,
so
you
piggyback
off
of
what
Aaron
was
saying,
I
think
having
a
a
priority
list
of
what
we
want
to
really
tackle
in
which
order
yeah
would
be
helpful,
because
I've
also
just
been
going
through.
Github
issues
that
I
just
sort
of
randomly
that
are
tagged
with
us.
Maybe
1.0
tag,
but
it's
just
I've
been
choosing
them
sort
of
arbitrarily
based
on
what
I
find
interesting.
So
yeah.
C
I
just
want
to
jump
on
Aaron's
comment
as
well
and
say
that
well
we
initially
asked
about
how
can
we
make
it
easier
for
folks
to
write
stuff?
Also
like
jumping
in
and
doing
the
review
is
super
helpful
as
well,
because
the
more
review
happens.
Well,
the
the
iteration
through
the
review
process
has
really
helped
consistently
improve
the
docs,
but
also
the
more
review
happens.
The
I
think,
ultimately,
the
more
we
free
up
bandwidth
for
folks
to
do
some
writing.
B
Thanks
for
that,
yeah
and
just
I'll
just
replay
one
more
time,
if
you
don't
mind,
you
know
me
reviewing
502
now
inspired
me
to
go
and
write
and
hopefully
contribute
right.
So,
like
that's
I
like
that
feedback
loop
right
there
and
you
know
Mark
I'm
not
trying
to
come
at
you
saying
that
was
giant
PR,
but
maybe
maybe
that's
good
in
a
way
right
to
like
kind
of
get
some
content
reviewed.
So.
C
So
I
think
we've
we've
talked
a
few
times
about
like
having
clear,
clearer
ownership
of
tasks
and
I
I
recognize
that
from
other
kind
of
Open
Source
communities
like
people
are
worried
about
starting
to
work
on
something
and
then
finding
out
that
someone
else
has
done
the
work.
C
So
I
guess
I.
Think
in
the
past,
we've
suggested
that
people
just
kind
of
comment
on
an
issue
and
we
can
assign
them
but
I.
Think
probably
the
other
thing
is
for
the
maintainers
myself
and
Mark
and
Mike
to
also
indicate
on
the
like
issues.
The
things
we're
working
on
by
using
the
assign
peace
is
that,
like
is
that
a
help
for
making
it
clear
where,
when
something
has
ownership
or
do
you
think
we
need
more
something.
C
I
think
I
can't
say
what
I'm
thinking
something
more
concrete
somewhere
that
indicates
kind
of
a
yeah,
the
ownership
of
of
pieces,
of
the
work.
A
Yeah
but
personally,
like
I
I,
know
that
I
almost
never
noticed
the
assignees
in
the
top
right
corner.
I,
don't
know
if
anyone
we
don't,
we
never
use
them
and
I
guess
my
eye.
Just
I
mean
we
could
start
using
them.
A
A
I
suspect,
I
think
my
guess
is
so
I
think
maybe
the
two
most
valuable.
A
A
The
issues
are
not
particularly
well
organized
they're
written
by
a
bunch
of
different
people
at
different
points
in
time,
which
is
effectively
like
more
people
like
your
past
self
and
your
current
self,
and
so
like
it's
not
clear
like
what
they
all
add
up
to
what
they
all
mean
and
whereas,
if
we
had
some
sort
of
hierarchy,
I
think
that
would
would
help
too.
But
we
don't
have
it.
Maybe
we
could
kind
of
come
up
with
like
a
couple
top
priorities.
A
I
also
think,
as
I
mentioned
before,
I
think,
a
lot
of
the
things
are,
the
difficult
part
is
kind
of
figuring
out
the
the
core
idea
of
what
we're
trying
to
say
and
like
what
we're
trying
to
do
and
like
even
if
it's
not
worded
carefully
or
it's
like
not
quite
right,
I.
Think
sharing
that
in
a
comment
has
been
really
valuable
because,
like
over
time,
we
kind
of
just
form
the
opinion
collectively
of
like,
for
example,
here's
one
better
defined
Source
I'm,
just
picking
one
kind
of
at
random.
A
Like
this
is
one
of
like
what
what
does
it
mean
for
Source?
What
are
the
specific
requirements?
Why
are
we
trying
to
do
this?
The
particular
issue
is
like,
if
you
have
a
GitHub,
let's
take
GitHub
actions
as
an
example,
because
again
we're
using
GitHub
as
our
platform
for
for
their
puzzles.
A
The
build
configuration
like
we
could
definitely
attest
to
that.
That,
like
the
workflow
file
is
there,
but
we
can't
actually
test
to
that.
The
source
code
was
there
because
that
the
first
step
is
to
check
out
some
repository,
which
is.
C
B
A
Same
exact
commit
that
triggered
the
workflow,
but
not
always
it
could
check
out
anything.
What
is
the
model
there?
A
How
do
we
do
that,
and
so
I
think
you
know
for
for
contributing
a
if
you
have
a
little
bit
of
time.
Just
thinking
about
it
and
kind
of
inching
us
forward
along
is
is
valuable
and
you
know
just
doing
it
in
a
comment
and
then
you're
not
effectively
working
on
it
long
term.
A
If
you're
working
on
like
a
doc
or
something
it
doesn't
have
to
be
a
markdown
just
any
sort
of
thing.
Maybe
we
could
add
a
comment
like
I've
been
working
on
it.
I
have
a
draft,
you
know,
but
even
if
you're
not
ready
to
share
just
saying
something
that
that
could
be
a
way
of
okay.
That
way,
people
were
also
thinking
about
it
could
connect,
or
they
could
just
open
that
person
think
about
I'm
not
going
to.
C
Yeah
I
agree
with
that
I
was
I
was
going
to
make
some
suggestion
to
kind
of
stop
sharing
initial
thoughts
in
the
issue
tracker
and
and
almost
using
that
as
a
way
to
draft
contributions,
and
that
helps
a
bit
with
the
with
the
markdown
document
and
get
workflow
being
kind
of
foreign
to
some
contributors
who
still
have
2.8
valuable
insights.
To
bring.
A
A
One
at
the
top
of
my
mind
is:
is
the
model
the
terminology
around?
We
already
have
a
model
for
the
build
terminology
we
need
I
just
mentioned
the
better
defined
Source
One
have
an
equivalent
for
Source
terminology,
but
also
I.
Think
I
just
submitted
to
do
to
do
that.
Oops
yeah,
like
ecosystem
project
like
for
pack
for
like
what
a
package
is.
A
A
Those
would
all
be
I
think
things
that
we
don't
is
more
on
the
writing
side
and
less
on
the
figuring
it
outside
I
mean
we
could
come
up
with
a
better
term,
and
we
could.
We
could
talk
about
that,
but
I
think
that's
more
shovel
ready
in
that.
It's
not
like.
Well,
how
do
we
integrate
policy
into
this
specification,
but
more,
you
know
pick
something
and
write
the
diagram,
so
that
would
be
one
kind
of
category
I
think
I
feel
like
it.
A
System
consider
I'm
not
sure
we
have
an
issue
for
that.
One
Mission
pilot
issue:
okay,
there's
another
and
someone
else
had
a
diagram
of
like
how
it
like
the
build
thing
spits
out
at
the
station.
C
A
B
A
Sorry,
every
time
probably
every
video
of
This
Is
Me,
not
making
that
mistake
yeah,
so
the
modern
terminology
I
think,
are
more
shovel
ready.
So
much
I
think
it's
kind
of
ready
to
write,
although
some
of
the
terminology
is
figuring
stuff
out.
A
So
I
think
comments
like
both
comments
on
the
issue
or
actually
writing
a
draft
would
be
valuable.
This
for
the
verification,
piece
I,
think
it's
more
figuring
out
the
concepts
and
would
require
kind
of
a
larger
investment
in
time,
because
it's
more
like
figuring
out
the
whole
like
how
the
whole
system
works,
and
so,
if
that's
kind
of
more
your
thing
that
would
that
would
be
I,
think
that's
a
whole
area.
A
What
else
I
Define
trusted
control
foreign.
A
There's
I
think
various
things
around
clarification
has
improved
wording,
there's
like
to
Do's
around.
A
Signatures,
oh
thanks.
C
Yeah
I
guess
the
problem
with
issue
cleanup
is
that
only
you
have
to
have
permissions
on
the
repository
to
like
close
issues
and
things.
A
I
think
also
like
splitting
up
build
versus
Source
I
think
there's
more
work.
There
update
requirements
and
the
update,
index.nd
I
I
can
take
that.
That's
what
that's!
What
I'm
working
on
now
foreign
that
will
allow
us
to
make.
You
know
more
direct
contributions,
not
stop
on
each
other's
changes.
C
Perhaps
we
should
move
the
starter
issues
list
here
to
like
a
top
level,
part
of
the
dock
and
let
people
add
their
name
and
use
that
as
a
kind
of
a
budget
project
tracking
space.
A
A
Issues,
what
would
it
be
helpful
to
like
categorizing
along
these
lines?
Is
that
helpful.
C
I
mean
I
suspect
it's
just
helpful
to
have
some
discussion
like
this
and
indicate
specific
issues
that
folks
might
jump
in
on,
and
maybe
we
should
try
and
like
reserve
just
a
bit
of
the
meeting
each
week
to
groom
a
list
of
starter
issues.
B
And
to
go
further,
you
know,
maybe
you
know
there
might
be
someone
that
wants
to
contribute
to
issues
or
close
issues,
but
they
feel
like
a
little.
You
know
hesitant
around
trying
to
do
that.
So
maybe
we
can
go
through
and
save
some
time
each
meeting
to
collectively
go
through
doing
that
right
and
then
we
can
kind
of
learn
and
feel
more
confident
together.
B
A
A
I
propose
that
that
is
like
for
folks
who
want
to
contribute,
can
can
work
on
that
I.
Some
folks
on
my
team
had
started
a
doc
around
that
and
what
I
I
well
I
can
do
later
today
is
gather
all
these
terminology
things
into
one
bucket.
So
we
don't
it's
not
spread
apart.
So
many
issues
for
like
make.
Maybe
one
master
issue
that
like
lists
all
the
other
sub
issues
and
have
folks
work
on
like
terminology
and
examples
for
like
packaging
and
Source
Etc,
because
I
feel,
like
that's
pretty.
A
Can
like
concrete
and
is
maybe
a
good
way
to
get
started
because
then
it's
like
you
kind
of
know
when
you're
done
right,
it's
like
we
need.
We
need
to
Define
this
thing
because
I
this.
A
B
A
I
guess
that's
true
is
this:
is
the
top
of
the
list
I
think
the
term
packet
well
within
Google
we've
had
a
lot
of
confusion
around
what
we
mean
by
package
of
like?
Is
it
the
specific
artifact
like
the
thing
with
a
hash?
Is
it
the
concept
of
like
you
know,
underscore
JS?
Is
it
a
version
of
a
package
which
could
result
in
multiple
artifacts
and
so
like
internally?
We
have
some
doc.
That's
like
agreed
upon
with
like
what
we're
going
to
use
that,
but
is
it
strictly
required?
A
I
wish
I
I
wish
sorry
to
interrupt
I
I'm.
Having
let
me
turn
my
mind.
I
wish
you
could
have
allowed
us
to
assign
priorities
right,
because
that
would
probably
not
be
a
blocker
right.
That
would
be
not
the
P0.
The
Google
speak,
I
think
a
P0
is
figuring
out
this
verification
stuff.
A
B
A
C
C
So
yeah
curating
this
list,
regardless
of
how
we
like,
regardless
of
how
we
stole
the
list
curating
the
list
together
as
a
as
a
group,
seems
to
be
a
good
use
of
time.
C
Mark,
did
you
say
you
would
share
your
definitions?
You've
been
using
internally,
or
should
we
I
just
just
start
something
new.
A
I'll
I'll
share
it
I,
also
post
it
on
the
slack
channel
whenever
it's
it's
ready,
I
I
think
I'm
finding
it
difficult
now,
because
it's
just
like
this
long
list,
how
many
issues
are
there?
It's
like
50
issues
right,
it's
just
so
many
to
even
like
I'm,
constantly
like
rescanning
and
trying
to
prioritize
and
I
think
we
really
just
need
hierarchy
and
so.
B
A
Like
I
mean
in
terms
of
like
priorities
for
1.0
of
like
what
we
actually
want
to
accomplish,
I
think
one
is
split.
Build
versus
source
include
verification
which
we
have
like
the
automatic
verification,
artifacts
manual,
verification
of
systems.
A
There's
probably
like
fix
specific
issues
that
are
like
blocking
adopters
of
0.1
I,
don't
know
what
those
are
yet,
but
I
suspect,
there's
probably
some
list
of
issues
that
are
more
important
than
others.
A
Like
oh,
this
thing
is
unclear,
or
it's
like
ill-defined
or
something
like
that:
I'm,
not
sure
exactly
what
those
are.
A
All
right
so
I
think
a
good,
a
good
Next
Step
would
be
I
can
take
all
the
issues.
I'll,
probably
just
use
a
spreadsheet
because
doing
in
GitHub
directly
is
too
painful
and
make
some
sort
of
hierarchy
and
share
it
with
everyone.
And
then
we
could
see
like
how
does
this
spreadsheet
or
a
doc
or
something
like
that
see
how
it
looks
and
see
if
we
could
kind
of
you
know,
each
thing
could
kind
of
roll
up
to
some
sort
of
larger
objective.
A
I
think
that
would
make
it
a
little
bit
clearer
and
also
to
John's
point
of
like
what
is
the
most
important
thing
about
your
actual
blockers,
what
are
just
nice
to
haves,
and
then
we
can
kind
of
vote
and
Grant.
Like
oh
I,
don't
think
that's.
B
A
Yeah
yeah
I
wish
we
had
it
a
different
issue.
Tracker
yeah
spreadsheet
seems
like
a
decent
compromise
for
now.
C
A
B
B
But
this
list
right
here
you
know
splitting
purification,
you
know
a
couple.
Adoption
and
terminology
don't
seem
like
they
all
seem
like
worthy
things
to
do
before
1-0.
B
A
Yeah
I'm,
hoping
that
once
we
have
a
like,
we
see
it
all
in
one
list
that
actually
makes
sense.
We
could
reword
things
and
merge
issues.
I
probably
would
be
valuable
to
just
merge
issues
that
are
all
about
the
things
and
have
like
GitHub
has
like
this.
Like
task
list
thing,
they're
like
check
boxes,
and
then
we
can
kind
of
go
and
tick
off.
Those
I
think
that'd
be
easier
to
read
than
having
this
flat
list
of
50
issues
or
or
somewhere
had
that
sort
of
hierarchy
easily
available.
A
A
In
terms
of
next
week,
I
am
not
going
to
coupon.
Do
we
have
quorum
to
meet
well
I
guess
we
could
just
try
a
meeting
and
if
no
one
shows
up
then
we'll
just
cancel.
A
All
right
sounds
good
and
again
so
I'll
send
this
out
on
the
I'll.
Just
do
it
on
slack,
unless
anyone's
not
on
slack
and
and
then
again,
as
Arnold
said,
we
could
kind
of
comment
on
there
and
just
vote
on
different
things
or
make
suggestions.