Future plans - open-review/open-review GitHub Wiki

Version Beta (merge freeze) Release
0.11 2014-03-23 2014-03-25
0.12 2014-04-04 2014-04-07
0.13 2014-04-18 2014-04-21

Version 0.11:

  • Better frontpage design (issue #24) (postponed)
  • Ability to post reviews and comments (Related: issue #34)
  • Reviews / comments should allow for LaTeX and Markdown markup
  • Anonymous reviews (postponed) (issue #77)
  • Overview pages for 'top' papers pull request #38
  • Scrapers for automatic retrieval of additional paper attributes based on given user input
  • Accounts page showing users contributions, settings, etc (pull request #37).
  • Star like rating system for papers (DJOERD: high priority) (postponed)

Version 0.12

Version 0.13

  • New layout on all pages (may not be final, but at least on par with previous Bootstrap design)
  • Anonymous reviews (pull request #77)
  • Basic ordering algorithms
  • Option for user to remove its account
  • DJOERD: medium/high priority -- should this also delete anonymous reviews posted with this account: maybe not?
  • MARTIJN: We'll give the user an option to either a) delete all their contributions or b) keep them, but make them anonymous.
  • Search (at least at a paper level)
  • DJOERD: high priority
  • MARTIJN: Implementing Django Haystack. After implementation of haystack the features highlighting, spatial search and spelling suggestions could be implemented by different developers @WNoort.

Undetermined:

  • Test mobile version extensively + create Firefox OS manifest. (I'm just gonna go ahead and mark this as high priority before Djoerd does ;-))
  • Merge paper tool
  • DJOERD: medium priority -- I read this as: some way to avoid multiple papers in the system with different IDs? this feature needs some additional thinking. If we -- as always -- take reviews are leading, then you might want to assign a single review to 2 equal papers. This is then an indication that both papers should be merged??
  • MARTIJN: Exactly. We will postpone this discussion until we'll start implementing it. Changes are 'merging' of papers will be left to the users.
  • MARTIJN: Since we split up 'add paper' and 'add review' into separate pages, we plan to implement this as a simple search query to the current database. Openreview can ask the user "Did you mean paper X?", which (s)he can choose to ignore or accept.
  • Reputation for users
  • DJOERD: medium priority
  • Add user documentation for LaTeX and Markdown notation.
  • Users should be able to report reviews as spam
  • DJOERD: medium priority
  • Community should be able to edit paper fields, based on a voting system
  • DJOERD: low priority -- fields like title, authors, etc.?
  • MARTIJN: Yes.
  • Automatic verifying of a users status (PhD, Msc, etc.) based on e-mail addresses in known papers
  • DJOERD: low priority
  • Model which links author, paper and university.
  • DJOERD: I do not understand: a paper would be the only valid/possible link?
  • MARTIJN: It's a way of showing "$author <$university>" as authors can switch (i.e., write for) different universities in their academic career.
  • Revision control for papers (as they can be edited in a Wikipedia like manner, they can easily be 'trashed'. Other users should be able to reverse those actions.)
  • DJOERD: ??? - In stack overflow, only the original poster can change the paper... So, I would expect that only the person that added the paper can change it?
  • MARTIJN: This feature is about adding missing authors, etc. Reviews should not be able to be edited by non-owners indeed.