►
From YouTube: Velero Community Meeting - October 18, 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
All
right,
hello,
everyone,
my
name
is
William
vasilif
and
as
the
official
community
meeting
for
Valero
today's
October
ancient
and
that's
the
US
slash
Europe
friendly
time
zone
meeting,
we
were
just
discussing
the
change
of
the
that
same
meeting
the
time
frame,
so
I'm
gonna
share
this
one.
A
So
the
update
for
me
is
like
tomorrow,
I'm
gonna,
send
a
new
invite
and
we're
just
discussing
with
Scott
that
there
will
be
two
meetings.
One
will
be
called
Beijing
friendly
time
zone
and
it
will
be
bind
to
the
Beijing
time
zone.
So
there
will
be
no
change
due
to
changing
the
daytime
savings
and
the
other
one
will
be
tied
to
the
East
Coast
right
right
code.
It's
it's
East.
B
A
Correct
yeah
and
they
will
start
the
next
one,
which
will
be
the
Beijing
friendly
one.
We
will
be
the
next
one
and
in
two
weeks
time
will
be
the
U.S
east
coast
and
European
one
friendly
with
the
new
time
frame
right.
B
A
B
And
then,
and
then
the
other
change
is
instead
of
having
a
separate
time,
for
you
know:
first
Tuesday,
second
Wednesday,
whatever
we're
just
gonna
be
alternating
weeks,
so
there's
no
longer
going
to
be
the
notion
of
First
Tuesday
of
the
month
is
a
certain
time.
It's
just
every
two
weeks,
starting
next
Wednesday
is
Beijing
times
and
meeting,
and
every
two
weeks
you
know
basically
from
today
is.
A
A
Correct
than
to
be
because
I
struggle
with
which
one
is
which
one
I'm
gonna
name
them
like
Beijing,
friendly
and
U.S,
European
friendly
sellers,
yeah
I
mean
it's
it's
a
bit
more
human
readable
than
yep.
So
with
that
two
things,
the
Oktoberfest
I
I
sent
that
message
to
the
Valero
death
Channel.
Nobody
responded
me
so
to
me
so
I
told
us
like
a
silent
agreement.
A
What
I'm
aiming
with
the
Oktoberfest
thing
is
to
get
more
visibility
on
the
project.
It's
not
that
I'm
expecting
like
super
duper
quality
PRS
from
random
community
members,
but
to
be
like
a
to
get
some
awareness
about
the
project
and
the
pure
active.
A
So
if
something
comes
in
and
to
be
marked
as
the
Oktoberfest
PR
I'll
I'll
make
sure
to
inform
you
and
to
get
the
load
as
much
as
possible
from
you
and
to
just
to
get
the
technical
stuff
out
end
of
the
month,
I'll
remove
that
slack
from
the
repository
and
we'll
get
to
so
without
you
have
added
some
some
stuff.
B
Yeah,
so
the
first
ones
here
are
repeat
from
last
week
just
because
those
are
still
PR's
out
there
needing
a
review
and
that's
the
item.
Action,
plug-in
design
and
there's
been
some
review.
There's
been
some
comments.
We
just
needed
to
sort
of
get
a
finalized
and
I
know.
I
talked
through
this
a
bit
two
weeks
ago,
so
we
probably
wanted
to
go
through
it
in
detail
again.
I'm
just
kind
of.
B
And
this
is
more
reminder
for
the
other
maintainers,
because
we
really
just
need
the
consensus
based
on
the,
because
there
were
some
comments
that
were
you
know,
going
back
and
forth.
This
is
not
going
to
be
in
the
110
scope,
but
I
want
it
approved
soon
so
base
My,
Hope
Is
that
when
we
Branch
for
110
with
the
rc1
or
c0
the
first
release
candidate.
B
That's
the
point
when
I
want
to
be
able
to
start
working
on
this,
so
we
can
kind
of
front
load
the
development
cycle
for
111
to
get
this
in
there
early,
because
you
know
that'll
allow
us
to
to
do
kind
of
the
data
mover
work
on
top
of
that
and
the
other
PR
is
listed
after
that
are
kind
of
follow-on,
basically
dependent
on
that.
B
So
the
async
action
plugin
is
the
overall
design
the
for
the
feature
that
includes
references
to
the
API
changes
needed
for
plugins,
and
these
are
more
isolated,
specific
plug-in,
API
design,
changes,
backup,
item
action,
restore
item,
action
and
volume
snapshotter
that
are
based
on
the
ideas
from
that
PR
there's
one
one
other
addition
in
the
restore
item
action.
It
also
includes
another
approved
previously
approved
design-
that's
referenced
in
that
design.
Basically,
we
had
another
feature
that
was
approved
some
time
ago,
but
it
was
on
hold
until
we
had
plug-in
version.
B
So
the
restore
item
action
design
includes
both
of
those.
So
those
are
draft
PRS.
Now,
because,
until
the
item
action
plug-in
design
is
approved,
the
API
designs
can't
be
approved
because
they
are
dependent
on
each
other,
but
there
there
should
be
basically
ready
to
go
unless
there
are
changes
in
that
first
PR.
B
So
and
that's
all
from
previous
meetings,
the
new
one
this
week
is
the
the
draft
implementation
of
the
backup
out
of
action
V2.
This
is
an
actual
implementation.
Pr,
that's
implementing
those
new
API
changes
that
were
proposed
again,
it's
a
draft
because
the
design
isn't
approved
yet
so
this
can't,
you
know,
merge
yet,
but
this
is
kind
of
you
know.
I
just
wanted
to
get
that
out
there.
So
people
can
start
to
see.
B
You
know,
based
on
that
design,
here's
what
we're
talking
about
changing
and
here's
what
it
would
look
like
again,
there's
some
build
changes
here
in
the
docker
file
to
also
handle
the
fact
that
we
now
have
the
Proto
protobuf
code
and
plug
in
specific
directories.
So
there's
a
little
bit
of
infrastructure
change
around
that
as
well,
but
basically
this
is
implementing
the
design
ideas
from
that
design,
PR,
which
adds
a
couple
of
new
functions
to
the
API
and
again
based
on
the
design
of
the
plugin
versioning
in
general.
B
We
have
a
notion
of
an
adapter
here,
so
that
pre,
so
we
move,
for
example,
backup
processing
to
use
the
V2
plugin.
So
when
the
backup
controller
says
give
me
the
plugins,
it
gets
V2
plug-ins,
but
for
those
we
don't
want
to
break
Legacy
plugins.
So
we
have
this.
Implementation
includes
an
adapter.
So
basically,
what
happens
is
that
if
a
plug-in
registers,
a
V1
plugin,
which
is
basically
any
existing,
plug-in
image,
will
still
work
or
even
a
new
plug-in
image
that
still
wants
to
use
the
old
API.
B
The
adapter
will
provide
a
default
implementation
for
those
two
two
new
functions.
You
know
either
a
no
off
as
appropriate
or
maybe
returns
an
error
saying
hey
this
isn't
supported,
but
in
any
case
the
adapter
will
return
to
Valero
a
plug-in
that
meets
the
new
API
design,
even
though
the
plugin
has
written
as
for
the
old
API,
and
this
is
to
preserve
backup
backwards
compatibility
with
existing
plugins.
B
Now.
None
of
the
changes
we're
proposing
should
break
all
plugins
at
this
point,
but
the
the
plug-in
versioning
design
kind
of
included
that
as
an
option
to
say.
If
you
know,
if
a
new
version
of
Valero,
you
know
we
come
out
and
we
say
we
need
this
new
thing
in
plugins
and
it
no
longer
makes
sense
to
have
an
old
plugin
without
this
thing
and
then
we'll
just
that
would
be
a
breaking
plug-in
change
that
would
not
create
an
adapter
and
we'd
have
to
announce
ahead
of
time.
B
A
Right
and
from
my
information
where
I
can
find
the
designs
for
this
stuff,
so
I
can
yeah.
B
If
you
go
back
to
my
PRS,
so
I
had
links
yeah,
so
so
the
first
design,
that's
kind
of
the
feature
level
design
talking
about
what
changes
we
need.
It
includes
plug-in
API
changes.
These
are
the
detailed
plug-in
API
design
changes
where
I'm
actually
identifying.
What
are
the
new
functions,
we're
adding
to
the
interface?
What
are
we
changing
in
terms
of
inputs
and
outputs.
A
B
Order
here
is
that
first
async
plugin
needs
to
be
approved
first,
because
that's
the
that's
the
feature
level
design.
Once
that's
approved
these
plug-in
version
design
changes
can
be
reviewed
and
approved,
because
those
basically
are
the
plug-in
API
specific
details
around
to
implement
what
we
proposed
above
and
then
once
those
are
approved,
then
the
implementations
that
themselves
can
be
put
in
place
and
so
those
those
design
docs
can
be
approved.
At
any
point,
you
know
those
don't
really
affect
they're,
not
really
part
of
a
release.
B
In
that
sense,
the
in
the
feature
PR,
we
were
just
looking
at
some
of
the
code
of
just
now.
That's
a
feature:
that's
not
being
delivered
in
110.
So
that's
a
PR!
That's
not
going
to
be
ready
to
merge
until
at
the
earliest.
We
did
make
the
release
110
Branch,
because
then
we
go
against
main,
because
none
of
that
code
is
slated
for
110.,
so
we're
not
going
to
merge
a
domain
until
after
we've
created
the
110
release,
the
release,
110
branch.
A
No,
then
I
have
my
next
one.
Europe
2023
for
papers
is
open
until
November
18th,
so
anyone
planning
to
apply
for
cfps
there
or
shall
we
try
again
to
submit
the
the
panel
discussion
about
the
future,
the
future
backup?
What
do
you
think
foreign
happy
to
to
apply
again
with
you
Scott,
if
you
want,
especially
if
we
have
the
new
data
more
stuff
in
place.
A
We
have
plenty
of
time
we
have
a
month
so
yeah
we
can
figure
out
I'm,
just
like
a
heads
up
for
everyone
to
think
about
it,
but
I
think
we
should.
We
should
definitely
apply
again
with
the
with
the
panel
this
question,
because
it's
I
think
it's
super
relevant
for
the
whole
thing
and
also
we
can
apply
with
few
few
others.
If
someone
wants
to
to
talk
about
it,
I'm
super
happy
to
help
anyone
with
this
one
with
the
logistics
or
presentation
or
whatever
and,
of
course
joining
me
on
stage.
A
If,
if
you
want
me
so
keep
in
mind,
think
about
it,
we
can
discuss
it
again
and
predict
you
have
the
Bolero
111
I'm
planning.
C
Yeah,
so
there
was
some
discussion
on
slack
like
how
do
we
go
about
the
kind
of
release,
discussions,
the
scope
and
all?
How
do
we
kind
of
make
it
more
kind
of
generic
and
I
saw
that
you
had
a
page
for
1.10
like
to
collect
requirements?
C
I
am
hoping
that
we
can
start
for
similar
wiki
page
sorry,
the
discussion
piece
for
1.11.
Thank
you
for
two
weeks
time,
people
to
kind
of
post
the
requests
and
also
the
Daniel.
Let's
get
a
label
or
1.11
so
internally,
I
am
going
through
issues
and
trying
to
tag
it
one
one,
and
then
we
can
kind
of
see
in
the
next
two
to
three
weeks.
C
If
we
can
collect
at
least
there
is
a
sense
of
community
to
go
through
in
one
one
list
and
second
topic
and
one
one
like
I,
want
to
understand
the
data
mover.
So
where
does
the
written
word
timeline
fits
in
based
on
that
we
can
decide
the
scope
of
one
one
with
data
mover
without
return
over
depending
on
timeline.
So
my
vision
is
like
we
should
do
three
releases
in
a
year.
C
I
have
not
kind
of
every
alternate
one,
but
at
least
three
to
four
months:
I
release
with
kind
of
a
meaningful
chunk
and
next
meaningful
chunk
is
data
mover
from
my
perspective
would
be
very
and
good
enhancement,
but
then,
if
one
one
time
frame
it
doesn't
fit
in,
then
we
can
look
at
some
alternative
options,
so
collection
of
requirement
and
then
once
the
requirements
are
there,
how
do
we
finalize
the
scope
of
one
timeline.
B
B
Our
concern
about
111
at
this
point
is
that,
like
this
async
plug-in
design,
that
we're
talking
about
here
was
something
that
was
originally
in
scope
for
110
that
we
were
hoping
to
get
in
there.
You
know
various
reasons.
It
slipped
design
didn't
get
approved
in
time.
B
Some
of
the
prerequisites
weren't
done,
that's
fine,
but
because
it's
something
that
we
were
hoping
to
have
in
110,
you
know
ideal
for
us
would
actually
be
a
slightly
shorter
release
for
111
to
make
sure
we
get
these
things
in
and
at
a
minimum,
even
if
it
meant
data
mover
was
in
112,
because
we
can
build
on
this
to
get
some
things
in
place
and
then
and
then
build
on
that
in
a
later
release
was
Data
mover,
and
so
that
would
get
allow
us
to
kind
of
be
more
incremental
in
our
approach.
B
Whereas,
if
we're
waiting
in
a
long
time
to
get
this
stuff
in
Plus
data
mover,
that's
going
to
be
a
little
bit
more
difficult
to
kind
of
work
into
our
schedule,
just
because
we're
trying
to
plan
our
next
release
with
one
you
know,
111
and
hopefully
get
at
that
111.
You
know
out
there
as
soon
as
it
would
make
sense
with
these
at
a
minimum.
These
things
that
we're
talking
about
designing
right
now.
C
Yeah
and
I
I
just
got
it
I'm
all
flexible.
We
don't
just
want
to
see
that
between
one
one
eleven,
what
all
we
can
do
that.
So
that's
where
the
discussion
will
explode
on
those
few
things
we
and
then
we
also
need
to
know
data
about
timeline.
So
I
don't
know
exactly.
Where
is
the
return
of
our
timeline?
If
it's
kind
of
one
month
plus
minus
case,
then
we
can
decide
either
way.
C
C
We
will
get
a
kind
of
idea
of
where
what
thing
Falls
and
then
so
if
each
number
is
released
latest,
we
should
release
something
in
February
March
like
four
months.
If
we
add,
if
it's
really
something
you
know
more
than
something
in
February
March
time
frame,
I
am
thinking.
We
should
release
every
three
to
four
months.
B
C
And
then
every
alternate
months,
if
they
find
a
major
version,
it's
tough
for
them
to
kind
of
certify
and
then
use
the
solution.
So
giving
a
kind
of
Cadence
of
three
to
four
month
cycle
makes
sense
in
my
so
that
it
kind
of
optimizes
that
option,
as
well
as
our
value
proposition.
E
So
pretty
this
is
one
sales
and
just
the
year,
estimating
a
possible
111
in
the
in
the
first
quarter.
Next
year,
like
March.
C
C
Yeah
yeah,
something
like
that,
would
be
more
of
a
and
then
before
cubecon.
If
we
have
a
release
with
the
kind
of
have
significant
things
in
that
would
be
great
and
that's
where
the
data
more
conversation
comes.
If,
if
it's
there,
then
it's
great,
if
it's
kind
of
sleeping,
we
will
kind
of
see
what
we
can
do.
C
E
B
Also
something
that
we
have
our
own
internal
data
mover
that
we
eventually
want
to
move
to
the
Upstream
data
mover
is
using
so
I'm
just
saying
that's
a
point
even
less
than
the
full
data
mover.
That's
still
useful
for
us.
If
there's
the
issues
with
data
mover
fitting
in
and
all
that,
obviously
you
know
if
we
can
fit
in
that
same
three
to
four
month
time
frame
to
get
all
the
data
mover
done
as
well.
B
That's
even
better,
but
I
just
wanted
to
point
out
that
that
first
step
towards
that
is
a
useful
point
to
release
on.
Even
if
we
don't
have
the
full
data
mover,
but
obviously
you
know
the
more
the
better
you
know
if
it's.
B
To
that
Cadence
that
we're
talking
about
yeah,
what
what
I
wouldn't
want
to
see
is
delaying
that
release
more
than
the
three
to
four
months.
You
know
to
get
data
mover
in
if
it
wasn't
going
to
fit.
B
C
C
We
are
kind
of
a
good
Community,
a
lot
of
kind
of
contributions,
so
we
should
start
kind
of
thinking
that
Cadence
I
don't
want
to
kind
of
break
a
Cadence
just
to
fit
in
things,
then
we'll
change
the
scope
or
reduce
the
scope,
depending
rather
than
attending
the
changing
the
Cadence
itself.
There
can
be
exception
where
two
weeks
plus
minus
delay
to
include
a
significant
capability,
but
not
beyond
that
kind
of
thing,
not
three.
Four
months
delay
for
sure.
E
C
Yeah,
so
so
it
should
be
done
in
the
end
of
normal.
That's
my
understanding.
The
copia
thing.
Okay,.
D
So
are
you
in
so
when
so
qualify
new
kubernetes
releases
right,
so
they
are
there.
Also
we
get
three
releases
so
like
I'm,
assuming
we
can
qualify
these
in,
but
fixed
or
minor
releases
right.
It
doesn't
need
to
be.
C
Here,
yeah
I
think
the
Virgin
qualification,
if
until
it
doesn't
need
a
major
change,
we
can
qualify
into
the
Mind
releases
like
you,
because
we
can't
sync
exactly
with
the
kubernetes
releases
are
releases.
So
so,
if
something
comes
it's
all
Backward
Compatible
you
qualify,
you
have
to
fix
minor
things,
do
that,
but
if
there
is
a
significant
change
or
you
want
to
use
kind
of
a
some
major
functionality
of
kubernetes,
where
there
is
a
more
change,
then
it
decides
case
to
case
basis.
We
can
pick
it
up.
C
B
One
ten
one,
for
example,
you
know
we
wouldn't
want
to
add
something
that
modifies
the
crds
generally
yeah.
If
we
can
avoid
that,
but
mostly
they're
bug
fixes
and
historically
but
and
I
suppose,
a
small
feature
that
didn't
change
crds
could
possibly
also
be
included
there,
but.
C
C
Yeah
just
run
kind
of
a
pipeline
test
or
something
if
All
Passes
without
like
everything
is
compatible.
It
works.
There
are
changes
which
makes
significant
change
will
trick
the
Backward
Compatible
compatibility
for
this
Miner
version
releases.
Then
we
should
not
do
that.
Then,
with
erosion
is
the
place.
So
again,
that's
what
I
said
case
to
case
basis.
We
can
kind
of
see
it
where
it
puts
in.
C
So
I
see
that
action
item
like
will
create
that
only
the
page
for
discussion
and
then
we'll
try
to
kind
of
start
doing
things.
What
Daniel
is
doing
is
creating
a
Wiki
page
for
roadmap
for
one
one,
the
similar
to
1.10
as
well
as
he
has
created
the
tag
label
already
for
tagging
it,
and
then
on
the
page.
We
can
notify
Community
to
kind
of
start
putting
their
GitHub
issues,
which
they
want
in
one
one
and
I
would
prefer
like
people
who
put
their
issues.
C
Also
knows
that
kind
of
either
someone
from
Community
picks
up
or
like.
If
you
can
start
a
defining
owner,
who
would
kind
of
start
wanted
to
contribute
to
that,
so
that
it
will
make
easy
decision
when
we
try
to
scope
it?
Whether
we
can
do
that
item
is
good,
but
there
should
be
some
takers
of
those
items
also
so,
which
will
will
discuss
on
the
same
thread
and
then
see
how
we
can
move.
A
You're
fading
out
a
little
bit.
So
just
repeat,
you
want
to
make
sure
that
our
message
towards
the
community
is
like,
if
you
have
something
in
mind
about
new
features,
to
be
like
the
same
person
to
be
like
engaging
with
the
actual
development
of
this
feature,
is
that
what
you're,
saying
or
I
I
didn't.
C
Get
it
or
once
it
is,
they
can
post
it,
but
if
they
are
not
able
to
do
someone,
if
doesn't
pick,
then
that
goes
away
from
the
plate.
So
so,
if
you're
proposing
something
either
you
become
a
contributor
or
or
someone
should
pick
it
up
like
good
idea.
If
nobody
is
kind
of
picking
up,
then
we're
not
kind
of
forcing
someone
to
just
take
it
up,
because
you.
A
To
that,
because
otherwise
it's
like
halfway
there,
it's
not
it's,
not
the
complete
thing
yeah,
because
it
can
be
priority
for
them,
but
definitely
not
priority.
A
The
team
so
yeah
yep,
yeah
yeah
sure
I'll,
send
I'll,
create
that
right
after
or
equal
I
have
a
topic
about
the
technique,
slash
architect
role
as
we
discussed
it.
I
think
last
time.
Dave
want
to
step
out
from
that
that
role,
I
didn't
manage
to
find
anything
concrete
on
this
one,
how
we
should
select
the
next
one,
so
I
think
we
should
either
get
up
get
up
governance
updated
with
that
election
thing
or
we
just
can
have
like
a
issue
voting
about
the
actual.
D
A
I
know
Daniel
is
normally
taking
the
technical
leads,
so
I
suppose
he
wants
to
be
the
architect
overall
architect.
Is
there
any
discussion
going
on
with
the
about
this
topic
on
the
other
community
meeting,
which
is.
B
The
Beijing
plan
I
have
not
seen
that
come
up
in
the
meeting.
I
was
just
going
to
mention
one
thing
in
terms
of
government,
I
I
would
say
if
it's
not
in
the
governing
stock.
I
think.
The
first
thing
we
need
to
do
is
update
the
governor's
stock
to
handle
this,
because
because
I
don't
think
we
can
say
well
we're
going
to
vote
on
it
because
the
revenue
stock
doesn't
allow
us
to
vote
on
it.
You
know
the
whole.
A
B
Here
of
being
an
open
Community
is
that
the
governor
stock
kind
of
tells
us
how
we
do
these
things
and,
for
example,
the
governor
stock
talks
about
how
you
add
maintainers,
and
we
followed
that
and
that
works.
That's
worked
pretty
well
for
us.
I
think
the
governance
stock
needs
to
address
Tech,
lead
and
architect
as
well,
and
the
other
thing
I
was
going
to
say
about
that
is
that
I
know
in
the
past.
Those
those
are
two
different
roles
and
we
always
had
two
different
maintainers.
D
B
Example,
most
recently
Dave
was
the
architect,
and
this
is
you
know,
rewind
back
when
Dave
was
still
at
VMware
and
he
was
active.
The
day
was
the
architect
and
Nolan
I
believe
was
the
tech
lead
and
before
that,
those
they
had
swapped,
and
you
know
so
and
then
now
I
guess
Daniel
is
Tech
lead,
but
anyway.
B
Those
are
different
roles
with
kind
of
different
focuses.
It
probably
makes
I
I,
don't
know
if
the
governor
stock
ought
to
specifically
say
that
you
know
the
preferences
that
those
are
different
people.
You
know
for
the
roles,
but
I
just
know
that
in
the
past,
that's
how
it
has
been
done.
A
Sure,
okay,
okay,.
B
I
think
you're
having
a
stock
probably
should
also
address
the
question
of
because,
again,
you
know
in
the
past,
these
rules
have
always
been
VMware
employees,
but
also
in
the
past,
the
maintainers,
with
you
know,
usually
one
or
two
exceptions
were
also
all
being
where
employees
I
think
the
governance
stock
update
should
be
explicit
about
this.
You
know.
B
You
know
if,
if
full
maintainers,
don't
necessarily
need
to
be
getting
more
employees
again
speaking
as
a
non-vmware
employee,
it
might
make
sense
that
the
same
would
be
true
for
tech
leads
and
Architects,
but
either
way,
I
think
that
needs
to
go
through
that
process
to
get
the
governor
stock,
updated,
I.
A
Sure,
okay,
so
I'll
address
that
to
our
Hospital
office
and
then
I'll
come
back.
Okay.
B
B
A
Correct:
okay,
that's
on
my
plate.
I
I'll
try
to
provide
update
on
this
one
until
next
week.
Okay,
another
one!
Do
we
need
like
a
time
slot,
within
the
maintenance
team
to
get
together
and
to
do
like
a
PR
three
editing
like
a
open,
PR
charging
and
to
get
over
the
new
PRS
and
discuss
them
good
thing
to
do.
Do
you
think
that
there
is
a
need
for
this
one?
A
What
I'm
aiming
with
this
one
I
may
need
to
to
to
to
to
make
the
the
time
to
respond
to
time,
to
review
and
time
to
engage
on
PRS
much
lower,
so
we
can
practically
nurture
the
new
contributors
or
anyone
who
is
contributing
and
spending
their
time
with
our
project
to
get
more
relevant
back.
A
E
The
idea
of
experimenting
with
things
to
improve
those
two
outcomes
of
the
time
to
review
and
and
triage
and
get
feedback,
certainly
I
think
we
need
to
think
about
the
things
we
can
do
there
and
that
those
are
two
I
mean.
That's
a
that's
a
viable
option
open
to
hearing
additional
thoughts
there
as
well,
but
yeah
I,
agree.
A
My
initial
idea
is
to
set
like
a
a
week
weekly
like
a
30
minutes
not
more
to
scroll
over
the
PRS
to
make
sure
they're
all
properly
labeled
or
properly
assigned,
and
we
have
provided
some
feedback
on
them
either
needs
fixing
need.
We
need
more
time,
whatever
I
mean
to
show
the
the
contributor
that
you're
engaged
with
their
their
time
and
they
don't
feel
like
lost
and
and
not
appreciated.
That's
that
that's
it.
B
Yeah
and
meeting
would
also
help.
I
mean
I,
think
that
we
just
said
it
for
new
contributors.
You
know,
and
their
PR
is
not
getting
lost,
but
I
think
even
for
existing
PRS.
You
know
right
now.
One
of
the
things
that
we've
been
doing
is
bringing
things
up
in
this
meeting,
saying
oh
by
the
way,
I
have
these
PRS
that
are
waiting
review.
B
You
know
that
can
also
be
brought
up
in
this
meeting
as
well,
even
for
even
for
you
know,
maintainers
and
others,
some
that
are
awaiting
review
to
kind
of
bring
up
the
priority
or
whatever,
but.
B
E
Right
which
I
I
think
if,
if
the
first
idea
out
of
the
bat
is
a
live
meeting,
it
would
I
think
it
would
be
a
smart
thing
to
alongside
that,
proposing
async
way
of
doing
it
as
well.
So
everyone
in
all
the
time
zones
has
an
opportunity.
A
Which
leads
to
another
one
just
to
to
open
up
a
little
bit
more
I
think
we
discussed
that
the
need
of
additional
Channel
I
hate
additional
channels,
but
like
the
maintainers
kind
of
Channel,
which
this
kind
of
stuff
can
be
discussed
and
like
async
asyncly
discussed
without
actually
making
all
the
depth
Channel
flooded
with
with
this
stuff.
What
do
you
think.
E
A
E
A
B
I
would
also
say
that
the
slack
channel
is
not
exactly
a
high
volume
Channel
most
of
the
time
yeah
and
in
fact
not
okay,
two
things,
one,
it's
not
exactly
a
high
volume,
Channel
and
I
would
say
of
the
volume
on
that
channel.
At
least
half
of
that
already
is
posting
a
PR
asking
for
reviews.
A
Okay,
so
subscribe
that
with
the
channel,
so
the
other
thing
is
we
should
either
we
can
either
if
we
want
to
do
it,
live
on
Zoom,
for
example,
we
can
use
that
time
same
same
time,
frame
that
we
have
for
the
community
meeting
and
we
can
do
it
like
in
at
the
end,
if
we
have
time,
for
example,
but
that
brings
the
possibility
not
to
have
time-
and
you
miss
that
thing
and
but
but
that
will
allow
us
not
to
have
just
additional
meeting.
B
Would
say
if
we
are
going
to
have
a
live
meeting
nearly
after
the
Community,
meaning
probably
makes
more
sense
than
trying
to
find
another
time
that
works
for
people.
B
B
You
know
we
would
have
to
you
know.
As
well
said.
You
know
there
is
the
possibility
running
over
and
we'd
have
to
probably
kind
of
conceptually
think
of
it
as
a
separate
meeting,
because
there
are
times
when
it
might
go
over
the
you
know
the
hour,
because
sometimes
this
meeting
lasts
the
full
amount.
B
So
if
we're
going
to
say
we're
going
to
do
that
after
the
meeting,
then
it
is
going
to
turn
something
that
might
be.
You
know
up
to
one
hour
into
something
that
might
be
closer
to
an
hour
and
a
half,
and
that
you
know
could
be
a
concern
for
some
people.
E
If,
if
we
could
pick
one
day
a
week
to
list
out
the
PRS
or
whatever
requests
need
maintainer
attention,
people
could
get
into
the
habit
of
getting
into
slack
and
and
having
and
and
maybe
it's
twice
a
week
time
zone
what
or
whatever
it
doesn't
need
to
be
live.
That's
the
beauty
of
having
it
in
slack
and
in
fact,
a
lot
of
Open
Source
communities
refuse
to
have
live
meetings
like
this,
and
only
do
it
over
a
staggered
time.
Over
slack,
it.
B
Might
make
sense
to
do
it
to
declare
Monday
to
be
that
day
over
slack
that
way,
if
there
is
a
PR
that
yeah,
you
know,
slack
discussion
indicates
hey.
We
really
do
need
to
talk,
live
about
it
added
as
a
discussion
topic
the
next
week,
but
that
would
be
the
exception
rather
than
the
you
know
the
norm
for
those
PRS.
E
A
Yeah
and
how
we
can
organize
this
one,
it's
like
reminder:
it's
like
a
folks,
just
take
a
look
at
the
PRS
yeah.
A
A
E
A
E
A
Yeah
yeah,
but
I
I,
just
don't
want
to
make
it
like
super
overwhelming
for
for
everyone
and
to
spend
like
an
hour
more
on
on
Zoom
costs.
That's
not
my
intention
at
all.
Yes,
but
I
I'm,
just
trying
to
figure
out
a
proper
way
to
build
up
the
habit
of
anyone
reviewing
the
pr.
A
So
that's
it
because
we
I've
seen
that
in
in
my
other
projects
in
the
past,
and
even
now,
not
for
later,
but
other
projects
that
people
are
just
forgetting
to
take
a
look
at
the
new
PRS
and
if,
if
we
don't
have
like
a
proper
code
owners
set
and
they
don't
get
assigned
automatically
to
specific
zones
on
the
on
the
code-
that
just
don't
take
a
look
at
it,
they're
too
busy
with
other
stuff.
A
So
so,
let's
let's
say:
what's
that
like
Monday
at
some
point,
I'll
send
out
a
message
or
I'll
set
a
reminder
in
the
channel.
Hey.
Please
take
a
look
at
this
one
and
then
we
can
all
kind
of
do
command
under
the
same
message
for
for
for
PRS
or
something
and
then,
if,
if
that
doesn't
work,
then
we
can
discuss
it
on
the
Tuesday
community
meeting
depends
on
the
time
frame.
A
And
that
will
be
only
in
the
dev
Channel
I'll
send
that
I'll
send
out,
like
a
Google
group
message
that
we're
gonna
start
this
kind
of
effort
on
Mondays.
So
if
someone
wants
to
have
like
a
special
attention
on
PR
and
wants
to
bring
it
just
to
to
join
the
level
of
death
and
and
post
that
as
a
message,
so
the
maintenance
can
take
a
look
at
this
time.
A
A
Right,
I,
don't
have
anything
else
for
today,
except
all
this,
so
anyone
else
wants
to
do
sharp
anything
thoughts.
They
don't
travel
to.
You
he's
gonna
travel
to
keep
connects
next
week.
A
B
No
I
don't
think
anyone
on
the
floor,
ODP
said
I'm
sure,
there's
others
from
they'll
be
there,
but
none
of
us
are
going
to
be
there.
B
For
most
of
us,
it
was
dependent
on
getting
those
talks
approved
and
they
didn't
get
approved
so.
C
A
And
for
me
it's
also
a
budgeting
thing
and
now
it's
my
wife
had
a
car
accident
two
weeks
ago
and
that's
definitely
changed
all
my
plans
see
go
anywhere
so
I
should
be
sticking
around,
cannot
leave
the
continent
for
now,
so
I'm
definitely
skipping
a
coupon
for
now.