►
From YouTube: SIG Release backlog prioritization
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
You
so
yeah
I'm
not
how
to
present
clear
on
the
intro,
but
my
name
is
Larry
Apple
and
I'm
coming
to
you
live
from
Berlin
where
today
going
to
spend
an
hour
doing
a
prioritization
session
for
how
the
release
team
can
improve
the
release
cycle,
happy
path,
and
we
have
already
done
some
work
on
this
through
the
spreadsheet
that
we'll
look
at
in
a
minute,
and
all
of
you
have
been
so
great
and
marking
the
items
that
you
consider
high
priority
for
the
release
team.
So
thank
you
for
your
participation
and
your
time.
A
We
are
here
to
be
excellent
to
each
others,
so
we
have
a
code
of
conduct
and
so
please
we'll
all
be
respectful
and
listen
to
each
other
and
have
a
good
experience
and
Jarmo.
If
I
miss
anything,
you
can
hopefully
yep.
That's
it
good
all
right
so
just
see
it
I
started.
So
this
is
the
fourth
session
and
I
have
noticed
that.
A
Well,
the
second
session
had
the
same
number
of
people
and
in
that
session
we
finished
10
minutes
early
on
yesterday's
session
same
number
of
people,
and
we
got
maybe
one
third
of
the
way
through
the
list
and
we
will
do
a
follow-up
session.
So
that's
a
way
to
say
that
these
sessions
can
vary
depending
on
you
know
and
what
you
feel
you
need
to
discuss.
A
So
if
we
are
going
slowly
like
we
did
yesterday
at
the
midway
point,
I
will
stop
and
give
us
a
chance
to
take
the
temperature
and
say
if
we
either
want
to
continue
going
at
that
pace
or
if
we
want
to
actually
think
about
having
a
follow-up
session
or
there
might
be
another
option
at
one
who
comes
up
with
for
getting
through
the
body
of
the
work
yeah
all
right.
So
is
anybody
here,
I'm
gonna
start
sharing
the
spreadsheet
OOP
I
could
not
get.
C
You've,
hello,
everyone.
This
is
my
first
meeting
on
on
such
initiatives
and
it
is
my
first
shadow
exercise
as
well
on
the
CI
signal,
so
I
added
the
comment
based
on
my
understanding
and
again
excuse
any
new
terminologies
from
you
or
anything.
That
is
that
we'll
be
saying,
but
this
is
my
first
interaction,
so
I
believe
the
item
on
that
board
is
critical.
For
us.
C
We
have
some
tests
that
are
failing
failing
for
a
long
time
without
any
action,
so
I
believe
it
is
critical
for
any
release,
moving
forward
that
you
are
taking
the
items
or
the
issues
that
you
are
listing
on.
The
CI
signal
board
like
a
little
bit
of
being
critical
for
any
release
because
they
are
in
a
sense.
They
are
issues
that
are
actually
either
a
flaky
test
or
feeling
test
that
maybe
something
like
Windows
just
being
feeling
for
for
long
without
any
proper
fix
for
them.
C
C
The
reporter,
as
well,
is
critical
for
us.
As
of
now
we
are
giving
the
status
casually
in
terms
of
if
we
have
certain
items
that
is
blocking
or
certain
items
that
is
failing.
However,
I
am
more
convinced
that,
having
reports,
it
is
worth
of
the
status
added
to
the
status
report,
maybe
generated
by
some
of
the
sample
tools
that
being
referred
in
here
or
even
follow
certain
format.
It
can
be
something
of
a
well
documented
approach,
so
at
least
give
us
the
indicator
around
the
release
around
the
test.
C
So
I
believe
the
sub-project
are
critical
and
I
will
talk
about
my
experience
since
I
joined
CI
signal.
There
are
a
lot
of
areas
that
we
learn
it
on
the
go
that
may
have
been
streamed
line
if
we
have
this
as
a
process
or
as
a
tool
or
as
a
sub-project
to
enhance
this
and
the
idea
is
I
believe
the
sub-project.
That's
why
I
added
sub-project
to
record
a
little
bit
of
longer
commitment
from
the
existing
shadows
and
the
moving
forward
until
we
have
this
project
graduated
and
being
used
for
the
subsequent
release
cycles?
C
That's
the
only
challenge
that
I
see
I
I,
believe
in
the
value,
but
the
time
and
the
effort
that
will
need
to
be
added
to
the
sub
project
may
be
a
little
bit
overwhelming
for
the
team
members
and
required
a
little
bit
of
longer
commitment
from
the
team.
So
if
we
start
at
something,
we
have
to
finish
it
and
that's
the
whole
purpose
of
it.
That's
why
I
added
should
but
I
believe
in
in
having
those
sub
project.
We
started
doing
a
little
bit
of
improvement.
C
We
may
not
call
them
as
a
sub
project,
but
some
sort
of
improvement
from
a
CI
shadow,
given
that
you
are
diverse
and
a
lot
of
people
are
new,
so
become
adding
a
little
bit
of
improvement.
Thinking
about
some
ideas
and
some
project
to
be
done.
However,
the
time
and
the
effort
may
be
the
only
the
only
limitation
that
we
have.
C
D
I
went
and
read
the
I,
just
read
the
information
about
it
and
then
went
and
looked
at
some
of
the
stuff
in
me
and
the
actual
github
page
and
I
just
thought.
I.
Think
anytime,
that
there's
a
way
that
you
can
streamline
a
process,
that's
really
people
oriented
I,
don't
think
we
should
have
to
by
any
means.
I
guess
especially
I
also
have
a
shadows
perspective.
So
anything
that
I
feel
like
is
going
to
enable
I
guess.
D
So
that's
one
that
we
could
call
that
a
muster
should
I,
don't
know
just
because
relative
to
just
to
be
frank,
there's
a
lot
about
the
project
that
I
still
don't
know,
I'm
signing
it
a
good
gauge
of
like
over
time
what
has
been
high
priority.
So
I
would
just
say
this
is
something
I
think
you
should
do
from
my
perspective,
but
I
must
relative
to
probably
some
other
priorities.
Okay,.
A
We'll
put
it
first
good
for
now
and
by
the
way
this
came
up
yesterday,
it's
because
something
is
a:
must
we're
not
gonna
go
in
a
spine
work
to
anybody.
This
is
just
your
reads
on
things,
so
we're
not
gonna
go
and
if
angel
has
to
is
involved
in
something
for
the
Hawks,
we're
not
gonna,
go
and
say,
hey
Jim.
You
need
to
do
this,
so
it's
just
more
about
like,
generally
speaking,
we
really
should
make
this
change
to
make
the
process
better.
So
before
we
get
too
far
into
that
no
one's
assigning
work.
A
E
Yes,
so
when
it
comes
so
yeah
I
mentioned
all
right
set
a
few
definitions.
I
had
problem
with
at
the
beginning
and,
to
be
honest,
just
recently,
I
found
all
the
definitions
for
those
like
alpha
beta,
stable
stages,
but
still,
and
they
look
pretty
reasonable,
but
I
still
don't
think
they
are
official
yet
because
what
I
can
read,
for
example,
is
that
alpha
means
experimental
feature
that
does
not
require
documentation,
while
tests
are
nice
to
have
so.
E
E
Are
also
those
those
other
terms
like
relates
to
stage
statuses,
there
are
state
statuses
like
graduating
and
the
other
one
is
I.
Think,
for
example,
major
change,
I
still
don't
know
the
difference
and
actually
I
still
don't
know
whether
they
are
important
and
well.
What
is
the
reason
they
are
there
in
the
tracking
sheet.
A
B
I
have
pretty
much
the
same
comments,
I
think
it's
so
I
did
enhancements
a
couple
times
and
I
feel
like
every
time
we
got
to
a
to
alpha
and
sometimes
beta
issues.
It
was
kind
of
up
to
us
to
determine
whether
things
met
the
criteria
or
not.
You
know
we
would
debate
like.
Is
that
enough
testing,
or
is
that
not
enough
testing?
Is
that
a
good
enough
set
of
Docs
or
not
so
it's
kind
of
subjective
I
think
that
it
could
be
a
little
more
crisply
defined
kind
of
session
on
what
Miroslav
said
is.
B
Is
it
required
to
only
have
units
have
seen
or
are
the
testing
things
we're
talking
about
like
and
and
conformance
tests?
Things
like
that
I
mean
would
be
good
to
to
clarify
that
and
define
it
a
little
bit
more
and
then
again,
like
with
the
statuses
I,
think
it's
kind
of
up
to
the
enhancements
team
to
determine
what
they
track,
especially
along
the
major
change
thing.
I
think
we
tend
to
track
the
major
change
things
so
like
if
something's
gonna
stay
in
beta,
but
there's
gonna
be
a
major
change
to
the
API.
B
We
generally
tracked
that,
but
again
it's
I
think
in
terms
of
the
enhancements
process
and
like
the
handbook
for
the
team,
we
could
probably
clarify
that
a
little
bit
more.
So
there's
probably
like
a
bit
of
clarification
that
can
happen
for
the
enhancements
process
itself,
like
what's
the
actual
graduation
right
here,
but
also
some
more
refinement
to
the
handbook
about
like
what
what
things
we
should
actually
track
or
not
care
about
part
of
the
under
arching
problem.
I
have
with
the
enhancement
process
now.
Is
that
it's
up?
B
You
know
people
open
an
issue,
they
come
and
go,
and
it's
hard
for
people
to
if
you're,
not
the
original
author
of
that
or
even
have
commit
access
the
right
access
to
the
repo.
You
can't
go
and
change
the
metadata.
That's
at
the
front
of
the
issue,
so
then
that
stuff
kind
of
gets
dropped
into
comments.
B
It's
up
to
the
enhancements
team
to
kind
of
scroll
through
those
things
and
reconcile
like.
Is
this
going
to
two
beta,
or
is
this
going
to
stay
in
beta,
or
is
this
going
to
graduate
disabled
and
it's
it's
very
manual
that
process
and
I
think
that
doesn't
help
the
fact
that
it's
kind
of
vague
in
some
cases
mm-hmm
it's
just
like
a
compounding
factor.
B
Think
I
think
it
should
maybe
like
a
weak,
must
strong
should.
F
I
just
want
to
add
on
because
I
was
also
and
I'm
in
hamsa
and
shadows
few
releases
ago
with
Jeremy,
but
just
hearing
both
of
you
talk
about
it.
I
think
it
kind
of
becomes
a
must,
because
I
remember,
we
have
to
go
back
and
forth
a
lot
to
other,
to
the
enhancement
out
to
the
people
who
made
the
enhancement
by
requesting.
We
had
to
go
back
and
forth
saying
that.
F
Oh,
this
does
not
meet
this
criteria
and
you
need
to
have
this
for
beta
or
alpha
or
seeable
and
I,
just
don't
think
it's
very
clear
and
that
kind
of
ruins
the
whole,
like
purpose
of
people
contributing
and
adding
a
feature
to
kubernetes
in
my
opinion.
So
maybe
it
is
a
must
and
it
needs
to
be
clarified
a
little
bit
more
yeah.
B
A
Gonna
flex,
something
too
and
there's
an
enhancements
meeting
that
is
to
be
scheduled
soon.
Announcer,
Bob
and
I
were
talking
about
it
yesterday
and
so
perhaps,
as
we
go
through
the
list
of
the
items
we
also
like
to
get
through
some
of
them
faster
right
now
we
can
flag
of
those
items
is
what
we
should
discuss
in
the
enhancements
meeting.
Yeah.
A
We
put
them
in
that
channel
so,
but
I
would
think
that
this
one
we
can
we
can
flag
is
is
one
of
those
what
I'll
do
is
I'll
highlight
it
in
yellow
and
then
I'll
just
signal
to
myself.
Afterwards,
we
can
collect
all
of
it
into
the
a
place
and
then
try
to
get
that
on
that
agenda.
For
that
next
enhance
to
this
meeting.
A
B
B
B
We
might
be
pinging
the
wrong
person
and
we
don't
get
a
good
response
because
of
that
to
the
people
that
do
open
those
those
issues
and
those
caps
like
we're
deferring
to
them
to
determine
if
that
should
be
in
the
release
or
not
and
I,
don't
think
we
always
get
the
buy-in
from
The
Associated
cig,
like
the
the
PR,
the
the
cap
may
have
been
merged,
but
they
don't
necessarily
vet
that,
like
they're
gonna,
have
bandwidth
to
review
all
the
PRS
there's
no
stated
with
it.
A
good
example
is
the
side
cars
kept.
B
That
went
for
like
several
releases.
We're
like
oh
yeah,
we're
gonna
include
this
and
you
know
it's
it's
up
to
to
just
I
think
was
Joseph,
we're
bringing
him
and
he's.
He
would
say.
Yes,
I
think
this
is
going
to
make
it
and
this
release
I
have
a
PR
open,
just
waiting
for
API
reviews
or
waiting
for
X
reviews,
but
like
at
the
end
of
the
day.
B
It
was
really
not
really
approved
by
the
appropriate
SIG's
I
get
the
D
cap
was
merged,
probably
shouldn't
have
been
merged
at
that
point,
but
it
was
merged
and
then
the
PR
was
open
in
it
like
he
did
a
hero's
work
of
keeping
that
thing
rebased
from
release
to
release
release
because
it
was
like
116
117
118
that
would
be
included
in
the
release,
and
then
it
wouldn't
get
past
the
the
final
code
reviews,
so
it
wouldn't
hit
code.
Freeze,
I
think
that
process
is
just
could
be
clarified.
B
B
That's
kind
of
like
Bob
had
an
idea
for
like
what
a
ticketing
system
might
look
like
for
something
getting
included
in
the
release,
and
that
would
be
more
like
you
have
to
open
a
PR
and
like
a
ticket,
gets
created
inside
of
a
directory
and
I.
Think
that
it
would,
you
know,
be
a
little
bit
more
explicit
that
something's
gonna
be
included,
because
what
have
to
be
approved
by
like
that
owning
saying.
F
A
And
it's
also
marked
that
this
is
a
must
in
Kendall
to
so
we're
driving
some
some
important
context,
clarification
some.
We
are
about
third
through
the
hours,
so
I
just
wanted
to
call
out
time
we
can
on
to
the
next
item,
which
is
another
enhancements,
I
didn't
unless
anybody
has
any
more
comments,
they
really
want
to
share.
At
this
time.
A
D
See
I
think
the
enhancement
tracking
will
also
be
a
benefit
from
like
a
comms
perspective
as
well.
Just
because,
when
we're
reaching
out
about
like
feature
blogs
and
things
like
that,
I
think
there's
some.
You
know,
there's
not
always
clarity
around.
What
features
are
actually
going
to
be
in
that
release
and
so
I
think.
D
A
A
A
B
I
mean
I
think
the
the
sheet
has
kind
of
organically
grown
and,
as
the
team
goes
through
each
cycle,
there
was
like
an
incremental
improvements
made,
including
some
automation
in
this
in
the
sheet,
which
is
pretty
awesome
but
I
think
spreadsheets
aren't
the
best
tool
for
that
job.
I
think
as
we
as
we
refine.
What
enhancements
look
like
we've
gone
to
like
having
more
metadata,
and
things
are
more
like
checkable
and
validated
well.
B
I
think
that
it
would
be
good
to
to
use
something
like
this
caps
ETL
tool
that
we've
kind
of
but
I
think
it's
really
really
important
that
we
have.
We
treat
it
like
a
real
project
and
we
have
a
good
road
map
for
what
its
gonna
look
like,
so
that
we
can
a
make
sure
we're
making
progress
but
B.
We
can
solicit
contributors
and
make
sure
that's
not
just
like
Jeremy
Bob
show
making
the
tool
yeah.
A
We're
on
our
way
to
that
already
yeah
yeah,
would
you
say:
master
should
yeah
the
most
and
Kendall
and
there's
what
also
has
access
Kendall
you
wanna
go
I,
don't.
E
A
E
G
A
F
I
think
mostly
when
I
was
an
enhancement,
shadow
I
think
I
ran
into
a
lot
of
issues
where
people
didn't
understand
like
how
to
enter
features
into
a
milestone.
I
think
like
and
I
know,
the
milestone
label
specifically
is
managed
by
the
release
team,
but
I
seen
a
lot
of
people
actually
remove
it
themselves
or
audit
themselves,
which
is
I.
Think
it's
a
problem
in
my
opinion
and
I.
Think
specifically,
that
is
what
concerns
me.
I'm,
not
sure.
If
anyone
else
agrees
with
that,
I.
B
Mean
there
are
more
people
than
just
the
release
team
that
are
in
that
milestone,
maintainer
x'
team
and
people
from
the
leads
of
the
SIG's.
Do
it
sometimes
I
think
it?
It's
I,
think
it's
okay!
If
they
do
that
as
long
as
we
have
an
understanding,
we
communicating
with
them
actively
I,
don't
think
that
all
always
happens,
I
think
just
you
know,
given
human
nature,
people
do
things
and
they
don't
always
communicate
what
they're
doing
yes,.
A
F
A
D
One
I
just
think
like
in
general,
as
a
shadow
that
came
in
on
the
calm
side
like
it,
it's
not
as
involved
in
the
actual
ongoing
I
guess,
phases
of
the
project
and
so
I
think
having
more
clarity
around
some
of
the
other
things
that
we're
talking
about
in
all
of
these
meetings.
That
I'm
sitting
in
that
maybe
are
like
a
bit
mystical
to
me.
I'm
like
okay.
What
are
we
talking
about
here?
D
A
All
right
so
we're
a
halfway
at
the
hour,
so
we
have
three
options.
We
can
keep
going
at
this
pace
and
schedule
a
second
session.
We
can
keep
going
at
this
pace
and
just
run
out
of
time.
I
guess
we
have
four
our
options.
We
can
also
go
faster
and
just
try
to
run
through
all
of
the
things
or
we
could
just
have.
A
Everyone
highlights
comments
that
they
really
want
to
point
out
so
like
we
can
continue
going
down
the
list
but
say
like
oh
I
want
to
speak
up
on
this
on
my
comment:
I
want
to
make
sure
that
I
draw
attention
to
it
or
I
have
a
question
about
it.
So
I
can't
see
you,
but
who
wants
to
have
the
second
session?
Can
you
put
your
comments
there
in
the
chat.
A
A
That's
all
right:
I
guess
we
have
a
quorum.
We
have
a
majority,
okay,
all
right,
second
session.
It
is,
and
I'm
gonna
nominate
Jeremy
to
be
our
Zoomer,
so
we
can
just
kind
of
wrap
that
up
and
then
we
can
just
keep.
This
group
also
sent.
Invite
specifically
to
this
group
will
have
to
agree
on
the
day
and
the
time,
but
we'll
keep
the
continuity.
A
D
A
E
I
think
we
covered
most
of
the
things
from
my
point
of
view,
at
least
that
are
here
mentioned
that
item
when
we
discussed
the
item
number
seven.
So
it's
about
like
glossary
of
terms,
so
definitions
of
terms
and
also
like
entry
and
exit
criteria.
What
what
does
it
mean
that
in
enhancement
has
to
have
tests
yeah?
It's.
D
A
B
B
A
B
A
B
I
think
you
know
we
need
a
schedule.
We
need
to
start
scheduling
the
enhancements
meetings.
I
have
an
action
item
to
make
a
doodle
for
that.
B
But
I
think
it's
I
think
it's
important
for
us
to
start
having
those
just
to
to
get
a
better
handle
on
the
process.
Do.
G
A
Effort
in
the
last
couple
weeks-
and
it
would
be
great
to
synchronize
with
them
and
get
them
home.
Alright,
so
I'm,
just
going
down
I
have
a
little
empty
space
and
then
now
yeah.
This
one
was
a
hot
I.
Just
want
to
I,
didn't
miss
any
Exodus.
I,
don't
think
I
did
nope,
okay,
they're,
making
the
cups,
transparent,
Anna
and
miroslav.
What
would
you
like
to
have
happen.
F
F
F
E
B
I
think
that's
a
plus
one.
For
me,
too
John
commented
on
my
my
cap
CTL
work
in
progress,
PR
that
he
he
taken
Brett
or
he
had
taken
the
branch
and
doctor
query
command.
On
top
of
it,
I
think
that
the
I
think
we
have
a
lot
of
opportunity
to
to
build
supporting
stuff
around
it.
I
mean
you
think.
Oh
it's
just
some.
B
Some
marks
some
mark
down
in
some
yeah
mo
like
any
tooling
around
it,
but
the
work
floor
on
this
I
think
is
complex
enough
that,
and
it's
touched
by
so
many
people
that
I
think
it
does
need
some
work
flow,
but
also
for
people
coming
from
the
community.
It's
it's
not
super
easy
to
like
click
around
and
github
and
say
like
oh,
maybe
this
thing's
under
stick
architecture,
or
maybe
this
thing's
under
signo.
B
A
F
So
I
don't
know
how
to
handle
this,
but
I
know
there's
a
lot
of
issues
in
PR,
that's
out
there
and
when
we
ping
them
about
just
anything
in
Hinzman,
going
like
any
dogs
or
anything
like
that.
We
don't
really
get
response
from
those
people
and
the
thing
is
when
we
do
have
a
bot
that
removes
that
label.
So
that's
a
steal,
but
a
lot
of
people
just
go
there
and
remove
this
deal
like
and
then
nothing
happens
afterwards.
A
It's
just
yeah:
it
adds
in
a
human
talks
to
that
efforts.
It's
especially
for,
like
the
release
team,
you're
trying
to
get
the
release
out
and
you
don't
need
that
attacks.
So
what
could
be
a
reliable
way
to
actually
close
items?
That's
that's
accurate,
that's
reflective
of
reality
and
what
people's
intentions
are.
Is
that
what
I'm
hearing
yeah,
okay,
I.
F
A
F
A
E
D
I
think
I
think
Anna
knows
well
and
has
covered
it
and
probably
has
even
seen
it
more
tangibly,
but
I
think
I
was
thinking
a
lot
from
like
a
burned-down
perspective
and
and
just
when
you
think
about
the
fact
that
that's
convoluting
and
creating
like
technical
debt
that
you
carry
forward
when
you
just
have
a
bunch
of
Steel
things
that
aren't
really
relevant
anymore.
So
yeah
I
think
she
I
think
she
nailed
it
and
I
think
it's
time
like
us
all
right.
A
D
Yeah
so
I
think,
especially
with
this
release,
with
just
the
way
that
we
shifted
the
timeline
and
this
being
with
her
and
I,
was
a
part
of
I
think
being
really
clear
and
having
it
documented.
Just
so
that
we
understand
the
cadence
that
things
are
expected
by
I.
Think
when
the
timeline
is
shifting,
having
a
source
of
truth,
for
that
is
really
important.
Just
so
that
the
only
were
aware,
but
so
are
you
know,
and
users
and
and
so
yeah
I
think
that's
a
I
think
that's
a
should
for
sugar.
A
F
So
I
don't
know
I'm
a
big
believer
of
retros
and
if
there
are
action
items
from
retros
like
I,
think
that
needs
to
be
action
upon,
so
that
our
release
cycle
becomes
better
like
for
the
next
release,
but
having
a
lot
of
action
items
left
over
from
2
releases.
The
girl
doesn't
seem
right
to
me
in
my
opinion,
so
just
any
action
items
from
any
retros
should
be
taken
care
of
as
soon
as
possible.
In
my
opinion,
I
think.
B
Part
of
the
issue
with
that
is
that
people
get
assigned
action
items
and
they
may
or
may
not
be
on
the
next
release
team
and,
if
they're
not
on
the
next
release
team,
obviously
pumps
way
down
in
their
priority
list
and
they
forget
about
it
and
just
kind
of
go
stale,
I,
think
figuring
out
how
to
fix
that
courage.
People
to
or
identifying
somebody
else
like
from
the
incoming
really
steamed.
A
A
So
this
relates
to
something
that
Steven
mentioned
last
Friday
having
a
synchronous
release
teams
and
that
might
not
just
being
by
time
zone,
but
also
being
this
continuity,
we
might
still
have
release
team
satellite
or
the.
How
do
we?
How
do
we
make
this
workflow
so
that
actually
gets
done
after
over
these?
How
do
we,
where
do
we
put
it
so
that
you
know
that
it
goes
forward
yeah.
A
E
A
A
E
A
E
D
C
A
So,
if
any
think
that
the
participant
said
inspires
you
to
have
a
thought
and
want
to
endorse
another
item,
that's
outside
of
your
domain,
you're
highly
encouraged
to
do
so,
because
everything
is
interwoven
in
the
end
anyway.
So
as
far
as
next
step,
so
we
could
use
the
remaining
time
to
sort
out
some
action
items
that
sounded
like
they
appeared
over
the
conversation.
Those
beings
didn't
answer
enhancements
meeting
and
when
we
might
do
that,
so
we
could
actually
talk
a
little
bit
about
this.
A
The
structure
and
the
content
of
the
meeting,
if
you
feel
comfortable
doing
so,
and
then
the
other
topic
might
be.
Actually
how
do
we
maybe
look
at
this
asynchronous
release?
Team
topic
like
if
you
wanted
to
if
you
wanted
a
second
session,
but
we
finished
this
job.
We
could
actually
still
do
with
the
second
session,
but
talk
about
that
and
the
idea
could
be
that
we
would
just
propose
some
ideas.
A
F
E
A
So
what
I
can
do
is
I
can
share
the
two
action
items
and
a
release
Tekin
channel,
and
then
anyone
from
the
team
who
wants
to
join
either
the
enhancements
meeting
or
the
well
Jeremy
will
take
care
of
enhance
this
aiming.
But
I
can
I
can
drive
this
one
forward,
the
asynchronous
team
topic,
and
then
we
can
probably
do
that
next
week,
I'm
wondering
if
we
actually
would
go
through
the
items
here
like
if
we
can
think
about
what
might
be
a
quick
win.
A
E
Something
that
may
come
like
usually
I.
Look
at
the
number
of
issues
that
are
open
to
see
the
world.
I
am
ahead
of
me
and
probably
there
to
avoid.
We
should
probably
think
about
the
day.
You
have
to
actually
have
issue
closed
and
not
just
mark
a
stay
from
the
bar,
because
it
gives
you
two
different
like
signal
you
know.
So
maybe
if,
if
the
interaction
between
an
issue
and
is
like
state
remove
state
remove
from
like
five
times.
E
E
Yeah
I
think
it
gives
you.
If
you
see
the
issue
open,
it
gives
you
a
different
feedback
that
if
you
see
they
should
close,
so
maybe
if
you
can
identify
how
many
times
an
issue
can
just
reopen
without
any
interaction
we
can
just
close
it.
So
I
think
if
we
get
harder
for
somebody
to
reopen
an
issue
other
than.
E
It's
a
change
in
the
automation
that
mean
no
feasible,
so
if
the
consequence
by
it
is
the
right
one
I
think
it
shouldn't
be,
do
I
I
don't
know
if
that
the
consequent
consequence
would
be
enough
or
people
we
just
don't
care
every
event.
Has
they
just
do
it?
The
labor
I
think
it's
like.
It
looks
easy
from
technical
point
of
view,
but
I'm
just
wondering
how
many
people
we
need
to
convince.
E
E
A
A
C
A
C
Could
go
for
also
the
the
CIA
signal
status
report:
okay,
mmm-hmm
I,
believe
this
is
again
agreeing
on
a
template
and
even
if
we
will
manually
have
to
do
it
now
and
later
on,
it
can
be
automated.
You
know,
somewhere
there
is
some
effort
already
around
around
having
this
automated,
but
if
this
can't
bring
a
value
and
it
doesn't
require
the
huge
effort
it
just
like
agreeing
moving
forward
or
now
on
a
format
for
this
report
is
doable
from
the
items
that
we
discussed
from
say
a
signal.
A
D
E
D
C
I
believe
the
common
theme
for
me
is
the
complexity,
is
start
to
increase
and
lots
of
bits
and
pieces
in
here
and
in
there.
So
if
it
will
take
you
a
lot
of
time
to
be
able
to
trace
something
in
to
end
across
different
SIG's
across
different
document,
different
repos
and
so
on.
So
one
of
the
things
that
I
struggled
with
when
I
started
with
a
CI
signal
is
to
be
able
to
trace
the
jobs
together,
reaching
out
to
the
right,
sick
and
and
so
on,
and
so
forth.
C
So
you
will
spend
some
time,
but
you'll
be
able
to
at
least
myself.
However,
the
ecosystem
around
will
still
be
way
more
complicated
to
absorb
in
one
release,
so
I
believe
most
of
the
team
has
done
multiple
release,
shadows
on
multiple
roles.
That's
why
they
start
getting
a
proper
understanding
for
the
overall
ecosystem,
but
it
takes
time
and
and
I
believe.
Something
that
is
needed
to
be
done
is
how
we
can
streamline
how
we
can
simplify
the
onboarding
and
the
process
for
people
to
understand
and
correlate.
C
A
So
what
we'll
do
next,
so
I
will
reach
out
about
the
session
about
the
asynchronous
teams
on
the
release.
Channel
Jeremy
will
have
the
doodle
out
for
the
enhancements
discussion,
and
then
we
have
a
hopefully
two
more
sessions
that
will
happen
next
week
and
then,
once
everybody
has
participated,
it
once
we'll
start
summarizing
the
information
and
then
you'll
hear
the
next
step,
but
basically
it
will
be.
A
I
will
try
to
frame
a
backlog
of
priorities
based
on
your
feedback
and
then
hopefully
start
tackling
these
items
and
strategizing
around
getting
them
done,
because
our
some
are
more
more
ambitious
than
others.
So
thank
you
for
your
time
and
your
feedback
and
your
participation.
This
was
really
great
and
fun
for
me.
So
I
hope
it
was
for
you
too.