> Often people who are not developers put "issues" into the bug tracker and they might not find working with the command-line easy. IME it's best not to have n

> Often people who are not developers put "issues" into the bug tracker and they might not find working with the command-line easy. IME it's best not to have non-technical people entering bugs, they should be submitting through email, a simple form, automated crash tracker or something along those lines. Most issue trackers will contain so many fields that will make zero sense for someone outside (or even inside) your organisation. They won't know the priority, the won't know the component, they can't find relevant logs to attach, they don't know the internal workflow, they aren't familiar enough to search for similar issues. And that's before you get to the corporate mandated fields, there's some on our issue tracker I don't know, I have no idea if something is capitalizable. Similarly I don't think I've ever put in a successful request to our internal desktop support system, I have no idea what their division of responsibilities are and somehow always select the wrong team. I've become quite religious about creating issues on behalf of people when we get support requests or relevant lunch room chats, otherwise nothing makes it up their side of the corporate org chart and back down ours.