►
From YouTube: Working Group: 2020-09-01
Description
* Redesigned Website
* Node.js rearchitecture
* Versioning builder.toml
A
B
C
C
Hey:
hey
how's,
it
going
pretty
good.
How
are
you
doing
today
pretty
good.
D
A
C
Yeah
ben
and
I
are
emceeing
a
breakout
track
starting
tomorrow,
so.
C
A
A
A
B
Is
ben
going
to
be
here?
If
not,
we
could
probably
get
started.
D
B
E
All
right,
so,
let's
pull
this
out.
E
All
right
so
outstanding,
rfcs.
E
E
Okay,
so
this
first
one.
E
E
And
basically,
this
is
aimed
at
just
formalizing
and
and
surfacing
guidelines
for
contributors
so
that
we
can
host
in
the
community
people
there
we
just
figured.
You
know
it
would
make
things
easier,
shortened,
feedback
loops
if
people
knew
exactly
where
and
how
to
get
started
with
contributing
not
to
a
huge
change,
and
I
figured
it
would
be
appropriate
to
add
that
as
an
rfc
there's,
we
I've
included
an
issue
template
and
a
put
request
template
that
are
certainly
open
to
review.
E
I
try
to
encompass
all
the
things
that
folks
might
care
about
from
at
least
from
or
from
my
experience,
but
if
anything
is
missing,
certainly
add
to
that
and
down
here
I
had
some
questions
that
I
wasn't
sure
about,
namely
the
legal
restrictions
were
bound
by
if
any,
in
terms
of
like
licenses.
E
What
happens
to
the
intellectual
property
of
contributors
when
they,
you
know,
contribute
to
the
organization.
Do
we
know
what
I
guess
we
want
to
put
forward
with
us
concerned.
D
B
B
On
the
ip
side,
I
think
forest
maybe
called
this
out
in
the
original,
like
community
charter
or
something
like
that.
All
licensing
should
be
apache
too
in
any
of
the
paketo
stuff,
community
and
official
thing,
and
then
ip
wise.
I
think
the
moment
anything
gets
moved
over
the
community.
Rfc
definitely
has
this
now
they
think
about
it.
But
ip,
like
just
kind
of
belongs
to
cff
cool.
E
I'll:
rework
that
part,
then,
speaking
of
the
cff,
do
we
need
to
add
any
new
infrastructure
on
clas
and
so
forth,
or
are
we
just
gonna
leverage,
the
same
infrastructure
that
already
exists
and
do
we
need
to
keep
them
on
files
somewhere?
Is
that
our
responsibility
yeah?
I
just
wasn't
sure
I
didn't
want
to
put
anything.
B
Forward
about
that,
I
think
that
that's
another
one,
that
the
cff
is
like
completely
on
top
of
and
taken
care
of,
perhaps
a
separate
thing
that
we
should
follow
up
on.
Is
I
don't
like
the
current
cla
format?
I
think
every
one
of
you
here
run
into
these
issues
and
I
want
to
switch
to
dca,
so
maybe
that's
a
separate
thread
that
we
could
start
with
the
cff
on
that
emily.
Do
you
know
much
about
this
around?
C
E
Okay,
I
guess
we
can
look
into
that
as
well,
and
yet
this
so
that
I
noticed
that
the
there
is
a
code
of
conduct
that
the
pax
org
uses,
that
the
cncf
endorses,
supposedly
by
one
that
who
exactly
or
how
we
would
enforce
that.
If
we
did
implement
a
code
of
conduct,
would
we
need
to
assign
a
specific
person
say
the
steering
committee
or
maintainers
of
sub
teams
that
roll
and
make
it
part
of
the
governance
charter
or.
D
What
might
make
sense
is
just
that
maintainers
handle
it
per
sub
team
like
for
their
contributors
and
then
beyond
that
steering
committee
for
maintainers,
just
like
a
standard
like
just
like
escalation
chain,
if
it
would
ever
come
to
that,
but.
E
Sure
yeah,
I
just
wanted
to
go
okay.
That
sounds
reasonable
to
me,
so
y'all
can
check
that
out
if
you'd
like,
I
will
continue
to
add
to
it
back
to.
E
D
D
C
D
C
One
I
put
this
up
a
while
ago,
already
sort
of
implemented
it
in
the
java,
build
packs
and
gotten
some
good
feedback
about
it.
I
think
we're
waiting
for
steven
to
review.
C
C
So
the
way
that
would
work
in
organizations
is
someone
would
like
ask
an
operator
who
would
then
go
ensure
that
the
dependency
is
being
installed,
is
approved
and
downloaded
and
then
uploaded
somewhere
within
the
whitelist
or
within
the
local
network.
And
then
you
can
use
this
format
to
tell
any
build
pack
where
to
look
for
a
given
dependency.
B
Got
it,
and
you
said
you
said
that
all
the
java
build
packs
do
this
right
now.
C
B
Cool,
maybe
after
this
is
approved,
we
could
get
issues
set
up
for
the
other
stuff.
Try
to
adhere
to
this
as
well.
E
So
the
redesigned
website
demo.
E
B
Up
to
you,
you
wanna,
you
wanna,
do
it.
I.
A
E
B
E
So,
first
off
I
guess
so
we
originally
had
surfaced
the
builder
information
here
on
the
front
page,
but
we
just
opted
against
that.
So
now,
what
we
have
is
we
simply.
We
changed
some
of
the
copy
to.
E
I
guess
to
be
more
relevant
or
more
informative
to
newcomers
to
the
site.
We
also
made
these
clickable.
So
these
take
you
to
the
docs
directly
and
think
we're
still
waiting
on
the
java
docs
to
complete
a
link
right
now.
It
just
links
to
the
build
pack,
but
that's
an
easy
fix
once
looks
in
and
I
think
we
we
tried
to
be
more
intentional.
E
I
guess
we
try
to
simplify
the
language
and
and
be
more
intentional,
so
that
people
and
to
be
more
explicit
to
that
folks
know
exactly
what
we're
trying
to
say
and,
as
you
can
see
here,
there's
a
nice,
it's
a
gif
of
what
it
looks
like
to
build
and
run
a
build
pack
or
an
app
with
a
buildback.
E
And
we
reworked,
I
think
this-
this
bottom
area
was
get
started
on
something
else,
and
now
this
links
directly
to
the
docs,
so
folks
can
go
straight
to
where
they
need
to
be.
We
read,
we
rewrote
all
of
these
docs
as
well.
E
Which
took
a
bit
of
doing,
but
there
should
be
a
lot
more
informative
for
folks
trying
to
get
started
with
buildbacks,
including
you
know,
information
about
the
environment,
variables
and
so
forth.
Is
there
anything
I'm
missing.
E
D
E
E
E
We
replaced
the
learn
page
that
was
here
on
the
home
page.
I
think
that's.
What
now
is
getting
started.
C
B
I
talked
to
him
just
last
week
about
it.
He
liked
he
seemed
to
like
the
format
of
all
of
this
a
lot.
So
he
wanted,
like,
I
think,
separate
pages
for
what's
it
called
the
java
native
image
and
also
a
separate
page
for
the
javadocs.
B
So
I
think
after,
like
perhaps
some
of
the
spring
spring
one
stuff
calms
down
a
little
bit
ben
or
some
of
the
spring
folks
might
help
out
with
us,
and
I
think
there
was
one
other
docs
change
ben
wanted
to
make,
which
was
to
document
like
the
c
like
the
cnb
binding
or
the
kubernetes
like
service
binding
spec.
I
think
the
java
build
packs
are
the
only
ones
that
utilize
that
so
ben.
I
think
just
wanted
to
enhance
that
water
build
packs
page
effectively.
B
So
I
think,
as
soon
as
we
get
that
we're
like
these
are
all
in
a
branch
right
now
as
soon
as
we
get
that
we're
probably
good
to
just
merge
changes
in
and
stuff
like
that.
So
probably,
like
you
know
two
weeks,
something
like
that.
E
Is
there
anything
else
that
folks,
who
aren't
as
familiar
with
this
site
can
see
offhand
that
jumps
out
that
could
be
corrected
or
improves.
D
E
D
B
Small
things,
but
do
you
actually
like
file
if
folks
notice
stuff,
like
github
issues
in
the
in
the
website,
repo,
because
that
would
really
help
just
with
like
tracking
tiny
changes
like
this.
B
D
Yeah,
like
transform,
transform
your
application
source
code
to
image
that
can
run
so
it
probably
should
be
images
right.
B
At
that
point,
just
like
push
up
to
the
redesigned
branch,
we're
all
contributors
to
this
thing.
I
push
up
to
it
every
day.
A
C
D
And
marty
now
that
I've
seen
the
stacks
page,
I'm
gonna
go
ahead
and
accept
your
story.
That's
why
I
want
to
look
at
it.
E
Next
on
the
list
is
the
node.js
re-architecture
update,
so
we've
I
think,
completed
the
three
bill
packs,
which
book
and
their
respective
order
groupings
in
the
node.js,
buildback
or
metabuildpark.
E
So
that's
nodestart,
yarnstart
and
npm
start
which
each
set
they
said,
the
command
the
start
command
for
the
build
pack
based
on
you
know
the
flow
from
the
up
two
of
these
yarn
start
and
npm
start
utilize
teeny,
which
allows
for
better
process
management-
and,
I
guess
most
or
more
importantly,
graceful
shutdown
of
the
app
in
like
its
context
or
in
a
darker
s,
context.
E
A
We're
transferring
ownership
of
the
builders
from
the
core
depths
team
to
the
feature
range
team
and
as
part
of
that,
we
are
going
to
start
checking
in
a
fi,
a
builder.toml
file
and
tagging
the
repo
for
that.
For
that
for
that
file,
so
yeah
we
were
kind
of
just
like
talking
about
it's
not
I
mean
that's
the
main,
that's
the
main
thing
there.
A
You
can
look
at
the
issue
for
like
a
little
bit
more
detail,
but-
and
another
thing
we're
gonna
do-
is
we're
also
going
to
split
out
each
builder
into
its
own
repo,
so
we
can
version
them
independently,
so
there'll
be
a
builder
full
of
builder,
whatever
like
media,
but
the
builder
small
or
whatever
they're
called
so
yeah
just
be
on
lookout
for
that.
But
the
the
final
result
will
be
the
same,
which
is
just
they'll,
be
in
the
same
place
in
gcr
and
docker
hub.
So.
C
A
A
For
the
builder
yeah,
we're
gonna
use
github
actions
for
at
least
most
of
it.
We
still
haven't
decided
the
best
way
to
pull
for
updating
components.
So
we
decided
to
leave
that
up
too.
Whoever
does
the
story,
because
it's
interchangeable
right
so
whatever
as
long
as
something
sends
a
dispatch
event
to
the
git
of
actions
to
create
a
pull
request.
Whenever
something
gets
updated,
then
it
can
be
kind
of
whatever
so
we're
gonna
experience.
A
So
we're
still
not
totally
sure
what
the
implementation
is
gonna
be,
but
we're
kind
of
leaving
that
as
an
implementation
detail
for
now,
if
that,
if
that
makes
sense,.
C
One
thing
the
riff
team
did
with
their
builder
repo,
and
this
is
a
bit
indirect-
I'm
not
sure
that
I'm
recommending
it
as
the
way
to
automate
this.
But
just
so
you
know
it's
an
option
because
they
had
basically
a
go
mod
in
the
repo
that
had
dependencies
to
all
the
different,
build
packs
and
then
sort
of
use
that
and
the
fact
that
you
can
integrate
that
with
the
pandabot,
which
will
then
make
a
pr
every
time.
A
C
A
Yeah
another
I
mean
another
option
we
have
is
like
we
do
this
for
tandoors.
We
just
have
a
concourse
pipeline
that
just
sends
dispatches,
that's
it,
so
it
just
watches
and
sends
this
matches.
So
that's
nothing.
We
do
we're
also
thinking
about
implementing
a
cron,
a
cron
job
on
github
actions,
that'll
just
like
every
minute
or
so,
or
something
we'll
try
to
do
something
to
figure
out.
If
there's,
if
there's
new
updates,
but
unfortunately
it's
going
to
no
matter
what
it's
going
to
be
a
little
hacky,
I
think
so.