Ask HN: BugsEverywhere was a great idea – why didn't it catch on?

I'm also someone that fell in love with the concept of issue databases as source control artifacts.

I think the biggest problem is always going to be the "Stakeholder" issue, and just about everyone else is touching on this too. Issue databases solve a number of different problems for a number of disparate roles of people. As much time as developers spend embedded in an issue tracker, you also have PMs, Managers, Executives, Clients, Customers, Testers, and sometimes a panoply (or even panopticon) of all sorts of other "stakeholders" with one reason or several to be in and out of an issue database scattered across a wide variety of technical acumen.

For anything more than a small team of only technical people, one or more systems of reporting (in either direction) becomes generally required. Can Clients or Customers submit new issues easily? Can PMs (or Managers or Executives) get the reports they need? Can Testers accept issues as completed or file new bugs on them?

There's so much more workflow than just the Developer side of things, for better and sometimes for a lot worse. (The "Jira Effect" where nearly every issue tracker eventually seems to succumb to becoming a super-configurable business workflow engine with a built-in CRM and a support desk ticketing system and a hideous kitchen sink with terrible load times.)

There's probably still a chance to find a really good sweet spot for distributed issue tracking that has just the right amount of bidirectional reporting to fill an average development team and their stakeholders' needs, but it's probably going to take a smart UX team to do it. A CLI-only approach seems unlikely to work, again just given the huge swath of technical acumen to be found with fingers in an issue tracking pie.

from Hacker News https://ift.tt/2LMV1Ra