►
From YouTube: Working Group: 2021-03-10
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).
C
No,
this
is
my
first
time
to
these
meetings.
Actually
I
am
one
of
the
I'm
I'm
in
lfx.
I
am
the
lfx
mentee
for
this
year.
So
joe
gartner
is
my
mentor.
B
Awesome
great
to
have
you
here.
Thank
you
all
right
next
thing
on
the
agenda
is
release,
planning
and
updates.
I
think
emily
is
not
going
to
be
able
to
make
this
one.
Javier,
do
you
want
to
cover
from
platform
side
and
then
maybe
natalie
could
take
rotation.
D
Yeah
all
right,
so,
let's
see
the
tekton
stuff
is
still
in
limbo,
waiting
for
approval
from
the
tecton
catalog,
so
still
poking
them
there.
Pack,
we
are
anticipating
to
release
next
week.
Dan
thornton
will
be
our
release
manager,
so
he
should
be
taking
care
of
that.
We
are
trying
to
go
into
feature
complete
either
today
or
tomorrow.
There's
a
couple
issues
in
particular
bugs
that
we
want
to
address
before
we
seal
it
off,
but
other
than
that
everything
seems
to
be
gone
according
to
schedule.
C
On
the
life
cycle
side,
I
think
we
are
getting
close
to
shipping
our
next.
I
guess
it
would
be
0.110.
C
C
B
Cool
so
then,
we'll
jump
into
our
weekly
rfc
review.
Give
me
a
second
to
share
the.
B
Screen
all
right
first
thing
is
process
specific
working
directory.
This
is
new
forest
openness.
Is
he
here?
I
don't
think.
Oh
yep
cool
awesome.
Are
you
in
the
corner.
F
F
B
Seems
like
there's
some
background
noise
on
your
side
forest.
Thank
you.
Next
rfc
is
guidelines
for
accepting
component
level
contributions.
This
one
is
mine
and
I
just
put
it
on
the
agenda,
and
we
can
talk
about
it
today
too,
one
after
that
is
rfc
for
displaying
contributor
graph.
A
Yeah
this
was
mine,
it's
exactly
what
it
sounds
like.
I
want
to
put
a
graph
somewhere
public.
I
will
talk
about
it
more
in
the
agenda.
B
Awesome,
if
you
want
to
put
at
the
end
that'd
be
great,
and
next
one
is
rfc
on
issue
generation.
B
B
The
review
part,
so,
let's
just
go
back
through-
and
this
is
buildpack
api
right.
B
This
would
require
a
spillpack
spec
change
and
it's
in
the
implementation,
yeah
where's
that
implementation
team
here
and
any
other
labels
supposed
to
add.
At
this
point,
I
think
it's
just
those
two.
C
B
C
D
E
Yeah
yeah,
I'm
mostly
just
looking
for
at
least
we
did
a
lot
of
discussion
last
week,
I'm
mostly
looking
for
feedback
on
still
kind
of
the
open
thing
that
joe
commented
on,
but
like
the
tl,
the
project
tld
and
how
we're
swatting
on
that
and
kind
of
where
people
sit
on
what
we
want
to
do
with
that
before
I
kind
of
move
forward.
B
Got
it
so
not
on
the
agenda?
Just
looking
for
feedback
asynchronously.
B
Sounds
good
and
how
would
you
categorize
this
I
forget.
D
B
Okay,
yeah,
we
got
this
extensions
one
there
cool
all
right
pack,
as
a
draft
add
builder
key
in
project
descriptor,
rfc
proposal.
This
is
in
fcp.
I
think
we're
still
waiting
on
image
or
on
some
issues
to
get
created.
C
G
I
had
a
quick
question
about,
like
I
guess,
process
here,
so
a
bunch
of
issues
will
be
created
for
that
rfc.
If
I
want
to
express
that,
I
would
love
to
see
this
implemented
faster,
like
where's
the
right
place
to
say,
like
hey,
can
the
cmv
project
prioritize
this.
B
I
would
comment
in
the
rfc
and
volunteer
to
start
kind
of
doing
the
work
to
get
it.
You
know
moving
forward
like
if
you
wanted
to
create
issues
if
the
officials
need
to
get
created.
You
know
that
I
think
that's
doesn't
have
to
be
the
person
assigned
to
look
at
the
rfc.
You
know
also
just
voicing
your
support
in
the
rfc
it'd
be
good
too.
B
No,
that's,
that's
we
don't
we
don't
have
a
great
process
answer
for
that
question,
which
is
my
advice.
B
Cool
next
thing
is
create
stack
fight,
repo.
D
B
E
E
D
Platform,
so
this
is
probably
ready
to
go,
I
think
so.
I
think
we
still
want
those
issues
created
label.
You
know
for
somebody
to
speak
on
behalf
of
the
implementation
side,
but
I
think
we're
good.
B
Cool
I'll,
let
emily
know
that
this
is
ready
to
go
to
add
those
labels
and
then
application
mix-ins
is
still
a
draft,
and
so
that
concludes
our
rfc
review.
B
Next
thing
on
the
agenda
is
a
process
specific,
oh
sorry,
component
guidelines.
I
just
didn't
link
it
to
the
rfc,
so
this
is
I'll
put
the
link
in
the
document.
People
click
on
two.
B
For
this
I
am
proposing
some
guidelines
for
what
it
would
look
like
for
the
project
to
accept.
Contributions
like
like
stackafio
is
an
example
of
like
repo
that
was
being
contributed
kind
of
externally
into
the
project,
as
opposed
to
you
know
some
lines
of
code
and
an
existing
repo.
B
I
can
just
let
me
share
my
screen.
Probably
the
easiest
way.
B
Cool
everybody
see
that
I
think
she
already
had
some
feedback
on
this,
but
the
idea
here
is
just
you
know:
we
don't
really
have
a
process
for
accepting
larger
things
than
you
know,
individual
contributions
to
the
repos
that
exist.
B
A
look
and
see
what
you
think
you
know
just
give
some
examples
of
what
you
know.
Things
that
could
be
contributed
and
couldn't
be
contributed.
Might
look
like
give
folks
a
minute
to
read
that
see
if
there
any
questions.
D
So
I
have
a
question
for
the
non-qualifying
example
there
on
the
generic
ci
cd
tool.
What
is
that
speaking
to
and
to
what
level?
Because
we
do
have
the
tecton
tasks?
Are
you
talking
about
like
susan.
B
D
B
Yeah,
like
you,
couldn't
contribute
all
of
something:
that's
like
all
of
tekton,
just
because
it
has
some
build
pack
building
functionality,
but
you
can
could
like,
like
an
example,
would
be
a
specific
github
action
that
does
build
pack
builds.
That's
you
know,
with
the
sole
intent
of
supporting
integration
into
that
platform
would
be
okay,
but
a
whole
cicd
system
that
happens
to
use,
build
packs,
probably
wouldn't
belong
in
the
project.
It's
kind
of
an
obvious
statement,
but
I
just
wanted
to
be
complete
and
kind
of
describing
what's
acceptable
and
what's
not
acceptable.
E
E
H
So
yeah
it's
it's
interesting.
What
I
was
I
thought
it
was
describing,
but
it
seems
that
it
sounds
like
it's.
A
other
other
open
source
organizations,
have
project
charters
or
or
guidelines
around
what
it
means
to
start
up
a
project
and
a
person
to
go
through,
including
showing
that
you
have
buy-in
from
a
community
that
it's
not
like
a
single
source.
That's
that's
going
to
do
the
development
in
case
that
that
company
changes
as
a
change
of
strategic
vision
and
decides
to
abandon
the
component.
H
So
they
want
to
see
that
there's
there's
buy-in
from
from
more
than
just
one
group,
which
I
guess
you
kind
of
address
a
bit
with
the
proposed
contribution
around
people
who
should
abstain
from
that
vote,
but
it
doesn't
directly
capture
that
that
there
should
be
that
there's
demand
for
it
from
more
than
just
that.
One
group.
B
Got
it
I
think
I
like
this.
This
tries
to
get
that
get
it
that
a
little
bit
right
like
it
has
to
be
something
notable
right,
but
I
think
you're
right
in
that
it
should.
There
should
be
some
item
that
says
you
know
there
has
to
be
community
consensus,
that
it
solves
a
need
that
people
need
solved
and
it
would
make
sense
to
work
together
on
that.
I
could
definitely
call
that
out
more
explicitly.
H
B
Totally,
I
will
definitely
add
both
of
those
things.
B
I
think
there
are
probably
like
legal
requirements
for
code.
That's
you
know
belongs
to
an
organization
is
now
like
moving
over
right
in
the
past
when
we've
like
moved
projects
that
were
owned
by
a
company
into
a
foundation
before
there
there's
some
like
legal
logistical
things
to
deal
with
there,
but
I'm
not
aware
of
any,
like
you
know,
guidelines
that
sort
of
sit
above
that,
if
that
makes
sense,
but
we
can
definitely
take
a
look
and
make
sure
that
that's
covered.
That's
a
good
point.
B
If
cncf
says
anything
about
this,
we
should
definitely
get
it
incorporated,
write
that
down
also.
B
B
C
F
Otherwise,
it's
linked
right
now,
I'm
having
some
trouble
sharing
my
screen.
One.
F
B
Sounds
good
so
move
that
below
the
next
one,
which
is
issue
generation.
D
All
right,
so
this
has
to
do
with
what
we
spent
most
of
this.
You
know,
beginning
of
the
meeting
on
which
is
these
issues
or
the
fact
that
we'd
like
to
have
issues
before
an
rfc
gets
merged
in
so
we
could
continue
to
track
the
work
as
it
progresses
through
through
the
whole
process
right,
and
I
think
right
now,
there's
this
sort
of
hindrance
on
on
two
individuals
or
set
of
individuals.
D
The
maintainers
of
the
individual
subgroup,
sub
teams
that
have
to
you
know
after
the
fact
after
the
rfc
has
been
quote,
unquote,
approved,
go
and
create
the
issues,
and
then
the
person
that's
actually
merging
the
approved
rfc
has
to
you
know
kind
of
go
and
poke
those
individuals.
So
that's
more
or
less
the
motivation
for
this.
D
So
the
proposed
solution,
there's
there's.
I
believe
three
proposed
solutions.
The
primary
one
is
based
off
of
adding
a
section
to
the
rfc
template
that
would
essentially
kind
of
negate
the
the
user
or
the
initial
author
from
filling
it
in,
but
then
the
maintainers
or
anybody
that
reviews
the
rfc
could
propose
issues
to
be
created
onto
this
section
via
list
in
a
very
specific
format,
and
then
it
would
require
the
author
to
accept
these
suggested
changes
right.
D
So
there's
there's
a
mechanism
built
into
github
for
this,
then
you
know
once
it
gets
approved
and
we
kind
of
merge
it
through
this
script
that
we
already
use.
It
would
kind
of
scrape
this
section
for
those
issues
and
create
the
issues
and
the
repositories.
D
That's
one
solution.
The
other
alternative
that
I
think
personally,
I'm
more
inclined
to
to
push
forward
on
is
using
comments.
So
in
this
case
I
think
you've
all
seen
kind
of
like
bots
on
github
issues
and
github
prs,
but
essentially
maintainers
or
whatnot,
would
be
able
to
add
a
comment
to
a
particular
rfc
to
add
a
pending
issue
to
the
rfc
that
then
very
similar
in
the
similar
vein.
The
rfc
script
could
then
go
and
scrape
for
those
comments
and
create
the
issues
from.
D
Since
we
already
used
the
script,
I
would
assume
that
the
script
would
do
it.
We
could,
then
you
know
if
we
want
incorporate
the
script
in
some
sort
of
you
know
higher
level
automation,
aka,
bot,
aka,
github,.
E
E
So
you
you're
proposing
the
first
thing,
but
you
like
the
comments
thing
more,
even
though
it's
in
alternatives.
D
Yeah,
yes,
only
because
I
think
this,
the
idea
of
the
original
author
having
to
accept
the
suggestions,
could
be
more
of
a
burden
on.
F
G
D
D
It's
simply
creating
this
comment
that
then
this
merge,
rfc
script
will
go
and
read
through
scrape
and
actually
create
the
issues
after
the
fact
and
that's
why
I
call
it
like
a
pending
issue,
because
technically
you
could
remove
an
issue
by
linking
to
a
comment
right.
So
it's
like
this
influx
state
before
it
actually
becomes
a
true
github
issue.
D
D
C
I
have
a
small
question:
does
only
maintainers
the
only
maintainers
can
add
that,
like
the
ad
issue
thing
or
do
like
everyone
can
do
this.
D
I
don't
see
why
other
people
wouldn't
be
able
to
do
it
right.
I
think
right
now
it's
a
responsibility
of
the
maintainer,
but
I
don't
think
it's
exclusively.
You
know
up
to
them.
F
So
yeah
this
should
be
pretty
straightforward
discussion.
If
I
can
actually
manipulate
this
window,
any
cool.
G
F
F
I
think
this
would
allow
users
to
or
build
pack
authors,
I
guess,
to
more
easily
specify
like
a
nested
command
or
even
a
user,
to
specify
a
nested
command,
even
though
they
are
pushing
an
app
directory.
They
would
like
to
run
some
sort
of
binary
that
they
have
or
something
like
that.
That's
embedded
further
down
in
the
application
structure.
F
So
yeah,
I
think
that
that's
pretty
much
it
with.
I
think
they
should
be
able
to
do
that
without
having
to
invoke
sort
of
a
change
directory
command
in
a
shell
or
something
along
those
lines.
So
the
life
cycle
would
essentially
invoke
from
the
directory,
given.
B
I
have
some
feedback
and
a
question
for
the
name
of
the
key.
This
is
very
minor,
but
you
know
command
and
args
feel
like
normal
dockery
casey
words
that
you
use
to
describe
those
things
I
think
workingder
or
workdir,
or
something
like
that.
You
know,
there's
probably
a
convention.
We
could
use
there
to
describe
that
kind
of
working
directory
the
process
starts
and
that
it's
not
as
generic
as
just
directory
yeah
totally.
F
I
did
yeah
I
did.
I
wanted
to
do
working
dash
dare,
but
I
did
directory
for
my
initial
thing.
For
brevity,
I'm
willing
to
go
long
form
if
that's
acceptable.
B
Maybe
not
working
dash
directory,
but
I
think
it's,
I
think
it's
okay
yeah
whatever
the
next
question
I
have
is
around
the
relative
path,
so
this
talks
about,
like
you,
can
do
a
relative
path.
You
know
to
the
app
you
know
within
the
actor,
if
you
created
a
layer
that
has
your
application
in
it
and
it
needs
to
be
invoked
with
some
subdirectory
of
the
layer.
It
seems
like
neither
an
absolute
path
nor
a
relative
path
from
the
app
directory.
B
You
would
be
very
good
at
like
doing
that,
because
you
know
if
it's
absolute,
then
you
have
to
know
what
the
layers
you
know
is
the
layers
they're
really
going
to
be
slash
layers.
I
don't
think
we
want
to
encourage
people
to
hard
code
that
into
their
build
pack,
because
it
could
be
different
and
then
they
have
another
build
pack
id
and
the
layer.
You
know
name
in
there
too.
It
seems
a
little
brittle,
but
then,
if
it's
you
know
relative
to
the
app
directory,
it's
no
good
way
to
get
there
relatively.
F
B
B
It's
like,
if
you
wanted
to
set,
if
you
wanted
to
say
this
process
type.
You
know
that
may
be
in
path
right,
maybe
contribute
in
a
layer,
spin
directory
that
may
end
up
in
path.
But
if
you
wanted
to
say
that
it's
working
directory
when
it
runs,
is
also
inside
of
that
layer,
because
it's
some
pre-packaged
software
that
the
build
pack
installed
that
has
to
run
in
the
context
of
other
things
that
build
pack
installed
into
a
layer
right,
do
we
need
a
way
of?
Maybe
the
answer
is
we
can
find
on
this?
B
F
G
It's
worth
a
conversation
about
a
very
similar
topic
recently
happened
between,
like
myself,
forest
natalie
and
emily,
and
the
cnb
slack.
I
can
fish
out
the
link
to
that
somewhere.
G
Where
really
the
conclusion
of
the
conversation
was
that
to
your
point
steven,
maybe
it's
not
great
to
assume
that
layers
will
be
in
slash
layers,
etc,
but
it
seems
like
right
now,
there's
a
gap
in
the
spec,
where
it
sort
of
strongly
implies
that
that
will
be
the
case,
but
it
doesn't
actually
require
those
things
to
be
the
same,
and
the
same
goes
for
a
slash
workspace,
which
is,
I
think,
opening
up
a
whole
other
can
of
worms.
Obviously,
but
it
does
kind
of
touch
on
the
topic
of
this
rfc.
D
I
was
going
to
add
the
question
you
know
about
workspace
and
cnb
after
and
how
that
ties
into
working
dur.
As
far
as
the
oci
spec
is
concerned,
I
believe
there
was
a
conversation.
I
don't
know
if
there
was
an
rfc
to
update
the
spec
to
make
those
match
in
this
particular
case.
Is
there
any
impact
to
that
say?
For
instance,
if
you
only
have
one
process,
it's
the
default
one,
it
has
a
very
different
working
directory
or
sorry
directory
set.
F
I
believe
it
should
still
apply
to
the
directory
structure
on
the
oci
image.
I
think
that
maybe
I've
misunderstood
your
your
question,
but
I
think
that
there's
a
link
between
the
structure
that
we,
the
layer
structure,
that
we
use
when
we're
building
and
the
final
running
structure
like
those
two
working
directories,
are
identical
because
the
exporter
writes
it
out
such
that
the
launcher
makes
that
the
working
directory
that
was
used
during
build
be
the
same
working
directory
that
was
used
during
this
used
during
launch.
D
I
guess
I'm
hoping
the
answer
is
no
right,
but
if
you
had
one
default
process
type-
and
let's
say
in
this
particular
example,
you
know
directory
is
set
to
either
a
relative
path
or
a
different
absolute
path.
And
you
have
cnb
after
equal,
some
value
with
the
oci
config
workdir
working
directory,
be
the
cnb
after
value
or
the
value
of
the
individual
process.
Type.
B
I
actually
want
to
take
back
my
my
feedback
from
a
minute
ago
about
the
absolute
pants.
I
think,
because
a
build
pack
has
access
to
that
layer
path
during
build
time.
It
knows
that
it
won't
change,
it
could
just
derive
those
absolute
pads
accurately,
regardless
of
what
the
directories
are
and
put
them
in
there.
So
I
don't,
I
don't
think
that's
as
big
of
a
concern
as
what
I
brought
up.
The
relative
path
is
just
for
convenience,
so
you
don't
have
to
embed
the
app
directory
that
the
build
pack
knows
about
into.
B
F
The
very
specific
use
case
that
made
me
write:
this
rfc
was
currently
in
piketto.
We
are
adding
directives
to
allow
like
this,
isn't
node
or
node.js
buildpack,
relying
directives
for
users
to
specify
a
project
path
that
is
not
necessarily
their
working
directory.
F
So
say
you
had
static
files,
but
you
also
had
a
node
app
and
you
wanted
to
push
to
into
that
node
app.
Currently,
what
we
have
to
do
is
we
have
to
change
directory
and
then
run
the
the
sort
of
same
nodes,
start
or
npm
start
that
we
would
run,
but
that
feel
that
felt
a
little
janky.
So
I
thought
I
would
come
all
the
way
up
here
and
see
if
this
was
something
that
was
interesting
to
y'all.
H
For
what
it's
worth,
actually,
we
have
that
same
problem
in
the
g
speed
build
packs
with
one
of
our
with
using
the
functions
framework,
so
I'm
clued
into
that,
but
that
this
could
be
very
helpful.
E
Yeah,
it
would
be
great
just
either
in
the
rfc
or
just
on
the
pr
itself
to
just
probably
get
links
to
those
use
cases
just
because
I
think
that
just
helps
with
context.
C
C
Oh,
I
don't
want
to
speak
for
emily
because
she's
not
here,
but
I
did.
I
was
recently
reading
a
conversation
in
slack
or
she
mentioned
just
a
concern
around
setting
the
working
directory
that
might
be
interesting
to
to
bring
up
like
build
packs
that
are
working
together.
C
B
So,
there's
a
difference
between
changing
the
working
directory
at
build
time
versus
changing
the
working
directory
for
the
runtime
process
is
that
I
could
see
that
happening
in
both
contexts,
but
it
seems
like
it's
a
really
big
concern
like
in
the
build
time
context
where
the
environment
can
change.
Do
you
know
if
she
was
concerned
about
one
or
either
of
both
of
those
I'm
just
curious?
I.
B
And
for
us
just
to
make
sure
this
is
just
about
run
time
right
for
what
you're
proposing
just
about
where
the
process
time
starts.
I
think
I
think
that
feedback
is
interesting,
though,
because
if
you
set
a
launch
time
environment
variable
that
assumed
the
path
you
know
and
applied
to
a
different
process
that
then
changed
the
path
you
know
it
kind
of
implies.
The
bill
pack
author
shouldn't
be
setting
run
time,
run
time
environment
variables
with
relative
paths.
I
don't
know
how
common
that
is.
B
G
B
Exactly
so,
I
don't
think
it's
as
big
of
an
issue
as
the
build
time
issue,
because
it
you
know
things
would
have
to
be
just
right
in
order
for
that
to
work
in
the
first
place,.
F
That's
a
good
question.
I
hadn't
thought
about
that.
I
I
don't
think
it
should
so
maybe
I
should
specify
that
it
shouldn't.
I
re
really
what
I
would
want
this
for
is.
You
know
like
just
I
need
to
before
I
execute
this
command.
I
need
to
be
in
this
directory,
so
I
don't
know
why
it
would
affect
that,
but
I
should
call
that
out.
B
B
B
B
Then,
let's
move
to
our
last
thing
on
the
agenda:
rfc
contributor
graph
from.
B
A
Okay,
thank
you
yeah.
So
the
idea
is
basically
to
put
a
contributor
graph
right.
I
think
github
has
these
but
they're
on
a
per
repo
basis.
The
idea
is
something
a
little
bit
more
ambitious
right.
The
idea
is
just
you.
A
You
want
to
see
the
activity
within
the
bill
cross
product
bill,
packs
project
in
some
public
way,
and
you
know
I'm
thinking
the
big
use
cases
for
people
who
aren't
quite
invested
yet
right
like
then,
maybe
they're
not
attending
the
working
groups-
they're
not
on
the
slack
channel
yet
right,
but
you
still
want
to
a
sense,
maybe
like
a
quick
overview
but
just
sort
of
what's
happening,
and
you
know
I
I
did
put
some
ideas
here.
A
A
I
did
take
the
time
to
make
a
nice
little
diagram
here,
just
to
facilitate
my
thoughts
a
little
bit,
but
that
doesn't
mean
I'm
adamant
about
anything
in
here.
I
just
really
wanted
conversations
around
sort
of
what
I
was
thinking
right
here.
We
have
the
different
repos
split
it
out,
and
then
we
have
data
points
indicating
an
rfc
or
an
issue
and
and
sort
of
the
time
it
takes
to
get
to
each
one.
A
And
you
know
if
your
contributor,
it
might
be
nice
to
see
your
your
little
face
up
here
and
your
company
became
represented.
But
that's
in
a
nutshell.
I
thought
it'd
be
good
in
the
community
section,
but
curious
other
thoughts.
C
A
Yeah
yeah,
I
can't
you
know
like
I
said
I
I
think
I
want
to
say
that
there
are
other
people
invested
in
bill
pax
as
a
whole,
or
you
know
any
oss
project
as
a
whole,
but
it's
really
hard
to
get
a
sense
of
that
stuff
without
being
in
touch
right
and
being
in
touch,
like,
I
said,
means
being
in
a
working
group
and
being
in
the
slack
and
things
like
that.
Right
so
does
that
explain
or
so.
D
Specific,
so
if
we're
adding
this
to
the
community
page
right,
is
it
more
or
less
to
depict
the
ongoing
efforts
and
contributions
by
the
contributors
so
that
people
want
to
contribute?
Is
that
more?
You
know
one
of
the
goals,
or
is
it
maybe
in
the
same
vein,
like
a
project
health
type
thing
that
we're
trying
to
relay.
A
That's
a
good
question.
I
mean
I
don't
really
think
it
has
to
have
a
single
function.
Right
like
I
was
thinking
it
could
be
public
because
you
know
other
people
might
be
invested
in
it
right,
like
other
people,
might
get
benefit
out
of
it
right.
Other
people
might
maybe
be
encouraged
to
contribute.
D
D
There's
the
dev
stats
that
the
cncf
project
provides,
which
is
a
whole
bunch
of
data
right
all
public
data
that
you
can
see
about
the
project
with
a
lot
of
data
points
and
again
how
you
consume
it
is,
is
very
different
and
then
I
think
I've
I
haven't
seen
it,
but
I
know
it
exists
that
there's
like
a
pocato
dashboard
that
talks
about
or
tries
to
portray
the
the
project,
health
and
stuff
like
that-
and
I
guess
maybe
that's
where,
where
my
questions
are
coming
from
right-
is
whether
or
not
we're
trying
to
do
something
very
similar,
whether
we
should
be
leveraging
some
tools
that
we
already
have,
and
you
know
other
thoughts
like
that.
A
Okay:
okay,
when
you're
talking
about
project
health
and
things
like
that,
I'm
gonna
lean
on
y'all
to
to
let
me
know
if
that's
a
priority
or
whatnot,
but
I'm
really
not
thinking
too
far
down
that
lane.
Yet
right
like
this
is
really
just
about
insights
right.
This
is
really
just
about
inside
at
the
first
level
right.
A
C
I
I
have
some
thoughts
about
the
fact
that
we
see
like
the
the
contributor's
name
and
the
company's
name,
I'm
wondering
since
we're
an
open
source
and
we're
trying
to
get
like
new,
contributed
new
contributors
from
any
company
or
like
individuals
that
would
like
to
contribute
to
our
project.
I'm
wondering
what
a
new
contributor
I
mean,
whether
they'll
see
it
and
what
their
thoughts
will
be.
I
mean
because
probably
most
of
these
thoughts
will
be
related
to
the
same
people
that
are
around.
C
Like
I
mean
from
vmware
from
heroku
from
I
mean
the
other
people
that
are
here
like
in
this
working
group,
and
I'm
wondering
if,
if
a
new
contributor
shows
up
whether
this
will
encourage
them
to
start
contributing
or
they'll
just
say,
okay,
there
are
too
many
people
out
there,
I'll
just
I'll
take
a
step
back.
A
I
think
it's
a
good
point.
I'm
also
worried
about
that.
That's
why
I
brought
this
to
working
group.
I
really
am
more
interested
in
how
everybody
else
feels
right,
like
I
think,
showing
people's
affiliations
like
that
could
be
a
drawback.
It
could
deter
people,
it
could
encourage
people-
I
I
don't
know
enough
yet
to
be
on
either
side
of
the
fence
there.
So
that's
why
I
put
it
as
a
drawback.
Maybe
we
want
to
consider
maybe
we
can
leave
this
information
out.
E
I
think
this
is
pretty
cool
thanks
for
putting
this
together.
I
probably
share
some
of
the
questions.
I
think
that
javier
had
originally
just
like
what
is
the
motivation,
because
I
think
there's
a
lot
of
information
here
so
just
trying
to
figure
out,
I
guess
the
use
cases
or
problems
your
use
cases
like
kind
of
the
the
problems
you're
trying
to
solve
exactly
because
I
think
yeah
you're
pulling
from
a
lot
of
kind
of
different
data
points.
E
So
I
think
you've
said,
like
you,
don't
want
to
solve
health
for
instance,
and
so
it
sounds
like
you're
trying
to
show.
I
feel
like
just
computer
activity
to
I
guess
like.
Are
you
trying
to
inspire
and
get
people
more
involved
in
the
project
because
they
see
how
active
the
project
is,
and
maybe
also
the
flip
side
of
that
is
like
feeling
a
moment
of
pride,
because
if
you
are
a
contributor,
you
get
to
see
your
name
or
something
somewhere
kind
of
on
here,
but
maybe
I'm
extrapolating.
A
No,
it's
a
good,
it's
a
good
thoughts.
Listen!
I
I
won't
say
I
know
enough
about
contributor
motivations
to
make
that
point.
Like
you
know,
I
really
just
want
to
say
it's
really
about
insight
into
the
project,
and
you
know
that's
where
it's
at,
like
you
know,
health
and
health
and
inside
doesn't
have
to
be
health
right
away
right,
like
it's
really
just
about
what
are
the
different
parties
so
that
people
can
have
a
like
discussion
around
it.
Something
like
that,
like
maybe
it
turns
into
a
health
conversation.
A
Maybe
it
doesn't.
Maybe
it's
just.
How
does
this
compare
to
last
month's
xyz,
but
like
it's,
it's
really
hard
to
even
know
how
to
start
this
conversation
without
without
like
a
uniform
understanding
of
the
project.
G
One
thing
that
I
really
like
about
this
mock-up
is
that
it
adds
some
sort
of
like
narrative,
I
guess,
to
understanding
like
how
technology
comes
into
existence
inside
of
this
project,
like
perhaps
this
is
like
so
obvious
to
everyone
in
this
working
group,
because
you
know
rfcs
are
sort
of
the
name
of
the
game,
but
seeing
like
okay
on
the
left,
like
an
idea,
starts
as
an
rfc
and
then
it
stays
that
way
for
a
while
and
then
becomes
an
issue.
G
D
D
How
do
you
link
the
progress
of
an
idea
all
the
way
to
being
shipped
right
like
because
it
goes
through
multiple
issues?
It's
not
just
one
issue
right,
like
one
rfc
could
end
up
with
so
many
different
issues
and
and
so
forth.
So
there's
one
thing,
and
then
I
guess
the
other
part
maybe
anthony
going
to
your
piece
and
patrick
yours
as
well.
D
I
do
wonder
if
this
is
like
the
right
way
to
project
the
data
right
like
because
again
we
already
have
dev
stats
right
and,
like
I
said,
there's
a
ton
of
information.
So
if
we're
really
trying
to
answer
the
you
know
being
public
about
the
information-
and
even
you
know
how
to
consume
that
information,
I
think
devstat
does
really
really
well
for
the
you
know
that
aspect
of
it.