GitXiv: Collaborative Open Computer Science | Hacker News Reader

GitXiv: Collaborative Open Computer Science

gitxiv.com

127 pointsarchgoon20 comments

Open articleView on HN

You can read more about GitXiv here: https://medium.com/@samim/gitxiv-collaborative-open-computer...

Previous submission (by me) on related issues...and converging on a similar portmateau:

https://news.ycombinator.com/item?id=9415985

fascinating! had not seen that one yet, nicely formulated. Lets do a hangout sometime soon?

Maybe, I guess. Who are you? Send me an email to my username @gmail.com

Nice post and especially your blog post "gitwikxiv". So many models & projects are already out there: PaperBricks, http://knowen.org/, https://www.authorea.com/, https://casetext.com/, https://www.sharelatex.com/, https://selectedpapers.net/, http://stacks.math.columbia.edu/, https://www.codalab.org/, https://pubpeer.com/, http://thinklab.com/publications

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

Jess: Let's have a hangout for sure!

This looks awesome! The comment part is particular enabling. I wonder if it's possible to build an open peer-review process on top of this.

Also, would be nice to have HTTPS given that it does have register/sign-in, etc.

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.

Check out https://www.codalab.org/ too. It's a more complete toolkit for reproducible computational research.

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.

So CS but you can either register or log in with twitter? Where is github oauth?

(Looks like there is an issue open so that's good: https://github.com/samim23/GitXiv/issues/3)

we´ll get to github login asap!

Awesome.

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.

Very nice, but IMHO too much of clutter. Why 3 abstracts?

Wouldn't it be better to have one abstract and leave arXiv abstract and GitHub abstract in their places (or import them)?

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 :)

cocs. right.

awesome!

Reply on news.ycombinator.com