Move planning/organizational discussions here

[tbreloff]

See:

• https://github.com/JuliaStats/Roadmap.jl/issues/11
• https://github.com/svs14/Orchestra.jl/issues/4
• https://github.com/Evizero/LearnBase.jl/issues

[Evizero]

To get things going I propose to move ValueHistories.jl here. It's already functional and in METADATA (which I think shouldn't be a problem for ownership transfer?) and it fits to the spirit of this org. I would still take responsibility for maintenance.

[Evizero]

Concerning mailing list: I think we should probably piggyback on the julia-stats mailing-list instead of julia-users (which is currently set as mail address for the org)

[ViralBShah]

We should probably move some of the JuliaStats ML repos here too.

[tbreloff]

Some potential candidates for moving here from JuliaStats:

• Lora
• Clustering
• MLBase
• SVM
• PGM

In addition, I think it would be great to start a wiki/webpage with some summary info on the currently available packages, with information on maturity, status (abandoned, well maintained, etc), and a list of features/algorithms. Should we use the wiki in this repo, or maybe start a website like http://juliastats.github.io/?

[ViralBShah]

Ping @simonbyrne and @johnmyleswhite

[simonbyrne]

I think the decision of whether to move a package should be up to the package maintainers, or in the case of unmaintained packages, only if JuliaML is willing to take over maintenance.

[ViralBShah]

Of course - I was only referring to the ones in JuliaStats. Perhaps having them here instead of JuliaStats might increase the likelihood of maintenance.

[Evizero]

I would volunteer to actively maintain MLBase.jl (if you'll have me). I'll make an effort to maintain it's original author's style in terms of being minimalistic and in terms of how the code is structured and commented

My plan for it would be:

• Make sure it defines all the verbs for all common metric (such as the missing accuracy from that PR)
• Move the code for the common classencodings there, (which build on labelmap anyway)
  • this also includes the abstract baseclasses for e.g. EncodedStatisticalModel that is currently in LearnBase.jl
• Enable testcoverage and see if there are missing tests
• Make sure the code stays up to date
  • remove compat
  • use slice instead of ArrayViews
• include function documentation using the 0.4 doc system
• maybe make the readme a little more informative... Might just be personal preference though

cc: @lindahua

[simonbyrne]

@Evizero I'm not particularly familiar with that package, but that seems like a good candidate to move. Perhaps open an issue in the repo? Requests to take over maintenance are viewed more kindly when accompanied with pull requests.

[Evizero]

@simonbyrne I generally agree with you, but in this case I rather wait for Prof. Dahua Lin's opinion on this instead of prematurely putting work into a PR. Maybe he feels like MLBase should remain as it is now, I don't know. As far as I can tell he is the main author, so it's his decision.

The general idea is this: I am not desperately looking for work, but I do want to devote some of my spare time to maintaining important Julia ML functionality

[Evizero]

Concerning moving repos here. In the meantime it might be a good idea to fork some of the really mature and currently maintained packages (for visibility).

Edit: I forked Mocha.jl, SVMLightLoader.jl, and MLKernels.jl. These are the ones I have confidence in are mature and up to date, or am actively working with myself

[Evizero]

By the way, JuliaML kinda aims in the direction of the umbrella Org that was proposed by @pluskid at the JuliaStats roadmap. It might be a good point in time to continue that conversation now. Given the importance of deep learning, it should undoubtedly be a focus of us as well. I know I will be more active in that area once my KSVM package is stable.

Given his contributions to the ML community of Julia I also think he deserves an invite if he is interested to be part of this org.

[pluskid]

I just came across this repo: https://github.com/JackDunnNZ/uci-data It looks quite useful. Probably should add to our list of packages (if someone could test a bit to see e.g. the compatibility with latest Julia).

[Evizero]

Interesting. I'll take a closer look at it in about a week or two. Datasets are complicated. One has to be careful with licensing issues

[Evizero]

I will close this issue for now. I have come to appreciate that growing naturally seems to be quite more manageable and less likely to cause friction between communities.

It seems that we evolved more into a "create basic functionality we all need together" community, than a "let's move our current stuff here" group. I consider this a good thing.