Chiming in as a user who never contributed but who uses sklearn a lot
(yeah, I know, I need to find the time to help a a little), I tend to agree
with this.
I know a couple successful projects that have stand alone plugins,
withwithv standardized names and interface and a easy to find curated list
or some kind of advertising about plugins on the main project. Maybe even a
contrib repo which is just a collection of subrepos (but this invites some
maintenance cost danger). Django and Flask are two examples.
In contrast, I know of no successful case of a separate contrib fork or
something like that. It might be better to follow former examples of
success.
That said, I guess every user of sklearn see value in the package exactly
because of the incredible amount of time and effort put in by the
maintainers to guarantee a dependable codebase, with good docs, good
performance, with trustworthy code quality. And for that we should all be
thankful (and also try to help a bit, which I am in debt for). Ruining that
(by overloading the maintainers with work) will ruin the usefulness of the
package.
Em qui, 4 de dez de 2014 06:38, Lars Buitinck <larsm...@gmail.com> escreveu:
> 2014-12-04 0:55 GMT+01:00 Joel Nothman <joel.noth...@gmail.com>:
> > For example, let's say someone has implemented an algorithm (Affinity
> > Propagation is what triggered this discussion so you might consider
> that).
> > Someone else wants to come and add features to it, or even just clean the
> > code, but by this time the original contributor has moved onto greener
> > pastures and is not interested in responding to a pull request. Who has
> the
> > right, and who the responsibility, to say that this change should be
> > allowed? Does the contrib repository, too, require an army of
> maintainers to
> > familiarise themselves with a vast collection of moderate-quality code?
> > Without strict gatekeepers, a centralised repository provides almost
> > nothing, and with strict gatekeepers it entails exactly the issue that we
> > are trying to solve.
>
> My thought exactly. Publishing separate packages is the way to go. The
> other thing we still need to do is implement the utils/_utils split,
> i.e., provide a stable set of utilities for extension writers to use.
> (This is also exactly the part where a forked repo is going to run
> into trouble: utils gets refactored often, without regard for
> backwards compat, and when it is, the fork is either going to diverge
> or all code in it has to be checked and updated.)
>
> ------------------------------------------------------------
> ------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&;
> iu=/4140/ostg.clktrk
> _______________________________________________
> Scikit-learn-general mailing list
> Scikit-learn-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
