►
From YouTube: Argo Contributors Office Hours 9th Sep 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
Right
so
I'm
going
to
share
my
screen.
We
have
quite
a
lot
of
topics
today,
added
to
like
agenda
document
thanks
for
everyone
who
who
did
topics
hi,
I
assume
you
just
did
it
and
if
I'm
going
to
move
the,
I
guess
I
actually
should
have
added
to
the
september
yeah.
So
I
think
we
maybe
we'll
have
time
to
discuss.
You
know
go
through
all
of
them
and
if
not
we'll
just
move
it
back
to
the
next
epic
and
we'll
have
a
chance
to
speak
about
eating.
Can
you
can
you
finish
off
this
too
fast?
A
B
Yeah
sure
so
again
like
following
up
on
every
week
right
so
pricing
and
discussion
feedbacks
so
this
week
it
is
so.
Can
you
share
your
feedback
on
the
classical
discussions,
anything
that
needs
to
be
called
or
required
help.
So
is
me
there.
B
C
The
ticket
looks
like
it's
a
plug-in,
have
issue
resolving
dependency,
but
then
the
real
problem
was
in
2.1.
We
introduced
the
change
and
that's
a
regression
that
calls
basically
the
repository
rcd
repository
server
that
the
image
is.
We
set
the
permission
as
a
read
only
and
that
calls
when
the
user
uses
their
own
plugin
they
generally
manifest.
Then
they
cannot
do
the
right,
but
that's
a
regression
and
some
other
issues.
Basically,
if
yc
is
a
real
issue
at
target
to
2.2
and
just
participate
answer,
the
few
discussion
questions,
that's
all
from.
B
A
E
Yeah
yeah,
I
can
I'll
follow
up
with.
I
think
he
he's
already
in
the
support
channels.
I
think
I'll.
Just
let
them
know
to
look
at
the
the
discussions.
E
E
Right,
I
forgot
okay.
B
Okay,
the
next
one
is
the
reload
1.1
release
status,
like,
as
we
discussed
in
the
last
week,
we're
continuing
to
call
out
for
or
not
only
status
that
if
anyone
has
features
that
are
needs
to
be
added,
please
let
us
know
and
currently
like
for
1.1.
We
have
two
features
that
are
currently
in
the
review,
which
are
waiting
for
the
release
cut
so
jjc.
E
Yeah
I
was
busy
fixing
a
regression
that
I
introduced
a
few
weeks
back
so
that
just
got
merged
then
for
dynamic
scaling
that
is
functionally
working,
but
all
the
unit
tests
have
to
to
kind
of
get
updated
to
to
accommodate
the
new
behavior.
So
that's
what
I
need
to
finish
before
this
is
ready
to
be
merged
cloud
watch.
I
just
got
the
review
feedback
incorporated
or
my
my
feedback
was
incorporated
into
the
review.
A
And
I
also
I
was
kind
of
trying
to
help
try
to
review
that
pull
request.
It
kind
of
I
didn't
catch
anything
just
letting
you
know
jesse,
but
I
was
you
know,
as
I
think
you
should
yeah.
I
didn't
want
to
approve
or
disapprove
until
you
take
a
look
so
because
yeah.
E
I
think
my
issues
were
only
with
the
api:
syntax
was
not,
it
wasn't,
kubernetes
compatible
or
it
violated
some
of
the
api
requirements.
I
think,
if
that's
a
trust-
and
I
think
some
of
the
other
feedback-
it
should
be
okay,
but
the
logic
was
good.
The
api
syntax
was
the
thing
I
had
problems
with
here,
there's
one
more
that
should
go
into
1.1,
which
is
basically
ready.
E
I
updated
the
tag
which
is
graphite,
support,
metric
provider
and
I
also
have
been
reviewing
that,
but
it's
not
tracked
because
it
hadn't,
yet
it
wasn't
tagged
to
the
101
milestone,
but
it's
already
been
in
review
and
I've
been
looking
or
I've
been
giving
my
feedback
on
graphite
support.
B
So
can
all
those
things
can
be
done
in
cesarean
ada
that
we
can
provide
for
the
release
cut
at
least.
E
I
would
say
I'm
the
long
paul
for
the
the
101
release,
because
the
dynamics,
the
the
dynamics,
killing
updating
that
the
test
is
a
little
tedious.
E
So
I
I
would
give
a
few
more
days
on
that,
but
plus
that
I
I'm
trying
to
incorporate
some
an
ed
test
framework
changes
that
allow
me
to
test
to
kind
of
pause
updates
so
that
I
can
more
carefully
verify
replica
accounts
during
the
update,
okay,
yeah.
But
right
now
the
the
ed
tests
are
too
they're.
So
a
lot
of
them
are
kind
of
too
timing
based,
and
I
think
if
we
do
it
at
some
other
techniques,
we
can
make
them
more
reliable.
E
That's
actually
there's
there's
there's
something
else
going
on
as
well,
which
is
the
the
k3
yes,
api
server
doesn't
seem
to
feed
updates
always
to
their
our
watch,
and
so
the
symptom
is
that
the
tests
start
failing
with
the
controller,
not
seeing
an
update.
So
as
you
see
you
see
this
error
saying
waiting
for
spec
to
be
observed
and
we
haven't
figured
out
what's
going
on,
but.
F
F
B
I
think
that
would
be
great,
then
I
think
that
is
fine,
so
any
help
will
be
a
contribution
will
be
good.
Yeah.
F
Yeah,
I'm
just
looking
for
the
resource
right
now.
Everybody
is
everybody's
busy
and
there's
lots
of
vacations
happening.
So
I'm
going
to
try
to
get
it
worked
out
here
in
the
next
few
weeks.
B
E
Actually,
I
think,
there's
one
okay,
never
mind.
I
just
found
out
yeah
there's
one
issue
that
was
not
yet
closed
and
I
thought
karina
fixed
it
already
and
she
did.
But
if
the
issue
is
still
open,
so
I'm
going
to
go
ahead.
B
Which
one
is
that?
Actually,
he
was
like.
A
E
Oh
okay,
I
see
the
last
comment:
yeah,
okay,
but
we
can
leave
that
open,
but
unless
we
get
feedback
on
how
to
reproduce
it,
we'll
defer
that
to
why
not
you.
A
E
Okay,
that
sounds
like
a
plan.
Let's
see
what
else
one.
F
Other
feature
coast
just
got
a
pr
opened
to
add
command
line
completions
to
the
client,
which
is
just
really
nice,
so
get
into
a
point
release.
But
okay,
we're
in
yeah.
That
sounds
like
a
cool
feature
can
can
I
get
a
volunteer.
A
G
A
E
B
So
whatever
I
agree
on
now
that
heinrich's
point
like,
as
we
are
closing
on
one
dot,
one
any
any
means
any
small
fixer
is
fine,
we
can
get
it.
Regressions
are
bugs,
but
the
features
I
think
we
can
push
it
to
the
1.2.
If,
if
the
chains
are
used
and
used
thorough.
A
Okay,
I
I
think
we
can
move
on.
Are
you
suggesting,
I
think,
I'm
here?
Okay,
all
right!
So
I
I
see
a
topic
about
argo
ui
code
and
there
is.
There
are
two
of
them
and
I
don't
know
who
edit
the
topic.
Can
you
please
speak
up
if
you.
H
Edit
so
vote
for
ui
library.
It
was
me,
but
I
think
it's
they're
a
bit
different.
The
idea
of
vote
for
ui
library
is
mostly
related
to
to
design
changes
that
you're
going
to
provide,
and
I
think
this
homes
argue
ui
code.
It's
like
it's
a
bit
different.
If,
if
it's
duplication,
so
let's
remove
my
own,
I
don't
know
yeah.
I.
A
Know
who
edit
the
first
one
so
we
can,
I
mean
okay,
basically
we're
going
to
report
and
publish
it.
So
whoever
asked
the
question:
will
she
answer
on
youtube
so,
basically,
like
the
ownership
is
kind
of
split
between
argo,
cd
and
workflow
maintainers
and
argo
ui
code
is
not
really
a
it's
not
like
a
library
that
we
expect
everyone
else
to
consume.
It's
our
way
to
just
share
code
between
workflows,
cng
and
then
rollouts
in
the
future
yeah,
and
that's
why
I
guess
it
might
look
abundant,
sometimes
because
I'm
sorry.
A
We
we
prefer
intentionally
not
to
make.
You
know,
changes
in
that
library
frequently.
So
typically,
we
would
work
on
a
component
in
either
argo,
cd
or
other
argo
workflows
until
it's
stable,
stable
and
not
required
a
lot
of
changes
and
then
just
move
it
into
your
argo
ui
library,
so
that
workflow
and
rollout
could
share.
A
You
know
could
start
using
that
component,
so
yeah,
I
hope,
whoever
asked
it
will
see
that
answer
and
yeah,
but
you
know
like
kind
of
maybe
we
can
discuss
it
right
now.
I
was
thinking
that
maybe
it
doesn't
make
even
sense
to
have
issues
enabled
in
that
library.
Prs
are
definitely
fine,
because
pr's
kind
of
like
someone
should
look
into
prs
but
issues.
I
technically
not
correct
to
report
not
to
create
issues
in
that
repository,
because
it's
not
like
react
or
whatever
like
it's,
not
the
library
that
people
consume.
H
Issuing
component-
and
it
happens
for
all
the
rbc
products,
it
should
be
reported
in
issue
of
product,
like
you
have
some
broken
component
that
see
it
inside
argo
ui.
So
how
we,
because
we
already
met
such
problem
and
we
just
reported
it
in
arcgis,
but
it's
actually
not
just
argo
cd
problem.
I
think.
A
It's
you
know
it
it's
useful
for
maintainers,
you
know
if
we
know
what
we're
doing
we
basically
just
want
to
create.
You
know
entry
in
backlog
in
this
case
here
it
it
makes
sense
to
create
it
in
argo
ui
if
you're
going
to
fix
it
in
argo
ui,
but
at
the
same
time,
like
users
like
end
users
should
not
report
issues
there.
So
it's
like.
A
Basically,
it
has
pros
and
cons
to
maintain
to
open
issues
and
features
in
argo,
ui
repository.
A
I
honestly,
I
would
still
you
know,
just
disable
it,
because
I
I
would
open
two
issues
like.
A
Even
even
if
you
fix
the
component
in
argo
ui,
you
still
need
to
update
you
know
version
in
argo,
cd
and
workflows
and
and
test
it
separately.
So
it's
kind
of
I
and
basically,
if,
if
if
component
is
broken,
that
means
it
manifests
as
a
bug
in
argo,
cd
ui
and
we
need
steps
to
reproduce
it.
Basically,
we
need
to
provide
instructions.
A
Yeah,
so
I
don't
have
honestly,
you
know
like
strong
opinion
about
it.
There
is,
they
will
know
it
wasn't
causing
issues.
To
be
honest,
like
I
think,
if
even
if
some
issues
were
reported
in
argo,
ui
library,
it's
not
so
much
and
yes,
we
were
ignoring
them
because
we
kind
of
don't
expect
anyone
to
use
it
in
their
own
projects.
A
Okay,
all
right,
okay,
I
guess
next,
it's
your
time
pressure!
No.
H
I
Actually,
head
of
design
and
just
the
product
manager
here
at
kothra,
parasha
promoted
me
but
yeah.
So
we're
really
excited
to
see
how
we
can
contribute
more
to
the
eye
of
the
argo.
The
argo
project.
I
Anastasia
has
done.
Some
amazing
work
on
a
few
screens
that
I
hope
you
guys
will
like
and
we'll
see
how
we
can
incorporate
it
into
the
argo
cd
project
and
we
want
to
kind
of.
I
This
is
a
proof
of
concept
and
we
want
to
kind
of
base
or
try
to
see
how
you
can
unify
the
entire
ui,
at
least
in
argo
city
and
maybe
an
additional
project
by
using
some
kind
of
ui
toolkit
such
as
ant,
design
or
or
any
other
and
start
building
a
design
system
and
specific
components
and
theming
them
and
then
incorporating
them
into
the
project.
I
A
Welcome,
yes,
and
I
think
it's
very
much
appreciated
this
effort.
Argo
ui
deserve
more,
you
know
love
recently.
It
was
not.
It
didn't
get
a
lot
of
attention
last
year,
unless
I
mean
without
taking
into
account,
I
mean
it
did
take
attention,
but
we
never
tried
to
re.
You
know
refresh
the
look
and
feel.
I
Okay,
so
if,
if,
if
we
can
anastasia,
can
you
share
the
designs
that
you,
when
you
guys
that
you
made
yeah
we're.
J
J
Filter
because
you
have
you
have
filter
and
I
a
little
bit
redesigned
this
filter
and
it
looks
like
drop
down
when
you
tap
on
this.
J
A
Before
we
move
on
just
one
comment
about
this
filter,
it
basically
idea
of
this
like
there
are
basically
they
used
to
be
three
links
all
out
of
sync
and
none,
and
this
is
like
a
quick
way
for
users
to
apply
checkboxes,
and
I-
and
I
guess
my
question
is
like
what
is
happening.
If
user
select
all
in
this
dropdown,
is
it
going
to
select
everything
or
is
it
yes?
Oh
okay.
So
it's
the
same
thing.
Basically,
you
are
still
yeah.
It
still.
I
Yeah
yeah,
so
I
think
we
need
to
kind
of
tweak
it
a
bit,
because
yours
was
a
selection,
quick
selection
option
yeah
and
we.
I
Maybe
a
filter
for
the
type
and
a
filter
by
name,
so
this
might
need
a
bit
more
fine
tuning.
But
the
approach
is
what
the
main
idea
here
is
that
we
want.
First
of
all,
we
wanted
to
do
minimal,
ux
changes
in
the
product
at
this
stage,
not
to
and
just
show
you
more
of
a
proof
of
concept
of
where
we
can
take
the
ui
and
the
components
and
and
kind
of.
I
Maybe
if,
if
this
is
an
approach
that
that
everyone
agrees
on
and
we
can
move
forward,
we'll
take
a
step
back
and
start
building
and
designing
the
ui
components
based
on
some
sort
of
framework.
And
then
the
adoption
can
be
sidewise.
B
B
A
I
want
to
say
that
I
jumped
straight
into
complaints,
but
before
I
think
I
should
have
said
that
I
totally
agree
it's
way
winner
now
and
much
just
you
know
much
more
attractive,
yeah
and
I
I
guess
I'm
kind
of
when
I
look
at
this
page,
I'm
now
realizing
that
this
page
needs
both.
It
needs
filters
and
it
needs.
You
know:
click,
quick
selection,
just
a
real
use
case.
I
I
use
this
page
pretty
much.
Every
argo,
cd
release
to
update
a
bunch
of
rvc
applications
and
what
I
usually
need
to
know.
A
I
want
to
go
to
the
page
go
to
this
page.
You
know
up
use,
filter
to
select
the
right
applications,
then
click
sync
and
then
I
actually
want
to
apply
a
filter
to
see
a
list
of
everything
which
is
in
either
in
progress.
Basically,
everything
which
is
not
synced,
and
I
guess
you
know
now
you
since
you're,
introducing
this
filtering
functionality
on
this
page
here.
Maybe
we
can
try
to
how
we
can
keep
both.
A
You
know,
quick,
quick
selection
and
I
guess
status
filter
status
filters,
but
I
mean
it's
not
required,
but
I
guess
we
sometimes.
I
agree
definitely.
E
I
think
this
works
for
apps
that
have
a
short
name,
but
if
you're,
actually
in
the
app
that
has
resources.
So
I'm
assuming
we're.
You
know
we're
going
to
reuse
this
sync
box
for
when
you're
inside
the
app
and
then
you
click
sync.
The
text
actually
for
resource
names
and
kinds
tend
to
be
quite
long
and.
E
E
I
mean
like
a
column.
Header
would
be
maybe
to
enough
to
indicate
whether
these
things
be,
but
I
don't
think
it's
necessary
to
say,
sing,
sing,
sing,
healthy,
healthy,
healthy.
B
K
H
E
In
fact,
like
when
you're
in
the
resource
view,
the
not
all
resources
will
have
a
help,
we're
the
app
view
right
now,
so
we're
selecting
applications
and
they
all
have
these
three.
But
in
the
res,
in
a
single
application
view
and
you're
looking
at
resources,
not
everything
will
have
a
health
status
and
everything
will
not
have
a
single
operational
status.
E
I
So
I
I
think
we
should.
This
is
definitely
great
feedback
and
we'll
take
it
into
account
and
I
think
for
the
next
meeting
we
can
provide
a
few
options.
It
would
be
fairly
quick
for
us
either
truncating
the
text
or
wrapping
the
text
or
providing
tooltips
or
just
showing
the
text
for
for
different
statuses,
and
we
can
decide
which
one
works
better.
A
Okay,
yeah
and
then
I
feel
like
we
had
this.
You
know
we,
the
mocaps,
were
presented
in
that
meeting,
because
you
know
we
just
wanted
to
get
this
feedback
first
about.
You
know
this
this
initiative
in
general
and
it
was
kind
of
touching
a
lot
of
areas.
I
assuming
we
passed
this
stage,
and
maybe
we
can
basically
move
now
discussion
into
the
issues
yeah.
So
now
we're
going
into
like
nitty
gritty
details,
which
is
you
know
hard
to
catch
in
these
discussions.
A
So
I'm
just
proposing
to
you
know
finish
reviewing
on
cups
that
was
prepared
for
that
meeting
and
then
move
discussion
into
issues.
H
That
make
sense.
Okay,
just
before
we
will
do
it
victor
presents
some
topics
that
he
wanted
to
cover
with
with
you
guys
and
ask
some
questions,
and
after
this
I
can,
I
think
we
we
can
move
to
issues
okay,.
L
Welcome
and
and
I
on
previous
meeting
and
also
today,
we
talking
about
s
ergo
cd
redesign
and
today
we're
going
to
show
our
vision
and
the
initial
plan,
maybe
for
for
implementation,
and
also
we
have
some
question.
So
let
me
share
my
screen.
L
And
maybe
it's
a
step
back
a
little
bit
about
motivations
for
that,
as
I
understand,
and
we
we
understand
so,
we
should
make
the
design
more
accurate,
fresh
and
attractive
for
2021.
L
So
in
terms
of
redesign,
we
see
three
approaches
that
we
can,
that
we
can
choose
so.
First
of
all,
we
can
we
can
choose
the
design
of
old
ui
kits
that
we
already
have
create
a
new
one
in
new
ui
kit,
and
maybe
you
can
use
some
radio
kit
like
an
end
design,
material,
semantic,
ui
or
something
else
that
they
don't
already
mentioned.
L
A
It
really
depends
on
how
difficult
it
is,
but
I
I
I
know
that
it
will
be
beneficial
to
try
to
improve
existing
qi
kit
because
it
will
immediately.
You
know
it's
already
used
by
argo
workflows,
and
so,
if,
if
we
go
this
way,
that
will
you
know
we
will
both
uis
will
stay
will
keep
looking
the
same
so
and
I
I
guess
this,
that
was
our
goal.
I
don't
know
if
you
have
any
of
you
know:
product
managers,
you
know
the
people
who
care
about
like
a
hennig.
I
think
it
maybe
you
can.
A
E
They
did
a
lot
of
work
to.
You
know,
make
the
dag,
rendering
and
stuff
work
with
the
workflow,
which
is
the
most
important
part
of
the
ui
in
workflows.
Is
that
compatible
with
any
of
these
approaches?.
A
I
think
that
the
rendering
it's
kind
of
it's
you
know
just
workflow
related
piece
and
it's
I'm
sure
it's
not
in
the
argo,
ui
library.
So
and
that's
my
understanding
and
basically,
I
think
we're
only
speaking
here
about
codes,
and
you
know
some
reusable
components
like
you
know,
maybe
panel
and
like
we
have
this
magic
component
called
white
box
which
should
have
heather
this
type
of
things.
E
But
because
I
think
in
the
in
the
order
priority,
I
feel
like
the
project
should
remain
consistent,
look
and
feel
so.
I
think
we
I
don't.
I.
I
hope
that
both
workflows,
ui
and
the
our
cd
ui
will
look
similar
and
if
we
can
accomplish
that
with
redesigning
both
at
the
same
time,
without
breaking
the
I
mean
the
essential
the
functionality
of
workflow,
dag
rendering,
then
then
I
would
support
the
any
approach.
G
Yeah
we
see
a
lot
of,
we
see
a
lot
of
crossover
uses
from
between
the
produce
right
and
but
the
users
also
like
that
the
projects
are
are,
are
independent
and
and
building
blocks.
I
think
you
know
having
a
consistent
look
and
feel
throughout,
I
think,
is
very
valuable
without
you
know
having
it
all,
bundled
into
one
big
big
platform
so
yeah,
I
would
definitely
support
any
anything
that
would
further
that.
A
And
just
one
more
comment
I
wish
remington
was
in
that
meeting,
but
I
know
he
was
passionate
about
actually
making
some
changes
and
the
reason
was
the
cargo
ui
was
built
before
react.
Hooks
existed,
so
it
doesn't
use
react,
hooks
and
react.
Hooks
is
basically
it
gives
it
better
ipi
and
I
feel
like
he
was
actually
advocating
to
make
a
change
and
implement
the
new
ui
kit,
and
I
and
I
I
kind
of-
and
I
was
agreeing
with
him
as
well.
A
So
in
some
cases
where
we
want
to
make
a
change,
I
would
you
know
basically
it's
com
component
by
component.
You
know
like
things
like
panels,
don't
have
any
state
and
they
there
is
no
need
to
have
a
hook,
and
there
is
no
need
to
introduce
like
a
new
panel
and
it's
better
to
just
redesign
it.
But
let's
say
you
know,
forms
component
and
you
see
the
ui
is
extremely
old.
It's
already
different.
K
M
I
I
do
have
some
thoughts
alex,
so
I
think,
first
and
foremost,
I
think
so
it
was
suggested
that
maybe
we
use
a
third-party
library
and
personally,
I
feel
that
that
might
be
the
wrong
approach
for
a
couple
reasons.
First
of
all,
it
adds
a
dependency
to
a
third
party
and
say
they,
you
know,
stop
maintaining
it
say
something
happens,
we're
kind
of
beholden
to
their
api
and
we're
beholden
to
them,
maintaining
their
project.
M
And
on
top
of
that,
I
think
that
to
go
use
a
third
party
library
kind
of
we're
less
distinguished
you
know
our
our
go
look
and
feel
is
no
longer
our
look
and
feel
if
we
go
use
material.
That
looks
exactly
like
a
google
product
which
I
don't
know,
is
necessarily
what
we
want,
but
to
kind
of
speak
to
what
we
should
do.
I
think
that
redesigning
the
ui
kit
and
kind
of
making
a
design
system
would
be
a
good
idea,
because
it
addresses
sort
of
two
issues
like
you
were
talking
about.
M
One
is
the
actual
look
and
feel
of
it,
and
two
is
the
development
experience
which
I
think
is
equally
important,
because
if
it's
easy
to
maintain
easy
to
develop
and
easy
for
people
to
contribute
to,
then
we're
going
to
you
know
be
able
to
maintain
that
for
longer
and
we're
going
to
be
able
to
work
more
rapidly,
et
cetera,
and
I
think
that's
especially
important,
given
that
we're
going
to
be
opening
it
up
to
extensions.
M
E
That's
like
that's
such
a
good
point
about
the
extensions
yeah
I
I
agree
with
that
last
point,
especially.
M
Yeah,
so
I
I
think
the
I
think
to
me.
It
sounds
like
a
good
idea
to
I
guess:
redesign
the
the
existing
ui
kit
or
the
v2
ui
kit,
whatever
you
want
to
call
it
and
redesign
it
both
visually
and
structurally
and
yeah.
I
think
that
would
be
a
good
idea
and
in
the
process
maybe
doing
some
sort
of
design
system,
so
something
that's
codified.
A
Just
in
you
know
want
to
propose
like
a
rule
like
do
you
agree
if
I
say
that
it
is
better
to
keep
existing
components
unless
we,
you
know,
enhance
existing
component
and
introduce
new
one
only
if
there
is
like
a
reason,
so
by
default
we're
kind
of
saying,
let's
just
try
to
keep
use,
you
know
just
improve
existing
component
and
the
explanation.
Why
is
because
workflows
use
the
set
already
algorithm?
A
Argo
cd
uses
it
already,
and
we,
if
we
make
an
enhancement
in
existing
component
and
keep
the
same
api,
then
both
projects
just
automatically
gets
enhancement.
But
there
might
be
plenty
of
cases
where
we
want
to
make
a
change
to
improve
their
experience
and
yeah.
And
you
know-
and
in
these
cases
like
as
soon
as
we
have
as
long
as
we
have
clear
reason
to
improve,
then
we
go
ahead
and
improve
like.
A
It
kind
of
we
decided
to
just
create,
like
a
brand
new,
auto
completion
component
that
uses
hooks
so
yeah
and
I
guess
yeah,
so
that
was
like
a
long
question
to
make
something
else.
Do
you
agree
with
this
approach.
M
Yeah,
I
think
that
that's
I,
I
think
that's
definitely
a
good
idea,
and
I
think
that,
honestly,
even
for
a
lot
of
those
components,
they
if
the
api
is
good
and
if
the,
if
the
developer
experience
is
good,
then
you
know
it
might
only
require
some
css
changes.
That
would
be,
you
know
relatively
easy
to
make
for
a
lot
of
the
components
yeah.
I
agree.
A
I'm
basically
like
I'm,
I'm
speaking
from
I'm
kind
of
trying
to
guess
how
much
time
it
will
take,
but
I
think
it's
really
up
to
the
person
who
is
going
to
implement
it.
We're
going
to
make
the
changes
so
and
I
feel
like
I
wanted
to
like
explain
really.
You
know,
make
it
really
clear
that
we
have
like
workflows
and
if
we
it's
like
technically,
we
cannot
forget
them.
If
we
start
making
changes
in
argo,
ui
very
likely
tomorrow,
there
will
be
a
bug.
You
know
that
affects
workflows
and
workflows.
A
Team
tries
to
make
tries
to
fix
that
bug
and
they
will
find
that
whole
ur
library
is
no
different
and
they
cannot
upgrade.
They
will
be
really
upset,
they
will
be
like
blocked
and
yeah,
and
that's
why
I
was
kind
of
pushing
to
try
to
it
so
yeah
we
can.
We
have
like
two
users
and
actually
argo
workflow
was
the
first
user
of
fargo
ui
library,
so
like
pretty
much,
this
set
of
components
was
create.
A
H
A
H
I
hope
I
agree
about
your
tremendous
points,
but
I
just
cannot
understand
how
we
will
gradually
expose
it.
I
mean
we
cannot
expose
it
for
two
platforms
because
they
still
have
some
diff
differences
in
slide,
sliding
panels
and
so
on
and
as
you
remember,
we
decided
that
first
thing
that
we
will
release
in
three
three
or
3.0
milestone
that
it
will
just
change
all
sliding
panels
and-
and
that's
I
think,
if
you
will
change
components
in
argo
ui,
we
will
affect
argo
workflow
and
it
can
completely
like
change
things
and
so
on.
H
A
We
have,
I
would
just
do
it.
You
know
component
like
basically,
we
already
have
v2
in
argo
ui
repo,
so
there
is
like
a
v2
folder,
which
is
meant
to
store
duplicated
components
which
are
supposed
to
eventually
replace
old
ones
and-
and
basically
let's
say
we
start
working
on
redesign.
That
was
proposed
for
sliding
questions,
and
I
guess
the
you
know
we
will
have
to
start
from
something
like
from,
for
example,
input
and
inputs.
A
Maybe
is
good,
maybe
to
improve
input
controls.
It
will
be
enough
to
simply
change
css
and
you
know,
and
then
and
then
we
can
make
a
call.
If
it's
really
that
easy,
then
there
is
no
need
to
introduce
input
v2,
but
you
know,
and
then
we
can
move
to
the
next
example
and
next
one
could
be,
I
don't
know,
forms
api
and
this
one
we
might
say.
A
Oh,
we
don't
like
it,
it's
old,
it
has
to
be
you
know,
and
then
we
can
propose
a
change
and
introduce
whatever
component
needed
in
in
v2
so
and
it
could
be
based
on
okay,
and
I
think
we
still
have
an
answer
question
like
do.
We
want
to
introduce
third
party
dependency
or
not,
and
so
yeah
for
v2
version
we
might
choose
to
build
new
one
or
yes,
build
new
one
and
use
third
party
dependency.
A
And
yeah
maybe
like
to
me,
I
think
it
seems
like
a
right
approach
to
you
know.
We
basically
depends
on
components.
We
can
make
decisions
to
either
keep
old
one
or
introduce
new
one,
and
I
think
decisions
should
be
made
based
on
what
is
easier.
If
we're
introducing
new
one
we'll
write
we're
free
to
make
whatever
changes
we
want,
because
you
don't
care
about
background
compatibility,
but
in
this
case
I
think
we
should
take
into
account
the
amount
of
work
that
will
be
required
to
migrate.
Argo
city
and
I'll
go
for
close.
M
I
agree
alex.
I
think
that
the
piecemeal
approach
is
probably
preferable,
and
so
maybe,
instead
of
looking
at
it
as
we're
going
to
redesign
this
one
specific
page
sliding
panel
all
at
once,
it
could
be
thought
of
as,
like
you
were
saying
one
component
at
a
time
by
the
end
of
it.
We
want
this
sliding
panel
to
look
like
this,
but
each
component
should
be
done
on.
A
M
One
at
a
time-
and
I
think
that
that
also
makes
it
a
lot
easier
when
we
decide
to
go-
permeate
these
ui
changes
across
the
ui,
because
then
it's
just
as
simple
as
you
know,
updating
the
component
or
updating
the
argument.
Library.
A
I
guess
you
know
we
try
to
just
scope
it
to
tables
only
to
reduce
amount
of
components.
We
should
redesign
just
to
make
this.
You
know
effort
a
little
bit
smaller,
like
yeah,
but
it's
still
quite
a
lot
like
this.
Sliding
panels
has
a
lot
of.
Basically.
This
is
the
these
panels.
I
used
mostly
to
let
user
input
something
and
that's
why
it
has
pretty
much
all
of
the
forms
controls
like
auto
completion
controls.
A
You
know
inputs
and
selects
and
and
so
on,
all
right-
and
I
I
do
not
know
I-
I
don't
have
opinion
about
using
or
not
using
credit
ui
kit
and
I
guess
remington
you
had
like.
Maybe
I
heard
it
as
a
strong
opinion
to
not
do
it
and
then
I
am
guessing
that
victor
suggests
to
use
it,
and
maybe
we
can
discuss
pros
and
cons
of.
A
You
know
whether
we
should
use
radioactive
or
not
and
maybe
like
richter.
I
guess
what
do
you
mean
by
by
ui
kit?
Is
it
like
a
set
of
rules
or
is
it
a
framework
like
I.
L
Mean
framework
like
design
or
something
else.
A
One
point
you
know
that
remington
was
trying
to
make
is
that
if
we
use
something
which
is
ready,
then
we
kind
of
don't
control
the
look
and
feel
we
kind
of
have
to
adopt
what
is
implemented
in
that
framework.
Like
are
you
visit,
or
you
know
all
the
framework
that
you're
referring
to
allows
customizations
like?
Can
we
still
keep
our
blog.
H
Yes,
so
the
idea
here,
okay,
the
motivation
of
these
slides-
was
okay,
guys.
We
need
to
decide
how
we're
moving
with
kids,
we
implement
our
own
components,
we
use
some
framework
or
something
like
this-
for
better
alignment
between
developers
and
designers,
because
in
such
case,
nsca
can
automatically
align
design
to
this
specific
framework
and
it
will
be
easier
to
implement.
So
if
you
will
decide
to
use
that's
something
that
we
do
in
quarters,
so
we're
not.
K
I
No,
no,
oh,
it
wasn't,
but
but
there
are
different
ui
kits
so
and
we
actually
went
through
this
process
internally.
Material
design
is
very,
very
opinionated.
So,
like
you
said,
every
material
design
project
looks
like
a
google
project,
but
ant
design
and
the
other
ones
are
a
bit
more
standard
and
easier
to
theme.
I
So
we
we
believe
that
working
with
them,
we
can
achieve
any
look
at
field
that
we
want,
and
ideally
it
will
make
the
the
the
whole
implementation
process
faster,
which
is
the
goal
we
don't
have
to
rewrite
everything,
but
we're
able
to
create
custom
themes
here
for
for
ant
design,
dark
and
light
themes
and
update
all
the
css
and
so
forth
to
match
the
look
and
feel
of
the
of
argo
that
we
want.
I
So
looking
at
what
we
designed
in
figma,
we
believe
that
there
shouldn't
be
an
problem
achieving
that
with
libraries
such
as
ant
design,
whereas
with
material
design.
It's
definitely
something
different
and
we
don't
really
recommend
that
that
approach.
F
It
might
be
worth
in
making
this
decision,
because
I
you
know,
I
hear
I
hear
the
concern
of
well.
Will
it
still
look
like
argo?
Do
we
have
to
develop
everything
from
scratch
all
this
stuff?
Maybe
maybe
the
next
step
would
be
to
do
like
take
the
application
sync
screen,
which
is
probably
one
of
the
most
important
in
in
all
the
projects,
and
do
the
approach
do
do
like
the
multiple
approaches
and
then
share
that
and
then
people
can
stay
like.
F
Oh,
you
know
what
actually
like
looking
at
ready,
what
you
did
with
ready,
with
whatever
ready,
ui
kit,
you
think
is
best.
This
still
feels
like
argo,
but
it
feels
like
an
upgrade
okay.
Then
then
people
can
kind
of
see
it.
I
think
I
think,
without
seeing
it
it's
it's
hard
for
people
to
make
a
meaningful
decision.
A
I
I
think
we
kind
of
agreed
that
everything
that
nasty
and
implemented
so
far
is
looking
good
and
it
was
kind
of
scoped
to
panels.
But
I
have
not
heard
a
single
word
that
says
no
like
we
don't
like
it,
so
it
I
feel
like
it.
We
mostly
discussed
now.
How
do
we
execute
it?
And
then
you
know,
and
now
we
have
like
cargo
ui
and
we
need
to
use
yeah.
K
A
We're
going
to
so
I
mean,
I
think
it's
it's
awesome
if
we
will
get
mockups
for
everything
else
outside
of
sync
panels,
and
it
it's
like
it's
totally
fine
to
do
it
in
parallel.
I
just
don't
expect
any
exactly
like
that.
We're
moving
in
the
right
direction.
Now
we
need
to.
I
guess,
developers
need
to
figure
out
how
do
we
actually
implement
these
changes.
H
A
If,
let's
say
if
I
was
tasked
to
work
on
it
and
you
know
and
we
work
in
the
same
team,
I
would
not
try
to
answer
generic
question
like
whether
to
use
frame.
You
know
some
framework
or
not,
I
would
say
like.
Are
you
fine
to
use
and
design?
And
this
is
example,
you
know
just
take
something
like
what
you
actually
planning
to
use
and
see
and
then
and
then
you
can
get
real.
A
You
know,
like
basically
real
arguments,
you
know
we
I'm
pretty
sure
and
design
saves
us
some
work
and
at
the
same
time
maybe
it
will
be
impossible
to
customize
some
things
which
is
fine
and
then
we
can
make
a
decision.
We
can
say:
okay,
it
saves
us
like
months
of
work,
and
you
know
this
particular
component
will
not
look
exactly
like
it
was
designed
and
if
and
then,
and
then
we
can
see
if
we
can
tolerate
it
or
are
we
willing
to
invest
more
time?
That's
how
I
would
approach
it.
So,
basically,.
H
Two
to
two
components:
so
it's
like
decision
will
we
use
it
for
all
companies
or
we
will
just
use
it
because
it's
good.
It
was
good
point
from
remington
and
just
if
you're
going
to
use
it
not
widely,
it's
not
make
sense
to
to
bring
all
these
things.
If,
okay,
maybe
good
start
here,
will
be
like
to
start.
I
don't
know
internet
without
and
and
let's
see
if
it
will
be
really
complex
to
compare
with
undesigned.
So
we
should
back
to
this
topic.
Should
we
should
we?
You
know
instead.
A
Of
discussing
it
now
with
like
everyone
and
everyone
will
have
opinion,
should
we
find
you
know
who
actually
committed
to
working
here
and
I
I
feel
like
it's
fair
to
let
people
who
actually
you
know
like
I'm
guessing
that
rammington
really
passion
to
to
participate
and
and
then
and
then
we
let
the
developers,
discuss
this
implementation
details,
because
now
it's
like
yeah,
but
but
what
is
in,
which
way
in
github
and
in
the
I
guess
I
guess
you
know
github
will
take
forever.
We
are
in
different
time.
H
A
I
propose
we
just
meet
one
more
time.
I
guess,
but
this
is
you
know
a
separate
meeting
or
okay.
Personally,
I
like
to
resolve
this
type
of
you
like,
like
there
is
hesitation,
you
know
we
never
seen
and,
like
I'm
pretty
sure,
a
lot
of
us
never
seen
and
design
and
no,
you
know,
doesn't
know
how
it
works
and
poc
kind
of
usually
helps
to
make
a
decision.
A
You
know
like
a
draft
pull
request
that
demonstrates
couple
components
and
then
kind
of
proving
that,
like
hey,
you
know
this
is
you
know,
we're
proposing
this
framework,
and
this
is
how
it
worked
for
button
and
top
down
whatever,
and
then
it
basically
helps
everyone
else
to
understand.
So
this
is
one
way
to
approach
it
as
well.
If
someone
willing
to
implement
a
poc,
that
is
also
a
good
way
to
start.
E
H
E
I
think
that
channel
was
created
by
remington,
specifically
for
there's
only
probably
five
messages
in
there.
H
E
That
may
not
be
efficient
enough,
like
I
do
agree
that,
like
going
through
github
is
gonna,
be
too
slow,
slack
channel
will
be
slightly
better,
and
then
I
think
we
can
for
this
just
the
handful
of
people
who
are
need
to
be
involved
in
this.
They
can
have
like
separate
meeting
for
that.
E
Just
join
this,
this
slack
challenge
cncf
called
I'll
type
it
in
the
zoom
chat.
Argo
dash,
sig
dash,
ui,
okay,
dash
ui.
E
At
least
that
will
be
fast
doubly.
You
know
slightly
better
than
github
just
issues
yeah,
you
can
get
more
rapid
feedback,
but
then-
and
then
you
can,
you
guys
can
call
meetings
when
appropriate
to
kind
of
get
even
more
faster
discussion.
A
And
unfortunately,
we
just
run
out
of
time
your
discussions
always
be
long
and
yeah.
I
guess
we
need
to
continue
discussion
in
in
the
chat
and
maybe
another
meeting
you
know
focused
on.
E
Okay,
so
so
we'll
agree
to
take
the
discussion
to
slack
channel
and
then
call
for
separate
meetings
when
as
needed.