Hi Trevor, This is an interesting question, and I don't have a clear cut opinion.
What you are talking about is, in essence a trademark issue: the brand "scikit-learn", carries implications about quality and API. We enforce this on the scikit-learn package and would indeed love if the users associated the name with a good experience. But we are not a powerful multinational with strong legal and marketting departments. We are an open development team built on collaboration and trust. We do not having the branding power to make sure that everything that looks a bit like us has the same standards as us. Nor do we have the resources to talk to all the independent packages. To make an analogy with the past, the idea behind the name "scikit", early on, was that there were many "scikits", that would be sharing an import name: "scikits.learn", "scikits.audio", "scikits.image", "scikits.statsmodels", "scikits.timeseries", "scikits.ann". This idea failed because each scikit lived and died at its own pace, because there was not enough resources for branding and communication to explain the links across the ecosystem. There was effort: http://scikits.appspot.com/ but this has never been enough for things to be clear. People, including very central people, are still these days calling scikit-learn "scikit". We get people submitting issues on our tracker for scikit-image. In my experience, there is only so much that we, as a team, can control. That said, beyond control: what should be the recommendations? My recommendation should be to make it very clear that the package is not scikit-learn, and to explicit the relationship with scikit-learn. We want to avoid to confuse users. That implies using a graphical design that is not too close to ours. Beyond that? Well I would argue for quality :). And it would help on our side if we could make the estimator common tests easier to use from the outside. And a final remark with regard to the name: gplearn is a name that I would read as "Gaussian Process learn". Acronymes are rarely unambiguous and we try to avoid them for this reason. Thanks for asking! Gaël On Mon, Apr 27, 2015 at 08:33:22PM -0700, Trevor Stephens wrote: > Hi All, > I've been working for the past month or so on a third-party add-on/plug-in > package `gplearn` that uses the scikit-learn API to implement genetic > programming for symbolic regression tasks in Python and maintains > compatibility > with the sklearn pipeline and gridsearch modules, etc. The reason it is not > being pushed as a PR is due to unproven usefulness in the scikit-learn > ecosystem, which comes up a lot on the GitHubs for major additions. > I am edging my way towards a release now with docs and examples in process and > thus have a general question about the use of parts of the scikit-learn logo > found here: > https://github.com/scikit-learn/scikit-learn/blob/master/doc/logos/ > identity.pdf > I would like to incorporate the 'learn' font into my own package's logo, > here's > the current draft: https://files.gitter.im/trevorstephens/lqYX/gp-learn.png > I noticed that `nilearn` shares the 'learn' font from sklearn's logo, though I > understand a lot of the same core devs work on it. I see a few pros and cons > to > allowing, or encouraging this: > Pros: > - encourages contributors to try out their algorithms in the wild to gauge > usefulness while still feeling like they are a part of an extended > scikit-learn > ecosystem. > - a lot of PRs fall flat after a lot of effort on the developer's part. As > above, this gives them more of a chance to have something to show for > significant work done, if it is not ready for a prime-time merge. > - encourages a more common naming convention for scikit-learn compatible > estimators for easier PyPI discovery, kind of like the implied link back to > scipy toolkits with the various scikits. > Cons: > - may carry an implication that the code is reviewed and +1'd by the core > devs, > which it clearly is not. > - that's all I can think of, open to hear other objections. > Anyhow, interested in what the core team thinks about this and am excited to > release my package, with or without the script MT bold fanciness. > Cheers, > - Trev > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Scikit-learn-general mailing list > Scikit-learn-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/scikit-learn-general -- Gael Varoquaux Researcher, INRIA Parietal NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France Phone: ++ 33-1-69-08-79-68 http://gael-varoquaux.info http://twitter.com/GaelVaroquaux ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Scikit-learn-general mailing list Scikit-learn-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
