Create yellowbrick.contrib and deprecate non-core visualizers

I that we should create a yellowbrick.contrib module to store visualizers, utilities and other functionalities that are prototypes, works in progress or just plain experimental.

For the core of Yellowbrick, only highly stable, fully tested, high value added and well documented visualizers and etc should be allowed to pass in.

I think that the first step should be to identify visualizers that are be suited for contrib and add a depreciated warning to them with a note that they are moving to contrib.

I propose using the deprecation library to do this. It seems stable and well tested. http://deprecation.readthedocs.io/en/latest/

For initial candidate visualizers to move, I recommend:

• features.scatter.ScatterVisualizer
• classifier.boundaries.DecisionBoundariesVisualizer

For experimental utilities, I think that we can also immediately add a basic working implementation of StatsModelsWrapper(BaseEstimator) that was in https://github.com/DistrictDataLabs/yellowbrick/issues/306

[ndanielsen]

@NealHumphrey I agree with the mirroring idea. It’s probably the most maintainable as well.

As for contrib naming convention, I appreciate the rationate behind your suggestions. I do agree with @bbengfort that it is a place for non-core visualizers and other utilities that are out of our core support of scikit-learn and contrb is probably the best name for it. I’ve been thinking that for the prototype / experimentation visualizers, we might want to include a warning with them making it clear that they are prototypes.

@bbengfort I’m okay taking the lead on contrib after I get the initial crop of missing values vizualizers out the door.

[ndanielsen]

I agree with the contrib documentation suggestion. For testing of contrib, I think that it can take one or two options - they can live in test/test_contrib or be right next to the actual files. I’d be fine with either and potentially both as long as we can pytest ignore what we want.

For what is in main vs contrib, I think that we can easily agree on the quality of tests, value and docs around each of them. For the substance of included in the main package, I think that it should be on a case by case basis. I agree that all first time contributors should plan to add to contrib and we can elevate it to the main package if it is makes sense.

There might be certain things like the StatsModelsWrapper that likely should always live into contrib as it is outside of our support ecosystem of scikit-learn unless we explicitly want to change direction.