The history, status, and future of RQC
History of the RQC initiative
Story told by
- 1997-12: When I receive my first article reviews as a young researcher
I learn that not every reviewer worked as thoroughly as
I would like. I understand that anonymous peer review has
a difficult incentive structure and in December 1997 decide to
do something about it:
I propose to two dozen journals that they should introduce a
"Reviewer of the Year" (RoY) award based on a concrete quality evaluation
of all reviews.
The 1997 proposal
features the same core dimensions of review
quality as RQC does today: timeliness, helpfulness for editor,
helpfulness for authors.
The (few) editors I talk to sort of like the general idea,
but say the bookkeeping for the process would be impractical.
One journal tells me they were picking up the idea, but nothing
happenes otherwise; I give up for the time being.
- 2006-06: I make another attempt with another journal. Again nothing.
- 2010-04: I make another attempt with another journal. Again nothing.
- 2010-07: I make another attempt with one of the 1997 journals.
Again some interest and discussion but no tangible effect.
- 2012-09: The German Science Ministry BMBF issues a request for
proposals on the topic of "Performance Evaluation in the Scientific System".
I submit a proposal (in 2012-11) aiming at implementing the RQC procedure
on a worldwide scale.
A lot of institutions support this proposal by sending a letter of interest:
- 6 of the largest scientific publishers in the world
(together representing more than 7300 journals),
- 9 research institutions as a whole,
- individual researchers
of another 25 research institutions from 14 countries (Brazil,
Canada, China, Finland, Germany, India, Italy, Netherlands, Norway,
Spain, Sweden, Switzerland, UK, USA).
- 2012-12: One of my many contacts during the proposal phase,
Fabio da Silva, asks me if I want to become Reviewer Awards Chair
at next year's EASE conference.
This prompts me to build a prototypical implementation of RQC for conferences,
- 2013-01: RQCconf goes online on 2013-01-12, has a surprisingly
successful run (with only one glitch),
and sends out the 48 first-ever RQC-style reviewing receipts on
- 2013-06: Despite the interest, the BMBF proposal gets rejected.
- 2013-10: I start several attempts to arrange a community-based funding
of RQC, but the required budget (of nearly EUR 500.000) is too large.
- 2014-03: I find an EU call for proposals (for rather large projects)
that has a component for which RQC fits very well. The call is due
in two weeks. I frantically search for a suitable consortium
and surprisingly even find it, but I am too late to get RQC in.
- 2014-05: I start working with Elsevier on their
"Reviewer Recognition Program" (RRP).
This was originally aiming at incentivizing the quantity of reviewing only,
but now they have become interested in picking up RQC ideas as well.
Elsevier is initially implementing the RRP in a pilot form with
only a few journals and intends to then roll it out more broadly:
first across the Elsevier universe and then across the whole publishing
industry (as a free service).
My attempts at making RRP pick up the full RQC idea fail, however.
Elsevier is going for a much simpler grading scheme.
- 2015-03: I finally decide that RQC is likely not going to happen
unless I build the software myself, so I decide to do just that,
starting with the version for conferences (RQCconf).
- 2016-03: My sabbatical starts and RQC software development picks
up a lot of speed.
However, my software development skills are not up-to-date and so
my knowledge of modern web development technologies, tools, and practices
is lacking everywhere and progress is a lot slower than
I would have thought.
But as I take a long-term perspective, I remain patient and the results
are satisfactory: Once something works, it works solidly and does
not deteriorate as work continues. Good.
- 2016-09-01: RQC goes online.
History of the RQC software implementation
Story told by
- 2012-12-01: Work on a rough RQCconf prototype starts.
I had already decided to build RQC in Python and now look which framework
to use: TurboGears and Django appear to be the strongest full-stack
Python web frameworks.
In one of the darker moments of my engineering life, I decide to use
TurboGears; a bad decision:
The TurboGears framework is OK, but the documentation is a mess;
Django is in fact about ten times stronger.
A quick search for the number of Google hits would have shown this,
but for some reason, I never do that.
I will struggle a lot more than necessary, but it will be alright.
- 2013-01-12: RQCconf goes online and is used for the EASE 2013 conference.
(It stays online until 2016, but I never try to find other users,
because this software was meant as a proof of concept only.)
- 2015-05: The first commits happen on the new implementation.
I had already decided in 2014-07 that the new implementation would
use Django so I start with that now.
I don't have much time, though, so it is going slooooowly:
3 commits in May, 5 in July, and not much faster after that...
- 2016-06: First deployment on a test machine.
Functionality for conferences only.
Some features are still missing, too.
- 2016-08-17: Start of RQC alpha test (with members of the
rqc-interest mailing list
- 2016-09-01: RQC goes online with complete basic functionality
- 2016-10-07: Corrected for a change in EasyChair URL structure.
- 2016-10-18: Corrected some more for changes in EasyChair URLs.
- 2016-10-19: Sandboxes can now be deleted, as can normal conferences
that do not yet have receipts.
- 2016-10-30: Adapted to EasyChair review tables format variability.
- 2016-10-30: Can now have a 2nd organizer for a conference-RQC.
- 2016-11-14: Can now cope with incomplete EasyChair subreviewer entries.
- 2016-11-15: Chair statusreport now sorted alphabetically.
- 2016-11-16: Clarified in email the handling of reviews submitted late.
- 2016-11-17: Explained how superchairs (of EasyChair multi-track conferences)
can determine a URL that actually works.
- 2016-11-22: Non-donated review texts now removed 100 days after end.
- 2016-11-23: Sandbox conferences now removed after 100 days.
- 2016-11-30: Corrected confusing grading status email when a co-reviewer
had opted out after you graded their reviews already.
- 2016-11-30: Emails now removed from database 100 days after end.
- 2016-12-01: Receipt percentiles now include opted-out reviewers.
- 2017-01-10: Adapted to the presence of an EasyChair navigation bar.
- 2017-04-04: Split RQC-creation into two steps so that the instructions
become easier to understand.
- 2017-04-11: Improvements to the guidance provided by the
conference RQC-creation form.
- 2017-07-18: My extension for the HotCRP conference
manuscript handling system is accepted by Eddie Kohler.
It adds a function to export all relevant reviewing data in a single
step and forms the basis for future RQC HotCRP support.
- 2017-09-07: Adapted to an EasyChair table format change
- 2017-12-20: New role-based 'Start' menu.
- 2018-01-16: RQC for conferences now also supports the
manuscript handling system.
- 2018-02-26: Better instructions for using RQC with
Easychair multitrack conferences.
- 2018-03-05: fixed a failure for the case when heuristic
firstname/lastname splitting gets it wrong for Easychair.
- 2018-04-03: made RQC robust against missing reviewer
firstname or lastname in Easychair.
- 2018-04-04: fixed failure when receipt creation encountered
- 2018-04-17: made RQC robust against additional columns on
submission detail page and against missing author email in Easychair.
Future of the RQC initiative
- RQC is probably going to spread only slowly for a while,
because conferences have sufficiently high relevance for
serious publishing only in computer science and a few other
- So the scope of the software implementation is the key
limiter currently and extending the software is the main
medium-term activity and goal.
See below for the plans in that regard.
- But once the software functionality for publishers and journals
becomes avaiable, some serious advertizing may lead to fast
spread of the idea.
In my experience, the RQC idea sharply splits reviewers into
two factions: Many think it's a very good idea, the others hate
it -- most often because they despise all forms of quantification
of their work.
Future of the RQC software implementation
Many small changes and improvements will be made to the software
frequently for a long time.
The larger pending improvement steps are the following, but
development capacity is small and irregular, so there are
no scheduled dates for any of this.
1. RQC manuscript handling system API
The main reason why RQC starts with conferences is that it is simpler:
- The workflow is simpler, not involving as many types of people and having
a compact and well-defined time frame.
- The availability of reviewing data is also simpler, because
RQC fetches the data from a conference management system
rather than relying on that system to send it.
This approach is not realistic for journals for various reasons.
For journals, the manuscript handling systems will need to tell RQC
what happens wrt reviewing so RQC can handle those episodes.
For that, RQC needs to provide an API (application programming interface),
a well-documented and publicly available set of operations that can
be called over the network via HTTP.
To make RQC available to journals,
the providers of the manuscript handling systems need to extend their
software to call the RQC API.
(Getting them to do that will likely be one of the most difficult
aspects of achieving large-scale RQC adoption.)
Such an API needs to be very well thought-out, because it cannot be
changed often -- the providers of the manuscript handling systems
would not like that.
Therefore, we will need a playground for trying it out and making
it sound and stable. This playground will be OJS,
an Open Source manuscript handling system used by many Open Access journals.
2. API trial phase
Next are a number of trial uses with journals using OJS
in order to validate and perfect the API.
3. RQC for journals and publishers
Only then does it make sense to actually roll out the API.
Until the providers of the manuscript handling systems have
implemented their use of the API, there is time to
build the remaining parts of the journal and publisher
4. RQC for research institutions
- Research institutions can register at RQC (with manual accreditation
- They can then create an arbitrary number of subunits and sub-subunits.
- Reviewers can assign the receipts they have received each to
one such research institution or subunit.
- Research institutions can download data about the receipts assigned
to them (essentially one record per receipt describing the quantitative
aspects of that receipt).
- Subunits can also download their parts of that data.
5. ...and then some
I already (as of mid-2016, before even the conference version of RQC
has launched) have a number of ideas of extensions of the core
functionality of RQC that will allow providing substantial additional
benefits. And I expect there will be more such ideas until
the core parts are complete.
Expect news about RQC for a long time.
If you would like to receive updates on the status of RQC
(12 messages per year max.),
subscribe to the mailing list.