►
From YouTube: Velero Community Meeting - Jan 25, 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
Hello,
everyone
and
welcome
to
the
valero
community
meeting
today
is
january
25th
here
on
the
east
coast
of
the
us,
and
it
is
it's
tuesday
january
25th
2022
there
we
go
that's
the
date.
This
is
the
valero
community
meeting.
Slash
open
discussion
welcome
everyone.
I
am
super
tired,
thank
you
all
for
being
here
with
me
today.
If
you
haven't
added
yourself
to
the
attendee
list,
please
do
so
and
we'll
dig
into
some
status
updates,
and
then
we
have
some
discussion
topics
as
well.
So
first
up
we
got
daniel.
B
Yeah,
since
we've
cut
the
brand
for
release
one
night
this
week,
mainly
I'm
reviewing
prs,
so
I
started
merging
the
change
to
main
branch,
especially
the
one
from
youtube
I
discussed
with.
We
we're
gonna,
go
through
it
together
before
she
leaves
so
hang
on
a
little
bit
and
you'll
see
some
comments
to
appeal.
B
And
yeah,
I'm
also
working
with
eleanor
to
go
through
some
issue
backups
and
to
put
them
into
the
one
nine
roadmap.
That's
also
a
working
progress.
A
We'll
talk
about
the
roadmap
a
bit
in
the
discussion
topic
today,
perfect.
C
Yeah,
as
we
know,
I've
moved
over
to
cast
and
veeam,
so
I
went
ahead
and
updated
the
maintainers
I
put
in
a
pr
with
the
new
affiliation
in
there.
I
think
we
need
to
have
a
majority
vote
of
the
existing
maintainer
companies
to
approve
that
so
scott
and
genting
are
on
there
and
daniel
is
listed.
So
scott's
already
said
yes,
so
yeah
just
two
more
and
we
can
go
ahead
and
kick
that
in.
I
think
so.
I've
got
the
governance
right.
A
Yeah
yeah,
it's
it's
just.
We
need
a
majority
vote
from
the
companies.
So
yes,
one
just
one
vote
from
vmware
here
and
you're
good
to
go.
Actually,
yes,
because
right
now
we
have
three
companies
listed.
So
yes,
one
vote
from
vmware
or
one
vote
from
susa
and
we're
good.
C
Yeah
and
also
there's
I-
I
can't
set
labels
at
the
moment
because
I'm
not
a
I
got,
kicked
out
of
the
org,
so
I
don't
think
this
requires
a
change
log
if
someone
would
set
that
as
a
kick
it
in.
That
would
be
good
or
I
can
write
a
change.
One.
A
A
Awesome
awesome
all
right.
Any
questions,
comments
for
tape.
E
A
All
right,
thank
you,
discussion
topics,
eleanor
you
get
a
bunch
today.
D
All
me,
I'm
not
sure
if
I'm
doing
them
in
the
right
order,
but
that
happened
to
be
the
order
I
thought
of
them
in
the
first
one.
If
you
could
click
on
that
link,
please
bridgette
was
so
helpful
and
really
helped
me
go.
We
went
through
all
oh.
That
should
be
a
call
out
too
sorry.
Just
remember:
docs
should
be
a
fourth
discussion
topic
so
bridge
and
I
went
through
all
the
docs
which
issues
which
were
very
helpful
and
I
did
come
across
this
one.
D
So
this
is
we've
already
documented
the
compatibility
matrix.
Thank
you,
jonas,
and
basically
we
can
see
exactly
what
what
versions
of
kubernetes
we
can
use
with
valero,
probably
I
believe
testing
is
done
on
most,
if
not
all,
but
many,
let's
say
many,
but
the
real
question
is
from
a
community
from
us
from
a
maintainer
standpoint.
If
we
find
a
bug
in
some
version,
do
we
fix
it?
So
the
issue
is
to
document
that,
but
I
don't
think
we
as
a
community
have
decided
that
so
shall
we
chat
about
it.
D
A
D
B
Yeah,
I
I
thought
we
someone
used
to
propose.
We
support
n
minus
one
all
right,
but
yeah,
I'm
open.
D
I'm
certainly
open
as
well.
I
mean
I
rather,
I
would
prefer
to
have
it
more
conservative,
because
I
think
I
would
want
to
evaluate
for
further
back
versions
like
obviously,
if
it's
a
critical
cve,
I
think
we
would
support
it.
We
would
fix
it
if
it's
anything
less
than
a
critical
cve.
I'd
really
want
to
see
how
many
users
are
affected,
because
if
we
fix
something
that's
older,
we
can't
do
as
much
future
work
on
a
new
version,
so
I
would
love
to
have
it
be
more
flexible.
C
A
If
we
go
back,
we
have
n
minus
one
release,
so
that
would
be
1.7,
which
was
released
in
september
october.
D
A
Yeah,
because
that
would
give
all
kubernetes
versions
from
1.12
up
to
latest.
That's
that's
a
long
span
as
well.
F
So
can
you
hear
me
of
course
yep?
Yes,
yeah,
I'm
not
sure
my
looks
like
my
head
has
said.
I
have
some
problem
yeah.
I
remember
we
have
discussed.
We
support
the
community
version
with
n
minus
one
back
to
october
last
year.
D
Right
so,
if
you're
you're
on
board
with
that
as
well,
then
yeah
okay,
so
maybe
what
I'll
do
is
I'll
document
I'll
in
the
issue
right
now,
I'm
going
to
put
it
in
as
n
minus
one,
because
maybe
we've
discussed
it
and
just
did
not
manage
to
do
this
so
we'll
document
it
as
n
minus
one
and
we'll
I'll
put
it
on
the
valero
channel.
So
anyone
can
say
something
for
the
next
week
and
if
it's
approved
then
I'll
make
it
as
a
documentation
like
well
put
it
forward.
D
Okay,
let
me
make
a
comment.
A
You
could
send
that
out
to
the
distribution
list
as
well.
Just
so
people
can
chime
in
if
they
have
any
issues
on
that
github
issue,
so
they
could
chime
in
there.
So
we
have
that
document.
D
D
May
I
even
I
didn't
update
the
hack
md,
may
I
say
segway
into
documentation.
We
want
to
improve
our
documentation
yeah,
we
want
to
prove
our
documentation.
So
do
you
mind
opening
up
the
project,
the
documentation
project,
and
actually,
I
guess
I
should
put
this
pack
to
md
anyway,
so
apologies.
D
I
will
do
that
at
the
same
time
yeah.
So,
if
you're
itching
to
just
help
out
valero
a
little
bit,
we've
got
an
even
easier
way
to
do
that.
Please
ignore
the
ice
box
bits
for
now.
They
have
for
one
reason
or
another:
they
need
more
work.
The
middle,
the
second
column,
backload
engineering,
help
needed
if
you're
an
engineer
and
want
to
give
just
a
little
bit
of
help.
Please
look
at
those.
Those
are
things
that
a
dot
grader
alone
cannot
do.
D
They
need
some
engineering
knowledge,
so
if
you
can
provide
whatever
engineering
knowledge
is
needed.
That
would
be
great
now.
This
one,
I
think,
is
a
little
harder,
although
maybe
it's
asking
for
some
of
these
are
clearer
than
others
about
what
we're
looking
for.
But
if
you
look
through
each
of
them,
yes,
usually
some
amount
of
testing,
for
instance
the
second
one
rustic
and
volume
snapshot
examples.
D
You
might
very
well
be
able
to
give
some
examples
so
feel
free
to
add
in
and
then
the
third
column,
if
you
are
less
familiar
with
valero
or
you
know,
shire
from
an
engineering
point
of
view,
but
but
still
want
to
help
out.
Those
are
ones
that
have
all
the
information
engineering
information
needed.
But
it
would
be
great
if
you
could
find
the
place
in
the
docs
and
make
a
pr,
and
so
we
would
love
help
with
that
as
well.
D
Great-
and
this
is
a
perfect
segue
into
my
third
thing,
which
is
community
support-
more
generally
apologies,
I
have
a
four-year-old
who
doesn't
want
to
go
to
bed
who
is
yelling.
So
sorry,
if
you
can
hear
him
in
the
background
daddy
and
my
husband
has
a
bad
back
right
now,
okay,
so
this
was
just
brainstorming
with
I
was
chatting
with
jalan
and
daniel
this
morning,
and
so
this
is
just
our
brainstorm.
So
the
goals
we're
thinking.
What
are
our
goals
with
regards
to
community
support?
D
We
want
maintainers
to
kind
of
think
about
the
amount
of
community
support
they
want
to
do
but
be
a
little
more
thoughtful
about
hey
and
kind
of
communicate,
hey.
This
is
what
I'm
I'm
going
to
do.
Whatever
folks
can
do
three
is,
I
would
love
to
see
documentation
be
better
because
I've
been
trying
to
help
people
in
the
kubernetes
slack
and
a
few
things
I
can
figure
out
through
the
documentation,
but
there's
a
lot
of
stuff,
some
of
it.
D
I
I
know-
and
I
just
don't
see
it
in
the
docs
and
some
of
it-
I
don't
see
in
the
docs-
and
I
don't
know
so.
If
we
can
improve
the
documentation,
we
might
actually
get
fewer
support
questions
because
users
can
help
themselves
and
folks,
like
me,
can
help
support
more
four.
I
do
want.
I
I
thought
about
wasn't
trying
to
put
this,
but
I
do
want
valeria
users
to
feel
like
the
valeria
team
is
present.
D
I
personally
think
that
an
engineer's
time
spent
on
feature
development
can
help
far
more
users
than
the
same
amount
of
time
spent
on
support
doesn't
mean
there
should
be
no
support,
but
that's
what
I
would
aim
for.
So
I
don't
know
if
we
want
to
stop
and
talk
about
the
goals
first
see
if
we
align
on
those
anyways,
we
kind
of
thought
about
some
action
items
which
may
you
know
some
of
them
might
be
controversial
so
but
to
address
the
goals
up
top.
So
let
me
pause.
How
do
folks
feel
about
the
goals?
D
D
Especially,
I
know
you
think
you're
very
community
minded,
so
I
wanted
to
yeah.
You
represent
the
community,
others
who
want
to
say
anything
about
goals
before
we
get
to
action
items.
D
Okay,
so
then
we
got
some
action
items,
so
here's
one
that
might
be
controversial
and
I'd
love
to
talk
about
it
again.
It
was
just
first
try
number
one
yeah,
so
our
thought
was:
how
do
we
encourage
valeria
users
to
help
each
other,
especially
on
the
valero
dash
users
channel,
and
the
thought
is,
if
we're
always
jumping
in
we
as
like
the
maintainers
or
the
valeria
team,
are
jumping
in
immediately
then
there's
less
incentive
for
users
to
help
each
other.
D
D
On
the
other
hand,
though,
it
is
pretty
important
to
me
that
really
most,
if
not
all,
queries,
get
some
kind
of
response.
That's
where
one
comes
in.
How
soon
do
we
give
a
response,
and
the
thing
that
I
was
thinking
about-
and
this
is-
I
really
want
your
thoughts,
it
kind
of
broke
it
into
several
different
types
of
questions.
So,
first
of
all,
we
want
all
queries
to
have
some
response,
but
it
doesn't
mean
you
solve
the
problem.
It
could
be
here,
look
at
this
stock
or
hey.
D
Try
aim
in
that
direction.
That's
what
I'm
saying
for
number
two
for
number
three
for
action
items
to
me
that
there
are
product
and
basic
feature,
questions
which
I
think
we
should
absolutely
answer
and
if
the
answers
aren't
in
the
docs,
then
we
should
get
them
in
the
docs
and
that's
the
kind
of
sort
of
thing
that
then,
ideally,
I
and
other
less
knowledgeable
folks
could
go
and
answer
people's
questions
because
we
just
point
them
to
the
right.
Docs
question:
on
the
other
hand,
we
have
number
four
which
are
complex,
setups
with
uncommon
components.
D
Perhaps
to
me
we
should
be
like
breaking
down
the
individual
components
we
just
saw
one
recently
that
talked
about.
I
don't
know
how
to
say,
k3
support
and
the
backup
of
an
mfs
mount.
I
felt
like
we
probably
should
address
this
individually
in
the
docs.
There
was
something
about
like
an
nas,
I
don't
know
some
storage
I'd
never
heard
of
I'm
not
sure
of
uncommon
stuff.
We
could
be
held
responsible
for
and
certainly
set
complex
setups
as
a
whole.
D
D
We
can
ask
them
to
open
support
tickets,
so
we
could
spend
more
time
there,
but
I
worry
that
debugging
questions
take
a
lot
of
maintainer
effort,
but
may
not
help
that
many
users
at
once
and
if
we
focus
more
of
our
efforts
on
these
number
three,
the
product
and
feature
basic
feature
usage
questions
for
now
to
improve
the
docs.
It
helps
many
more
people
and,
lastly,
six
is
about
figuring
out
maintainer
support,
but
I
will
stop
there.
That
was
a
whole
lot
of
information
really
would
love
to
hear
people's
thoughts.
A
C
So
I
was
thinking
about
that
and
I
agree
with
jonas.
I
also
see
eleanor's
point,
so
I'm
thinking
is
there
a
way
to,
for
example,
give
an
automated
reply
right
away.
That
says
you
know
you
know.
Community
support
will
be.
You
know
this
time
allocated
for
community
support.
You
know
we'll
do
our
best
to
you
know,
have
a
maintainer
or
have
a
vmware
person
right,
because
that's
kind
of
what
we're
saying
right
now
is
really
it's
like
vmware
people
respond
to
it
within
this
time,
but
then
you
have
to
like.
D
Right
and
let's
be
clear,
actually
I
personally
am-
I
usually
put
a
little
time
into
the
kubernetes
slack
every
day,
so
I
actually
don't
mind
responding
within
24
hours,
but
I
know
that
developers
I
want
to
be
conscious
of
what
the
developers
want
to
so
this
could
be
like
shorter
for
some
easier
questions
longer
for
harder
questions,
but
I
like
dave's
point
too.
I
think
that
those
are
all
possibilities
and
jonas,
I
hear
what
you're
saying
if
everything
takes
three
days,
maybe
we
seem
absent.
A
B
How
about
we
say
no
more
than
48
hours,
but
still
I
have
a
little
concern.
I
I
don't
think
we
can
guarantee
that
each
of
the
message
in
that
channel
can
be
replied
properly,
because
when
you
reply,
the
message
that
potentially
may
become
a
very
long
conversation
and
the
user's
expectation
is
you
reply.
You
know
sooner
and
sooner.
D
But
you're
addressing
two
different
things:
one
is
how
fast
we
respond
and
that's,
I
think,
what
we're
more
discussing
now
hi.
The
other
thing
I
would
say,
is
how
thorough
a
response
we
give
and
that's
where
I'd
love,
to
talk
more
about
number
two.
I
think
we
should
give
some
response,
especially
pointing
in
the
right
direction,
but
that
thorough,
like
100
tech
support.
I
think
we
cannot
maintain
so
so
sorry,
daniel
first
yeah.
I
would
separate
the
two
how
long
it
takes
us
to
respond
and
how
thorough
our
response
is.
A
I
think
that
having
a
response
within
48
hours
is
is
good
and
then.
A
And
then
have
a
I
mean
we
can't
really
give
a
time
frame,
we'll
solve
your
problem
within
72
hours,
because
that
doesn't
work
but
having
a
yes
we'll
give
you
a
response
within
48
hours.
I
think
that's
fair
and
then
depending
on
the
problem,
if
it's
debugging
and
things
like
that,
absolutely
point
them
to
points.
D
I,
like
that
point,
and
I
mean
I
guess
the
and
here's
the
big
really
kind
of
controversial
question
beyond
that.
So
a
dave,
I
really
like
your
point
about
reducing
slack
conversations.
It'll
be
more
efficient,
but
I
guess
my
question
is:
are
there
some
debugging
conversations
where
it's
like?
Oh
wow?
If
we
put
this
in
the
docs
like,
is
it
clear
that
if
we
did
a
little
more
in
the
doc
say,
then
we
could
avoid
it
versus?
D
I
feel
like
there
are
some
where
just
there
just
really
don't
know
how
to
use
maybe
kubernetes
or
they're
really
basic
users,
and
I
don't
think
that
we
can
educate
at
that
level.
Is
it
possible
to
try
to
make
those
calls
like
you
know,
spend
10
minutes
on
the
debugging
and
then
say
yep,
you
know
I
don't.
I
don't
think
we
can
help
you
with
the
level
you
need.
I
don't
know
I'm
just
wondering
if
we
can
do
that
kind
of
triage.
C
D
C
D
A
A
So
we
need
to
make
sure
that
if
we
point
to
this,
which
we
all
agreed
to
to
do
in
december,
we
need
to
make
sure
that
we
look
at
this
as
well,
because
we
have
several
several
unanswered
things
in
here
which
are
great
support,
questions
it
looks
like
and
with
details
and
things
like
that.
Maybe
we
can
be
a
little
more
specific
of
what
is
needed
here
and
we
create
a
new
discussion.
I
don't
know
if
we
could
do
discussion
templates
because
then
we
could
say
hey.
We
need
you
to
follow
these.
D
A
B
Yeah
yeah,
we
have
been
ignoring
discussions.
I
think
the
all
these
months,
yeah
sorry,
I
was
thinking
okay,
it
will
be
easier
for
the
engineers.
It
will
be
also
easier
for
us
to
say
it
will
be
easier
for
us
to
measure
the
effort
we
put
into
supporting.
If
we,
you
know
narrow
down
the
channels
for
supporting,
it
will
be
easier
to
ask
them
just
open
an
issue
and
we
we
so
that
there
will
be
on
fewer
channels.
We
need
to
focus.
B
Currently
we
have
like
three
or
four
slag
channels
and
lateral
issues,
and
then
discussion
yeah,
I'm
a
little
concerned
about
this
situation.
It
will
be
easier
like
we
can
only
guarantee
fewer
issues
like
this
slack
channel
and
issues,
and
if
you
really
have,
if
you
really
have
a
severe
issue
or
a
question
and
really
need
us
help,
you
should
go
through
these
issues.
Can
we,
you
know,
send
a
message
to
a
community
like
this,
and
I
think
that
will
outflow
the
burden
of
the
developers
a
little
bit.
A
B
I
would
prefer
we
only
monitor
the
issues,
because
I
think
we
are
treating
the
issues
pretty
seriously.
We
have
a
weekly
trial
meeting
for
each
issue.
We
discuss
each
of
the
men,
assign
them
to
make
sure
that
will
be
followed
up.
B
So
if
they
have
a
need
something
needs
support,
I
would
suggest
they
open
an
issue
in
valero
directly.
As
for
the
questions,
I
think
or
discussions,
or
the
slack
channels
is
more
like
a
platform
for
valet
users
to
interact
with
each
other.
I
mean
the
developer
can
sometimes
join
the
discussion,
but
I
also
does
usually
see
you
know
the
more
the
channel
that
we
will
follow
more
closely.
B
A
B
Like
but
for
discussions
like
nancy
open
to
collect
the
requirement
for
one
line,
that's
a
good
example
for
discussion.
That's
not
an.
A
A
Nails
go
in
and
just
change
these
to
issues,
so
a
maintainer
can
go
in
and
say
hey.
This
is
now
an
issue
and
then
we
can
close
down
the
community
support
q
a
and
then
you
have
issues
and
we'll
send
out
a
message
say:
yeah.
B
B
The
best
way
just
my
thoughts,
but
if
I
look
at
this
one
discussion
like
the
request
for
deployment,
could
you
one
share
the
guy
doc?
I
don't
know
because
shall
we
just
reply?
I
don't
know
where
it
is
or
because
yeah
that's.
D
This
person,
in
particular,
has
asked
in
a
few
places,
they've
also
messaged
me
and
I've
said
I
well
actually
scott
replied
as
well
to
this
person.
I
think,
if
you
don't
have
it
you
just
say
you
don't
have
it
that's,
okay,
that
one
by
the
way
is
more
of
a
product
thing
and
that's
one
of
those
things
where,
ideally,
we
could
put
something
in
the
docs
to
point
to
either
we
have
it
or
we
don't.
D
D
But
but
in
charge,
just
daniel
I'll
say
personally,
I'm
fine
with
what
I
think
we
can
do
support
in
a
number
of
ways.
What's
most
important
is
we
choose
something
that
works
for
the
majority
of
the
folks
doing
support?
So
I'm
perfectly
fine,
I'm
fine!
Being
me,
jonas
and
nancy,
being
the
only
ones
replying
on
slack,
and
we
make
it
clear
saying
if
you
want
to
fill
up,
if
you
want
engineering
support,
submit
an
issue
that
works
for
me.
B
D
Well,
I
would
be
careful
and
properly
that's
the
point,
I'm
making
that
I
to
do
each
question
properly.
We
need
a
huge
number
of
amount
of
support
hours
and
we
don't
have
that
properly
to
me
is
a
couple
answers
of
take
a
look
at
the
stock
and,
if
they
still
say,
they're
confusing
sam,
you
know
I'm
sorry.
The
team
has
stretched
really
thinly.
We
unfortunately
can't
probably
give
you
the
level
of
support
you
need
or.
D
Yeah
and,
dare
I
say,
jonas,
whatever
we
do
decide,
I
think
we
should
really
make
sure
people
feel
behind
it.
So
that's
maybe
all
the
support
folks
can
have
a
little
chat,
because
once
we
switch
to
a
new
thing,
I
think
we
should
stick
with
it
for
a
while,
because
I
know
we've
been
switching
back
and
forth
a
few
times
and
to
jonas's
point
yeah.
We
definitely
need
a
new
template.
Sorry,
jonas,
I
kind
of
cut
you
off.
There.
Apologies.
B
Yeah,
so
I
think
engineer
can
continue
answering
questions
in
slack
channel
and
I
like
the
48
hour
policy
and
for
q,
a
yeah
I
can
create,
or
someone
from
us
can
create
a
template
for
the
issue
so
yeah.
We
just
focus
on
the
issue.
Tab.
D
C
D
In
the
slack
channel,
we
have
a
pin
post
saying
how
you
get
support
and
I
suspect
it's
pointing
towards
the
discussions
right
now.
It
should
be.
D
Sorry
I
got
distracted,
I
updated
the
thing
for
48
hours,
but
yeah.
So
can
someone
volunteer
to
do
the
issue
template.
A
Thank
you,
yeah.
I
can
create
a
basic
one,
daniel
if
you
have
anything
specific
that
you
would
like
to
see
in
the
issue.
Template.
F
Yeah,
just
one
comment:
so
with
this
action
do
we
have
any
actually
for
the
external
maintenance
maybe
to
follow
up
with
them?
Let
them
know
what
what
they
can
have
on
this
part.
A
A
D
Now
that
we
have
a
new
external
maintainer
dave
can
give
his
thoughts.
I
don't
know
if
it
would
be
helpful.
Like
you
all
tell
me,
this
is
engineering
and
I
may
be
sticking
my
nose
too
much
into
it,
but
it
might
be
helpful
to
get
a
sense
of
all
the
external
maintainers,
how
much
time
they
intend
to
put
in
each
week
or,
if
they're,
going
to
focus
more
on
pr's
versus
community
support.
This
might
be
a
bigger
question
of
what
does
it
mean
to
be
in
a
valero
maintainer,
but.
C
It
might
also
be
interesting
to
see
if
they're,
actually
community
members
other
than
maintainers
who
we
could
you
know,
ask
to
do
stuff.
I
I
don't
know
I
mean
this
is
something
I'm
not
really
good
at,
but
this
whole,
like
you,
know,
support
your
users
supporting
each
other.
How
can
we
get
that
order.
C
C
So
I
don't
know
if
we've
got
any
successful
models
under
the
tanzu
you
know
umbrella.
Is
anybody
else
able
to
get
good
community
engagement?
Jonas
for
that
kind
of
stuff.
C
A
C
I
I
was
asking
if
any
of
the
other
tanzania
projects,
if
they
are
successful,
getting
community
people
to
engage
with
supporting
each
other.
A
The
the
valero
channel
had
that
before
so
we
we
used
to
have
more
interaction
there,
so
we
I
would
like
to
see
that
get
back.
I
think
we
we
just
need
to
be
a
little
more
active
as
a
team
as
a
maintainer
team
in
there
answering
questions
and
see
that
the
channel
is
active
and
not
just
a
lot
of
unanswered
questions
that
usually
feeds
on
discussion
and
then
discussion
helps
everyone.
A
So
I
just
think
if
we
can
start
that
and
then
start
pointing
people
for
debugging
things
and
like
real
support
questions
to
issues
and
then
we
can
have
further
discussions
and
it
would
also
help
if
we
had
more
discussions
within
those
channels,
especially
the
valero
dev
channel,
have
more
discussions
in
there.
C
A
We
are
actually
implementing
that
starting
in
february,
so
we'll
have
contributor
of
the
month,
which
is
not
just
a
code
contributor,
but
also
slack
users
and
people
who
are
helping
out
within
the
community,
so
we're
implementing
that
most
likely
late
february.
D
I
don't
really
want
to
go
over
ex
there's,
not
much
of
a
change
I
just
wanted
to
sorry.
Maybe
we
did
the
shout
out
last
week,
I'm
so
sorry
anyways,
the
shout
out
is
we're
still
going
to
think
about
the
road
map,
but
in
short,
we're
going
to
really
finalize
things
after
spring
festival,
because
much
of
the
team
will
be
out
for
that
so
say,
february,
13th
or
so
we'll
start
14th,
we'll
start
finalizing.
D
So
still,
if
you're
curious,
it's
there
at
that,
first
link
and
just
nancy
had
asked
for
feedback,
and
I
saw
that
rafa
and
sean
both
posted
some
thoughts,
so
we'll
definitely
take
those
into
account.
So
if
anyone
else
has
anything
to
add,
please
do
it
before
february
13th,
when
we
will
really
start
to
finalize
things.
D
A
Awesome
all
right,
any
other
discussion
topics
for
today.