►
Description
In this session we discuss ways we can improve writing issues so that they can assume less context and be better picked up by the wider community.
A
B
B
You
then
have
ones
either
where,
after
a
while,
they
become
this
or
you
create
it
from
the
beginning,
where
you
know
a
follow-up
or
something
where
you
say.
Oh
it'll,
be
good
in
the
future
to
add
some
tests
for
this
or
to
refactor
this
or
at
which
point
you've
immediately
got
almost
the
implementation
plan.
B
So
one
thing
to
consider
is
I.
Don't
think
we're
always
going
to
have
an
implementation
plan
from
the
beginning,
but
I
don't
think
that
stops
us
having
a
section
in
every
issue
that
sort
of
says
implementation
plan,
and
then
you
know,
TBC
or
or
whatever
the
only
problem
that
causes
is
I,
think
we've
got
some
triage,
Ops
automation
that
checks
for
implementation
plans,
maybe
labels
or
does
something
accordingly
based
on
whether
there
is
or
isn't
one.
B
B
A
B
A
B
B
A
B
Like
yeah
and
I
hate
to
name
drop
but
I'm
sure
you
know
you've
come
across
like
Marco
and
Nicholas
and
the
the
likes
you
know
if
they
were
creating
an
issue.
They'd
probably
fill
out
more
details
than
if,
if
you
know,
I
was
crazy,
so
we've
definitely
got
plenty
of
community
members
and
you
know
we're
trying
to
build
that
up
as
well.
A
B
A
B
B
B
A
B
A
A
A
B
A
A
A
A
A
B
A
It's
very
for
me:
it's
like
I
I'm,
not
reading.
All
this
I'm,
not
gonna,
say
beat
I
will
if
I
will
read
it,
but
it's
just
so
much
easier
for
me
to
like
I
could
put
in
all
the
context
and
the
screenshot
and
there
we
go
and
but
what
I
would
say
is
like
I.
Normally,
then
do
you
know
I'll
add
you
know
possible
details
or
investigation,
and
it's
like
I
think
is
this
line
of
code.
Here's
another
pattern
whatever
and
I'll
drop.
B
A
There-
and
this
is
the
part-
that's
like
it'd-
be
really
great
if
we
could
prompt
or
issue
authors
to
doing
this
and
then
even
instructions
for
like
hey.
If
you
don't
have
this
here's
you
know
see
if
you
can
reach
out
to
the
team
that
can
fill
this
out
so
that
we
can
have.
You
know
a
more
healthy
issue.
Backlogged
for
and.
A
Adding
these
labels
this
actual
labels,
not
accepting
merger
requests
that
you're
supposed
to
add
like
if
all
of
that
instruction
was
here
in
the
issue,
description
that
would
be
really
cool
but
I
I'm
already
noticing
myself.
I.
Think
these
for
me
of,
like
get
so
wordy
and
irrelevant
to
what
I'm
trying.
A
A
B
Know,
I
I
think
it's
challenging,
though,
because
I
there
are
optional
with
it.
So
if
you,
if
we
went
through
that
bug
template,
you
know,
if
your
self-managed
self-hosted
there's
a
bunch
of
like
you
know,
can
you
run
this
command
and
dump
the
logs
here?
Can
you
do
this
and
dump
the
you
know
so
unless
we
want
to
sort
of
split
that
out
into
set
more
separate
templates
I?
Yes,
it's
quite
hard
to
avoid,
if
you
know
like
I.
B
A
A
B
A
A
B
B
Definitely
quick
win
will
remain
yeah
or
I
think
it
will
because
definitely
the
newer
contributors
want
something.
That's
that's
a
quick
win
and
ideally
has
so
what
we're
hoping
I
don't
know
if
you
I
personally,
don't
use
them,
but
I'm
I'm,
just
about
allowed
to
excuse
myself
because
I'm
not
technically
an
engineer
anymore.
B
The
workflow
labels
I
think
differentiate
between
something
that
I
think
there's
like
a
plan
in
Breakdown
like
ready
for
designs
and
then
like
ready
for
development,
or
something
like
that.
So
they
should
allow
you
to
sort
of
say:
okay,
I'm,
a
community
contributor
and
I.
Don't
know
how
to
code
Ruby
in
JavaScript,
but
I
can
design
and
I
can
discuss
and
I
can
pull
in
the
PMs,
and
you
know
I
can
help
to
flesh
this
out.
So
I'm
going
to
look
for
stuff.
B
B
C
Justifications
for
why
we're
doing
it
like
the
it's
basically
just
replacing
part
of
the
build
process
of
the
main
gitlab
flow.
So
there
may
still
be.
You
know,
design,
breakdown
and
and
stuff
like
that,
but
like
in
practice,
that
often
doesn't
happen
because
the
designers
they
do
their
designs
and
then
you
know,
that's
perhaps
part
of
an
epic
or
or
maybe
an
issue,
and
we
that
you
know
that
phase
that
that
workflow
label
doesn't
necessarily
get
applied.
You.
B
C
Or
it's
like
in
our
particular
case,
perhaps
because
it's
much
more
of
a
sort
of
a
backhand
and
less
design
focused
feature,
there's
not
a
lot
of
need
for
those
other
stages.
It
kind
of
goes
from.
You
know
the
the
PM's
mind
to
you
know:
planning
breakdown
to
implementation,
there's
and
there.
If,
if
there
is
a
design
phase,
that's
like
in
the
separate
issue,
the
thing
gets
you
know
pulled
in
to
other
issues
that
don't
necessarily
sit
there.
I,
don't
know
how
relevant
that
is.
C
B
C
B
C
C
C
B
B
C
And
like
I,
try
to
input
like
literally
I
myself
made
a
template
for
our
group
that
had
all
of
these
nice
things
in
it,
and
you
know
we're
trying
to
force
ourselves
to
refine
it,
but
even
I'm
reluctant
to
do
that
because
it's
it
takes
a
lot
of
work
like
I'll.
Do
it
on
the
ones
that
really
matter
but
like
the
small
refactorings,
I'm
sort
of
cheating
on
them
and
stuff,
like
that,
it's
yeah.
A
I
would
say
that
the
there's
somewhere,
the
implementation
plan
is
so
trivial.
It
puts
extra
work
to
put
it
into
words,
because
it's
just
so
clear
what
needs
to
have
while
I'm
pointing
to
the
code
I
might
as
well
just
do
it,
and
maybe
that's
fine
to
just
say
then,
and
the
implementation
plan
like
and
say
above
it's
very
trivial,
just
see
above,
like
I,
think
that's
totally
doable,
there's
other
times
where
it's
like
you
shouldn't
be
spending
more
than
five
minutes
on
the
implementation
plan.
A
We
need
to
actually
make
it
really
clear
in
the
implementation
plan.
We
have
to
do
investigation,
we're
not
even
sure
how
we
need
to
solve
this
and
or
we
don't
even
have
a
good
direction
forward
and
that's
very
clear
for
future
readers
of
like
oh.
What
is
the
state
of
this
issue?
Is
it
clear
what
we
need.
A
A
A
Can
you
spare
five
minutes
of
your
time
to
just
drop
lines
of
code
for
future
readers
just
making
it
anything
we
could
do
to
make
issues
more
attractive
to
community
contributors
goes
a
super
long
way,
but
yeah,
even
if
the
implementation
plan
is
just
n,
a
I
think
that
that's
better
than
even
not
saying
anything
like
we
haven't.
Even
you
know
what
I'm
saying
one.
C
Of
the
things
I
did
when
I
wrote,
I
wrote
a
a
custom
template
for
our
remote
development
team
sort
of
inspired
by
the
others
where
you
have
to
put
in
implementation
plan
and
a
use
case,
but
instead
of
having
like
that,
the
instructions
within
comments.
So
if,
if
they
don't
do
anything,
that
section
is
just
blank
I
made
them
actually
like
to
do.
You
know
out
of
comments
so
to
do
colon
fill
out
the
implementation
plan.
C
It
should
look
like
this,
so
then
it's
explicit
that
somebody
did
it
and
it's
part
of
that
to
do
instructions.
It
could
say,
delete
this
or
replace
it
with
not
necessary,
because
this
is
too
trivial
like
and
then,
when
anybody
looks
at
the
text,
zero
works
on
their
part.
They
don't
even
have
to
care
about
it.
But
when
somebody
comes
and
looks
at
that
in
the
future,
it's
clear
whether
okay,
this
was
just
ignored-
or
this
was
intentionally
left
out
because
they
had
to
at
least
type
that,
but
that
wasn't
a
whole
plan.
C
B
Do
you
think
either
that
accurately
would
be
reflected
by
a
workflow
label?
So
you
know
I.
If
something
has
an
implementation
plan,
and
we
can,
we
can
include
the
implementation
plan,
is
so
basic
that
it
doesn't
Warren
writing
in
that.
But
if,
if
we
haven't,
if
we
know
it's
going
to
take
time,
you
know
hour
to
to
dig
in
and
figure
out
what
and
where
Etc.
Then
it's
not
ready
for
development
and
it's
kind
of
again.
C
That
would
make
sense
to
me
it's
like,
but
I'm,
not
a
PM,
that
makes
more
work
on
the
piano
size,
because
then
they
have
to
move
all
of
those
things
along
or
or
deal
with
them.
But
honestly,
that's
you
know,
just
like
it's
part
of
the
engineer's
job,
to
write
a
good
Mr
description
and
and
describe
everything
as
part
of
the
PM's
job,
the
triage
every
history
that
comes
through
and
make
sure
it's
in
the
right,
workflow.
C
But
I
think
that's
sort
of
it's
orthogonal
to
me,
preferring
to
leave
instead
of
the
instructions
and
comments
like,
even
in
addition
to
the
comments
like
an
actual
to
do
like
you,
must
delete
this
to
do
and
put
something
in
here.
Otherwise,
by
definition,
it's
gonna
tell
people.
This
was
not
filled
out
yeah,
not
even
looked
at
right.
A
C
A
Of
what
I
think
would
be
helpful
instructions
to
making
issues
it's
active
for
contributors,
so
this
is
at
the
top
of
it
of
do.
We
have
an
investigation,
implementation
plan
or
possible
fixes
section
and
then
I
think
somehow
finding
a
nice
way
to
leave
these
like
canned
responses
of
like
not
applicable.
This
is
super
trivia
or
to
do
we're
gonna
ping,
someone
or
to
do
like
hey,
we
gotta,
we
gotta.
A
B
B
A
A
A
C
B
Yeah-
and
it
is
interesting
because,
as
I
say,
if
you
look
at
the
quick
win
labels
and
I'm
sure
I'm
guilty
of
this
as
well,
that
things
on
the
surface
can
often
seem
like
a
quick
win
and
then
when
it
comes
to
it,
we
we
did
have
a
good
example.
Earlier
in
the
week,
you
can
pass
a
negative
time
estimate
for
a
an
issueable
and
just
adding
some
logic
in
to
prevent
a
negative
time
estimate
seems
like
a
quick
win
right,
but
then
it's
well
there's
the
rest.
B
C
C
You
can
still
make
an
issue
and
start
it
and
wait
it
yourself
if
you
want,
but
the
standard
way
is
that
the
team
collectively
discusses
every
prioritized
issue
and
does
Rosh
humble
rock
paper
scissors
to
throw
a
Fibonacci
weight,
and
that
is
the
opportunity
for
at
least
everybody
on
the
team
to
contribute
to
say
no.
This
is
actually
a
five,
you
know,
or
this
is
actually
a
three
year
this
actually
has
to
be
broken
down.
C
A
A
So
what
do
you?
What
do
you
think
of
the
one
is
I'm
sure
that
there's
a
better
way
to
present
this
than
a
blob
of
text
that
No
One's,
Gonna,
read?
I,
say
this
as
someone
that
tends
to
not
read
Blobs
of
text,
I,
guess
what
my
eyes
do
is
I'm
like
I'm
like
a
I'm
like
a
model
that
just
looks
for,
doesn't
actually
read
the
text
which
is
tries
to
gain
the
sentiment
of
it.
C
A
B
B
A
B
C
B
You
could
even
argue
because
these
then
links
is
the
the
handbook
as
well,
but
we're
not
going
to
go
to
the
handbook
every
time
and
read
the
entire
documentation
on
like
the
issue
workflow
and
how
to
create
a
good
issue.
It's
it's.
You
know
like
we've
got
to
be
somewhat
realistic,
yeah,
but
again
some
people
hate
the
Bots.
You
know
so
it's
really
hard
to
come
up
with
this
Middle
Ground
I.
A
We
gotta
update
the
templates
I'm
inclined
to
do
that.
The
Bots
I
know
I
won't
be
able
to
respond
to
as
well,
because
like
I've
already
moved
on
and
when
a
bot
tells
me
to
do
something.
That's
just
going
to
be
another
to-do
on
my
large
to-do
list
that
I'm
not
I,
may
not
be
able
to
get
to
you
and
I
may
forget
about,
and
those
are
all
real
possibilities,
the
the
so
ideally,
we
won't
need
a
bot.
A
Exactly
like
look,
we
don't
even
have
features,
we
just
have
feature
proposal,
but
we
don't
even
have
like
an
implementation
issue
or
something
like
we're
just
doing
a
here's.
The
next
step
of
the
thing
that
I
need
to
do
and
if
we
have
issues
for
those
types
that
we're
using
all
the
time
oh
yeah,
they
even
yes
that'd,
be
so
great
and
they
even
implied
they
even
said.
A
A
A
B
One
is
to
improve
the
templates.
Another
is
to
potentially
use
some
automation
as
well.
That
is,
you
know,
starting
at
a
certain
workflow
and
reminding
people
if
they
set
to
some
other
workflow,
but
it's
missing
something
that
would
normally
be
associated
with
that.
You
know.
Oh
you've
said
it
ready
for
development,
but
it
hasn't
got
away
or
already
developed,
but
it
hasn't
got
an
implementation
plan.
Those
kind
of
things
could
all
maybe
work
together.
A
A
A
B
A
B
A
B
B
A
But
I
almost
want
to
always
call
it
like
yeah
I
guess
we
can
call
it
implementation
plan
I.
Think
across
all
of
the
issues.
I
want
to
call
this
investigation
slash
implementation
plan-
let's
just
let's
just
call
it
one
section
for
that
bit
and
I
agree
possible
fixes
are
really
great
because
the
possible
fix
could
be
applied
to
like
just
fix
them,
not
details
that
we
haven't
actually
done
investigation.
A
B
Because
you
invest
the
guy
in
order
to
come
up
with
the
implementation
plan,
so
you
might
have
investigated
it
and
said:
look
you
know,
I've
found
that
this
method's
being
called,
but
more
than
that
I
I,
don't
know
or
you
might
be
able
to
have
gone
deeper
and
said
yeah.
This
is
being
called,
but
this
isn't
and
it's
because
of
this
or.