Author Topic: Techniques for self-debugging support issues (proprietary code)  (Read 2320 times)


  • Senior Community Member
  • Posts: 303
  • Hero Points: 27
There is one thing that is bugging me when working with SE. When there is something that seems like a bug in the program, it is very difficult for me to report the problem and receive help from support. I can't send my project to support because this is a proprietary code. I can't send my configuration directory neither - things like project names, file names and other stuff included in configuration directory are proprietary information too and I am not supposed to share it with anyone. So eventually, I have to either come up with some dummy project that reproduces the problem or just ignore the problem. Unfortunately I have very little spare time, so I can't spend too of it on reproducing the problem.
Eventually, most of the problems I see remain unaddressed.

I would really like to see this problem addressed in future releases. This means better support process. Also, this may mean tools that will help me analyse the problem myself. For instance, today in case of tagging problem, I have some old email I received from support explaining what I should do. The procedure works most of the time, but it is way too long and cumbersome. I believe there is number of such procedures for various problems. I am sure that such procedures can be mostly automated. Some procedures can be changed to rely on some new tools. For instance, tagging related problems may benefit from a tag file explorer that would give me all kinds of information about tags found in the project and in specific lines in project's files. This will both improve support process and benefit users who cannot or don't want to ask for support.
« Last Edit: April 06, 2011, 08:47:28 AM by asandler »