So, I used to think that it would be a good idea to give the customer access to the issue tracking system, but now I've seen that it creates less than ideal situations, like:Customer judging progress solely on ticket countDevelopers denied to add issues to avoid customer thinking that there is less progressCustomer appointing people on their side to add issues who don't always do a good job (lots of duplicate issues, insufficient information to reproduce, and other things that distract people from doing their real job)However, I think customers should have access to some indicators or proof that there is progress being done, as well as a right to report bugs.So, what would be the ideal solution to this situation?, specially, getting out of or improving the first situation described?
What level/format of access should be given to a client to the issue tracking system?
project management;agile;issue tracking
It's hard to say. To use an analogy some restaurants allow you to see into the kitchen so you can see how hard the chefs are working. Some don't. However, we're programmers not chefs. I would say you need a forum where developers can be honest so as work can get done. The solution is either to adjust the security settings so some things stay private (we have this at my current place of work) or to see if it is possible to better educate your customers. Judging productivity on ticket count is a bit like judging a horse's performance in a race on the amount of hay it's been eating. The system we use is ZenDesk. This allows our customers to submit tickets but we use permissions to keep some things private.