3 ms·

> A bad issue: too much in the title. "Fixing the performances after the rollout of the last Express.js" is much more descriptive than "performance tool in dev

> A bad issue: too much in the title. "Fixing the performances after the rollout of the last Express.js" is much more descriptive than "performance tool in development environment". Descriptiveness counts—scanning through a list of issues I'd know immediately what the first one entails. I wouldn't with the second. > Keep titles short and descriptive. Yes to descriptive, no to short if you're compromising on descriptiveness.

hunvreus 13y ago
That'd depend of the context. If you have a lot of issues related to Express/performance, then maybe being slightly more verbose is the way to go.
- beaumartinez 13y ago
  Say you revisit that issue in three month's time. Would you know what the cause of the "performance tool in development environment" issue was? Probably not. "Fixing the performances after the rollout of the last Express.js" tells you straight away though. Admittedly it's a minor issue, but overzealously enforcing "keep titles short" will make titles less descriptive.
  - dikunlun 13y ago
    It is a good point. However by keeping most of the issues in a milestone and making sure those issues are based on actual deliveries help to keep things in context without a need of a fully verbatim title. This will be the subject of another post.
sberder 13y ago
I like short titles with labels in addition to create the context. I find it the best mix for me.
kibwen 13y ago
Came here to echo this sentiment. I find that Github's issue search is so painful that long and overly-descriptive titles are essential for finding anything relevant, especially in a project that uses issues extensively.
skidding 13y ago
Couldn't agree more. Within a max num of characters previously established, a title shouldn't be minimal, but say as many things as possible, if they are explicit and clear. > People's attention is hard to capture, even your colleagues. True, that's why communicating as much as possible from the title is important, because you don't always expect them to click and "zoom in" --- Github issues are also essential where I work. We're trying to make them BDD stories, emphasizing most on the customer need and the WHY, followed by what (deliverables) and how (solution) We went the extra step to have a template that we apply before starting any new issue. I even wrote a Chrome extension a while back, that reads that issue template from an open source repo and applies it in the textarea when you open the /issues/new page on Github. https://github.com/skidding/github-issue-template https://github.com/skidding/github-issue-template

hunvreus 13y ago

That'd depend of the context. If you have a lot of issues related to Express/performance, then maybe being slightly more verbose is the way to go.

beaumartinez 13y ago
Say you revisit that issue in three month's time. Would you know what the cause of the "performance tool in development environment" issue was? Probably not. "Fixing the performances after the rollout of the last Express.js" tells you straight away though. Admittedly it's a minor issue, but overzealously enforcing "keep titles short" will make titles less descriptive.
- dikunlun 13y ago
  It is a good point. However by keeping most of the issues in a milestone and making sure those issues are based on actual deliveries help to keep things in context without a need of a fully verbatim title. This will be the subject of another post.

sberder 13y ago

I like short titles with labels in addition to create the context. I find it the best mix for me.

kibwen 13y ago

Came here to echo this sentiment. I find that Github's issue search is so painful that long and overly-descriptive titles are essential for finding anything relevant, especially in a project that uses issues extensively.

skidding 13y ago

Couldn't agree more. Within a max num of characters previously established, a title shouldn't be minimal, but say as many things as possible, if they are explicit and clear. > People's attention is hard to capture, even your colleagues. True, that's why communicating as much as possible from the title is important, because you don't always expect them to click and "zoom in" --- Github issues are also essential where I work. We're trying to make them BDD stories, emphasizing most on the customer need and the WHY, followed by what (deliverables) and how (solution) We went the extra step to have a template that we apply before starting any new issue. I even wrote a Chrome extension a while back, that reads that issue template from an open source repo and applies it in the textarea when you open the /issues/new page on Github. https://github.com/skidding/github-issue-template https://github.com/skidding/github-issue-template