Inclusion of KShifts and / or Quickshift?

[rened]

Would there be interest in having https://github.com/rened/KShiftsClustering.jl included here? I have not registered KShiftsClustering with METADATA yet. Or we keep it separate, whatever you think is best.
It is basically a one-iteration kmeans algorithm, similar to self-organizing maps.

[rened]

There is now also https://github.com/rened/QuickShiftClustering.jl. Shall it live in a separate package or shall I work on a PR to include it here?

[ViralBShah]

Ping @johnmyleswhite. It seems to me that it would be a good idea to put energies into one package here.

[johnmyleswhite]

My concern here is that there is no one who's actively maintaining Clustering, so I'm hesitant to add new functionality.

[rened]

Then let's keep it separated for now I would propose. We can always revisit this when the future for Clustering.jl is more clear.

[jpfairbanks]

Is there anything worth saving here? Are the interfaces the right way to do it and just the code is rotting?
It looks like the tools for measuring clustering success are useful. I would hate to throw away good code because no one cares to maintain it. If there are better clustering packages, then I would like to know about them.

I am able to help maintain it, although I am not a clustering expert.

[johnmyleswhite]

Nothing is rotting: the code is completely stable and should not be thrown out.

My point is only that I would like us to stop accruing new features until we start accruing developers that we can trust to take over maintenance of these packages. Adding features is too risky given our labor resources, since we clearly don't have the resources to even respond to the currently open pull requests.

If you have time to review and comment on the existing pull requests, that would be amazing. Once you've done a little bit of maintenance work, I'm happy to give you commit access to this package.

[jpfairbanks]

Ah I misunderstood the situation thanks for giving more detail. I will take
a look at some pull requests and issues.

On Wed, Mar 18, 2015, 12:15 PM John Myles White [email protected]
wrote:

Nothing is rotting: the code is completely stable and should not be thrown
out.

My point is only that I would like us to stop accruing new features until
we start accruing developers that we can trust to take over maintenance of
these packages. Adding features is too risky given our labor resources,
since we clearly don't have the resources to even respond to the currently
open pull requests.

If you have time to review and comment on the existing pull requests, that
would be amazing. Once you've done a little bit of maintenance work, I'm
happy to give you commit access to this package.

—
Reply to this email directly or view it on GitHub
#40 (comment)
.