Comment by jasode

>So use a real issue tracker.

That's a reasonable answer -- but it's an answer to question I wasn't addressing. Whether github reinvents the wheel is not relevant to my point.

I was specifically debunking the illusion that "simplicity of the issues submission form == no cognitive overhead".

If the "issues creation" web form is lightweight, the submitters will eventually expend "cognitive overhead" by clogging up the threads with clarification messages.

If the project maintainer uses your solution of an external tracker, that means the submitter still expends cognitive overhead by noticing that the project's "issue tracking" has been disabled, and then reading front page README.TXT or CONTRIBUTIONS.TXT to figure out what external website he's supposed to use to submit issues. No doubt the web forms[1] on those external trackers will have the checkboxes and dropdowns that some people are suggesting people avoid.

The "cognitive overhead" required to clarify and provide meta-descriptions for bug reports is inescapable. You're only deciding whether it is structured or unstructured and where it is shifted.

Your reply is going in different direction from cognitive overhead and on that perspective, I don't know what makes the most sense. My guess is that many open source maintainers don't need a heavyweight tracker that can do things like assign tasks to multiple programmers, burn down dashboards, correlate activity hours to billing, etc. They don't need all that. They just want a template to improve how users file issues. Maybe a survey would provide insight as to whether your answer is the most sensible.

[1]https://www.google.com/search?q=jira+submit+issue&source=lnm...