"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.
> 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
Admittedly it's a minor issue, but overzealously enforcing "keep titles short" will make titles less descriptive.
Doing so is also drastically reducing the amount of misunderstandings and the length of your Scrum meetings.
(Edit: maybe it seems superfluous because I typically want notifications for everything in the repositories that I have greatest interest in)
What's your take on using labels?
I also followed this up a bit by solidifying our CONTRIBUTING doc: https://github.com/BroadleafCommerce/BroadleafCommerce/blob/...
