►
From YouTube: Manage:Import 14.4 planning
Description
This is the sync planning session for the 14.4 milestone for the Manage:Import group.
Planning issue shown:
https://gitlab.com/gitlab-org/manage/general-discussion/-/issues/17383
A
Hello
and
welcome
to
the
14
4
planning
for
import,
welcoming
a
lot
of
new
members
this
time
around,
even
temporary,
so
I'll
I'll,
probably
just
talk
through
some
of
this
stuff
that
we
normally
just
fly
through,
perhaps
a
little
bit
more
slowly
to
make
sure
we
get
all
the
questions
answered
so
for
import.
We
typically
do.
A
The
planning
is
not
as
big
of
an
event
as
this
for
some
of
the
other
groups,
because
we
do
kanban
and
we
try
to
plan
refine,
prioritize
and
add
things
in
a
more
continuous
fashion,
but
still
it's
good
to
get
together
once
a
month
and
talk
about
where
we
are.
What
our
objectives
are
for
a
particular
milestone,
and
you
know,
discuss
kind
of
the
priorities
and
capacity
and
all
the
things
that
have
been
going
on
so
I'll
share
my
screen
and
we
can
talk
through
the
planning
issue.
A
So,
as
I
said,
the
group
is
has
been
enhanced
for
at
least
three
milestones
with
five
additional
back-end
engineers.
So
we're
thankful
for
that
and
welcome
all.
A
We
do
have,
I
think,
since
last
time
a
security
counterpart
like
a
stable
counterpart
has
been
identified.
That's
rohit,
so
I
just
wanted
to
call
that
out
as
well,
because
there
was
something
that
that
was
changed
couple
months
ago
and
at
this
point
we
are
semi-permanently
without
a
ux
counterpart,
but
we
are
going
to
get
another
backend
engineer,
hopefully
instead
of
the
ux
designer,
so
that
we
can
make
more
more
progress
on
the
back
end
stuff.
A
A
Sorry,
who
was
that
it's
alan
alan
cook,
oh
cool,
do
you
want
to
edit
that
or
do
you
want
me
to
add
it.
C
A
A
So
something
else
about
capacity,
I
know
we,
we
had
this
engineering
allocation,
which
had
beginning
of
august.
It
feels.
A
And
that
that
that
has
that
is
still
active
in
a
way,
but
it's
being
superseded
by
the
headcount
reset.
So
it
is
a
little
weird
and
I'll
just
give
you
my
take
on
it,
and
you
tell
me
if,
if
that
makes
sense
for
everybody
or
not
so,
first
of
all
what
it
is
for
people
who
haven't
seen
who
have
not
you
know
haven't
been
around
to
see.
It
is
that
we
have
50
of
the
capacity
dedicated
to
not
directional
items
to
more
of
a
security.
A
Infradev
stability
issues
and
those
issues
have
been
identified.
They've
been
tagged
with
engineering
allocation
and
we
kind
of
had
a
plan
in
place
to
dedicate
half
of
our
capacity
to
to
that
backlog,
which
was
important
for
engineering,
which
is
what's
called
engineering
allocation.
A
In
my
mind,
those
objectives
are
now
fully
covered
by
the
headcount
reset.
So
now
100
of
everybody
is
sort
of
in
that
area,
and
I've
looked
and
all
of
the
issues
that
have
been
tagged
with
engineering
allocation
are
now
part
of
the
backlog
for
the
headcount
reset.
So
in
my
mind,
we're
kind
of
still
respecting
the
engineering
allocation,
while.
A
A
E
I
have
one
comment.
I
guess
I
am
kind
of
also
involved
in
an
engineering
allocation
from
the
quality
side,
which
is
not
mentioned
in
our
team
board.
So
there
was
because
of
the
few
recent
incidents,
the
there's
a
push
in
better,
basically
tracking
and
visualizing.
E
The
test
behavior
performance
like
over
time,
which
we
don't
have
like
at
all,
I
kind
of
got
involved
into
setting
up
that,
because
I
have
experience
in
creating
a
setup
like
that
before.
E
Yeah
so
yeah,
I
kind
of
because
I
was
basically
up
to
speed
with
my
currently
planned
tasks.
I
didn't
mention
it
right
away
like
it
started
last
week,
so
it.
B
E
Really
impact
our
our
progress
on
adding
tests.
A
Okay,
so
a
rule
for
things
like
that
on
the
team
was
typically
that
you
would
still
put
it
on
our
board
and
we
still
track
it
together,
even
if
it's
not
directly
driven
by
you
know
by
me
or
okay,
if
it's
some
kind
of
like
allocation,
which
is
like
automatically
you
have
to
work
on
this,
you
can
still
track
it
on
the
board
so
that
there's
visibility
into
what
you're
working
on.
E
Okay,
yeah
yeah.
I
will
I'm
not
sure
like
there's
already
an
issue,
we
put
it
on
our
board
or
do
we
copy.
A
A
E
B
B
A
We
have
visibility
yeah.
I
will
update
it
good
cola,
so
team
velocity
will
not
mean
much
today,
but
I
think
it's
kind
of
just
an
interesting
trend.
Of
course,
the
last
milestone
always
is
missing
things
because
we
have
not
fully
closed
up
14-3,
so
it
always
bumps
at
the
end,
but
there's
definitely
been
an
impact
to
like
how
much
we
get
done
with
all
of
the
distractions
that
we've
been
having.
So
I
expect
this
to
shoot
up
next.
A
Next
couple
milestones
for
sure
I
do
wanna
call
out
the
front
end
velocity,
which
we
have
not
increased
the
capacity,
but
it
has
gone
up
so
kudos
to
earlier.
There.
F
C
A
So
proposed
objectives,
so
this
is
sort
of
the
flavor
of
the
milestone
for
sure
the
biggest
flavor
ingredient
for
for
the
milestone
is
going
to
be
the
headcount
reset.
A
I
have
only
listed
the
links
to
the
individual
epics
for
each
one
of
the
subteams
and
from
there
we
can
take
a
look
at
the
backlog,
but
I
didn't
want
to
list
issues
here.
It
made
no
sense.
We
already
are
tracking
and
prioritizing
each
one
of
these
areas
separately.
A
A
A
Also,
this
would
require
us
to
actually
put
weights
in
each
one
of
the
issues
that
are
in
the
epic,
because
this
is
just
three
of
25
weight
completed.
However,
half
these
items
are
not
weighted
and
our
process
does
not.
You
know
like
using
our
process.
We
do
not
put
weight
on
the
items,
we're
not
going
to
work
on
kind
of
in
a
short
manner.
A
C
G
A
Some
weight
and
I've
put
some
comments
in
there
for
all
of
you
to
consider
to
maybe
put
some
average
weights
on
the
rest
of
the
items
to
just
sort
of
maybe
get
this
to
look
more
accurate.
F
F
A
Well,
we'll
we'll
see
I
mean
we
could
also
always
if
it's
not
ready
for
development.
The
weight
is
still
pending
like
and
you
can
tell
that.
I
added
the
weight
and
therefore
you
can
ignore
it
like
there's,
probably
ways
for
us
to
ignore
my
weight
but
yeah.
I
didn't
realize
that.
F
A
Also,
don't
want
to
complicate
it
too.
Much
like
this
is
like
potentially
an
interesting
view
like
I
don't
know
how
accurate
or
how
useful
it
will
be.
So
I
wouldn't
want
to
spend
too
much
time
on
it.
Maybe
do
something
crude,
but
maybe
I'll
play
with
some
other
way
of
being
able
to
easily
see
how
we're
doing
against
this
thing.
D
I
also
want
to
throw
out
there
that
I
did
respond
to
your
your
your
cue
of
harris
of
asking
just
put
three
on
everything.
From
my
perspective.
That's
fine,
and
because
my
estimations
aren't
really
that
good
anyways.
G
Yeah,
historically,
all
of
our
estimations
are
either
three
or
five.
You
know
so
maybe
carries
your
estimations
with
everything.
Three
are
going
to
be
spot
on.
You
know.
A
Agile
teaches
us
this.
That
estimations
are
notoriously
inaccurate
and
we
do
just
as
well.
If
we
just
said
everything
was
one
or
just
count
how
many
issues
right
so
just
count
the
issues,
so
each
just
gets
one.
A
That's
pretty
much,
it's
kind
of
as
accurate
as
adding
particular
weights
and
particular
issues
for
a
team
that's
been
established
and
where
the
issues
sort
of
have
a
similar
feel
to
them,
and
I
feel
for
us,
we
do
have
a
flavor
to
the
issue
like
our
issues
are
typically
not
gonna,
be
fixed
and
they're.
B
F
And
also
like,
if
we
have
an
issue
that
is
set
to
three
and
after
a
while,
we'll
defined
that
we
realized
that
it's
so
big
that
it
needs
to
be
broken
up
and
we
need
to
set
it
to
five.
This
is
also
like
not
a
big
problem
right
does.
It
has
any
consequences,
no.
A
If
you're
in
kanban
there's
no
consequences
because
we
do
not
have
commitments,
so
you
know
this
is
just
the
most
important
thing
to
work
on
and
if
it
is
gonna
be
larger,
then
that's
reality
like
yeah.
It
is
gonna,
be
these
multiple
issues
and
it's
gonna
be
this
extra
work
and
that's
just
reality
of
things
things
got
bigger
than
we
thought
they
would
be,
but
typically
on
the
average
there's
gonna
be
some
of
that
all
the
time.
A
B
A
So
anyway,
I
don't
want
to
derail
this
too
much.
So
you
know
the
back
end
is
definitely
all
dedicated
to
headcount
reset
to
these
three
areas
and
also
covering
the
engineering
allocation.
By
that
the
front
end,
we
have
a
carrier
for
from
1403
where
we
want
to
see
the
history
of
all
the
imported
groups,
and
this
is
just
the
front
part
of
the
of
that.
Ilia
is
the
back
end
done
in
progress
planned.
C
Yes,
it
is
done,
but
there
will
be
future
improvements,
but
they
are
out
of
scope
of
this
issue.
This
could
be
fulfilled
with
what
we
have
currently
okay,
so.
A
A
The
group
imports,
because
that's
that's
kind
of
new
and
fresh
and
also
at
the
same
time
we
are
going
to
want
to
make
this
experience,
be
an
example
of
what
the
other
importers
should
do
so
adding
pagination
and
table
sorting
and
multi-select
for
for,
like
bulk
import,
all
of
those
things
are
going
to
be
desirable
for
other
importers
as
well.
So
this
is
kind
of
establishing
the
best
user
experience
for
one
importer
so
that
later
we
can
go
back
and
update
the
other
importers
that
we
care
about.
E
Yeah,
so
essentially
it
is
what
it
says
so
to
to
finish
up
with
the
coverage
of
group
bulk
migrations.
We
still
have
basically
iterations
and
badges.
E
Everything
else
is
like
done
as
as
much
as
it
it
felt
is
feasible
to
do
and
the
other
item
I
added
was
actually
getting
back
to
the
github
migration
or
rather
import.
So
the
test,
the
daily
test,
like
I
set
up,
started
to
actually
fail.
E
So
currently
there
was
no
one
who
could
have
like
who
did
have
some
time
to
investigate.
Why
is
that?
So?
Essentially,
the
test
right
now
shows
that
the
importer
is
consistently
missing
some
comments
and
some
issues.
B
E
Yeah,
I
need
to
figure
out,
if,
like
it
doesn't
seem
to
be
an
issue
with
the
test,
because
the
the
results
the
test
expects,
are
consistent,
but
the
imported
results
are
not
so
it
leads
me
to
believe
it's
either.
Gitlab
api
isn't
returning
something
correctly
or
we
actually
consistently
are
missing
some
items.
B
E
No
not
yet
didn't
have
time,
and
I
need
to
improve
the
test
setup
a
bit
because
it
has
like
a
huge
oversight,
since
we
run
it
on
staging.
We
are
supposed
to
be
cleaning
up
data
after
the
test.
So,
aside
from
trying
to
see
the
logs,
the
actual
user
and
the
imported
group
is
deleted
after
the
test,
which
is
not
very
useful
for
investigating
failures,
I
need
to
kind
of
improve
on
that
a
little
bit.
A
Okay,
so
once
you
can
confirm
that
it
actually
is
missing,
I
think
we
can
definitely
we'll
create
an
issue,
and
we'll
put
it
I
mean
it's
definitely
part
of
what
the
headcount
recent
reset
is
about.
Like.
F
A
Is
going
to
be
a
customer
escalation
pretty
soon,
but
right
now
it
is
just
like
unreliable
there's,
a
reliability
problem
with
the
github
importer,
which
is
one
of
our
two.
E
Consistently
and
at
some
point
when
I
tried
to
switch
to
a
larger
project
and
the
test
was
not
running
it
like
something
changed,
so
I
couldn't
pinpoint
the
exact
time
like
it
started
to
behave
differently.
G
Yeah,
so
I'm
looking
at
the
logs
there
I
mean
we
don't
have
to
go
through
the
detail,
but
it
could
be
the
same
issue
that
I
worked
on,
where
the
api
from
github
just
no
longer.
C
E
Yeah,
essentially,
that
is
why
I
added
this
back
to
the
next
milestone.
A
Yep,
I
completely
agree
and
if
you
run
out
of
things
to
do
again
in
this
milestone,
I
think
probably
the
next
step
that
we're
going
to
talk
about
probably
next
milestone.
But
maybe
even
this
month's
not
get
time
is
to
start
adding
the
project.
E
A
D
Have
a
question
harris
sorry,
I
I
see
with
the
combine
you
don't
put
on
the
milestones.
I
assume
engineers
pick
the
milestone
once
they're,
confident
that
it'll
go
into
review
or
be
merged
for
that
milestone.
A
That's
a
good
question.
I
should
probably
just
very
quickly
talk
about
how
we
use
the
kanban
board,
given
that
reviewing
the
actual
issues
on
it
is
probably
now
out
of
scope
for
this
meeting,
because
a
there's
there's
a
lot
more
work
and
b,
it's
kind
of
managed
in
separate
backlogs
and
just
having
this
overall
view
as
one
way
to
do
it.
I
think
it's
good
as
a
reflection
of
what's
going
on,
but
I
don't
think
it's
useful
to
to
now
talk
about
each
one
of
these
issues.
A
I
feel
like
there's
just
too
much
work
and
it's
already
kind
of
known
as
far
as
what
the
order
is
so
talk
about
that
sort
of
how
we
use
the
the
board,
the
you
know
the
engineers
the
developers
will
look
at
refinement
sort
of
as
a
starting
point
for
the
engineers.
A
You
know,
sometimes
engineers
will
be
involved
in
planning
breakdown,
so
this
is
kind
of
an
issue-
that's
too
large
and
needs
to
be
broken
down
into
smaller
issues.
This
is
more
of
an
epic,
so
we're
discussing
sort
of
how
to
do
it
here
and
then
once
we
create
all
the
issues
we
want
to
create
out
of
this
and
we
break
down
this
issue
to
you
know
the
nominal
size
that
we
typically
have
all
of
those
issues
will
then
move
into
refinement.
A
So
you
know
developers
will
pick
it
from
refinement,
add
weight
and
you
know
kind
of
think
about
the
approach,
discuss
it
with
other
engineers
and
then
add
the
weight
once
the
weight
is
added,
and
there
is
a
note
like
we
know
what
the
solution
is.
What
the
approach
is.
A
It
will
be
ready
for
development,
it's
placed
in
here
and
then
sits
there
until
it's
ready
to
be
picked
up.
It
still
sits
in
a
non-uh
non-milestone
like
a
next
one
to
three
or
whatever.
The
milestone
is
only
when
it
gets
pulled
into
development.
Are
we
supposed
to
assign
the
milestone,
because
at
that
point
you
kind
of
know
what
you're,
targeting
like
your
mrs,
are
gonna
start
targeting
a
particular
milestone
and
for
early
in
the
milestone,
you'll,
probably
assign
that
milestone.
A
But
if
we're
like
today,
you're
not
going
to
assign
14
3
you're,
probably
going
to
sign
14
4
as
your
target
muscle,
so
you
will
decide
at
the
point
when
you
move
it
from
ready
into
in
dev.
You
will
assign
yourself
as
an
assignee
as
the
owner
of
the
issue,
and
then
you
will
assign
the
milestone
to
whatever
you
think
is
going
to
be
the
milestone.
So
that's
kind
of
the
point.
All
the
things
in
dev
should
have
a
milestone
assigned
to
them
like.
A
A
Yeah,
so
the
the
gateway
for
ready
for
development
is
to
have
weight
assigned
to
it
and
for
the
engineers
to
feel
like
this
is
an
issue
that
they
they're
ready
to
work
on.
It's
shovel
ready
like
there's.
If
there
are
questions
for
the
pm,
they
they
were
answered.
If
you
know
there
is
a
technical
approach,
or
at
least
an
idea
of
what
approach
to
take
to
investigate
how
to
get
there
and
then
for
in-dev,
there
needs
to
be
an
assignee
and
there
needs
to
be
a
milestone
assigned.
A
I
think
that's
it's
probably
other
questions
about
process.
I
know
it's
new
to
people
so
like
no
question
is
so
all
questions
are
welcome.
A
There's
no
bad
questions.
If
there's
anything
that
is
confusing
or
if
you
think
like.
Oh,
we
should
do
something
differently
because
good.
D
Question
for
what
I,
the
the
group
or
team,
I
come
from
it's
a
small
group
as
well
like
two
people,
and
so
what
I
typically
do
is
it
may
not
apply
here,
but
the
way
I'm
currently
wired
is
that,
at
the
start
of
a
milestone,
I'll
will
have
a
planning
meeting
I'll
grab
everything
that
I
think
I
can
do.
Even
if
it's
ready
for
development
and
assign
it
to
myself,
and
then
I
don't
look
at
the
board
anymore
for
the
rest
of
the
milestone.
D
F
I
saw
like
three
issues
with
the
deliverable
label.
Do
you
track
like
this
for
say,
do
ratio
stuff
like
this
and
when
do
you
use
it.
A
So
typically,
we
would
use
deliverable
kind
of
when,
when
it
was
a
smaller
group,
we
would
talk
about
okay.
So
now
that
I
have
presented
the
objective
I,
it
would
be
more
of
a
feedback
from
engineering
on
which
not
necessarily
exactly
which
issues,
but
what
features
we
might
be
able
to
deliver.
A
So
it
could
be.
You
know,
making
progress
against
a
particular
epic,
so
we
think
we'll
get
probably
two
or
three
issues
from
this
epic
and
then
feel
the.
So
it's
almost
like
the
commitment
thing,
but
it's
not
necessarily
committing.
It
gives
me
an
idea
of
what
things
we
are
really
targeting
to
deliver.
So
we'll
pick
the
top
most
important
things
that
we
will
deliver
and
we'll
set
that
as
deliverable,
because
then
we
can
easily
see
what
are
the
you
know.
A
What
are
the
things
that
have
advertised
so
I
will
take
take
those-
and
I
will
talk
in
my
kickoff
about
those
and
I
may
create
island
documentation
around
it.
So
these
are
the
things
that
we
would
like
to
get
delivered.
A
So
I
don't
think
the
lever
will
make
sense
for
us
to
set
while
we're
doing
the
headcount
reset,
but
that
that
was
kind
of
the
reason
why
we
did
it
was
to
sort
of
get
an
idea
for
what
do
we
now
feel,
like
I'm
kind
of
bonus
up
information
as
far
as
what
we
feel
it
could
get
delivered.
F
A
And
just
to
chime
in
on
whether
to
assign
yourself
to
to
something
ready
for
dev,
I
wouldn't
do
more
than
one,
maybe
like
the
next
one,
if
you
just
refined
it
and
you're,
just
not
ready
to
pick
it
up,
but
you
will
next
find,
but
on
a
larger
team,
you
know
other
people
might
be
able
to
pick
up
something
before
you
do
and
yeah
and
then
again
like
if
that
just
works
for
you
and
you
talk
to
the
one
more
person
on
your
sub
team
and
you're,
both
okay
with
that
that's
fine
too,
like
I'm,
not
that's,
not
something
that
we
need
to
prescribe.
D
A
D
A
Right
this
is
the
overall
board
for
everything
that's
going
on
with
import
with
all
of
the
things
that
are
in
progress.
So
this
is
the
board
that
normally
does
not
have
as
many
issues
in
progress,
and
it's
a
lot
more.
This
one
is
not
so
that's
why
I
didn't
want
to
like
go
over
this,
but
this
is
something
that
we
would
typically
take
a
look
at
and
see
the
few
items
that
are
in
progress
on
here
right
now.
A
So
at
the
kanban
board
we
also
had
the
sub
board,
which
was
security
prior
to
the
whole
headcount
reset,
where
we
were
tracking
the
security.
So
that
is
the
security
board
that
one
of
groups
is
using,
but
you
know
I
think
everybody
should
stay
on
their
smaller
boards
and
just
manage
things
from
there.
A
That
kind
of
that
does
it
for
like
what
I
had
to
present.
As
far
as
the
planning
issue
goes,
we
have
some
time
if
you
have
some
thoughts,
questions
more
suggestions
for
improvement,
how's,
everybody
doing
don't
talk
about
that.
G
I
just
have
one
piece
of
advice:
I
guess
because
the
people
who
are
new
right
that
they're
not
used
to
the
refinement
process,
as
as
people
who
have
been
here
longer,
I
wonder
if
we
should,
you
know,
assign
individual
issues
to
specific
engineers
to
make
sure
these
issues
are
refined
instead
of
kind
of
waiting
for
them
to
refine
themselves.
You
know
something
that
we
agreed
to
to
be
doing
before.
G
Just
make
sure
that
the
issues
you
get
refined,
you
know
like
batches
of
wishes
to
get
refined
in
time.
I
know
we've
been
doing
that
before
in
import.
You
know
when
you
or
liam
signs
an
issue
for
for
us,
but
I
just
wanted
to
kind
of
flag
it
up,
so
that-
and
I
know
this
has
been
done
before
I've
seen
others
doing
the
investigation
and
refinement.
I'm
not
saying
that
it's
not
happening,
I'm
just
saying
that
just
flagging
this
up,
something
that
came
out
to
my
mind's
business.
D
G
A
That's
a
good
point,
I
mean
so
the
the
way
we
kind
of
evolved.
The
refinement
was
that,
just
like
everything
else
on
the
board
in
kind
of
the
kanban
style
it
is
pool,
so
the
developers
pull
things
into
refinement.
They
don't
get
assigned
things
to
refine
and
the
developers
pull
things
into
in-dev.
They
don't
get
assigned
things
to
to
work
on,
but
we
do
have
kind
of
an
exception
to
the
refinement
process.
If
things
are
important,
then
we
might
just
like
tag.
A
Someone
and
say:
can
you
please
just
refine
this,
because
this
is
you
know
we
can't
wait
for
you
to
to
just
naturally
come
back
to
this
and
find
that
this
just
needs
to
happen
now.
A
So
we
could
potentially
use
that
here
to
just
make
sure
that
enough
things
are
being
refined
for
each
one
of
the
boards
and
especially
since
that
refinement
is
probably
better
down
for
the
groups
that
have
a
counterpart
from
import
like
that
refinement
is
gonna
need
a
lot
of
input,
a
lot
of
work
from
that
team
member-
and
it's
probably
you
know
better
done
by
that
team
member.
A
So
yeah,
I'm
okay
with
that.
Let's,
let's
just
make
sure,
let's
take
a
look
and
see
if
there's
enough
things
in
the
refinement
and
if
not,
I'm
okay,
with
assigning
things
out
or
view
all
engineers
want
to
sign
things
out
to
yourself
ahead
ahead
of
this,
that's
fine
too.
D
No,
I
do
typically,
but
I've
noticed
I've
been
doing
with
this
refinement
is
I
do
assign
it
to
myself
while
I'm
refining
it
and
then
on
a
sign
myself
or
take
it
immediately
into
ready
for
development
and
leave
it
assigned
to
myself.
That's
what
I've
been
doing
so
far.
A
That
makes
sense,
but
I
think
what
georgia
was
suggesting
was
that
we
assign
more
than
one
item
to
to
someone,
so
we
can
just
assign
you
like
three
issues
to
refine
just
to
make
sure
that
all
three
are
getting
refined
like
somebody's
looking
at
them,
as
opposed
to
they
could
just
be
sitting
on
the
board,
not
getting
refined
so
to
kind
of
make
sure
that
things
are
going
to
refine.
We
could
pre-assign
more
than
one
issue
to
the
engineers.
I
think
that
was
a
suggestion
right,
george.
G
Yeah
I
mean
it
can
be
one
it
can
be
more
than
one.
I
I'm
just
saying
that
you
know.
Let's
say
I
finish
an
issue
and
there's
nothing
ready
for
that.
That's
not
ideal
right.
If
I'm
ready
to
pick
something
up
and
that's
the
ready
for
death
volume
is
empty,
but
yeah
sometimes
I
mean
I
can
be
guilty
of
something
like
there's
an
issue
to
be
refined,
but
I'm
like
okay,
you
know
what
it's
so
much
going
on
in
there
I'll
just
wait
for
somebody
else
to
find
us.
G
You
refine
it
and
it
never
gets
refined.
So
it's
yeah,
I
mean,
I
think
you
know
in
sub
teams.
I
will
make
sure
to
I
mean
I'll,
be
keeping
an
eye
on
that,
but
I
just
wanted
to
call
it
out
as
something
that
you
know
can
be
slightly
different
in
our
team,
I
suppose
to
other
teams,
but
we
sometimes
if
the
issue
is
set
in
refinement
but
nobody's
assigned
what
we
used
to
do
before,
like
one
of
the
practices
is
a
proactively
going.
G
Every
engineer
would
go
through
refinement
once
in
a
while
and
refine
these
issues
voluntarily.
I
supposed
to
be
explicitly
told
to
to
do
it
so
yeah.
A
By
the
way,
I've
put
up
the
template
that
we
used
to
do
when
we
did
our
refinement,
so
this
was
kind
of
the
template
that
we
would
use,
and
we
would
like
put
a
comment
in
the
issue.
That
said,
you
know
that
would
just
tag
everybody
who
is
in
the
group
and
can
announce
that
something
is
ready
for
refinement
and
you
know
needs
to
be
picked
up
by
someone
out
of
this
group.
A
You
can
then
self-assign
when
you're
ready,
but
it
would
also
just
it
was
good
because
it
gave
you
a
good
place
and
it
was
good
visual.
It
was
easy
to
find
the
refinement
thread
in
the
issue,
so
you
could
see
what
was
discussed
in
the
refinement,
because
sometimes
these
issues
have
all
kinds
of
discussions
from
sales,
people
and
customers
and
a
lot
of
people
chiming
in,
but
this
would
be
kind
of
a
separate
thread
for
just
the
engineers
who
are
going
to
work
on
it
to
discuss
the
approach
the
size.
A
You
know
how
they
feel
about
it
and
then
voting
it
up,
whether
it's
ready
or
not,
for
for
development.
So
does
it
make
sense
for
me
to
just
go
ahead
and
do
that.
I
felt
like
that
was.
D
If
you
tag,
everybody
has
potential
to
create
noise
and
distraction.
For
me
at
least
okay,
two
cents.
A
I
can
then
just
do
it
without
tagging
and
I
wouldn't
tag
everybody
in
all
the
issues
it
would
be
just
on
your
sub
board.
Is
that
still.
D
Oh,
that's,
that's,
that's
fine!
Then.
I
think
the
sub
boards
are
pretty
pretty
focused
so
that
that'd
be
welcome.
D
It's
also
okay,
not
to
do
it,
I
mean
I
don't
need
it,
I'm
just
saying
I'm
okay
with
it,
so
I
don't
want
to
create
more
work
for
you
than
necessary.
A
F
Sorry,
I
got
kicked
off
by
technical
reasons
for
the
last
minute,
so
what
was
the
decision
about
the
refinement?
Can
anyone
like
summarize
to
me?
How
do
we
do
with
it.
A
I
think
we're
going
to
leave
it
up
to
the
engineers
to
just
on
a
pool
basis.
Take
things
into
refinement.
A
I
will
monitor
and
I'm
sure
that
this
will
as
well
and
just
make
sure
that
enough
things
are
being
refined
and
if
anyone
of
you
notices
that
not
enough
things
have
been
refined,
you
can
discuss
with
your
team
or
assign
things
to
yourself
or
you
know
just
you
know,
we'll
find
a
solution
if
the
problem
arises,
maybe
not
right
now
before
there
is
an
issue
there,
but
please
do
consider
when
you
take
things
into
refinement
when
you
assign
yourself
to
it,
create
a
thread
that
says
you
know,
refinement,
thread
and
then
kind
of
put
your
notes
in
there
and
tag
people
in
there
to
discuss,
refinement
and
help
you
decide
if
the
weight
is
right
or
whatever.
D
Sounds
good
I've
been,
I
have
a
habit
of
assigning
the
well
you
in
this
case
harris
when
I
don't
when
I
have
questions
about
refinement
on
an
issue
that
just
sends
me
a
signal
that
it's
not
all
on
me
to
you
know
it's
not
waiting
for
me.
Basically,
I
don't
know
if
that's
distracting
to
you
or
not.
I
can
find
other
ways
to
do
that.
A
No,
I
I
noticed
that,
so
it's
not
something
I'm
used
to
and
other
people
don't
do
it,
but
I'm
also
very
flexible
and
I
I
will
work
with
whatever
works
for
you.
So
I
I'm
fine
with
that.
Please
keep
doing
that.
I
don't
pay
attention
to
it
much.
I
really
pay
attention
to
the
mentions
right,
but
if
that
helps,
you
have
the
visual
that
you
know
that
you've
asked
somebody
a
question.
That's
that's
fine
with
me.
A
So
I
think
this
may
be
all
we
have
for
the
session.
How
does
everybody
feel
just
like
a
final
up
down
vote
on
this?
Does
everybody
feel
okay
with
what
we're
doing
and
how
we're
doing
it
and.