Before closing a Bug in ESRI software, reach out to the customer who found it to approve the resolution, work around or closure of the defect.

07-10-2020 11:32 AM
Status: Closed
Occasional Contributor II

Before closing a Bug in the ESRI software, reach out to the customer who found it to approve the resolution, workaround or reason to close it.

Recently the ESRI development team decided not to fix a bug I found without any interaction with me. (#BUG-000130643) 

There is no way to interact with the team that made the decision. Technical support are not able to reopen bugs.

I also work in IT. If I fix a defect in an application I have to get approval from the customer that the resolution is acceptable before closing the ticket. Please make this standard practice at ESRI.

Please enhance ESRI customer service and have the development team work directly with customers on resolving bugs.

1 Comment
Status changed to: Closed

Hi @FionaRenton1 I apologize that you encountered this bug and that there was confusion around its handling. In the end, the bug you refer to was addressed, and the following explanation was provided through Support channels:

"This is a duplicate of BUG-000130328: While this was previously a known limit, an enhancement to the Create Feature Class tool and a refinement of the XY Table To Point code result in the desired behavior in ArcGIS Pro 2.7."

I appreciate the spirit of this idea; however, it would likely prove to be a burden to ask customers to install development builds on their machines (I imagine some wouldn't be able to as many bug fixes are installed before the software is even in beta stages so organizations may not allow it) to test a fix. This is why it is so important that bugs contain clear, concise and easy to follow steps to reproduce, along with any specific data that may be necessary to reproduce it. That way, a Product Engineer can confirm the bug on the released version of software, work with a developer to fix it, and then verify that following the same steps to reproduce, etc. does not demonstrate the bug after the code change. It is our job to take on that testing and verification burden - you have already had to invest your valuable time to report the issue to us and we acknowledge and appreciate that.

I want to provide further clarity around a couple of other points in this idea:

>>"There is no way to interact with the team that made the decision." While it is true that you are not able to directly call and talk to somebody on the development team, if a bug is severely impacting your business/workflows, there is a process to escalate an issue. See Escalations with the business justification provided do go directly to the responsible development team so that they can better understand the bug's impact (if that was not fully conveyed at the time of logging the bug) and re-assess whether the issue can be addressed.

>>"Technical support are not able to reopen bugs." This is not true. If needed, bugs can be re-opened to be re-assessed.

I hope that this explanation provides additional context into the reported situation. We are continuously working to improve issue management and communication between support teams, development teams, and customers. If you do encounter an issue in the future, please do contact Technical Support with the bug # and further information so that it can be re-assessed. 

Thank you.