Update Help Files With Known Issues

[JamieHammermann]

When there are known issues with a particular feature, the description of the issue should be linked or embedded in that feature's help file.  Understanding the limits or bugs in certain features would save users a lot of time.

For example, in the Manage Map Server Cache Tiles tool help file, it would be helpful to have the issue "When using the Manage Map Server Cache Tiles tool in ArcMap, the results do not retain the defined area of interest (AOI)" annotated in this help file.  If a fix is planned, it would be helpful to know the version for the fix (eg. 10.2.1).

[RandyKreuziger]

I forget the details but there was a bug introduced in 9.2 in a command that was never fixed until 9.3.1.  I wasted god knows how long trying to debug a program and then with ESRI support before finding out the command didn't work.  Updating the help page would have saved me time and all the other users who tried to use a command in their scripts that never worked in 9.2.

[JoshuaBixby]

This is a fantastic idea, but one that I can't imagine we will ever see.  The vast majority of Help documentation just scratches the surface, especially with developer-related topics, tools, etc....  One of the biggest hurdles I see to this type of idea is that a large number on bugs aren't even published to ArcGIS Resources.  I have never figured out how they decide what bugs get published publically and what ones don't.

Great idea, though.  Given how common bugs are and how many string are typically attached to tools, this kind of linkage between bugs and Help documentation would be a big time saver.

[KoryKramer]

Unfortunately sometimes there are bugs with geoprocessing tools. In many cases, there are known issues that get carried over from one release into the next, meaning that even though we know a tool won't work as designed, there is no way to tell this even if we diligently read all of the documentation related to the tool. 

If there were a section in tools' documentation that pointed customers to open bugs related to the tool, it would be extremely helpful.

Furthermore, many bugs already have a listed workaround. If we could find the bug and workaround directly from the tool's documentation, this would allow us to continue our work right at that moment, instead of potentially losing days, sometimes even weeks, going through standard support channels.

 

[ShelbySouthworth]

Thanks Kory - beat me to the punch :)

[Bud]

Even if only certain kinds of bugs were included in the docs, that would be a start. For example, bugs where the status is "known limit" or if the bug is older than x years.