►
From YouTube: App Runtime Platform Working Group [Nov 3, 2021]
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
And
thank
you
for
coming
to
our
first
working
group
meeting.
It's
finally
happening,
so
it's
good
to
see
all
of
you
here,
I'm
going
to
attempt
to
do
this
meeting
in
30
minutes
and
not
take
up
a
full
hour
of
your
time.
A
A
Okay,
so
the
agenda
today
we'll
discuss
some
working
agreement
proposals
we'll
look
at
some
github
projects
and
if
anyone
else
has
something
that
they
want
to
talk
about,
please
add
it
here
and
that
way
we
can
schedule
time
for
it.
So
without
further
ado,
we'll
get
started
with
some
working
agreement.
Proposals
right,
so
we're
bootstrapping.
This
whole
new
way
of
working
together
from
the
ground
up,
and
so
a
lot
of
these
proposals
are
kind
of
like
okay.
A
If
you
look
at
it
and
eventually
get
to
the
markdown
version
of
the
pr
it
looks
like
this,
I'm
just
going
to
review
it
really
fast
and
then
I'll
ask
for
comments.
So
the
idea
is
anyone
can
submit,
or
anyone
in
this
working
group
an
approver
or
lead
can
submit
this.
A
When
you
make
one,
please
announce
it
on
the
slack
channel,
so
other
people
know
when
you
make
one.
Please
present
it
at
the
next
working
group
form
like
I
am
doing
right
now.
A
Anyone
can
comment
and
voting.
This
is
the
most
important
part.
So
all
of
you
who
are
part
of
the
working
group
approvers
for
leads
can
cast
a
vote.
My
current
method
of
voting
suggestion
is
just
to
reply
with
a
plus
one
or
minus
one.
A
You'll
have
one
week
to
vote
so
like
I'm
presenting
it
to
the
forum
today,
we'll
give
everyone
a
week
to
vote
so
that
way,
if
you
couldn't
come
to
the
forum,
you
have
time
to
watch
the
recording
understand.
What's
going
on
vote
et
cetera,
I'm
gonna,
do
it
as
a
simple
majority,
and
if
we
have
a
tie
breaker
the
tech
lead
will
break
the
tie
and
then
we'll
merge
the
pr
or
close
it.
So
that's
the
basic
idea.
A
We
want
to
talk
about
how
we're
working
together
we're
making
these
working
agreements
we'll
present
them
at
these
forums.
You
all
get
a
plus
one
minus
one
vote.
One
thing
I
didn't
see
at
the
beginning
is
we
have
a
lot
of
us.
So
if
you
want
to
add
a
comment,
please,
like
use
the
little
raisy
hand
thing.
So
if
you
have
a
comment,
I
would
love
to
hear
it
now
or
also
like.
I
said
this
will
be
open
for
a
week
for
discussion,
so
you
can
also
add
it
later
on
the
pr
itself.
A
Yay
everyone's
down
with
simple
majority
or
I'm
taking
silence
as
yes
great,
I
see
a
thumbs
up
from
greg.
Thank
you
greg,
okay,
so
that's
the
most
basic
level
one,
and
so
that's
how
I'm
hoping
that
these
will
go
in
the
future.
So
then
you
know
I
was
writing
these
up
for
our
working
group.
I
was
like.
Oh,
how
do
I
want
us
to
work?
A
I
wrote
one
about
doing
moving
to
a
pr,
only
system
which
I'll
talk
more
about
in
a
second
and
how
reviewers
should
work,
and
then
the
toc
came
to
me
and
was
like
hey.
Maybe
those
shouldn't
be
working
group
level
working
agreements-
maybe
some
of
these
should
be
done
at
the
foundation
level
and
they
wanted
it
in
a
google
doc.
So
I
closed
those
prs
and
instead
there's
this
doc
that
we
discussed
in
the
toc
meeting
yesterday.
A
If
you
go
here
and
you
open
this
little
sidebar
you'll
see
it's
actually
four
different
ones,
that
they've
kind
of
grouped
together
that
jeff
and
reuben,
and
I
have
been
working
on
and
I'm
just
going
to
kind
of
breeze
through
these,
because
I
think
some
of
them
are
a
little
more
just
like
maybe
minutia
comment
on
your
own
time.
I
hope
there's
nothing
too
scandalous
about
what
we
want
our
names
of
our
github
teams
and
access
to
be.
A
The
next
the
bigger
one,
though,
is
moving
to
a
pr
only
workflow.
This
has
been
floating
around
a
lot.
I
think
this
will
be
make
things
a
lot
better
for
the
community
to
know
what's
going
on,
so
it's
not
just
all
vmware
has
right
access
and
no
one
else
does
so
that's
changing
soon
and
I'm
excited
for
it.
A
A
Maybe
I
should
mention
the
way
that
the
since
they're
in
the
doc,
the
toc,
has
had
a
lot
of
opinions,
and
so
they
wanted
to
work
in
a
dock
first
before
we
move
it
to
github
and
it's
a
little
bit
harder
to
have
conversations
in
github,
but
eventually
the
toc
will
vote
on
these,
not
us,
but
of
course
they
want
your
opinions
and
thoughts
on
them.
A
A
A
So
those
are
for
working
group.
No
wait!
Wait
for
it
working
agreement.
I
don't
really
love
that
it's
a
working
agreement
for
a
working
group
working
gets
confusing.
So
if
you
have
a
better
name,
please,
you
know
feel
free
to
share
at
some
point
any
thoughts
on
these.
You
can
provide
now
provide
on
the
doc,
but
I'll
leave
just
a
little
empty
space.
Now
for
anyone
to
add
a
comment.
B
A
A
A
And
if
you
eventually
click
through
the
pr
and
get
to
the
like
the
page
itself,
it
looks
like
this
so
now
that
we
have
this
idea
that
we're
moving
to
the
pr
workflows
right-
it's
not
officially
approved
yet,
but
we're
headed
there
soon.
It's
like
okay,
now
that
we're
making
prs.
What
does
that
mean
for
reviewers
right?
Someone
has
to
be
merging
them
and
what
is
that
process?
And
so
that's
what
this
working
agreement
proposal
is
about.
A
So
I
try
to
write
this
as
like.
What
is
the
problem
statement
that
we're
trying
to
solve
from
all
these
different
perspectives?
Like
as
a
pr
author
right,
I
want
my
pr
reviews
reviewed
in
a
timely
manner.
As
an
issue
author,
I
want
to
be
able
to
fix
my
bug
in
a
timely
manner
as
an
approver.
That's
you
all!
I
want
to
know
which
pr's
and
issues
that
I'm
supposed
to
be
like,
which
ones
am
I
responsible
for
and
as
a
tech
lead.
A
A
A
A
So
there
are
swimlanes
they're,
probably
a
little
fuzzy
for
you
that
are
called
inbox,
reviewer
assigned
review
in
progress
done
and
then
triage
complete
needs
fix.
So
my
thought
is,
you
know,
issues
and
pr's
get
added
here.
This
is
the
issue
workflow.
So
I'll
just
talk
through
that.
First,
the
issue
gets
added
here
right
now,
it's
not
automatic,
maybe
in
the
future,
it'll
be
automatic.
But
right
now
I
manually
add
prover
and
I
move
it
to
this
swimlane.
A
Then
you
as
the
approver
you'll
work
with
the
author
to
understand
the
issue,
go
back
and
forth
with
them.
I'm
leaving
it
up
to
you
to
decide
on.
You
know
how
you
do
that
on
what
schedule.
I
don't
want
to
micromanage
you.
I
trust
that
if
I
assign
you,
you
will
eventually
get
to
your
own
work
and
the
idea
is
that
as
soon
as
you
leave
one
comment
on
that
issue:
it'll
move
into
this
swimlane,
so
I
really
just
want
to
know.
Hey.
A
Has
anyone
replied
to
this
person
because
we're
not
always
been
great
about
that
in
the
past,
then
with
an
issue
either
you
helped
them
fix
their
bug.
You
they
figured
it
out
or
you
helped
them
figure
it
out.
We
move
it
to
done,
or
maybe
you
say,
oh
you
found
like
a
real
bug
that
we
should
fix
in
the
future,
and
so
that
would
be.
This
needs
fix,
swim
bling.
So
as
an
approver,
I
do
not
expect
you
to
be
the
one
to
fix
the
bug
if
you
want
to.
A
B
Does
this
result
in
an
ever-increasing
list
of
things
that
need
to
be
fixed?
How
do
things
if
someone
points
something
out
it
it's
wrong,
but
no
one's
going
to
fix
it.
Do
we
keep
track
of
those
forever?
Do
we
just
let
them
pile
up,
because
we
know
that
they're
wrong?
Maybe
that's
fine,
maybe
that's!
Okay,.
A
A
You
know
like
when
I'm
working
in
different
open
source
areas
and
I'm
like
searching
for
my
problem-
it's
like
oh
by
the
way
I
had
this
problem
too,
like
I
love
being
the
sex
person
to
apply
and
be
like
me
too.
Please
fix
this
so
like
I
definitely
think,
there's
a
benefit
of
keeping
them
open.
But
yes,
I
do
see
that
as
something
we
will
probably
have
to
tackle
in
the
future,
but
maybe
we're
not
there
yet.
A
C
I
guess
on
the
topic
of
that
assignment,
is
there
an
algorithm
for
determining
how
they're
assigned
or
is
it
just
brown
robin
or
is
there
going
to
be
some
some
heuristic
to
determine
who
gets
what
ticket.
A
I
plan
on
starting
at
round
robin,
but
I
also
understand
that
some
of
you
only
work
in
very
specific
repos
and
not
every
repo
in
an
area.
So
it's
going
to
be
and
yeah
we'll
figure
it
out.
A
The
reviewer
works
with
the
pr
author
to
make
sure
you
know
the
code
is
well
written.
Eventually
they
merge
it
in
I'm
asking
as
soon
as
you
reply
once
to
move
it
to
the
swim
lane
so
that
we
know
hey,
we've
responded
and
the
reviewer
merges
the
code,
and
then
it
automatically
goes
to
done
and
gives
us
that
self
a
sense
of
accomplishment.
A
I'm
not
setting
any
sli
or
slos
or
whatever
those
acronyms
are,
but
I
do
ask
that
you
look
at
your
issues
at
least
once
a
week
just
generally
pull
through
them
and
make
sure
you're
replying
and
being
a
good
community
member
and
you
know
greg
if
I
assign
you
as
a
reviewer
to
something
that
you
have
no
context
on
or
anyone
feel
free
to
push
back
and
say.
No,
I
don't
think
so,
but
you
can
also
use
it
as
a
chance
to
learn
something.
A
And
maybe
you're
pairing
with
someone?
Okay.
So
when
github,
like
you
can't
let's
say
greg,
you
submit
a
pr.
You
can't
actually
review
your
own
pr
in
github
reviewers.
You
need
to
have
someone
else
review
it
for
you.
So
let's
say
you're
pairing
with
anthony
anthony
could
review
your
pr
great,
repairing,
that's
a
form
of
review
or
maybe
you're
pairing
with
anthony,
but
like
he
didn't
get
submerging
it
yet
and
I
assigned
ben
you
know
anthony's
free
to
go
in
there
and
be
like
actually,
I
was
working
on
this.
A
And
then
my
last
comment
was:
is
there
sometimes
issues
that
we
write
that
are
like
hey?
We
intend
to
support
http
2
or
we
intend
to
do
cdc
with
tos
and
they're,
not
necessarily
like
one
issue
for
one
person
to
review
and
I'm
gonna
call
those
proposals
and
they
will
not
be
a
part
of
these
github
projects.
A
A
A
A
So
here
we
have
an
inbox.
I
have
not
started
assigning
reviewers
yet
since
we
had
not
had
this
conversation
yet
jeff
assigned
himself
to
some
thanks
jeff
some
reviews
are
in
progress.
A
lot
of
things
have
been
done
since
I
set
up
this
board
and
one
made
it
all
the
way
to
needs
fix.
A
B
I
haven't
looked
at
the
issues
recently.
I
imagine
giving
stale
bot
a
three
week
head
start
would
be
a
helpful
process.
I
guess
I
imagine
there
are
a
lot
of
things
that
are
stale,
that
we
that
should
get
cleaned
up.
Maybe
that's
the
way
to
phrase
it.
I
haven't
actually
looked
recently,
but
I'm
guessing.
A
If,
as
a
reviewer,
if
you
are
assigned
something
and
you're
like
okay,
this
was
open
two
years
ago,
you
are
free
to
respond
hey.
This
is
old.
You
know,
if
you're
still
having
an
issue,
let
me
know,
or
else
I'm
gonna
close
it.
So
I'm,
I
guess,
feel
free
to
do
the
you
know,
manual,
stale
bot
and
I
have
been
cleaning
them
up
somewhat
as
I've.
You
know
been
doing
this
organizing
they're,
actually
not
that
bad
they're
not
near
as
bad
as
you
would
think.
B
A
A
Hopefully,
the
next
meetings
will
not
be
so
much
of
me
talking
at
you,
but
I
appreciate
you
listening.
While
we
get
this
all
bootstrapped
and
while
we
all
get
on
the
same
page.