With GitXiv as one commenter also implied we really want to focus on building a bridge between the 2 core issues of making real research possible/replicatable: articles & code (of course with the 3th even more difficult problem to solve being "data"), as well as building a community around it.
Another point of focus is making everything what goes on with GitXiv as transparent as possible, ie by having public "issues" at github (https://github.com/samim23/GitXiv/issues), and open discussions at our wiki: https://github.com/samim23/GitXiv/wiki/Thoughts-on-GitXiv
I was thinking the same. In our current era of always-on info saturation, a blog may prove to be more adequate for science divulgation and peer-review than the older journal format.
If I understand the article, the goal of the site is not merely to provide a toolkit for collaboration but to build a community around it - which is critical if they want to achieve adoption.
With Gitxiv, two minutes after following the link and reading the blurt, I have access to a continuous stream of projects organized in categories, to which I can post comments - in essence, it's a blog focused on CS news, which also can be used to kickstart collaboration. This already provides me with value even if I don't intend to use the platform. It's a neat approach for filtering the noise and providing a strong signal.
Is it just me with my limited sample or is there a huge trend towards recurrent neural networks, deep learning, and natural language processing right now?
This, combined with other sources, could be a good way to find indicators of what we should all be brushing up on.
top abstract = human readable overview of what paper/code describes. the other abstracts are paper/code specific - which often deviate allot. The aim is to give you an overview at a glance. If you have ideas on how to improve, please post them on our github issues page, always open for great suggestions!
But then, isn't it better to have one high-level overview instead of 3 overlapping overviews? (3 overviews do not make it easier to get a quick grasp of the project.)
I don't have a quick solution - it's much matter of taste (and balance).
BTW:
- Any plans to add some external measures of interest? (E.g. GitHub stars, arXiv trackbacks, SciRate scites/# of comments?)
The authors often don´t provide one or the other, so we opted to give them choice over convention. API integrations are planned down the line. As well as using machine learning techniques to cut down on noise.
I suppose the idea is allowing more than a single paper and/or implementation in each topic, since a certain paper can have a follow-over or technical report and be implemented in different languages or over different frameworks.
yes you nailed it. At the moment if there are multiple implementation the author can just (rather arbitrarily) add the github implementation he/she likes the most as "github" link, and other code implementations as side links. ie rnn-char (http://gitxiv.com/posts/W6Y3pLrEAG5jmuJzz/char-rnn) main and original torch implementation, with to the side extra info + links to pure python, chainer, caffe (apollo).
Maybe not the most elegant solution, but it works for now :)
