►
From YouTube: Argo Contributor Experience Office Hour 20th May 2021
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
yeah
hello,
everyone
again
nice
to
be
back
after
break
I'm
going
to.
Oh,
I
swedium
is.
A
A
I
guess
we
want
to
talk
today
about
some
process
changes
and
I'm
going
to.
I
guess,
give
it
again
to
start
first.
B
Yeah
thanks
alex
so
yeah.
I
think
after
reviewing
your
document,
it's
it's
not
it's
not
the
same,
but
it's
it's
going
in
the
same
direction
right.
So
the
first
topic
I've
added
is,
is
about
pr
review
and
approval.
C
B
I
think
shubik
already
brought
that
up
a
couple
of
weeks
ago.
B
So
one
thing
is
that
I
feel
it's
time
to
have
like
a
four
ice,
a
mandatory
for
ice
process
for
prs,
so
that
that
we
say
that
we
need
two
people
approving
a
pr
before
being
merged,
so
maybe
not
for
each
and
every
pr
right.
So
some
are
very
small
and
and
don't
change
much
things
maybe
fix
a
thing
in
in
the
build
2
chain,
or
you
know,
documentation
and
stuff
like
that.
I
think
for
for
these
it
would
be
overkill
to
have
a
foreign
review
process,
but
I
think
for
larger
changes
it.
B
It
would
make
sense
if,
if
we,
if
we
have
at
least
two
approvers,
go
over
a
change
before
it's
merged.
B
B
To
achieve
it's,
it's
it's
so
my
my
main
goal
would
be
to
to
catch
things
right
so
for
ice,
always
see
more
than
two
yeah
and
that's
basically
about
it.
So
for
for
the
real
large
changes
we
we
already
have
the
the
proposal
process
right
so,
but
this
is
basically
this
is.
This
is
more
about
increasing
quality.
A
Yeah-
and
I
feel
like
I
also
if
we
get
to
to
the
document,
I
had
probably
to
change
review
process
as
well,
but
and
my
main
goal
was
to
make
sure
we
have
someone
to
test
that
change
closer
to
end
of
release.
So
I'm
kind
of
assuming
that,
like
with
two
or
four
eyes,
we
will,
we
still
might
get
something.
You
know
we
might
miss
a
bug
and
then
someone
would
have
to
test
and
fix
it,
and
I
feel
like
it
would.
A
E
So
is
the
implication
of
this
that
you
know
a
significant
amount
of
stuff
has
gone
in
that
wasn't
thoroughly
reviewed
enough,
like
is
that
the
impetus
for
this.
B
B
But
for
some
reason
maybe
it
was,
it
was
much
too
quickly
or
something
like
that,
but
I
haven't.
I
don't
have
a
concrete
example.
E
Having
someone
review
a
pr
is
a
fair
bit
of
work
for
that
person.
They
need
to
get
into
the
headset
of
the
pr.
The
mindset
of
the
pr
kind
of
understand
what
the
original
issue
was
kind
of
think
through
maybe
in
their
mind
how
they
would
solve
it
or
you
know
whatever
process
that
we
as
reviewers
or
coders,
do
to
kind
of
build
our
mental
model
of
what's
being
worked
on.
E
So
so
one
has
to
do
that
for
the
space
that
is
being
modified
by
the
pr,
then
they
have
to
look
at
the
pr
look
at
the
code.
Look
at
what
the
code
connects
with
et
cetera,
et
cetera.
So
it's
a
fairly
involved
process.
So
the
more
folks
that
you
ask
to
do
that
process
you're,
definitely
going
to
find
more
bugs.
E
Just
by
definition,
as
you
said,
more
more
eyes
are
going
to
find
more
issues,
but
it
would
definitely
be
a
lot
more
work
for
in
general,
when
you
sum
up
any
single
individual
having
to
go
through
that
process
of
building
the
mental
model
and
then
applying
that
mental
model
to
what
the
pr
is
doing
versus
having
you
know,
a
bunch
of
people.
Do
it
so
yeah
thoughts
on
that.
A
F
A
F
Also
gonna
bring
that
up.
I
think
we
can
definitely
apply
this
to
a
certain
class
of
of
prs.
I
think
especially
things
that
change.
For
example,
the
specification
or
maybe
the
api
right.
Those
to
me,
I
think,
would
be
automatic
candidates
for
two
sets
of
eyes
because
they're,
basically
changing
potentially
the
user
experience
and-
and
then,
but
you
know,
on
the
gray
area,
are
you
know
I
was?
I
would
say
that
bug,
fixes
and
stuff,
maybe
wouldn't
need
to
on.
You
have
two
eyes
on
that
right.
F
So
is
there?
Is
there
a
certain
class
of
prs
that
you
would
apply
this
to
but
not
apply
to
others
or
is?
Are
you
saying
yeah.
B
C
I
I
can
provide
some
ideas
around
how
to
you
know
not
lose
the
awesomeness
of
multiple
eyes
at
the
same
time
preserve
the
speed
which
is
in
a
lot
of
peak
cases,
a
pr
may
have
key
design
changes.
It
may
have
key
refactoring
and
going
in
while
it
also
is
solving
a
bug.
C
For
example,
let's
let's,
let's,
let's
look
at
the
most
complex
one,
what
would
be
the
most
efficient
way
of
reviewing
that
vr
one
person
may
go
in
depth
and
be
and
and
do
all
the
checks
and
and
basically
apply
the
checks
and
balances
on
the
code
to
ensure
the
code
is
same.
It
has
been
properly
structured.
C
The
packages
look
okay,
while
the
other
reviewer
may
actually
do
a
little
less
of
that,
while
ensuring
that
the
bug
or
the
feature
actually
works
so,
which
means
folks,
might
want
to
actually
divide
by
saying,
hey,
I'm
good
with
this
pr.
I've
checked
x
and
y.
The
following
things
may
not
have
been
checked
and
that's
where
the
second
reviewer
can
play
a
good
role.
So
what
this
effectively
means
is
per
reviewer.
You
might
actually
spend
lesser
time
while
have
more
eyes
on
it
and,
in
the
end,
have
a
better
pr.
C
So
what
that
means
is
the
feedback
from
the
reviewer
should
be
a
little
more
verbose
than
it
would
be.
Otherwise,
by
saying
that
these
are
things
I've
tried,
while
the
other
things
have
not
tried
and
that's
what
automatic
the
next
person
picks
up
and
goes
in
this
way,
two
people
have
the
rise
in
yet
they
don't
have
to
do
the
exact
replica
of
the
work
the
previous
person
did.
F
Yeah,
so
actually
I
agree
with
what
you
just
said.
Like
example
of
this,
is
actually
when
I
started
getting
less
hands-on
with
the
workflow.
I
I
actually
still
really
cared
about
the
the
the
api,
the
spec,
so
one
of
the
things
we
did
for
a
while
was
that
I
was,
I
think,
under
the
owner's
file
of
the
proto
folder
of
the
change.
F
So
any
change
to
the
protos
I
had
I
was
automatic
reviewer,
because
then
I
would
review
just
the
api
changes
or
the
types
go
changes
that
were
made
and
then,
but
I
actually
didn't
review
any
of
the
the
logic.
F
So
at
least
the
syntax
is
something
I
agreed
with
or,
and
so
I
think
that
might
be
a
good
heuristic
right
like
we
could
start
using
owner
files
in
the
nested
directories,
that
and
for
big,
for
changes
like
that
affect
a
certain
portion
of
code
that
maybe
someone
has
a
pretty
good
expertise
on.
They
would
be
in
the
owners
of
that
directory.
And
then
you
automatically
get
this
four
eyes.
C
That
is
relevant.
I
I
think
that's
a
perfect
way
to
do
it,
especially
because
rgo
cd
is
a
big
monorepo.
You
have
ui
code
in
there,
you
have,
you
know
server-side
back-end,
you
have
controller
code
in
there
and
they
all
have
different
levels
of
you
know
the
expertise.
That's
needed
to
be
actually
reviewing
that
in-depth,
so
the
owner's
file
you
know
triggering
the
suggested
reviewer.
That
is
a
great
way
to
do.
It
love
the
idea.
F
Yeah,
this
is
a
way,
a
mini
version
of
that
I
think,
is
leverage
quite
effectively
and
in
many
many
other
projects.
You
know,
like
you
know,
helm
core
and
like
or
brew
right
brew
will
have.
I
think
owner
falls.
So
I
think
maybe
that's
rather
than
have
a
blanket
statement
of
two
eyes.
F
You
can
maybe
naturally
get
that
through
heavier
use
of
the
owner's
files
like,
like
maybe
you'd,
add
a
couple
owners
to
the
types.go
direct
or
the
the
api
directory,
and
then
then
then
you,
if
someone's
changing
the
spec,
that's
automatically
get
like
a
lot
of
attention,
because
you
have
like
a
bunch
of
owners
in
there
right.
A
F
No
actually
settings
was
on
my
mind
as
well.
Settings
is
a
big
piece
of
the
user
experience,
so
yeah
no
settings
also
makes
sense
to
me
like
if
that
that
usually
means
you're,
also
introducing
some
new
features
as
well
right,
so
yeah.
A
F
Names
industry,
by
the
way,
I'm
assuming
we're
specifically
talking
about
cd
in
this.
I
think
because
I
think
for
rollouts
just
a
lot
of
times,
it's
hard
enough
to
get
a
second
reviewer
and
let
alone
two
second
reviewers.
I
mean
I
mean
you
know
what
I'm
saying
right
so
and
I
think
I
know
for
for
workflows.
Actually
they
we
just
lost
a
person,
and
so
they
actually
disabled.
They
went
the
opposite
direction
because
they
had
less
people
working
on
it
and
and
they're.
F
Now
I
know
alex
is
merging
in
stuff
for
like
at
least
stock
changes
and
stuff,
like
with,
I
think,
using
administrator
rights
right
now,.
A
F
A
That's
so,
and
I
feel
like
I
feel
and
able
to
kind
of
maintain
the
quality,
and
I
just
don't
have
a
second
person
who
can
yeah,
so
the
choice
right
now
is
basically
either
don't
move
at
all
or
move
quickly,
yeah.
So
having
these
two
choices,
it's
yeah.
A
Yeah-
and
I
guess
it
also
would
have
motivation-
we
spoke
recently
about
maybe
splitting
argo
cd
like
moving
some
code
out
of
the
three
point
or
some
other
ripples
and
it's
another
motivation
to
do
it
like.
Basically,
if
we
see
that
some
parts
of
argo
cd
safe
to
change-
and
they
don't
get
that
much
attention,
maybe
it's
also,
you
know
a
good
candidate
to
be
moved
out
of
the
mainly
point
to
situation.
A
B
F
F
I
think,
if
you
add
owners
to
the
proto
stuff,
the
auto
generated
any
that
actually
is
automatically
you
get
types.code
changes
because
those
affect
the
the
generated
protos,
and
so
that's
one
place
where
you
you
get.
You
detect
changes
to
both
the
api,
as
well
as
the
spec
like
the
types
models.
So
then,
so
we
had
owners
there.
The
configuration
is
a
another
good
one.
I
think
that's
I
forget,
there's
like
a
configuration
package
just
right,
we'll
give
seating
speakage.
Oh
yeah
settings,
that's
right!
F
I
and
then
yeah.
I
would
say
we
start
there
and
then.
F
And
again,
and
keep
going
as
it
see
how
it
works.
F
Yeah
that
one,
I
think
we
our
back
package,
hasn't
really
changed
much.
So,
even
though
we
change
our
like
actually
the
api.
F
Server
is
where
r
back
is
allowing
for
so
it
wouldn't
catch
like
mistakes
in
enforcing
r
back
there.
But
okay,
but
I
would
say
we
start
with
conf
settings
and
and
and
protos.
F
John,
you
want
to
be
on
that
that
ownership
files,
actually
we.
So
I
think
you
can.
I
don't
know
if
github
lets
you
so
you
can
just
add
like
a
bunch
of
people
and
then
I
I
don't
know
how,
if
there's
a
way
to
configure
it
like.
Oh,
you
need
to,
or
from
two
of
the
list.
B
A
B
Yeah,
please
I
I
hope
this
is
maybe
a
little
quicker,
so
I
think
we
we
spoke
about
that
already,
also
so
that
there's
so
many
enhancements
proposals.
So
the
the
usual
github
issues,
the
enhancement
proposals
popping
up
and
and
people
have
lots
of
ideas,
and
I
thought
it
would
be.
It
would
be
great
if
we
can
discuss
those
ideas
like
in
a
formal
round
right
like
in
this
meeting,
so
maybe
take
30
minutes
of
of
the
agenda
to
discuss
the
new
enhancement
items
and
also
introduced.
B
So
I
was,
I
was
looking
at
the
go
project.
Actually
so
they
have,
they
have
a
quite.
I
think
it's
a
quite
nice
process
to
to
identify
the
enhancement
proposals
that
needs
to
be
discussed
and
they
discusses
they
discussed
them,
and
then
they
have
this.
This
multiple
swim
lanes
for
those.
So
when,
when
things
need
discussion,
they
are
moved
into
active,
so
then
they
are
discussed
and
depending
on
those
discussions
on
the
initial
outcomes,
they
move
to
likely
accept
or
likely
decline.
B
And
finally
they
move
it
to
accept
it.
And
when,
when
it's
in
accepted
state,
then
their
process
says
code
can
be
written
for
those
enhancements.
This
would
be
like
the
the
real
large
enhancements.
We
have
the
proposal
pr
process,
but
for
for
for
something
that
wouldn't
require
the
proposal
process
like
all
the
pros,
are
that's
in
there
and
stuff
like
that,
but
still
affects
some
parts
of
of
the
user
experience.
B
Maybe
we
we
don't
have
to
blow
it
up
like
the
go
people
because
they
have
like
you
see
they
have
5k
plus
issues
so,
but
this
this
could
help
us
like.
If,
if
we
want
to
bring
up
some
enhancement
for
discussion,
we
can
move
it
like
into
the
project
into
the
the
incoming
row
and
then
see
in
like.
B
It's
discussed
by
some
people
in
the
community,
not
not
so
much
by
one
of
the
maintainers
and
someone
decides
to
send,
decides
it's
a
great
idea
right
and
sends
a
pr
and
maybe
has
put
lots
of
work
into
the
pr
and
in
the
end
we
have
to
tell
folks.
So
sorry,
all
the
work
was
like
done
for
nothing,
because
we
don't
want
to
have
this
feature
or
for
whatever
reason-
and
this
would
also
be
like
the
indicator
for
the
community-
that
this
enhancement
idea
was
discussed
by
us.
E
So
I
think
one
central
problem
is
that
we
need
some
way
to
distinguish
between
enhancements.
That
folks
are
actually
willing
to
work
on,
like
they
themselves
are
willing
to
contribute
resources
to
make
happen
versus
things
that
people
are
just
opening,
because
they'd
like
to
see
it
as
a
feature
within
argo.
E
Cd
like
it
seems
like
a
lot
of
the
time
folks,
will
open
an
enhancement,
something
that
they'd
really
like
to
see,
but
there's
many
fewer
people,
of
course,
that
have
the
time
or
interest
or
inclination
to
move
through
the
process
to
discuss
the
feature
to
get
requirements
and
implementing
implementation
details
sorted
out
and
then
actually
implementing
it.
So,
like
argo
cd
has,
it
looks
like
481
enhancements
open
the
vast
majority
of
those
don't
have
pr's
attached,
of
course.
A
Know
that
we
willing
to
review
you
know,
changes
for.
A
Let's
say
someone
come
up
with
this
idea
and
and
we
like
it
and
then
we
want
to
encourage
to
work
on
that
feature
and
if
we
somehow
mark
that
proposal,
as
you
know,
kind
of
a
welcome
enhancement,
then
people
would
want
to
work
on
it
and
and
but
I
totally
didn't
think
about
how
do
we
even
decide
if
we
like
that
feature
or
not-
and
maybe
you
know-
maybe
we
don't
have
to
you
know
if,
if
some,
if
person
don't
even
tell
us
that
he's
willing
to
he
or
she
willing
to
work
on
it,
we
still
can
discuss
that
proposal.
A
B
Yeah
and-
and
I
think
so
we
we-
we
may
catch
those
issues
so
that
require
a
real
proposal
process.
B
A
F
A
A
A
Would
we
use
it
just
as
a
tool
to
to
make
sure
we?
A
You
have
a
list
of
everything
which
has
to
be
trashed
and
then
a
person
would
like
maybe
some
kind
of
rotation,
and
you
know
that
the
person
who
is
responsible
for
preaching
would
have
to
move
one
of
these
proposals
from
incoming
into
either
active
or
just
just
decline
or,
if
necessary,
bring
up
it
into
in
that
meeting
and
kind
of
together.
We
can
decide
where
the
proposal
should
go.
E
A
Which
is
not
so
much
right,
it's
okay,
like
we
could
maybe
discuss.
Usually
not
all
seven
requires
a
thorough
discussion.
Some
of
them
would
be
duplicate
some
of
them.
We
know
so.
A
Just
start
with
that,
you
know
just
make
sure
we
have
a
list
of
those
to
to
be
discussed,
and
then
there
is
your
10
minutes
to
discuss
potentially
up
to
seven
proposals,
and
if
discussion
takes
too
long,
then
we
particularly
kind
of.
E
C
I
think
we
definitely
need
an
effort
which
should
be
a
mixed
of
you
know,
mix
between
the
maintainers
and
somebody
who's
not
not
to
maintainer
to
actually
go
through
the
full
list
of
proposals
and
at
least
eliminate
some
of
them,
which
are
no
longer
valid
as
a
starting
point
and
then,
of
course,
the
next
step
would
be
to
start
bringing
them
up
in
these
meetings.
If
they
are
to
be
discussed
or,
as
alex
said,
not
every
proposal
needs
to
be
discussed
here.
C
Some
of
them
could
be
a
conversation
on
github
itself
and
that's
fine,
but
they
should
be
triaged
in
some
manner,
which
means
this
proposal
is
valid.
We
want
to
look
at
it
in
future,
or
this
proposal
is
not
valid
anymore
either,
because
it's
done
or
it's
totally
off
track,
and
we
don't
need
to
be
looking
at
it,
and
we
just
add
a
comment
and
close.
It.
A
F
To
go,
do
it?
Oh,
that's
a
good
thing
about
prs,
because
if
it
I
mean
a
lot
of
times,
people
jump
straight
to
pr
without
even
filing
an
issue
about
it,
and
so
it's
like
you,
you
just
come
in
with
the
both
the
code
and
the
feet
and
the
description
of
the
enhancement
in
the
same
thing.
Does
this
model
work
for
that
as
well?.
B
B
B
Some
people
ignore
it
for
whatever
maybe
they
haven't,
read
it
or
they
think
so.
But
that's
I
I
would
say
that's
their
risk.
You
know
I
mean
they're,
doing
work
so
and
they're
doing
it
for
good,
so
they
want
to
submit
code
to
rocd
which
which
implements
a
feature
right
or
fix
a
bug.
Something
like
that
and
and
they
they
do
the
work,
probably
in
their
free
time,
spend
some
good
hours
developing
that.
F
But
I
think
if,
as
long
as
the
pr
can
they
can
they
get
into
this
project
view.
E
F
Yeah,
but
I
think
it's
if
we
can
still
do
that,
then.
F
Yeah,
no,
no,
it's
a
good
thing.
If
we
can
do
that
because
then
then
the
process
still
works
like
I
think,
if,
even
though
we
tried
to
discourage
it,
if
someone
comes
in
with
the
pr
off
the
bat
for
enhancement
at
least,
we
can
still
apply
the
process
to
it.
By
and
actually
I
mean
we'll
say,
hey,
this
needs
to
be
discussed
and
approved
before
we
move
forward
for
this
just
fyi
and
then
and
then
it
goes
into
this
column
board.
E
F
Like
that,
I
think
I
I
don't
like
to
apply
that
for
for,
for
things
like
bug,
fixes
a
lot
in
in
smaller
things,
I'm
actually
okay,
with
coming
in
straight
with
pr,
but
for
usually
for
enhancements.
I
I
go
the
opposite.
I
I
usually
prefer
that
to
be
an
issue
before
anything
else,.
B
And
it
actually,
it
is
part
of
the
of
the
pr
template
and
it's
also
it's
also
in
the
contribution
guides,
but
it's
it's
formulated
rather
weak.
So
it's
it's
more
like
a
pledge
than
a
rule,
so.
C
Yeah
and
and
with
respect
to
the
fact
that
we
have
a
huge
volume
of
prs
and
issues
that
are
very
old,
and
I
think
this
is
something
that
we
did
get
started
a
while
ago,
and
I
think
the
right
frequency
of
you
know
getting
to
those
issues
prs
would
be
maybe
once
a
release.
C
The
main
reason,
I'm
saying
that
is
because
we
have
newer
issues
coming
in
which
are
significantly
more
relevant
than
something
that
is
two
years
old.
So
we
need
to
still
be
on
top
of
the
ones
that
are
coming
in
now.
A
good
balance
would
be
take
a
look
at
it
once
a
release
like
we
did,
I
think,
alex,
and
I
did
go
through
it
during
one
of
the
sessions
and
we
basically
covered
a
good
deal
there.
C
So
once
a
release,
we
need
to
take
a
look
at
the
old
stuff
and
see
if
they
fit
into
the
upcoming
release
when
we
plan
it
prior
to
that,
if
something
is
really
old
and
hasn't
been
looked
into,
we
should
really
make
an
announcement
in
the
community
meeting
that
we
are
going
to
plan
the
release
in
the
upcoming
weeks.
Please
call
out
if
a
github
issue
or
a
proposal
you've
made
a
while
ago,
hasn't
been
taken
in
at
least
that
way.
C
People
may
be
able
to
surface
something,
that's
really
old
to
us,
and
we
may
consider
that
instead
of
us,
you
know
spending
the
next
three
or
four
meetings
just
to
go
through
the
huge
backlog
of
issues
that
we
already
have,
which
again
may
not
all
be
relevant
at
all,
because
they're,
really
old.
F
Yeah,
I
like
my
idea,
because
it
almost
self
organizes
the
priorities,
so
I
I
think
also
because
we
tend
to
use
like
you
know,
activity
and
thumbs
up
and
stuff
on
issues
like
one
kind
of
automated
way
we
can
help
facilitate.
F
Is
that
as
we
announce
this
planning
for
the
next
released
activity,
maybe
the
action
users
can
do
is
like
to
thumbs
up
things,
and
I
don't
some
some
automated
thing
that
will
get
our
eyes
on
like
sorting
it
in
in
a
way
that
we
can
do
it,
because
we're
not
going
to
be
able
to
get
the
400
issues
and
right
yeah.
Precisely.
I.
A
F
A
C
F
Probably
don't
know
to
look
at
because
we're
probably
right
now
we're
only
looking
at
the
res
or
what
we're
proposing
is
that
we're
going
to
be
looking
at
incoming
stuff
and
trying
to
just
keep
up
at
the
same
time
we
want.
We
need
a
way
to
kind
of
look
at
the
older
stuff,
and
then
the
community
can
help
us
with
that.
Somehow
I
was
suggesting
thumbs
up,
although
that
can
be
flawed.
I
don't
know
what
a
good
mechanism
for
that
voting
would
be,
but
yeah
something
yeah.
C
I
mean
in
in
in
general.
I
wouldn't
even
think
that
a
lot
of
people
would
need
to
vote,
because
let's
say
we
go
to
the
committee
meeting
and
say
hey
if
you
have
opened
an
issue
a
while
ago,
and
we
need
to
do
this
a
few
times
a
while
ago,
which
hasn't
been
looked
at,
and
we
basically
do
this
in
slack
and
everywhere
else,
and
you
still
still
think
this
is
relevant.
C
C
That's
one
and
I
think
let's
say
we
do
this
exercise
and
nobody
comes
forward
with
any
old
issues
out
there
and
that's
a
possibility,
because
somebody
may
be
reported
a
year
and
a
half
ago,
and
then
they
moved
on
to
a
different
project,
but
what
they
proposed
is
still
valid
so
which
means
once
a
release.
Just
like
you
know
alex,
and
I
did
last
time
you
know
we
went
through
the
old
ones
created
a
list
took
care
of
them
and
then
we
moved
on
we'll
do
the
same
thing.
C
If
nobody
points
out
old
issues
that
need
to
be
taken.
A
look
at
once
prior
to
the
release,
planning
alex
and
I
can
go
through
them-
go,
go
through
a
finite
list
that
is
humanly
possible
and
then
we'll
just
move
on
again.
So
this
way
you
know
in
a
few
releases,
we
can
hope
that
the
backlog
is
well
taken
care
of,
even
if
nobody
responds
from
the
community
with
their
old
issues.
E
A
F
That
it
started
closing
issues
that
I
filed
that,
like
that
they
were
always
on
my
like
to-do
list
but
and
then
that
I
felt
were
important,
and
so
we
didn't
like
for
a
while
that
it
was
like
closing
stuff
that
you
know
we
we
knew
we
wanted
to
do
eventually.
You
know
now
I've
kind
of
flipped
the
other
way.
I
think
it's
which
I
think
it
should
be
part
of
the
process,
but
I
just
want
to
get.
F
A
F
Okay
is
that
is
that
the
end
of
the
columns?
Yes,
okay,
so
so,
basically,
once
an
issue
gets
through
the
in
there
there
and
the
last
they're
in
the
accepted
column,
so
there's
actually
171
issues
in
this
case
from
that
from
these
171
only
if
some
of
them
will
get
into
the
next
release.
So
this
would
help
us
with
release
planning
right.
Basically,
we've
done
the
triage
on
whether
or
not
it's
a
good
idea.
I
think
like
I
guess
we
would.
F
F
A
Is
way
less
than
go
so
right
that
it
in
that
discussion
we
would
not
just
agree
whether
we
like
it
or
not.
We
also
might
find
a
person
who
is
willing
to
kind
of
review
and
test
and
kind
of
be
an
owner
of
that
feature,
especially
if
contribution
came
from
outside.
You
still
need
someone,
you
know
from
maintenance
to
kind
of
be
responsible
for
the
future,
and
basically
you
know
if
we
move
it
into
active
state,
I
would
expect
to
assign
it
to
someone
or.
F
A
To
okay,
no,
not
not!
Okay,
I
don't
know,
let
me
take
it
back.
I
don't
know
how
exactly
we
would
mark
it,
but
like
someone
from
maintainers
would
maybe
comment
on
that
issue
and
say
that
yeah
I
want
to
I'm
willing
to
spend
time
and
help
you
to
get
it
done,
and
that
includes
review
and
discussion
and
you
know
kind
of
it's
not
requirement,
but
I'm
just
saying
in
that
meeting
we
can
discuss
it
as
a
community
and
we
can
vote
that.
We
like
that
feature.
F
Oh,
so
I
think
that
process
would
be
just
part
of
the
all
right
to,
in
my
mind,
right
now,
we're
separating
just
the
this
is
essentially
backlogged
grooming.
If
yes-
but
I
think
you
apply
the
process
you're
thinking
about
once
it's
in
that
accepted
state
and
it's
you
know,
gonna
be
part
of
a
release.
So
at
that
point
in
time,
then
then
we
need
like
someone
to
code
it
and
okay,
you
think
basically
kind
of
two
stages.
If
it's,
I
guess,
active
or
active,
I
thought
this
is
in
the
discussion.
B
Yeah
right
so
so
I
I
got
to
this
because
I
sent
an
enhancement
proposal
to
to
go
so.
B
I
saw
that
someone
put
the
proposal
attack
on
it
and
then
I
went
to
this
board
and
they
have
us
a
documentation
on
their
processes,
and
this
is
correct.
So,
if
the,
if
it's
in
the
proposal
in
the
most
left
column,
it's
just
an
issue
on
github
and
if
it's
moved
to
active,
it
indicates
that
a
a
round
of
people
will
talk
about
this
issue
and
decide
whether
it's
accepted
or
not
or
will
be
accepted
or
not.
B
A
F
B
F
Maybe
yeah
so
the
the
reason
I
think
it
might
be
better
to
keep
them
separate
is
because
I
I
feel
like
people
outside
the
this
could
get
a
let's
say.
I'm.
I
want
to
contribute
to
the
project
myself
and
I
want
to
pick
up
issues
so
I
mean
the
first
problem.
A
lot
of
people
have
is
what
should
I
work
on
and
I
think
if
they
pick
from,
you
know
accepted
pool
of
of
things.
F
That's
already
a
good
start,
because
we
vetted
the
idea
out,
and
so
there's
not
they're
not
going
to
waste
time
working
on
something
that
ultimately
might
not
get
accepted,
but
and
but
another,
and
then,
when
we're
actually
doing
the
release,
we
also
are
picking
from
the
same
pool,
but
we
are
just
essentially
by
having
a
release
process,
we're
prioritizing
we
okay,
these
are
things
we
need
to
get
soon
done
sooner
rather
than
later,
and
then
we're
also
picking
from
that
same
accepted
poll.
F
So
that's
that's
my
thought
around
keeping
the
release
this
strictly
for
triaging
of
ideas
and
then
but
the
release
is
just
basically
we're
just
taking
accepted
stuff
tagging
it
to
a
milestone
and
that's
kind
of
like
our
release,
planning.
A
F
I
I
think
it
makes
release
the
deciding
what
gets
into
releasing
much
simpler,
because
you've
already
kind
of
done
a
lot
of
the
grooming
ahead
of
time,
and
so
when
you're
planning
you're
just
kind
of
picking
from
already
a
groomed
list
of
accepted
proposals.
It's
just
you
know,
which
ones
do
you
want
to
get
done
next.
A
A
You
know
in
that
meeting
we
don't
want
to
go
back
in
time
and
see
what
should
be
active
right.
Is
it
kind
of
basically
one
proposal
if
you
identify
component
owners
every
time
you
get
then
you're
automatically
kind
of
splitting
work,
maybe
like
once
a
week,
we
get
one
proposal
to
improve
api,
another
proposal
to
improve
security
and
basically,
if
we
have
owner
for
each
area,
that
means
there
is
not
so
much
work
and
we
can
just
owners
can
commit
to
do
the
triaging.
F
Oh,
I
see
so
you're
actually
saying
one
way
to
split
divvy
up
the
work
is
that
when
we
now
that
we
are
agreeing
to
start
using
code
owners,
is
that,
yes,
how
would
they
know
to
to.
A
C
That
person
should
just
go,
and
you
know,
but
should
have
the
powers
to
be
able
to
label
issues,
because
that
will
help
us
assign
that
person
who
is
a
volunteer
in
this
group
will
go
in
and
mark
different
issues
for
the
respective
areas
when
things
go,
fine,
which
means
something
gets
marked
for
ui.
Let's
say
all
good,
but
let's
say
if
something
gets
marked
for
a
component
or
area
which
is
incorrect.
C
The
corresponding
component
owner
can
flag
that
saying:
hey
you
put
something
on
my
bucket,
but
it
looks
like
it's
on
somebody
else's
bucket,
but
the
chances
are
that
it
70
to
80
percent
us.
You
know
the
groupings
should
work,
fine
and
that
way
what
we
are
effectively
doing
is.
We
are
ensuring
that
the
owners
don't
have
too
many
responsibilities,
because
well
reviewing
prs
in
their
area
is
already
a
big
responsibility.
C
Rather
somebody
else
gets
to
step
in
and
also
learn
the
code
base
and,
potentially
you
know,
help
out
the
peer
reviewers
eventually
as
well,
because
right
now
they're
actively
looking
at
issues.
But
then
what
this
means
is
in
this
meeting.
We
need
to
make
another
assignment
like
we
do
for
question
answers.
B
C
B
Yeah
no,
but
but
we
we
do
have
to
have
to
fix
bucket
size
on
the
active
list.
Okay,
yeah.
C
B
Yeah,
that's
what
we're
going
to
discuss
so
or
hope
to
get
done
to
discuss
in
one
session
right
so
sure.
A
B
B
Yeah,
I
I
like
it.
So
if
you
create
a
project-
and
maybe
you
can
create
a
a
google
doc
or
something
like
that,
where
we
can
collaborate
on
defining
the
process,
writing
it
down.
So
this
process
is
actually
ultimately
gonna
get
in
the.
F
G
A
E
E
To
github
permissions
differ
between
those
two
and
just
something
to
take
a
look
at.
C
A
F
Okay
thanks
first,
I
have
to
drop
off,
but
and
next
yeah.
We
we're
gonna
present
on
the
enhancement
proposal
for
argos,
extending
giving
people
a
way
to
extend
argo
cd.
They
like
incorporate
their
own
ui
components
or,
and
so
remington
alex,
and
I
are
been
putting
ideas
onto
paper,
so
that
will
be
on
the
agenda
for
next
week.