Visualizer Audit

[bbengfort]

In preparation for Yellowbrick v1.0 we would like to conduct an audit of the state of Yellowbrick visualizers (both documented and undocumented).

With the idea in mind that the overall purpose of this audit is to get a comprehensive sense of where our visualizer hierarchy is most and least healthy, we should:

• Audit the quick methods, to support the follow-on task Verify and document quick methods #600 (maybe add Cooks Distance?)
• Ensure code conventions are defined in docs
• Build the updated uml diagram of the classes
• Examine for "hot spots" -- this will be places in our class hierarchy where there are attributes/methods missing or implemented in a non-standard way; we'll use the columns of the audit spreadsheet as a de facto health check
• open up follow-on issues to fix things that need to be fixed (i.e. in future milestones). This should ideally on a per-visualizer (e.g. Radviz) or per-visualizer family (e.g. regression visualizers) basis, since this will be easier to distribute across contributors than a task that says, for instance, "update all the classes to make sure fit returns self"

The ongoing audit can be viewed on this google sheets document.

Related issues:

• Code review checklist #345: Code Review Checklist
• Verify and document quick methods #600: Verify and document quick methods
• Estimator Attributes - Naming Convention - Audit #326: Estimator Attributes naming convention
• Test all visualizers against API promises systematically #180: Test all visualizers against API promises programmatically

@DistrictDataLabs/team-oz-maintainers feel free to give suggestions on the things we should be looking for!