I suggest we should enforce checkstyle on build, i.e. let the build break if the code does not follow the style. (Or maybe just warn about it)

Test with "mvn checkstyle:checkstyle" and "mvn checkstyle:check"

Check all errors: "mvn checkstyle:checkstyle-aggregate" and look at output in rival/target/checkstyle-result.xml

Implement evaluation according to http://graphlab.com/files/lsrs2013/paper_12.pdf

This will likely have to be an evaluation strategy taking a different strategy as input since the per-user evaluation does "standard" evaluation for each user and then averages the results.

I propose we do a feature freeze for the current master branch, any additions should/could go into a v2.0 branch that we merge into the master once it's tagged/released.

The only thing left prior to 0.1 is to finalize the maven-site stuff (see 917788f), although I think most of the stuff I want to add (github maven-site plugin https://github.com/github/maven-plugins) could go in to v0.2

(answer and close issue if there are no questions)

Write basic javadoc for variables.

At least the cross-validation script.

The error appears because the tail does not consider the reminder part of the splits.

Parsers should be able to read compressed files.

We ought to standardize our API so as to keep compatibility between versions.

Ideas? Comments?

Write basic javadoc for variables.

Should each sub-module contain main methods or should we move these out to a separate sub-module (e.g. rival-examples which would provide example instances of the various functions of rival).

In the use case of including rival as a dependency to perform eval on an external project, the main methods are redundant. Probably we need to rethink how we're instantiating the different processes.

We need to set up proper logging and make sure we log things in new (and already implemented) classes.

Now that there are metrics, there should be runners, or, at the very least, examples of how to use the, e.g. https://github.com/recsyschallenge/RSChallengeEval/blob/master/src/main/java/com/recsyschallenge/evaluate/Evaluator.java

Create JavaDoc for methods and classes

Write basic javadoc for variables.

Python interface through JCC or similar
https://pypi.python.org/pypi/JCC/2.12

Write basic javadoc for variables.

Create a module with examples, i.e. the complete process from data splitting to recommendation to evaluation.
This should contain at least one example for LensKit, one for Mahout, and a few data splitting strategies.
Think something similar to the examples in Mahout, just to help people get started.

Possibly aim at having this done for v0.2-M1

Please assign basic eval metric creation/classes to both of us.
We probably need to figure out how to start the implementation as well.

Create wiki pages containing information on main classes, how to run the steps, etc.

Create JavaDoc for methods and classes

Getting weird results for NDCG, please do unit tests

Update wiki, provde example code.

Create JavaDoc for methods and classes

Related with split subproject

See b40a05f
Document the undocumented fields and exceptions

[WARNING] /workspace/rival/rival-split/src/main/java/net/recommenders/rival/split/parser/LastfmCelma1KParser.java:17: warning - Tag @inheritdoc cannot be used in class documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-split/src/main/java/net/recommenders/rival/split/parser/LastfmCelma1KParser.java:39: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-split/src/main/java/net/recommenders/rival/split/parser/LastfmCelma360KParser.java:15: warning - Tag @inheritdoc cannot be used in class documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-split/src/main/java/net/recommenders/rival/split/parser/LastfmCelma360KParser.java:37: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-recommend/src/main/java/net/recommenders/rival/recommend/frameworks/mahout/GenericRecommenderBuilder.java:55: warning - [at]return tag has no arguments.
[WARNING] /workspace/rival/rival-recommend/src/main/java/net/recommenders/rival/recommend/frameworks/mahout/GenericRecommenderBuilder.java:70: warning - [at]return tag has no arguments.
[WARNING] /workspace/rival/rival-recommend/src/main/java/net/recommenders/rival/recommend/frameworks/mahout/GenericRecommenderBuilder.java:85: warning - [at]return tag has no arguments.
[WARNING] /workspace/rival/rival-recommend/src/main/java/net/recommenders/rival/recommend/frameworks/mahout/GenericRecommenderBuilder.java:102: warning - [at]return tag has no arguments.
[WARNING] /workspace/rival/rival-recommend/src/main/java/net/recommenders/rival/recommend/frameworks/mahout/GenericRecommenderBuilder.java:115: warning - [at]return tag has no arguments.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/error/AbstractErrorMetric.java:46: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/error/MAE.java:20: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/error/MAE.java:28: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/error/MAE.java:38: warning - [at]return tag cannot be used in method with void return type.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/error/RMSE.java:20: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/error/RMSE.java:28: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/error/RMSE.java:38: warning - [at]return tag cannot be used in method with void return type.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/ranking/AbstractRankingMetric.java:30: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/ranking/MAP.java:21: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/ranking/NDCG.java:37: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/ranking/Precision.java:21: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/metric/ranking/Recall.java:22: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/strategy/AllItems.java:16: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/strategy/TestItems.java:16: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/strategy/TrainItems.java:16: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.
[WARNING] /workspace/rival/rival-evaluate/src/main/java/net/recommenders/rival/evaluation/strategy/UserTest.java:17: warning - Tag @inheritdoc cannot be used in constructor documentation. It can only be used in the following types of documentation: method, inline text.

We should figure out what to prepare for a first release.

My thoughts are that the core, split, recommend modules are in a state that is "releasable". We need to have some structure in the eval module.

@abellogin can you create and assign issues for metrics in eval that we should implement?

(use the comments for discussion).

More thorough test cases are needed (not only checking for 1.0)

Implement a splitting strategy according to
http://graphlab.com/files/lsrs2013/paper_12.pdf

Create rival-wevapp.
Should include:

• file upload
• selection of metric
• basic metric output

possibly for v0.3 or above.

We have single and multiple runners, but right now there is no clear relation between them (i.e., if we change something in the single runner we will have to modify that also in the runner to parse multiple strategies, for instance).
We should generalize the multiple runners so that they use the code implemented in the single runners.

Like MultipleRecommendationRunner in recommend subproject

This is in progress already

Fix basic documentation for new metrics.

Fix authorship of your classes.
I propose to use: Name making links appear in properly in javadoc.

Example in net.recommenders.rival.core.DataModel

Create JavaDoc for methods and classes

Complete overhaul of tests.
Increase coverage of tests.

See b40a05f
There's a bunch of undocumented exceptions etc.

Fix authorship of your classes.
I propose to use: Name making links appear in properly in javadoc.

Example in net.recommenders.rival.core.DataModel

Extract all property reading to class in core instead of current management in each class using properties.

C# interface through IKVM or similar
http://www.ikvm.net/