►
From YouTube: Argo Contributor Experience Office Hour 5th Nov 2020
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
Okay
hope
we
can
start
so
hello.
Everyone
welcome
to
argo
contributors
meeting
and
usually
we
have
no
introductions,
but
today
I
see
some
new
faces
at
least
one.
I
think
victor.
Can
you
please
introduce
yourself
quickly.
B
A
Welcome
glad
to
see
you
here
and
yeah
sure
is
there
anyone
else
who
is
new
to
the
meeting
and
didn't
have
a
chance
to
introduce
yourself.
D
Yes,
oh
yes,
so
hello,
everyone,
I'm
shama!
I
joined
the
I've
worked
with
into
it
and
I
joined
the
algo
team
recently.
B
A
I
hope
you
can
see
it.
I
will
try
to
make
it
bigger,
so
we
didn't
really
have
too
much
too
many
topics
for
today's
meeting,
but
there
was
one
important
topic:
it's
about
1.8
testing
process
and
I
think
it's
kind
of
perfect
timing,
because
I
think
we're
pretty
much
done
most
of
the
works
and
enhancements
for
1.8
release
are
completed
and
I
feel
like
we
can
start
testing
and
I
was
just
going
to
propose
kind
of
a
process
which
we
can
use
to
test
and
discuss.
D
A
So
that
kind
of
two
very
simple
proposals:
one
is
try
to
avoid
making
big
code
changes
into
the
master
branch,
and
so
I
think
we
can
revise
it.
You
know,
even
even
if
someone
disagrees
and
wants
to
work
on
on
a
new
feature
in
master,
just
let
us
know,
but
the
idea
that
is
to
you
know,
try
to
stabilize
master,
make
sure
it
has
no
showstopper
issues
and
then
once
we'll
feel
it
stable.
A
We
can
create,
create
release,
branch
and
assume
developing
is
normal
and
it
is
going
to
just
simplify
our
life,
because
if
we
fix
bugs
and
work
on
major
features
of
1.88
1.9
release,
that
means
we
have
to
create
release
branch
right
now
and
then
cherry
pick
each
and
every
fix
yeah
or
we
can
simply
kind
of
pause
for
around
five.
Four
days
fix
all
the
bugs
create
release
branches
later,
but
it
will
save
time
on
picking
issues.
A
Yeah
yeah
and
I
think
that's
what
we
were
doing
in
all
previous
releases,
but
the
main
difference
is
that
we
had
less
like
way
less
contributors,
so
it
was
very
easy
to
coordinate
yeah
so
now
I
think
it
that
might
means
that
you
know
if
someone
do
not
participate
in
bug,
fixing
and
working
on
on
the
future.
You
might
have
to
keep
working
for
a
while
in
you
know,
for
several
days
in
your
dev
branch,
but
it
kind
of
benefits.
F
A
quick
suggestion
to
make
it
easy
to
convey
that
to
folks
who
open
prs
would
be,
if
you
could
add
labels
to
a
pr
about
which
version
that
could
potentially
go
in.
That
would
be
easier
for
folks
to
understand
that
hey.
This
is
not
something
that
the
maintainers
think
would
be
scheduled
to
go
in
for
1.8
or
1.9.
A
Okay,
yeah,
that's
a
good
suggestion.
So
if
we
decide
to
just
put
this
on
code
until
1.8
testing
is
complete,
yet
label
will
make
it
easy
to
understand.
A
A
Hopefully
it
can
scale
to
more,
but
idea
that
we
simply
create
a
spreadsheet
which
has
list
of
bug,
fixes
and
features
and
all
the
kind
of
user
facing
improvements,
and
that
list
is
based
on
just
a
git
log,
and
I
kind
of
manually
went
through
all
the
changes
in
git
and
then
get
rid
of
all
noise.
So
no
documentation
changes,
no
internal
refactorings,
no
kind
of
non-user
facing
changes,
and
it's
a
little
bit.
A
You
know
kind
of
sorted
by
change
type,
so
we
had
around
50
like
even
more
than
50
features
in
this
release
and
same
number
of
bug,
fixes
which
has
a
lot
so
yeah,
and
the
proposal
here
is
to
kind
of
if
you
want
to
help
this
testing.
Just
add
your
name
in
one
of
these
columns
and
then
we
kind
of
use
this
you
know
here
is
the
small
legend
of
the
marks
you
can
put
into
each
column
here.
So
if
you
think
it
looks
good,
just
put
this
checkbox.
A
If
you
found
some
something
wrong,
then
just
put
crossmark
and
add
a
comment,
and
this
is
like
it's
not
really
it's
not
formal
at
all.
E
A
E
Yeah,
just
just
like
an
indicator
on
which
issues
someone,
someone
is
gonna
testing,
you
know
so
that
not
everyone
is
testing
the
same
issue,
but
so
you
can
reserve
it
for
yourself
or
indicate
that
you
will
test
it.
A
Yeah,
I
think
it
that's
good
idea,
but
kind
of
as
a
heads-up
I
feel
like
I'm
going
to
so
there
are
two
kind
of
reasons
to
do.
The
testing
first
is
to
verify
that
feature
is
working
and
then
second
is
to
kind
of
just
get
familiar
with
it,
because
I
personally
I
didn't
even
I
wasn't
even
aware
of
some
of
these
changes
so
like
personally,
I
will
go
for
all
of
them,
no
matter
what,
like
no
matter
just
to
know
what
happens.
A
Yeah,
but
I
feel
like
this
indicator
is
still
useful,
because
if
I
see
it,
maybe
I
don't,
I
will
spend
less
time,
you
know
verifying
it.
I
will
just
briefly
take
a
look
make
sure
it.
I
understand
what
the
future
means.
So
I
I
mean
I
feel
like
it's
useful.
A
Okay
kind
of
that
indicator
will
help
to
decide.
You
know
how
much
how
deep
we
should
verify
the
feature.
I
think
we
should
just
agree
that
we
put
that
indicator
if
you
really
kind
of
trying
to
test
the
feature.
If
you
just
look
at
it
closely,
then
don't
put
that
indicator
so.
D
F
And
I
think
the
assumption
would
be
that
the
corresponding
github
issue
would
have
enough
details
on
what
the
acceptance
criteria
is
for
features
which
are
not
very
obvious
to
the
one
who's
testing
it
out
and
if
not,
we
should
probably
just
ask
each
other
is
good
enough
or
we
should
go
ahead
and
then
use
it
as
a
feedback
to
ensure
that
next
time
somebody
works
in
a
pr.
There
is
a
good
enough
acceptance
criteria
in
the
pdr
itself
or
with
the
associated
issue,
to
ensure
that
whoever
is
reviewing
the
pr
or
later
on
testing.
A
G
A
You
know
what
we
did
from
this
iteration
and
yeah.
We
can
use
it
in
the
next
one,
okay
and
all
right
about
access
for
now.
I
just
made
this
document,
you
know
just
open
like
I
provided
fine
access
to
the
whole
world.
I
think
it's
okay,
like
I
don't
think
people
are
going
to.
F
What
we
could
do
is
we
could
give
like
edit
access
to
almost
every
known
contributor
within
this
call
and
everybody
we
know
just
to
be
on
the
safe
side
and
open
it
up
for
comments
to
the
whole
world,
which
means,
if
somebody
wants
to
you
know,
come
in
and
also
add
a
column
to
their
name,
and
you
know
update
details
at
the
very
least.
They
should
be
able
to
communicate
that
intent
by
adding
a
comment
say
hey.
I
want
to.
D
F
A
Okay,
yeah,
that's
not
it's
not
difficult
to
do
so.
I'm
going
to
you
know,
send
it
like
open
access
to
everyone
in
that
meeting
right
after
the
meeting
as
soon
as
meeting
is
done,
yeah
and
then,
if
I
miss
someone
just
like
me
or
you
know,
add
a
comment
here
yeah
and
I
will
try
to
keep
an
eye
on
all
the
comments
in
this
document.
A
Oh
okay
and
yes,
and
it
will
be
in
missing
agenda.
Thank
you,
okay.
I
think
that
sounds
good.
That's
all
I
had
about
testing
and
if
there
are
no
other
questions,
we
can
move
on
to
the
next
topic
in
the
agenda.
A
A
A
Work
is
going
on
right
now,
I
already
in
the
background,
and
we
were
planning
to
work
on
it
in
1.9
degrees.
So,
and
the
idea
of
application
set
project
is
to
solve
application
management
problem
problem
in
argosy
team
and
the
second
idea
I
think
ian
is
most
aware
of
that
feature.
So
the
idea
is
to
support
application,
syncing
orchestration
in
argo
city
using
sync
cld.
A
A
E
Yes,
so
from
my
point
of
view,
I
I'd
be
glad
if
someone
else
would
pick
that,
because
I
think
currently
it's
it's
laying
at
my
table
but
yeah,
I
I
don't.
I
don't
have
that
much
time
to
work
on
it
because
it
really
requires
some
some
time
also
for
the
design.
C
F
B
G
Saying
you,
you
haven't
had
time
to
work
on
the
sync
john.
E
Right-
and
I
probably
won't
have
that
much
time
anyway,
so
if
it
if
it
should
make
it
in
1.1.9,
so
I'm
I'm
not
sure
if
I
have
all
the
time
to
to
drive
it.
A
Yeah
and
just
to
kind
of
clarify,
I
think
this
topic
came
with
in
response
to
william's
proposal,
so
william
them
mentioned
in
during
class
meeting
that
he
is
looking
for
something
you
know
for
a
big
feature.
So
if,
when
you
think
that
you
know
william-
and
maybe
jonathan
people
from
red
hat
could
take
that
feature
so.
B
G
The
I
think
one
known
about
absetz
is
that
there's
actually
one
the
primary
person
working
on
it
is
actually
from
red
hat
devon
goodwin,
and
I
thought
that
one
was
actually
might
be
a
good
one
for
for
rahab,
because
actually,
I
feel
like
you,
you
might
be
able
to
coordinate
much
better
with
the
the
person
who's
primarily
working
on
it.
F
Yeah,
I
think
yeah
I
mean,
from
my
perspective,
to
be
very
honest.
I'm
more
familiar
with
the
application
sets
conversation
than
the
other
one,
so
yeah
I
could
have
you
know
folks.
F
With
william
and
other
folks
have
that
being
driven
so
yeah,
I'm
I'm
happy
to
go
for
that.
Unless
you
know
jan,
do
you
want
us
to
go
for
the
other
one
which
is
also
fine,
but
I
just
haven't
got
a
lot
of
chance
to
understand
what
exactly.
G
Yeah
yeah
we've
been
trying
to
press
internally,
we've
had
push
to
use
it,
for
sometimes
we
haven't
had
time
to
work
on
it
and
make
sure
it's
integrated.
F
Yeah
yeah,
I
I
think
that
totally
makes
sense
if,
if
we
can
add
that
to
the
milestone,
I'm
sure
it's
already
in
the
milestone.
If
you
could
point
forks
towards
it,
then
if
there
is
bandwidth
folks
should
pick
up
it,
it
could
be
purely
by
red
hat
or
it
could
be
a
mix
of
other
folks
as
well.
G
I'll
say
we
we
won't
like
commit
to
the
app
sync
job
for
like
the
next
month.
It
was
just
an
idea
for
as
a
bigger
term
project
because
it
require
ui
and
api
and
controller
work
like
that,
but
I
I'm
not
saying
that
we
should
try
and
make
that
for
one,
but
not
nine.
It
was
just
an
idea
as
a
big
work
item
got
it.
Okay,.
F
I
think
nothing
sounds
good
to
me.
We
could
probably
do
some
homework
on
application
sets
in
general
on
how
the
work
distribution
like
where
it
stands,
ensure
that
everybody
in
the
team
is
aware
of
it
and
then
yeah.
G
I
think
one
of
the
things
that
still
needs
to
be
thought
out
is
so
as
a
as
a
resource
object
and
a
controller.
I
think
it
seems
pretty
well
understood,
but
then
how
that
experience
translates
into
the
argo
you
know:
server
argo
ui,
how
you
know
how
they
involve
with
projects
that
part
is
still
kind
of
hasn't,
been
ironed
out
and,
like
I
think,
that's
there's
some
a
lot
of
thought
that
needs
to
go
into
that.
So
that's
why
you've
got
it.
Yeah.
F
So
it's
not
just
getting
the
crd
and
the
controller
in
it,
but
the
I
think
the
next
I
mean
I
think,
there's
been
enough
work
that's
been
done
to
ensure
that
it
works
independently.
We
just
need
to
figure
out
how
it
can
become
part
of
the
bigger
story
right.
G
Yeah
so
so
someone
asked
the
name
of
the
red
hat
contributor:
that's
devon,
goodwin,
I'll
link
to
this
github
and
in
chat
cool.
G
A
A
F
Yeah,
I
I
had
a
quick
topic
which
I'd
like
to
just
bring
up,
and
this
is
more
of
a
very
ad
hoc
one.
So
I
think
one
thing
that
we
should
probably
aim
for
and
we
could
figure
out
how
to
plan
that
well,
is
that
if
we
could
have
enough
e2e
tests
or
in
a
more
ui
world
selenium-like
tests
to
ensure
that
we
group
every
feature
into
a
scenario,
so
that
so
that,
like
the
goal,
should
be
everything
that
the
team
is
going
to
test
now
on
that
spreadsheet.
F
Eventually,
there
is
an
e2
test
for
it
and
it
doesn't
have
to
be
a
one
is
to
one
mapping,
but
we
should
be
able
to,
in
a
couple
of
releases,
be
able
to
map
everything
being
manually
tested
to
an
existing
test
which
gives
us
enough
confidence,
or
in
other
words,
if
somebody,
let's
say
in
in
a
couple
of
releases
from
now.
If
somebody
didn't
test
one
of
those
features
manually,
would
we
get
a
good
sleep
while
we're
doing
a
wild
video
release?
F
A
F
Some
initial
investment
on
it
every
like
the
goal
should
be
sorry.
The
gold
score
should
be
with
some
initial
investment
on
it.
Every
new
pr
that
goes
in
without
making
the
barrier
for
entry
to
high,
we
should
be
able
to
ask
for
an
e2
test
associated
with
it.
A
A
It
then
we
should
start
asking
for
e2e
tests
for
next
for
new.
A
F
G
F
There
is
a
yes,
we
potentially
don't
have
to
invest
a
lot
of
time
in
retesting
it
manually
and
I'm
pretty
sure
not
every
scenario
will
have
only
two
tests
to
be
very
practical,
and
probably
those
are
the
subset
of
features
that
folks
can
concentrate
on
ensuring
that
they
continue
working.
Even
if
that
feature
didn't
come
in
the
recent
milestone,
it
might
have
come
five
milestones
back,
but
it
never
made
into
an
e3
test.
F
A
F
F
There
is
also
a
repo
with
working
code
and
everything
as
a
first
step
ensure
that
everyone
is
up
to
speed
with
what
work
has
gone
in
and
then
we
should
ensure
that
we
work
with
devon
and
actually
find
out
what
other
plans
he
had
and
ensure
we.
F
We
should
first
try
to
gather
all
the
information
that
we
may
not
have
that's
the
first
step
and
then
the
next
step
would
be
brainstorm
to
a
level
with
a
proposal
of
how
to
integrate
it,
and
I
think
that
will
take
at
least
a
week,
and
we
should
again
be
back
to
this
meeting.
We
could
add
this
as
an
agenda
for
almost
every
meeting
now,
if
we
need
to
there's.
G
There's
a
community
presentation
that,
michael
goodness,
did
that
was
a
pretty
good
intro
on
how
they're
using
app
sets
so
and
then
and
they're
not
they're
doing
it
obviously
manually
applying
the
resources
manually,
but
this
because
it's
not
integrated
in
our
go
cd.
But
that's
that
should
be
a
good
intro
of
like
the
use
case
and
current
experience.
A
A
H
G
G
Have
a
we
have
actually
a
separate
controller
and
working
implementation,
and
I
think
mlb
might
actually
be
running
it
in
production,
so
the
the
missing
pieces
that
we've
developed
it
independently
the
application
set
controller
with
the
eventual
goal
of
it
being
merged
into
argo
city
core.
G
What
hasn't
been
figured
out
is
what
is
that
experience
like
if
someone
wants
to
manage
applications?
That's
through
the
argo
ui
and
and
what
what
is
that
experience
like,
and
so
some
considerations
has
to
be
done
like
with
you
know,
is,
is
apple.
G
Here's
one
application
sets
lets
you
templatize
in
an
application,
and
one
of
the
things
that
you
can
template
is
what
project
the
application
will
ultimately
be
in,
so
that
what
that
implies
is
that
app
sets
may
not
be
kind
of
bound
to
a
project,
unlike
just
regular
applications,
because
the
whole
point
of
app
sets
is
that
you
can
and
templatize
all
kinds
of
your
your
your
app.
So
if
appset
is
not
bound
to
a
project,
what
is
the
multi-tenancy
story
about
that?
G
The
like
the
attempt,
the
whether
you
think,
yeah
there's
a
lot.
F
F
So
so
I
think,
william
to
your
point,
there
is
a
proposal.
There
is
an
implant.
There
is
an
implementation
which
is
independent,
but
what
is
not
well
flushed
out
and
that
needs
to
be
done
is
how
does
it
look
like?
How
would
it
look
like
when
it's
considered
to
be
part
of
argo
cd
itself
that
needs
work
primarily,
the
independent
bits
are
fairly
there.
I
would
say.
A
G
H
Oh,
she
can
ask,
did
you
mind,
can
you
also
paste
the
link
to
this?
Should
you
have
earlier
about
testing?
I
didn't
yeah
john
earlier.
A
Thanks
here
it
is,
I,
I
will
repeat,
I
will
you
know,
move
all
these
links
to
to
the
meeting
document
right
after
the
meeting.
J
H
Yeah
on
the
smash
you
have
like
x,
y
and
v:
wasn't
that
what
it
was
supposed
to
mean-
and
I
I
heard
about
the
w-
is
working
progress
because
x
is
g.
A
J
A
Exactly
so
that's
and
kind
of
very
piecing,
but
it's
the
idea
is
not
to,
I
feel
like
we
should
assume
that
each
and
every
feature
already
tested
and
unless
it's
ui
change
there
must
be
either
unit
test
or
intuit
test.
So
it
should.
We
have
good
set
of
automation,
tests
for
back
end,
at
least,
but
still
like.
We
idea
is
to
go
through
all
these
changes
and
make
sure
they
all
kind
of
make
sense
together.
A
For
example,
you
know
some
vacant
change
might
be
totally
fine
by
itself,
but
someone
else
in
parallel
worked
on
this
other
change
and
together
these
two
features
breaking
some
use
case.
So
it's
not
even
about
functional
correctness,
but
this
is
to
make
sure
that
user
experience
is
still
good
and
plus
it's
kind
of
an
exercise
for
everyone
to
get
familiar
with.
One.
Do
that
release
and
you
know,
understand
what
what
did
we
do
during
last
couple
months,
yeah.