The MSDN help for FxCop rules is extremely helpful. It should be easier to create similar help for analyzers. See https://msdn.microsoft.com/library/ms182363.aspx

Creating similar pages and keeping them up to date is going to be a real pain for community analyzers. This seems unnecessary since much of the information is available in the analyzer and much of the remainder could be considered valuable to be stored in the analyzer. This would allow a "one stop shop" for creating both analyzers and default documentation for them.

If there is helplink or no page found, use information from the analyzer to create the following display (possibly through a webservice):

• A block similar to the top of the MSDN pages that includes the basic information from the analyzer
• Include in this block default severity and enabling
• If there are fixes available, at least their names and descriptions listed
• Cause: anticipate new overload for DiagnosticDescriptor constructor or well known custom tags
• Description: from DiagnosticDescriptor constructor)
• How to Fix and When to Suppress: anticipate new overload for DiagnosticDescriptor constructor or well known custom tags
• A standard test format that allows use of test code for Examples - both violating (DiagnosticResult != null) and not-violating (DiagnosticResult == null) inside the test.
• Assuming the preceding test format is one set of sample code per test, an attribute on the test that would allow comments on that particular example
• Do a moderate level of diffing to ensure that multiple tests on the same code (such as to ensure correct location for squiggles) do not result in redundant examples. Probably also have an attribute to skip a test or identify prototypes for examples.

Note that the above 3 suggestions would result in text/code, text/code